March 16th, 2010 Security Conference Call

Security Work Group Weekly Conference Call

Attendees

• Bernd Blobel Security Co-chair, absent
• Bill Braithwaite
• David Bruce
• Steven Connolly
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Rob Horn
• Don Jorgenson
• John Moehrke Security Co-chair
• Milan Petkovic
• Pat Pyette
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Tony Weida
• Craig Winter

Agenda

1. (05 min) Roll Call, Minutes from Security March 9, 2010, Minutes from CBCC March 9, 2010 & Call for Additional Agenda Items
2. REPORT OUTS
   • (10 min) PASS Audit update
   • (10 min) Privacy Policy Reference Catalog update
   • (5 min) Security and Privacy Ontology project
3. ACTIVE PROJECTS
4. (90 min) Harmonized Privacy and Security DAM Peer Review

Minutes

1. Action Items

1. Pat: Circle back with Richard and Suzanne (CBBC Co-Chairs) regarding next steps related to the scope statement

2. Resolutions

See discussion within each comment below in bold

3. Updates/Discussion

PASS Audit update

• It was agreed during Monday’s PASS Conference Call (3/15/2010) that we will call out DICOM Supplement 95 and IHE ATNA as done from an audit perspective
• We will focus our attention on a service capability to support (not perform) disclosure accounting – to extract the audit information necessary to produce accounting of disclosure reports
• It is somewhat touch and go in terms of what we can reasonably deliver for the May ballot but we will try to deliver something useful. Otherwise we’ll postpone for a future ballot cycle

Privacy Policy Reference Catalog

• Nothing to report at this time
• Pat needs to circle back with Richard and Suzanne (CBBC Co-Chairs) regarding next steps related to the scope statement

Security and Privacy Ontology project

• Last week, Mike met with Cecil Lynch and the ArB in a special meeting to answer their questions related to the scope statement
• Cecil reported to the Security List that the ArB approved the scope statement from their perspective following that meeting
• Not clear what the next step is. The TSC needs to approve as well, and the plan is to meet with the TSC next Monday (3/22) and then with the Security Steering Division on the following Tuesday (3/23). It appears that we’re about to get an official approval for this project and we’ll be able to start work
• Also met with Ken Rubin (SOA co-chair) to discuss a common set of tools for the project. There are a couple of options, and we will review with Russ Hamm (Vocabulary co-chair) & involve Cecil Lynch as well. It is important to establish a common tool for HL7
  • Protégé: supports OWL – ontology language
  • IHTSDO Workbench – does not support OWLs
• OWL is widely recognized including by the W3C
• OWL/Protégé is available free
• RBAC Permission Catalog already has a version in OWL
• It is expected that this project will be officially approved by our next Security WG meeting

Harmonized Privacy and Security DAM Peer Review

Comments submitted in response to the first peer review draft were consolidated into a single table. Ioana addressed each comment and added a response in the disposition column

• Dispositions to the comments were marked Accepted, Rejected, Answered or Clarification Required. Today's meeting focused on those comments that were not marked Accepted. It is assumed that interested parties will review the entire list of comments off line. This provides an opportunity to raise questions at next week’s meeting should there be any discrepancy of opinion about the Accepted dispositions
• Milan Petkovic comments: These were reviewed in last week’s meeting.
  • Comment #1: Milan suggested adding a single diagram that includes all the classes (Privacy and Security) to the document.
    • A version of the unified class diagram will be included the next version of the harmonized Security and Privacy DAM
    • The Privacy use cases will also be restored to the harmonized DAM
    • Examples will be included to demonstrate how the information model supports Consent Directives as well (from the Composite Privacy DAM)
  • All other comments submitted by Milan were accepted
• John Moehrke comments:
  • Comments #4 & #5: “Can we not use the more internationally friendly Protected-Information (PI)” instead of IIHI; This is a very USA specific term... This comment generated considerable discussion. The term IIHI was chosen following lengthy debate during the development of the Composite Privacy DAM. Ioana argued that changing to a new term (PI) would create confusion and for the purposes of backward compatibility with the Privacy DAM, we should probably stick with IIHI
    • Rob Horn presented the argument that using IIHI (where “H” is specific to health care) creates a situation that presents a barrier for use in Europe where privacy concerns are across the board and not specific to health care information; therefore PI is more palatable and makes this a more acceptable, international model
    • Rob McClure raised the fact that in the past, Richard Thoreson has argued that we’re not talking only about protected health information, but safety-net information as well
    • Mike agreed Protected Information is more usable, but we can leave the terms IIHI and PHI in the document and define that these are a subset of PI
    • PI is a broader term that includes financial data and the concern is that financial data could be considered out of scope if we refer to IIHI
    • Bill Braithwaite suggested that we go back to the European Union definition of PI to make sure we are reflecting their intent, and he will check this. Milan agreed and said that he thinks the EU is talking about Personal Information as opposed to Protected Information.
    • Mike: the security view, devoid of input from a domain like finance or health care, would say we protect information at a high level. Recognizing that this is a privacy and security harmonization effort related , and privacy has a special role here, we can select a number of terms that apply to different jurisdictions. We’ve defined protected information (PI) that includes IIHI and PHI
    • Protected Information (PI) will be added to the glossary reflecting this conversation
    • Pat: In Canada, when we refer to PHI, we mean Personal Health Information, as opposed to Protected Health Information, so Mike’s comment that we can select a number of terms that apply to different jurisdictions supports these differences
    • Mike: There was a table that we created (Pat & Mike) that harmonized these terms across several domains. This table was also presented to HITSP
  • Comment #8: Discussion around this comment resulted in changing the model with respect to two classes: Role (that has an attribute: StructuralRoleCode) and FunctionalRole (that has an attribute: FunctionalRoleCode). These classes were in the Composite Privacy DAM. John and Mike had similar comments (and Mike provided a modified diagram to reflect this, included in the consolidated Peer Review comment document) which suggests that we have only one class called Role that is both structural and functional.
    • Mike has been trying to get rid of this distinction for a long time. A role is a role, whether it is a structural or functional role, or whether there is a hierarchical relationship between them. For the purposes of the class, we have the notation of a role and all roles have actions on protected objects. They are different at different levels. Structural roles: things like CanAccessHealthcareApplication instead of CanCreateOrder. They’re still roles. Bernd sees some hierarchical relationship between structural and functional roles that perhaps an ontology might reveal. But for the purposes of a class diagram, we can have Role and one type of role is structural role and another type is functional role. Sometime in the future, someone may define another type of role. We have Organizational Role, but these are typically not Security-relevant, but they might be. The more general approach, without trying to name a particular type of role seems appropriate here.
    • John: for this level of abstraction, we shouldn’t get too far into the morass. But the first thing we should address is that the term Role is overloaded, at least within the HL7 domain. We should qualify the term Role.
    • The group agreed to changing the model so that we have a single Role class, and that the class name will be renamed to SecurityRole for clarity.
    • All roles will reference Permissions – they point to 0…* permissions. They also have to be self-referential, meaning a SecurityRole can point to other SecurityRoles.
    • The primary attributes for this class are: (this is not the exhaustive list of attributes, but those that are critical to this model)
      • unique id II, (for this instance of the object created from this class. This attribute is included in most of the classes within the model)
      • name EN,
      • type (functional, organizational, structural),
      • code CodedDescriptor-CD(coded concept for role ASTM, SNOMED-CT)
    • A question was raised, can you put these data types in as attributes or do they need to be elements or does it matter at this level?
      • Data types are the types of these attributes and they already are included in the model
      • For example, within the class OperationType ActionOperation enumeration is the type of the attribute operationCode, these enumerations are defined in section 4 of the document; string is the type for the attribute name; there could also be a specific HL7 V3 data type associated with an attribute
  • Comment #22: Ioana walked through the relationships between the Security and Privacy classes related to CompositionPolicy
    • John: When you compose policies, you need to explain the relationship between the composed policies, e.g., do all three have to return "Accept" for access to be granted, or only one? How do I combine the policies, what is the logic? One way to resolve question is to add attributes that explain the policy combining mechanism. Getting down to the concrete, XACML has mechanisms that flag whether all must meet, or first met, or all no negatives.
    • Mike: I’m not reading the model like that. When I think of the combinatorial policy, I agree, you have policies from two different sets that are going to be used to make a decision. But we don’t have to specify the algorithm. When you get done, they’re combined. The evaluation is against the combined policy. If you have a jurisdictional privacy policy and a patient’s privacy policy, you have to combine them by whatever rules there are to get to a decision.
    • Ioana: The logic is in the policy language used to implement the policies. This is at a higher level.
    • John: Then a CompositionPolicy itself has policy rules. Currently the model currently is nothing but a pointer from 1..n policies.
      • After walking through the model in discussing this issue, the group agreed with John that adding definitions for relationships as well as definitions for the classes and attributes of the model will clarify the understanding of the model.
    • Mike: It's important that we get this correct. There are numerous shared classes between the Security and Privacy models that affect how Privacy is described on either side. There’s a Security ConstraintPolicy and Privacy ConstraintPolicy (this was presented in Vancouver many months ago). A Lot of the privacy policy is composed in the security policy through the ConstraintPolicy. That is the binding class between security and privacy for much of the policy composition. The rest of it is accomplished through shared classes.
    • John: It would be good to paraphrase Mike’s statement above and include it in the document as well.
    • Rob McClure: Exactly how this happens is still unclear. This is where good examples would help.
    • Steve: One of Bernd’s comments referenced this: A policy can be constrained in terms of profiles for tailoring a policy instance.
    • Ioana: Point of clarification. We’re talking about CompositionPolicy, not ConstraintPolicy
    • Steve: It falls into the same issue. The idea is that we put all constraints in one class called ConstraintPolicy and that’s combined into CompositionPolicy. But in fact, the entire model is a constraint. By putting constraints into one class – every policy is a constraint.
    • Mike: A concrete example of two way of looking at it: the Security domain policy is that dermatologists can see all health care records including psychiatric notes. The patient says, I don’t want my dermatologist to see my psychiatric notes. That’s a constraint, and it constrains the Security policy. So the combined policy that gets evaluated includes the patient’s consent directive. Constraint policy is just a policy – it can be positive or negative. The patient can say I authorize release of my information to another provider (a positive constraint). The organization’s policy may be to deny release of information without the patient’s authorization. So the combination of the positive constraint with the organizational Security and Privacy policy to create a CompositionPolicy.
    • Rob McClure: There is an initial policy (based on Security policy) and then everything applied against that, you’re calling a constraint.
    • Mike: The constraint also applies to organizational and jurisdictional policies as well. There is also further combining of these policies. They are combined by hierarchical relationships between policies, and also by policy sets. Policies are grouped into sets. For a particular decision, you are not dealing with a single policy. You first combine the policies into individual policies, and then you group them into whole policy sets that apply, the higher level policy.
    • Milan: in Mike’s example, there is an assumption that the patient’s constraint has a higher priority than the organizational policy. Do we want to capture this priority?
    • Mike: If you look at the SOA Access Control models, there is a reference information model that says patients initially create a policy, but there is an iteration with the organization’s management, and eventually there is a policy that is accepted by both the patient and organization. This is the official policy. When that policy is sent to the Security people that they’ve already implemented the dominance relationships when the policy was created or there may be IF statements that provide some alternative pathways. But those decisions are incorporated into the CompositionPolicy creation. This is the Security and Privacy management function.
    • In addition to adding definitions for the relationships between classes in the document, an attribute to refer to the policy combing algorithm will be added to CompositionPolicy. An attribute (an identifier for the combinatory rule, or some way to say there is something there)
  • Comment #33: ConstraintPolicy class - systemStatus attribute
    • John: Why is this an attribute that only shows up in ConstraintPolicy? This is generally an operational attribute that refers to an entire system state whether you’re in a test mode, or operational mode. This has implications for which access control policy set is instantiated when the system is booted up.
    • Mike: this attribute would apply to the whole policy
    • John: It would have to be in a class above anything that is currently in the model
    • Ioana: ConstraintPolicy inherits from BasicPolicy and CompositionPolicy inherits from Policy, this is the only reason for having two base classes for these concrete classes (RefrainPolicy, DelegationPolicy, AuthorizationPolicy, ObligationPolicy ). it is a useful attribute to have, but it is not specific to CompositionPolicy
    • Mike: Until we have a more thoughtful discussion, my recommendation is that we assume that the policy we’re describing means that the system status is in normal operation in a secure state
    • John: It is not an attribute of anything that we currently have. We can bring it in later on when we’re addressing this st of policies is for run time, this set is for test mode, but this is not something that is in the current use cases. Our use cases assume we’re in normal operational mode.
    • Ioana: we will remove the attribute from ConstraintPolicy and enter this issue in tracker to re-visit in the next iteration of the model
  • Comment #38: RefrainPolicy class (following discussion, it was agreed that the disposition Rejected for this comment was acceptable)
    • John questioned why we needed four separate classes in the model
    • Ioana: These classes have been included to align to ISO 22600. From analysis standpoint, if you put something as a type, you lose the visibility. As a communication tool, it is better to spell out that you have four different kinds of specializations than to have a value set called policy type that has four values that never change.
    • John: if we’re going to have a RefrainPolicy than we need an AcceptPolicy
    • Ioana: AuthorizationPolicy with the flag “enabled=true” is the AcceptPolicy. Enabled=false is not the same as Refrain. RefrainPolicy explicitly prohibits an action whereas Authorization/enabled=false doesn’t allow an action. There is a difference: prohibition, allow/disallow (AuthorizationPolicy. There are some implementation languages that will not support RefrainPolicy, simply because they cannot distinguish between a lack of authorization and a prohibition, so I agree with John this is challenging. We are merely reflecting the ISO 22600 specification. We will elaborate on AuthorizationPolicy and RefrainPolicy in the document to clarify
      • These classes may have different behaviors (RefrainPolicy versus ObligationPolicy for example), which support the need for defining separate classes. This is actually making a conceptual distinction, rather than a practical implementation distinction
  • Comment #46: Authority
    • John: wouldn’t domain be a base policy attribute? Doesn’t the base policy have to point to the authority
    • Ioana: It does, via an association. All policies inherit the association to Authority
    • John: So this is another case where relationships need to be explained in the document
      • This led to different opinions on whether a web publication of the model would improve communication (where you could however over a class, relationship, attribute to get further explanation). John feels that the diagram should assist the text and not the other way around. To rely on the diagram as self documentation is not appropriate. If we were using hyperlinked documentation models, then perhaps yes
  • Comment #48: ClinicalCondition
    • Ioana: ClinicalCondition could be associated with a piece of information, and could be used to compute access control rules.
    • Rob McClure: When you create a policy it is created on a series of things. One is role, another is the clinical condition.
    • John: defining this is an unsolvable set.
    • Mike: You are correct that this is not possible. When we talk about sensitivity, we’re talking about the labeling of information with a sensitivity label. That is a concrete thing that a security system can react to. The system does not perform any kind of analysis (inferring that something exists because of a number of things). Any references to these sensitivities has be n understood to be data that is explicitly labeled with those sensitivities.
    • Rob: If you clarify that it has been labeled, that helps. Because then you’re limiting things to stuff you can label.
    • John: Someone has made a decision (labeled). We pick it up from there
    • Ioana: We’re assuming when you ask for a specific test because you are investigating HIV, you have the information itself. I think what could clarify this is to say that it is the health condition associated with the information itself. That association is built into how that health information is collected, it is an attribute of that health information; it is not inferred by the security system
    • Rob McClure: the problem with saying that something is labeled is a little too restrictive. It may be the piece of information rather than a label that is used that is available and that’s where the potential to use ClinicalCondition may come in. If you put a Condition in there and that’s visible to machinery outside the protected sphere (meta-data) than obviously it’s not protected anymore
    • Ioana: The definition for ClinicalCondition will be changed to “The health condition(s) associated with the information”.
      • But it’s OK to have a policy that says, we protect HIV information. It doesn’t disclose any information. How this is implemented is out of scope.
    • Rob McClure: The issue of the linking of what people expect when creating a policy and then how that gets actualized inside a system, there is still a gap. The fact that we have ClinicalConditions that are the heart of what most people what to control when accessing their medical records. The thing about this clinical piece is that it has to be hidden in a different place than all the other attributes to these policies.
    • John: This is the stickiest thing we have to deal with. People tend to gravitate towards the clinical condition vocabularies because it’s something tangible that is already available today. But it’s not the right mechanism for communicating this.
    • Ioana: right now this is implemented in Canada using only the category type.
    • Rob Horn: It’s implemented with very coarse on/off controls, i.e., clinician, non-clinician
  • Comment #58: default value=Progess Note for InformationObject
    • The default value will be removed, since there are no default values defined for any other attributes within any other classes
• Steve Connolly Comments:
  • Comment #6: ConstraintCatalog
    • Steve asked for a class diagram describing the RBAC as an example. What is not represented in Figure 1.3 is the constraint catalog, the constraints that are contained in the constraint catalog
    • Ioana: Are you suggesting that we have another catalog called the ConstraintCatalog that is referencing Permissions? Or another class that has different attributes?
    • Steve: There is within the RBAC ballot, a constraint catalog – cardinality, time dependency, separation of duties
    • Ioana: Do I need to add the class ConstraintCatalog from the HL7 RBAC Spec?
    • Mike: No, we already have a constraint catalog in the model.
    • Steve: Perhaps I should show you in a diagram what I mean.
    • Mike:The thing we have called a ConstraintPolicy is captured in what the RBAC people would call a constraint catalog. It’s a table of these constraint policies. And the constraint policies can be organizational, jurisdictional or patient policies. But the RBAC is focused specifically on the types of constraints that Steve was referring to. There is no need to build a relationship for these classes for specific use.
    • Ioana: Steve, you may be thinking about our discussion about linking the security with the privacy point of view. We’ve already addressed this in the diagram.
    • Rob McClure: So does that mean that the things that are in the current constraint catalog don’t apply? The elements that are in the constraint policy aren’t represented here so they don’t apply?
    • Ioana: No the ConstraintPolicy is represented here, but what we’re grasping for here is, what is the link between a consent directive and a security policy. And in this context, the consent directive realizes the ConstraintPolicy. And the constraint catalog is nothing more than a catalog of ConstraintPolicies.
    • Rob McClure: If you look at the constraint catalog, the attributes that are in there don’t line up. I think that is what Steve is saying
    • Mike: I understood that the attributes of these classes are for example only. For the ontology work, we need to make them more concrete and justifiable.
    • Ioana: they aren’t examples really, they are the most significant ones.
    • Mike: I don’t know what basis you have for saying that, it is opinion.
    • Ioana: Yes, in the opinion of the stakeholders, here are the most important attributes of a specific conceptual object, like a Policy
    • Mike: It’s all ad hoc. There are existing standards which have been identified which are international which specifically characterize these classes; we haven’t used that approach. We’ve just put in whatever feels good. We haven’t looked at existing standards to see if they actually inform these policy classes
    • Ioana; We’ve used ISO 22600 and other standards to inform the definitions
    • Mike: Then you need to reference the standards in the description of the classes to indicate which standard the attributes come from
    • Ioana: Which attributes do you feel have not been defined sufficiently?
    • Mike: At this point, I am not concerned about it. But as part of the ontology effort, I want to revisit these attributes to create a more structured approach. We need a very clear definition of where these things come from, if there isn’t a standard we can cite that will define the classes, we have to clearly identify it as such.
    • Ioana: There are two sources for these attributes. The requirements and alignment with the standards. Some standards don’t care who is the subject of the record and whether they are a patient or a population, and they will be silent on that subject
    • Mike: Yes, true. But we have to go through each one of the classes and determine if a standard would apply or not. And if it does, what it would be and if there isn’t one, and there is a need, maybe there’s a gap. In Purpose Of Use (POU), ISO is working on that standard. Some of these things are in progress, or they haven’t been harmonized across different domains.
    • Ioana: This is not an implementation model. We need to have POU as a coded concept, but we’re not standardizing it here. We’re defining the attribute and where it comes into play when you’re declaring a policy. This is not the purpose of this analysis model. If ISO is working on it, an implementer can use the ISO standard, or the OASIS WS-Trust value set or the SAML value set.
    • Mike: We do not have sufficient rigor in the definition of these attributes and we need to spend some effort to develop this. The first effort can’t be to sit down on a 50 minute telephone call and define these attributes in an ad hoc manner
    • Ioana: I don’t think anyone has suggested this. The peer review is designed to identify specific attributes that are problematic. Some of these attributes were already defined in the Composite Privacy DAM. I can explicitly reference the DSTU for every attribute that comes from the Privacy domain analysis model and also add references to the other standards that reference the same concept. Would that be useful?
    • Mike: It would be useful to have a structured process to go back and look at the models and have a structure process to provide a mechanism for asserting the validity of the attributes explicitly. I’m looking for a structured process that we can use and that somebody else could use to validate that we got the right answer, or understand where we got the information from. I want to be very explicit about it. I’m OK with the model right now because we never applied that rigor and I’m not suggesting that we do it at this point. I’m not overly concerned about it, this is a big brush thing. As we discuss in more detail how these different classes interact together, we may find that we’ve missed attributes. Does anyone else share my concerns? I’m concerned that we don’t have a rigorous process, but for now, it’s fine. I know that I’ve given you some ISO standards that contain at least a standardized description of what one of those classes would contain in terms of attributes. I’m not proposing any action
    • John: I agree with you and that’s where a lot of my comments come from. We either need to explain what these things are or don’t put them in here. I’m worried that the existence of them being in here will later be perceived as having been something far more rigorous than we have today. That’s why I’m commenting they way I am commenting. And I would prefer that this be thinner and thinner unless we give them the appropriate rigor.
    • Mike: We are agreed. It’s an action for on-going work. If we keep the notion that what we have is either directly reference-able because it comes out of...
      • We can say that we got there because it was in a use case. But how do I know that the use cases completely describe all uses of that class, and therefore all the potential attributes for that class?
    • Rob McClure: Mike, you’ve referenced ISO a lot. What is it that wherever a more rigorous approach is taken, what it is that they are doing that is different from building use cases, building a model and then having it discussed? I’ve been on some ISO calls and I don’t see a distinction between what they’re doing and what we’re doing. I’m not disagreeing that there needs to be rigor and that there has to be alignment of proposed model elements defined where they come from other standards. But what is it that you’re proposing should happen?
    • Mike: A lot of the classes here are represented by ISO 10181-3 (Access Control). I did that with purpose of forethought to make sure that we covered that standard, and that is one of the referenced standards. (PMAC is another, ISO 22600). A lot of these classes can be traced to some reference. For example, Obligation didn’t at one time have a reference anywhere. It was a reference to an OASIS concept of obligation. I think it’s an ITU standard now. I think they’ve moved SAML and XACML into ITU status. So there’s a reference there in ITU for where obligation comes from. We’re now harmonizing these class and policy concepts and we need to explicitly say where they come from. Then you can go back to that body of work to see how they’ve defined it and what its use is. So going forward, we are able to say where these things came from in our model, it’s not just that we were sitting around drinking cokes and smoking cigarettes.
    • Rob McClure: It’s a chicken and egg thing. Let’s be honest, speaking of smoking cigarettes and drinking something, that’s how the ISO stuff gets started. But I understand you want rigor, but ISO starts with a bunch of guys and gals sitting around trying to figure out the right thing to do
    • Mike: All I’m saying is that we should be clear as to which classes and attributes come from our smoke session versus someone else’s.
    • Steve: That’s why I brought up the RBAC. Because we’ve been involved with RBAC and it was represented at one time in the Security DAM and I felt that was an accessible and convenient use case. If it’s not possible to represent RBAC in this model...
    • Mike: It is, I’m comfortable with that.

John: We’ve gone long beyond today’s call, but we will continue these discussions.

• Mike: For John’s purposes, yes, it’s a little loose, but it’s where we are and how we’ve put it together so far. Going forward, we will take a more structured approach to defining these attributes. But let’s not try to do that now. We’re not quite there yet. It will be part of our next step, for the ontology where we’ll have to have these structured attributes.
• Suzanne: Next week, will we continue this discussion?
• Mike: We have more comments to deal with, so yes.
• Suzanne: So for next week’s agenda we will plan to continue the conversation for the entire two hours
• Mike: I haven’t heard a lot of discussion from the Privacy people and we’re trying to get this to a ballot in May. I’m a little concerned to the amount of discussion we’re having here. There is still a lot of work to be done to move this forward to make sure that everyone agrees to what we’re doing to get this to a May ballot. I'm a little concerned about where are we as a group. We’ll have to see the next version and the new models that have been proposed so the group can review to ensure that everyone agrees. We need to continue the review, but I don’t know whether we need more calls, or whether this is good enough.
• Ioana: Mike, to get back to your point, it’s very trivial to link these attributes to an approved standard, so we’ll do that.

The meeting adjourned at 3:30 PM EDT

No significant motions or decisions were made