1. Response to the HITSC Analysis and Recommendations on Patient Privacy, Provenance and Identity Metadata S&I Framework Data Segmentation for Privacy Initiative 6/29/2012 1

2. DS4P Proposed Approach Data Segmentation for Privacy aims to address standards needed to protect those parts of a medical record deemed especially sensitive or that may otherwise require additional privacy protection, while allowing other health information to flow more freely. 2

3. Use Case Example 3

4. 4

5. DS4P Approach 5

6. Requirements of Sending System - LOINC Document Type/Datatype for CDA - ASC X12 4010/5010 for Healthcare Provider & facility types and Healthcare Coverage Type - SNOMED-CT for Protected diagnoses/problems -Query for consent directive location (optional) -Query for consent directive (optional) -Check HL7 CDA R2 PCD for HL7 PurposeofUse Vocabulary (aligns with NwHIN exchange) and obligations - HL7 Confidentiality Code: for CDA (N,R,V) -HL7 Obligation Code: An obligation policy (e.g. prohibition on re-disclosure without consent) -HL7 Purpose of Use: The purpose for the information disclosure (e.g. support treatment, payment, operations, research, etc.) -URL or XACML for Policy Reference PROCESS STEP DS4P MECHANISM 6

7. Receiving System Requirements include: -The receiving system MUST ensure that the provenance of patient data is tracked. -The receiving system MUST enforce the annotations related to confidentiality, obligations, and purpose associated with health information received from other organizations in order to prevent unauthorized disclosures. 7

8. HITSC Recommendations with Strong Alignment to DS4P Approach HITSC Recommendations with General Alignment to DS4P Approach HITSC Recommendations for which DS4P Proposes Alternatives HITSC Recommendations not addressed by DS4P 8 Response to HITSC S&P WG

9. 9 HITSC RecommendationDS4P Analysis Power Team suggests that metadata for patient identification, provenance, and privacy be expressed using elements from the HL7 Clinical Document Architecture- Version 2 (HL7 CDA R2) header. DS4P will use not only the information in the HL7 CDA R2 header, but also IHE XD* and XUA metadata. This decision was reached based on the fact that information within the header is part of the document itself, and therefore cannot be viewed without providing access to the contents of the entire document. While this is not a concern during transit (since the data and metadata is encrypted), it is important for receiving systems to be able to adjudicate internal access control requests based on attributes about the data without going inside the data. Response to HITSC S&P WG General

10. HITSC RecommendationDS4P Analysis We initially considered three components necessary to enforce privacy: the policy, metadata about the content, and metadata about the requestor. However, information about the requestor would be used by the sender to mediate the request, but would not need to be tagged onto the data exchanged in an authorized request. It was determined that including the policy with each TDE was not feasible because policy changes over time. Therefore it was agreed that a pointer to an external policy registry would be most appropriate, though we did not address the specifics of how these registries might be implemented. We are therefore restricting our metadata recommendation to the content. The Data Segmentation for Privacy (DS4P) Initiative looked at possible approaches for sending or pointing to a policy, and focused on piloting two approaches: For pointing to a policy, it was determined that a policy reference could be used (with various approaches being piloted, including the use of a policy pointer and the use of XACML-encoded policies. For sending a policy, it was determined that the consent directive could be sent to a receiving system (and processed) prior to sending any patient data. 10 Response to HITSC S&P WG General

11. 11 Response to HITSC S&P WG Privacy Recommendations The specific focus of the Data Segmentation for Privacy Initiative was on privacy metadata and defining where that metadata should be placed to support the needs of the S&I Framework and its scope of data segmentation.

12. Response to HITSC S&P WG 12 HITSC RecommendationDS4P Analysis Metadata pertaining to privacy should include: Policy Pointer: A URL that points to the privacy policy in effect at the time the TDE is released. A Policy Pointer should point to a universally recognized Policy Reference to enable the consuming organizations to apply their interpretation of that policy.* Metadata can also be used to provide some context as to why the information is protected (i.e. policy pointer/reference), as well as the special handling obligation placed on the receiver as a result of the policy. *The Policy Pointer can be included in the IHE XD* metadata or in the Patient Consent Directive. Privacy

13. Response to HITSC S&P WG 13 HITSC RecommendationDS4P Analysis Metadata pertaining to privacy should include Content Metadata (Datatype and Sensitivity). Content Metadata that are needed to enforce current federal and state policies as well as to anticipate more granular policies that may be defined. Datatype: Information category from a clinical perspective. Sensitivity: Indicates special handling that may be necessary per the referenced policy. DS4P Approach uses Datatype and Confidentiality* content metadata Datatype as a data element refers to the document type (patient data) being exchanged. An initial list of possibly sensitive document types that would require data segmentation has been provided in the implementation guide. DS4P Approach leverages Confidentiality codes. Initial approaches recommended for piloting focus on using the confidentiality code specified within privacy metadata, or by using the Patient Consent Directive. * DS4P approach uses HL7 confidentiality codes as metadata to describe sensitivity. * Initial approaches recommended for piloting focus on using either the Patient Consent Directive as expressed using CDA or by specifying a confidentiality code within the IHE XDS/XDR/XDM metadata. Privacy

14. Response to HITSC S&P WG 14 HITSC RecommendationDS4P Analysis Expand HL7 vocabulary for sensitivity. A proposed starter set could include: Substance Abuse Reproductive Health Sexually Transmitted Disease Mental Health Genetic Information Violence Other The DS4P initiative will pilot HL7 confidentiality code vocabulary as part of its implementation guide using the constrained value set specified by the C-CDA (e.g. N,R,V). Rationale: (1) These codes are used as short-hand to reference the privacy policy dealing with certain conditions or problems. Enumerating these policies in a code set is not scalable as new privacy policies are introduced overtime. In the US this value set would have to be extended to include sickle cell anemia and sexually transmitted diseases and it would have to be continuously updated as new policies are added. (2) The detailed “sensitivity” codes only have value when used in the context of a privacy policy. The privacy policy is referenced in a policy pointer, which already contains all the information necessary to adjudicate the data element. Thus the “sensitive” codes are redundant. Privacy

15. Response to HITSC S&P WG 15 HITSC RecommendationDS4P Analysis In order to provide coded values for Datatype, the LOINC codes specified in the CDA document code element are suggested. LOINC codes are suggested because they provide additional granularity. DS4P concurred with this recommendation and a constrained list of document types are included in the Data Segmentation for Privacy implementation guide that are specific to the requirements of data segmentation. As recommended by the Health IT Standards Committee, document codes MUST be defined using LOINC, and Sending and receiving systems MUST be able to validate and evaluate LOINC document types to be able to implement this guide. Privacy

16. 16 Response to HITSC S&P WG Provenance Recommendations: The Data Segmentation for Privacy initiative community specifically looked at provenance in the context of ensuring that provenance metadata could persist when healthcare data is exchanged with other systems. Provenance was not analyzed to define specific guidelines or standards recommendations for ensuring the provenance of patient data. The initiative did not explicitly focus on defining the metadata used to define provenance but the implementation guidance does recommend specific standards for how to support provenance.

17. Response to HITSC S&P WG 17 Provenance HITSC RecommendationDS4P Analysis Metadata contained within the provenance envelope should include Tagged Data Element (TDE) identifier Time stamp Actor Actor’s affiliation Actor’s digital certificate This metadata is included within several components of the DS4P technical approach, including SAML assertions and in the document sharing metadata. DS4P recommends that metadata that defines provenance is established at the document/ payload level (CDA R2 header) where possible, allowing the specific attributes inside the document to show their own provenance in the context of that document. Because the payload mechanism may support possible alternative formats for patient data (such as DICOM or X12) provenance for those formats may differ significantly from the method established in the implementation guide.

18. Response to HITSC S&P WG 18 HITSC RecommendationDS4P Analysis The metadata describing the actor (in the form of a digital certificate) should include the name of the actor who signed the envelope and the organizational affiliation of the actor. Note that this scheme allows for exchanges involving both organizational “actors” and individual “actors.” The Data Segmentation for Privacy initiative felt that in this case, the actor would use SAML to support the requirement as laid out, including the use of an X.509 digital certificate (specifically in those instances where the patient data that has been segmented is being “pushed” using point-to- point information exchange, such as Direct). SAML would not apply in those push scenarios. The use of a digital signature was not specifically discussed in the Data Segmentation for Privacy initiative. Provenance

19. Response to HITSC S&P WG 19 HITSC RecommendationDS4P Analysis The use of an X.509 certificate to digitally sign the envelope contents. The use of a digital signature fulfills two requirements outlined by the Power Team: Non-repudiation. If a medical decision is based on the contents of a TDE, it is important that the contents cannot be later denied by the origin. Tamper-resistance. It is important to be able to verify that the content and metadata of a TDE have not been tampered with after production otherwise new content could be substituted by a malicious intermediary and TDE could not be trusted. Digital certificates were not specifically addressed in this initiative but are supported within the Data Segmentation for Privacy implementation guide An assumption was included in the implementation guidance that assumes usage of a digital certificate when signing the contents of segmented patient data. An assumption to use digital certificates was also included in the S&I Framework Data Segmentation Use Case. Provenance

20. Response to HITSC S&P WG 20 HITSC RecommendationDS4P Analysis While the actor and actor’s affiliation are expressed within the X.509 certificate, there should be the additional optional metadata fields for actor/affiliation. After reviewing the expressed reasons for including these metadata elements, the initiative did not see any specific immediate objections to these optional elements. These will be further clarified and tested as part of piloting efforts. The Data Segmentation for Privacy Initiative also specified the following requirement: The receiving system MUST ensure that the provenance of patient data is tracked. Provenance

21. Response to HITSC S&P WG 21 HITSC RecommendationDS4P Analysis An optional portion of the actor/affiliation metadata should point to the entity record in the Enterprise-Level Provider Directory, which may be a URL. If available, this will decrease complexity in the TDE and enable lookup of the source information in a provider directory. The Data Segmentation for Privacy initiative looked at this requirement and the following initial observations were made: There is no current recommendation for an ELPD that we can leverage to support this specific requirement. It is unclear in the recommendation what the ELPD would be used for in relation to provenance that would not already be supported by CDA R2 Provenance

22. 22 Response to HITSC S&P WG Privacy Recommendations: The initiative did not look at patient identification attributes as specifically necessary to segment patient data. However, an analysis was done to look at the patient identification metadata that the HITSC identified and how it aligns to current work in the DS4P Initiative.

23. Response to HITSC S&P WG 23 Identity HITSC RecommendationDS4P Analysis Extend the existing HL7 id element that allows a URI to be used as the value of the root attribute instead of the currently allowed UUID, OID or HL7 identifier. Out of scope for Data Segmentation for Privacy initiative. 23

24. Response to HITSC S&P WG 24 Identity HITSC RecommendationDS4P Analysis Metadata pertaining to patient identity should include the following: Patient name Date of birth Current ZIP code Patient identifiers Address The DS4P covered each of these data elements within its analysis of existing and possible future standards. It was determined that the metadata for patient identity should primarily be concentrated in the metadata for metadata associated with a name, ID, or organization, and within the patient data itself (the payload) for anything else, such as a ZIP code or DOB. Suggest that metadata expressing patient identifiers use the HL7 CDA R2 header format. We believe this XML-based format for describing generic clinical documents can best accommodate international representation of names. Additional information supported by the CDA R2 header could be included if desired. Out of scope for Data Segmentation for Privacy initiative 24

25. Response to HITSC S&P WG 25 Identity HITSC RecommendationDS4P Analysis Add a display name element to the HL7 CDA R2 standard to accommodate non-western names. This may require an extension of the HL7 schema. Out of scope for Data Segmentation for Privacy initiative Use a URI to act as a namespace for the identifier, as opposed to an OID as used in HL7 CDA R2. This allows for an extensible, flexible mechanism to uniquely identify an individual, without having to specify explicitly what type of identifier is used. Out of scope for Data Segmentation for Privacy initiative 25

26. Additional Guidance DS4P supports the goal of implementation of the Direct protocol as outlined in Meaningful Use language. Thus, it included specific guidance concerning use of Direct within implementation guidance. Specifically, because the current use of SMTP/SMIME as articulated within Direct implementation guidance cannot support the explicit definition of discrete metadata as articulated in this initiative, the use of IHE XDM is recommended as a specific path for implementation. The DS4P initiative members recommend alignment with the Direct XDR and XDM Specification to accomplish the implementation of data segmentation. 26

27. References/Contact Information The full whitepaper by Melissa M. Goldstein, entitled, “Data Segmentation in Electronic Health Information Exchange: Policy Considerations and Analysis” is available at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__privacy_and_security/1147 http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__privacy_and_security/1147 Thank you! 27 Johnathan Coleman, CISSP, CISM Initiative Coordinator, Data Segmentation for Privacy Principal, Security Risk Solutions Inc. 698 Fishermans Bend, Mount Pleasant, SC 29464 Email: jc@securityrs.com Tel: (843) 647-1556jc@securityrs.com Scott Weinstein, J.D. Office of the Chief Privacy Officer Office of the National Coordinator for Health Information Technology Department of Health and Human Services Email: scott.weinstein@hhs.govscott.weinstein@hhs.gov Erik Pupo DS4P Initiative Harmonization Team Lead Deloitte Consulting LLP erpupo@deloitte.com 27