Privacy and Security at HIMSS 2008

This Wiki Article assumes that you have read and understand appropriately the ATNA, XUA, and BPPC profile. The details are not duplicated here. This document includes only the minimal necessary to express the DEMO Affinity Domain Policy and the use for demonstration.

EXECUTIVE SUMMARY

The S&P (aka BPPC) scenario will focus on the security and privacy interoperability profiles (ATNA, XUA, and BPPC). Because of this security/privacy focus this scenario will not focus on the clinical content, but rather use the scenario to carry the security/privacy message.

The patient that is used will be having a sensitive observation (e.g. HIV) that the patient wishes to blind allowing only direct care providers. In this way we can show the use of a different confidentiality code from other scenarios. In theory, the documents registered during this scenario will only be available from BPPC enabled systems that have clinical users with elevated privileges or during a break-glass situation. The reality is that only the BPPC systems will be enforcing these policies, which means that all other systems will be operating at highest privilege.

The general scenario goes like this:

1. The patient registers as a patient to get a patient ID. During this process the patient will be given some pre-negotiated documents. Some of these documents simulate ACT-1. There will be a LAB document that indicates that the patient has HIV.
2. ACT -1
   1. Patient sees their primary care physician who discovers that the patient has HIV. Because of this observation the Primary Care Provider encourages the patient to get a PHR so that the patient can track their own health. The PCP gives the patient a list of PHR providers that are ‘in-network’, meaning that they already have the business relationship to participate in the HIE. The PCP then publishes a HITSP-C32 into the HIE marked with the Restricted code because the patient wants to keep Restricted the HIV positive status. The PCP also recognizes that the patient may want to participate in a PHR that is not ‘in-network’, so also publishes the same documents onto a removable-media (USB stick) that the patient can carry. The PCP also reports the condition to public health.
   2. The patient decides to use an ‘in-network’ PHR (CapMed). To authorize this PHR to act as their agent, the patient acknowledges the privacy policy for CapMed.
   3. Patient uses their PHR to publish a clinical document that doesn’t include the HIV status and marks that for Normal clinical use. This allows all clinical users to have normal access to this document. Patient uses their PHR to publish an emergency data set for Emergency Responder access
   4. Public Health Authority – something goes on here that is not privacy/security
3. ACT-2
   1. the patient gets into a car crash (or building collapse). The 911 operator accesses the NHIN and finds the patient’s records. They only see the documents marked with “Emergency Responder”. The 911 operator then does a lookup for bed availability in local hospitals
   2. At the scene an authorized licensed EMT sees the same “Emergency Responder” documents, also is given "Break-Glass" access to the clinical documents marked Normal that the patient published from their PHR, and is not even shown the restricted documents.
   3. In the Emergency Department the doctor can see that there is a normal document that is accessible and a Restricted document that would require the doctor to use ‘break-glass’ procedures. The doctor determines he has reason to use ‘break-glass’ and accesses the document.
   4. The Patient goes to a different PCP and revokes the implied consent. We will show on a system that the documents can be seen before, the patient will acknowledge the OPT-OUT policy, and we will then see that the PCP can no longer see the documents in the Affinity Domain (although local data is outside of scope)
4. Accountability shown at Infrastructure pod
   1. We visit the system that issues the smart-cards to the 911 operators and EMTs. This system is used during ACT-2 to authenticate the individuals strongly and issues assertions that are used in the NHIN to allow data access.
   2. We then see how the use of identity assertions gives better fidelity to the audit logs, allowing us to see direct user accesses where this had to be indirectly before XUA. (This was not shown as no one used XUA at HIMSS)
   3. We then visit the Security Officer to see how security alerts (e.g. from "Break-Glass" events) could be generated from the audit logs.
   4. We visit the Privacy Officer to see how the audit logs can help resolve a patient complaint that a neighbor, who is an employee of the hospital, may have inappropriately accessed the patient records. And see how the audit log can be used to assist with the development of an Accounting of Disclosures.

Optionally : It would be good if we could have shown time-limited consents, thus being able to show a situation where consent is needed at each healthcare visit. This requires more logic in the Document Consumers as they must also test the validity timeframe of the consent.

Prime differences from last year

For background I refer to the video made at last HIMSS last year. http://www.ihe.net/Scenarios/security.cfm

The main differences:

1. Consent will be used to authorize a specific PHR as an agent to the NHIN
2. We will be showing how to publish documents that have sensitive content. Publishing one document with all the data and marked Restricted, and a second document without the sensitive data and marked Normal.
   1. It would be good if we could have shown this through an XDS Transform
3. We will be showing Emergency Responder accessing a set of data identified for their use.
4. We will be showing off more uses of the ATNA audit log. Specifically showing the bridge to an Accounting of Disclosures.

PRIVACY CONSENTS POLICY FEDERATION

At HIMSS there will be multiple XDS Affinity Domains. They will all be bridged using XCA. This will present problems as we will only have a few systems that can enforce BPPC policies. What we will do is explain that all the other systems are running at absolute highest privileges, thus only showing access controls in special scene.

If we could get everyone to do their XDS query with the Normal code, then we wouldn’t need to do this. But this attribute is not common on all queries. A second alternative is to insert this code in the XCA gateways, but these systems were not ready to do that.

BPPC PRIVACY CONSENTS POLICIES

Our Affinity Domain will:

• All documents are published (no need to check consent on publication).
  • This way we have the longitudinal completeness of the record regardless of the current state of consent
  • This way the documents are available to be used for required government reporting, and quality control. The use of the data is de-identified
• Consent is implicit for sharing of the documents for normal treatment, operations, billing, and required government reporting. Other uses could be tightly controlled, but we are not showing that.
• PHR Access: PHRs will each have their own business-privacy-policy. This is common today. This is a pre-conditional legal agreement that allows the PHR to act as a ‘system’ in the NHIN. This does not allow them to act on behalf of any patients. For this we need to get a Patient Consent to the PHR privacy policy. So for each PHR that is ‘in-network’ there is an OID that references their policy. For our DEMO there will be two actual PHRs and three dummy ones. Note that more than one consent document can be acknowledged, so the patient could choose multiple PHRs.
  • Authorize CapMed - 1.3.6.1.4.1.21367.2006.7.111
  • Authorize CareEvolution - 1.3.6.1.4.1.21367.2006.7.112
  • Authorize Acme - 1.3.6.1.4.1.21367.2006.7.113
  • Authorize ABC - 1.3.6.1.4.1.21367.2006.7.114
  • Authorize XYZ - 1.3.6.1.4.1.21367.2006.7.115
• If the patient does not want to be a part of the HIE then the implied policy will be ‘replaced’ with an Opt-Out policy. OPT-OUT = 1.3.6.1.4.1.21367.2006.7.106
  • If they decided again to participate the OPT-OUT can be replaced with an explicit OPT-IN = 1.3.6.1.4.1.21367.2006.7.108
• Document when published can be marked with combinations of three different uses, where any of these uses allows access to the document. That is that where multiple confidentiality codes exist they are in an OR relationship.
  • Normal sharing allows for the widest access for treatment, operations, and billing. Essentially this code requires that consent has been given.
    • NORMAL = 1.3.6.1.4.1.21367.2006.7.107
  • Restricted sharing for direct treatment. Documents marked with this code are only accessible to care providers that have a direct care relationship.
    • RESTRICTED = 1.3.6.1.4.1.21367.2006.7.109
  • Emergency Responder: Documents with this code are accessible by emergency responders (e.g. 911 operators, EMT, Police, Fire, and Rescue).
    • EMERGENCY_USE = 1.3.6.1.4.1.21367.2006.7.110
• When a user does not have .access to the documents, the Affinity Domain Policy indicates that clinical users are allowed to see that blinded documents exist. This means that they will see documents that are marked RESTRICTED, but won’t be able to access them unless ‘break-glass’ applies.
• The overall policy allows for the override in the case of emergency, commonly called “break-glass”. There are three identified cases where this is allowed when a qualified clinical user has a medical reason. The user must have been assigned the permission to ‘break-glass’. All instances where ‘break-glass’ has been used SHALL produce the ATNA “Security Alert - Emergency Override” audit message.
  • When OPT-OUT (dissent) has been registered. This would be a case where the patient has requested not to share. Note that in some regions (Australia) opt-out does not allow for break-glass. As indicated the break-glass can only be done by authorized clinical users during what that individual considers justified.
  • When data is marked as RESTRICTED yet the individual accessing the records is not part of the direct treatment team. An example is where the patient has been referred under urgent conditions. As indicated the break-glass can only be done by an authorized clinical user during what the individual considered justified.
  • A special case of both is a clinical user in the Emergency Room. These users because of their functional role are authorized to ‘break-glass’, but like any break-glass case they must have good clinical reason to do so. Thus these users will not normally have any additional access.
• There are likely other documents that are too sensitive for any of these policies and will not be shared into the Affinity Domain. This does not mean that they are not shared within an enterprise via other means.
• All accesses to the documents SHALL be recording using the appropriate ATNA audit log event/message.

The Privacy Consent Policies are non-XDS documents. For internal computer purposes the policies are identified by the Privacy Consent Policy Identifier OIDS (e.g 1.3.6.1.4.1.21367.2006.7.107)

DETAILED SCENARIO STEPS

1. CAPTURING THE PATIENT CONSENT FOR SHARING DOCUMENTS This step takes place prior to a PHR having access on behalf of a specific patient. This step will register that the patient has agreed to authorize a specific PHR system to access their documents in the Affinity Domain. The steps needed to register the act of consent to share are:
   1. Interact with the patient to choose their PHR system from the list of pre-staged PHRs. That is, the Affinity Domain must have already had a business agreement with the PHR system that has setup gross connections and policies.
   2. Interact with the patient to obtain their consent for Normal document sharing. This is done by some undefined means, likely a digital ink system for demo purposes.
   3. Create an XDS-SD of the ink-signature on the consent document.
   4. Include the BPPC content in the same CDA header as the XDS-SD
      1. List the consent OID for their PHR Policy
   5. Register this BPPC (XDS-SD) and create the association to the proper OID.
      1. EventCodeList includes OID for their PHR Policy.
      2. ConfidentialityCode = NORMAL (This means that the existence of the Normal consent is also privileged and only knowable by users that have privilege)
   6. Normal ATNA Audit messages are generated.
2. SHARING A CLINICAL DOCUMENT When a clinical document is to be shared, the Document Source takes the following steps:
   1. Assign the clinical document with the proper confidentiality code(s) to the document and metadata. Recognize that when multiple codes are applied they operate independent (i.e. the OR operator is used).
   2. Register the document
   3. Normal ATNA messages are created
   4. In cases where the document needs to be marked Restricted because one component of the document is sensitive, then it is possible that a “Transform” may be registered with the sensitive information redacted and thus the Transformed document can be marked as Normal.
3. FINDING CLINICAL DOCUMENT The query is from a normal doctor about a specific document result on a normal patient. This is simply documenting what is happening in all Document Consumer scenarios. It can be shown using BPPC systems too.
   1. The Document Consumer determines that the doctor should have access to the patient data. This is based on local policy rules, e.g., this is an authorized doctor and patient is assigned to this doctor. If the doctor should not have access, the Document Consumer should not interact with XDS. This is required behavior of all XDS Consumers since the original publication of XDS.
   2. The Document Consumer verifies that the patient does NOT have a current OPT-OUT. This is done by doing a XDS Registry Stored Query looking for Consent Documents with the EventCodeList including OPT-OUT. If zero results are returned then the patient has not dissented (OPT-OUT). In the case of non-zero results returned, no further interactions with the XDS Registry should be allowed.
   3. If we support Consents on an event-by-event basis (like in Minnesota) then the Document Consumer must also check for OPT-IN with the XDS metadata start and stop time are within the current timeframe. There might be an OPT-IN that has expired.
   4. The Document Consumer includes normal sharing policy (Normal) on confidentiality codes because the doctor does not have permission to see Restricted status.
   5. If the user does have privileges to see Restricted then include that code too
   6. If the user has the privilege to break-glass then include Restricted code too
   7. The query is performed, and matching documents returned.

Appendix A: Mapping to HIMSS demo systems

It doesn’t matter much what domains the ARRs are in. We will demo what we can off of the data they have. Yes it would be best if the ARR that shows the Security Officer scenario is in the same domain as Centricity Enterprise so that it can see the break-glass

Appendix B: Accountability

The ATNA Audit Record Repository should be ready to show:

1. How the Security Officer could get security alerts generated from the audit logs.
   1. Too many login failures – may indicate a hack attack
   2. Use of “Break-Glass” – may indicate someone inappropriate use
   3. Unusual traffic from a one source
2. How the Privacy Officer can use the logs
   1. how the audit logs can help resolve a patient complaint that a neighbor, who is an employee of the hospital, may have inappropriately accessed the patient records.
   2. how the audit log can be used to assist with the development of an Accounting of Disclosures. – Filter out systems that can be tracked to only uses that are not part of an accounting of disclosures. For example the accesses from the EMR would all be for treatment purposes, any exceptions would need to be identified by the EMR. Where as all accesses from the “reporting” system would need to be accounted for.
3. Federated ID
   1. how the use of federated identity gives better fidelity to the audit logs, allowing us to see direct user accesses where this had to be indirectly before XUA.
   2. Show how some audit logs from XDS Registry Actors don’t have a user identity because the Document Source doesn’t support XUA. Where as other events have a user identity clearly showing the user identity and the identity domain that user identity is issued out of.

Appendix D: Notes about our simplifications

Note 1: The Affinity Domain Policy clearly states that all clinical documents will be published. That access is controlled on use based on consent or dissent. We have allowed for restricted access, so if a patient requests restricted access we can support that, but if a patient says “please don’t share my sexual health information with anyone” the answer for now is “don’t publish it at all”. There are standards efforts ongoing to fill this and many other identified gaps.

Note 2: In the real world, federation of BPPC policies is not as simple as we have made it. Different Affinity Domains would likely have their own OIDs that would represent their own idea of Normal and Restricted. It is possible that multiple Affinity Domains might be able to agree that among the Affinity Domains that all variants of Normal are substantially identical, and all variants of Restricted are substantially identical. Although this can be agreed by people, the systems within each Affinity Domain would need to be configured with all lf the OIDS from all of the Affinity Domains so that they also treat the ‘other’ Affinity Domain’s normal policy as if it was their own normal policy. Even this type of policy bridging may not work in the long term either.

Note 3: Multiple confidentialityCodes: There was no normative reference for how to interpret multiple confidentialityCodes. We noticed that CDA resolved this by restricting the CDA internal use of confidentialityCode to be a single code. IHE choose to allow multiple codes and define that they have an OR relationship. We choose an OR relationship due to the simplicity of the supportable policies (meaning that any of the codes would allow access). Since IHE published BPPC, HL7 has since defined that they expect multiple confidentialityCodes to be in an AND relationship (meaning that all codes must allow access). IHE recognizes this new conflict and expects that in the future when we can support complex privacy policies that we will align with CDA and allow only one code, where this one code will point to a policy that has the appropriate combinatory in computer processable form.

Note 4: IHE recognizes that BPPC only supports Basic privacy policies. IHE has initiated two projects with OASIS and HL7 to provide the necessary vocabulary, obligations, and combinatory logic.

Appendix E: Code-table

Here is the informative update to the Affinity Domain code tables (official table http://ihewiki.wustl.edu/wiki/index.php/XDS_Main_Page#Configuration_and_Change_Log)

<CodeType name="confidentialityCode" classScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"> </CodeType>