Proposed Health Care Security and Privacy Classification System Ballot

1. Proposed Health Care Security and Privacy Classification System Ballot Kathleen Connor VA (ESC) Rosenthal markup – just my opinions June 12, 2012

2. Foundations for my comments • Take a broad view from the start: extensibility and flexibility cannot be retrofit • We do not want separate control systems for emergency (and limits on emergency), for payment, research, quality control, …. So word everything under the assumption that there are many purposes. Then focus examples and drill down on “normal treatment” • Exception mechanisms are also in scope, e.g., really need a consult from a doctor who does not have his secure system at his dinner restaurant. • I haven’t reread your Purpose taxonomy recently. Need to do so. • When making design choices, try to avoid an assumption “some other system handles this” • Avoid this circularity: Scope to be solvable by particular mechanisms Alternative mechanisms are out of scope • Be cautious in adopting ideas from the Defense markings • They have had much careful thought, but also suffer much from legacy practices, paper documents, and multiple separate networks • They are not a success at enabling rich information sharing • Clearance is a poor metaphor for Health. Social workers often see the most sensitive info.. Surgeons may have less need. • Test any scheme to see how well it handles changes in patient wishes or government policy My comments are green, or red for strong points

3. My general assessment • “Clearance” attributes in health seem useful for describing certified systems (esp. if only a few levels are used, and exceptions can be made). Work poorly for people’s access Tags have three aspects below, two of which are very beneficial • Descriptive: Tags provide information useful for many purposes, including security (standard should address) • Some will be defined and governed by security committee, some governed elsewhere but adopted by us. • Vocabularies and orderings are useful for access control, protection, search, statistics,… • Tags should be sticky – go with the data, to support future handling decisions • Facilitation/convenience:Frequently, a patient or organizational policy will include a term of the form DataItem.Attrib ≤ X.Attrib (where X refers to a person, organization, or system. (can these all be sessionattribs?). User interfaces should make these convenient to include in rules (implementation advice, not std) • Encourage using only those adopted into security standards. Do allow for local extensions, e.g., an HIE might offer additional ALLOW rules for those who possess certain attributes • Automatically become rule conjuncts. Too prescriptive, e.g., inapplicable to emergencies.

4. Health Care Security and Privacy Classification System - Status • HL7 Security and CBCC Confidentiality Code Refactoring Project 798 provides for an opportunity to ballot outcomes from the project • The project’s multiple Privacy and Security Vocabulary proposals have been approved in Harmonization process • A few technical corrections and augmentations are in play for July Harmonization

5. Outcome of Project • HL7 Privacy and Security Vocabulary restructuring and participation in ONC Data Segmentation for Privacy Project have led to realization that this vocabulary is the healthcare analog to the Classification and Control Marking Systems utilized by other industries • Balloting HL7 Healthcare Classification and Control Marking System guidance culminates that project and provides alignment with industry practices

6. Purpose and Scope • This paper describes a Health Care Security and Privacy Classification System suitable for automated “tagging” and segmentation of protected health care information for security and privacy logical access purposes. • Information classification provides the means to apply information about information (information metadata) so that rights of access can be established, and access control decisions can be made  at each layer of security services. We want also to help with other decisions (retention, protection, …) • This includes access control governing access by intermediaries such as health information exchanges, health information service providers, clearinghouses, and gateways; and access and use by end users within the Receiver’s System. <I like the inclusiveness. >> • Support receiver’s efforts to establish suitable controls , even beyond required • This applies to Access Control on the payload by an enterprise ACS as well as controlling access to metadata appropriate to transport, security, and business envelopes, as well as payload metadata (e.g., in a federated Registry).

7. Context for metadata tagging (??? How mature is this in the HL7 world? Is security/privacy ahead of the curve, or can it rely on stuff?? This context should let us put issues at the right level) • Metadata tagging is a fundamental info mgt issue, going far beyond security/privacy. It includes • Representations for attaching metadata to chunks of data. (Also tells what kinds of chunks are supported, and how attached) • Vocabularies and formats (schema, meaning, codesets) for the metadata – just like ordinary data • Separation of concerns: client does not know how it is physically represented. Tagger knows the meaning but not all future uses • Incentives and processes to attach the metadata • Policies can derive additional tags • Implementers can decide if it’s done in advance or at request time. Often it depends on whether the tags will need to change • Metadata is data; it too can have metadata (including privacy tags) • Security and privacy groups define meaning of some attributes, define “standard” vocabulary for use in policies, provide incentives • Local extensions and versioning should be facilitated • Much metadata relevant to security/privacy will be supplied by or shared with other processes. This improves quality, saves $$

8. Description of Use (first half) • The health care security and privacy classification and control marking metadata is used to classify (“tag”) protected health information with security and privacy attributes in accordance with jurisdictional, organizational and individual needs to identify and segment specific categories of information so that access control rules can be applied. • Users requiring access to this information are given corresponding attributes, which define their “entitlement” with respect for the informationComparison of attribute vectors defines a useful rule language pattern, but it should not be THE rule language. Other things to say: Patient might say “for data in {STD, substance abuse} require that person be affiliated with MyFavoriteFreeClinic”. These free-clinicians might not have STD attribute, it’s the affiliation that mattes. Another predicate might be geographic conditions (must practice near my home town). The ruleset also probably needs to be conditional on purpose, e.g., for emergency treatment, ruleset1. For research, ruleset2. For normal treatment, ruleset3? Notes pages discuss constructs for the language. • A positive access control decision is made when the attributes possessed by the requestor are equal to or greater than the attribute tags on the protected informationShould depend on purpose of the request. May be very different for research, payment, normal treatment, urgent treatment, emergency

9. Description of Use (second half) • Control markings add additional security and privacy related Obligations (mandated actions) and Refrain policies (prohibitions such as Intelligence Community “dissemination control markings”).Do we create these at the time of record creation? How to they change if State or Patient changes their mind? Better to stick to descriptive markings (which can give shades of meaning), and have editable rules that determine the effect. • General principles: • “Do not redisclose” is very uninformative, will not lead to good handling. • “Has unspecified sensitive stuff” is better, and might be coupled with rules: • Deny if purpose is in {normal treatment, research} • Allow if purpose is emergency treatment • Try to tag the disclosed data with enough stuff to enable compliance with currently applicable rules plus rules patients or others are likely to apply in the future. Tags are valuable. If recipient is able to, they should retain.

10. Classification System Components Based on the Intelligence Community use of “Classification” metadata, HL7 has developed seven levels of the core classification metadata “Confidentiality” for application to healthcare information: • Unrestricted, low, moderate, normal, restricted and very restricted • Each level of classification indicates an increasing degree of risk for malicious unauthorized <see notes> accessto increasingly sensitive information It hardwires a tag to both the bullet above and the treatment below. I agree that the tag should be present, but I treat it as informational, fodder for policies but not necessarily determining. I believe it will do more harm than good. Issue for discussion: Should levels drive a system partition. In the US government, each security level gets a separate system and network. It’s plausible to have two databases but probably not two networks. Six separate ones seems implausible. . Conclusion: It’s probably better to tag within one system, and use software to mask high levels. Issue: If you create two separate environments with no “virtual” combined environment, it’s likely to break applications that cannot do access across the boundaries, most often because the software breaks, sometimes for lack of permissions. E.g., an alerting application written to be unaware of partitioning might fail to work on restricted data. • Thus, if a security principal is one holds restricted level of authorization to access information with confidentiality level of restricted, one that principal is allowed to handle information up to the confidentiality levels of unrestricted, low, moderate, normal, and restricted, but of restricted, including normal, medium and low information. If one holds a restricted level of authorization, one may not handle very restricted information, which is a (higher level of confidentiality than restricted.), but may handle information classified restricted and lower. Issue above: for what security principles might we assign levels? For principal =session, it seems quite helpful. But don’t give clearances to humans – just put gatekeepers on giving a clearance attribute to a session. Consider an addict who trusts his social worker more than he trusts the emergency room that functions as his PCP. Does that mean his social worker needs higher clearance than the trauma surgeon? Applicable to other patients too? • In accordance with the Intelligence Community use of “Classification”, there can only be one “high watermark” Classification value for a given information resource, which is the most restrictive classification, although some subparts may be marked with less restrictive classifications.

11. Subordinate Classification Metadata (first half, split for space) • Having “eligibility for entitlement” toinformation tagged with core classification attributes such as “restricted” does not necessarily allow one to view all restricted <see notes> • Data classification categories are further sub-divided on the basis of specific fine-grained tagged data attributes applied to the information and the operations possible on it <make this purely descriptive> • Information categories are defined by operation-data pairs (permissions) such as create, read, update, delete and execute applied to any available information object <see notes> • Some rules require that The user of the information must establish, in addition to the authorization level necessary for the sensitivity of the informationrequested, a specific entitlement for access by possession of a credential equivalent or dominating the information tagged attribute. < Once again, it’s a good construct for building rules but should not be foundational, supplementing all rules. Will you allow Patient to grant Restricted rights? I may trust my social worker and my PCP, but not the surgery department head (who may have said publicly that all clinicians in the system should have access to therapy notes).

12. Subordinate Classification Metadata (second half, split for space) • For example, clinicians who are part of a patient’s health care team may be allowed to see information on a specific patient while other clinicians, not part of the team, may not, even though they all have the same rights to information marked “restricted” and below • Without the ability to assert the additional subordinate classification metadata, access is not allowed to this type of information • The situation is analogous to the situation in a movie theater. • No rights are required to park in “free” public parking. However, a ticket holder is required to enter the theater and access the lobby and its services (normal access) • A different ticket attribute would be required to visit the projection room (restricted access) or perhaps to sit in special area other than the theater (box office seat) • The movie name printed on the ticket allows access to “view” a specific movie, but no others • Access is controlled by checkpoints and ushers • Subordinate classification metadata is equivalent to the attributes of the specific movie printed on the ticket For the next two bullets: They’re good requirements, but it’s better to meet them by constructs included within specific rules.

13. Categories that are not classifications (Compartments)(ActPrivacyPolicyType (and subordinates)) • <Nit: When I see the word ‘classify’ as categorize in this brief, I confuse it with military classification. Tags “categorize” or “describe”. Some rules or rulesets draw military-style orderings, some don’t. Descriptive tagging (from ordered and partially ordered sets) has useful analogs for sensitivity and topic And dissemination is better handled on the policy side (for classes of documents), not via document tags. • There are information compartments, defined by coding systems, which pertain to specific projects and are used to more easily manage which individuals require certain access to these projects (Once one has a descriptive tag, the “compartment” concept adds little). • Code words are not levels of classification themselves, but a person working on a project may have the code word for that project added to his file, and then will be given access to the relevant documents • For example, persons working on a research project for “Agent Orange” may possess the access category “Agent Orange” • Other examples include records for “Very Important Persons” (VIP) or employee records of the health care organization

14. Dissemination Control Handling Caveats(ActSecurityPolicy/ ActRefrainPolicy) • The Healthcare Classification System also classifies restrictive caveats that can be added to an information artifact • These may include (in the abbreviated form) a requirement that the document not be shared in specific ways such as with a specific individual, role or not leave a specific room • These restrictions are not classifications in and of themselves; rather, they restrict the dissemination of information within those who have the appropriate clearance level and possibly the need to know the information • Remarks such as "Pharmacy Personnel Only" also limit the restriction. • Handling caveats describe “rules” for access independent of authorizations possessed by the recipient • For ease of use, caveats and abbreviations can be included within the summary classification marking (header/footer) or on an outer wrapper or “envelope” to enable the restrictions to be identified at a glance. • Note that handling caveats do not describe metadata about the information (no assumptions or inferences regarding information sensitivity can be made). • Handling caveats may also provide a useful way to transmit conditions that apply to opening and accessing information inside the outer wrapper • In this case, information has been provided in response to a request and determination of a positive access control decision • The handling rule, however, requires that the recipient agree to additional terms of use as a condition or “obligation”. The act of opening the wrapper (“breaking the seal”) is understood agreement to the conditions expressed in the handling caveat

15. Balloting Timelines The Ballot Schedule outlines the 5-week Ballot Countdown Schedule indicating important deadline dates for all ballot-able submissions.  For the September 2012 Ballot Cycle, the next deadline is the Notification of Intent to Ballot Form deadline on Sunday, June 24.   The on-line Notification of Intent to Ballot form (off of the TSC page Special Uploads page) is available at: http://www.hl7.org/special/committees/tsc/ballotmanagement/index.cfm.     Please note that a few New Projects have NOT YET had their starting NIB records set up, although most should be available.  If you need a NIB set up for a new project, please contact me and I will set it up for you. As a heads up, the next important deadline following the NIB deadline is the Initial Content Deadline.  Any initial content for the V3 Ballot Web site should be submitted to Headquarters (HQ) by end-of-day (midnight) eastern time on Sunday, July 1st.