Share with Protections 6/18/2019 Mike.davis@va.gov

Overview DS4P combined with “Share with Protections” provides: 1) critical conceptual components supporting goals of the 21st Century Cures Act, TEFCA and ONC’s interoperability NPRM and; 2) implementing foundations for interoperability improvements capable of eliminating intentional or systemic information blocking as an impediment to accessibility.

As-Is Typically, unless the patient affirmatively makes the choice to share some protected information, it is blocked. The blocking may be legal, but the net result is information is not shared. Second, presented in this way, a patient, likely already in stress, must calculate the benefits of not sharing (the de-default and presumptively best choice), or drawing upon their own courage to over-ride their provider in order to share. In the case that most patients actually give their consent, the provider is then left with a mountain of paperwork to maintain and manage.

Result of Not-Sharing The current opioid/methamphetamine/fentanyl crisis touches both information blocking and potentially patient safety issues. Efforts to give providers access to state level prescription information have been less than effective and circumvent privacy by providing a “back door” to sensitive conditions for patients that may have chosen not to share in the first place. No consent should mean that treating clinicians do not have access without patient consent. Providing clinicians access through state prescription registries, without consent, while well-intended, violates this principal. Recognize that not-sharing is a patient-safety issue.

Introducing “Share with Protections “ (1): 1991 Institute of Medicine: “Legislation should clearly establish that the confidentiality of person- identifiable data is an attribute afforded to the data elements themselves, regardless of who holds the data. “Big Data Proxies and Health Privacy Exceptionalism” legal paper” “Of considerable importance to the arguments advanced in this article, HIPAA does not literally protect data. That is, the data subject’s privacy rights do not attach to and flow with the data. HIPAA, like the common law rules that preceded it,13 created a liability rather than a property model.14 Unlike those common law rules (such as the breach of confidence), HIPAA provides that the liability rule’s remedy inures benefit to the regulator rather than the data-subject.”

Introducing “Share with Protections “ (2): A 2013, Mckinsey report proposed a new notion for healthcare: “share with protections.” “Shift the collective mind-set about patient data to ‘share, with protections’ rather than ’protect.’ With the more widespread release of information, the government, leading companies, and research institutions need to consider regulations about its use, as well as privacy protections. To encourage data sharing and streamline the repetitive nature of granting waivers and data-rights administration, it may be better for data approvals to follow the patient, not the procedure. Further, data sharing could be made the default, rather than the exception. It is important to note, however, that as data liquidity increases, physicians and manufacturers will be subject to increased scrutiny, which could result in lawsuits or other adverse consequences. We know that these issues are already generating much concern, since many stakeholders have told us that their fears about data release outweigh their hope of using the information to discovered new opportunities.”

HL7 DS4P Plus Share with Protections Today, HL7 standards support an updated vision of DS4P which combined with “share was protections” supports ONC’s TEFCA and 21st Century Cures NPRM vision of interoperability and sharing (the opposite of information blocking). Data is always shared by default, accompanied by enduring security labels, Originators classification “flows with the data” Recipient retains (persists) and honors labels Recipients only allow access by staff with a valid “need to know”. To do this, each receiving organization would be responsible for managing and granting “Clearances” to individuals based on job description, assigned duties and policy

Results Patient confidence that more highly sensitive information will continue to be appropriately protected even after disclosure in the same way as it was when originally created and that disclosure does not result in unintended “declassification” and exposure to persons who do not actually need this information for their treatment or the performance of their duties. With “Share with Protection” elements in place, it is now possible to make data sharing the default.

Use Case Descriptions

Requirements 1 No. Requirement Enforcing Party General 1 Originators shall apply HL7security labels, including any handling instructions, to all health information disclosures at the Document, Section and Entry levels according to policy. SLS   Originator applied security labels shall use HL7 standard terminology Originators who are also federal agencies may apply security labels for Controlled Unclassified Information as required by regulation. “Recipients of labeled data are obligated to honor and enforce received labels and to persist these labels and associated handling instructions upon redisclosure”. ACS, Cache, EHR Recipients shall ensure that only those individuals under their authority having a valid need to know, and appropriate clearance may access healthcare information. ACS Recipients shall store information containing CUI classifications only in media properly marked IAW NARA guidelines. EHR, Cache Recipients shall not de-classify information containing security labels except as permitted by the Originator.

Requirements 2 Requirement Enforcing Party No. QHIN   Records received by QHIN may be stored in QHIN or Participant DB QHIN, EHR, Cache Participants Participant actions must be mediated by ACS based on permissions/clearances ACS Participant Member Received Records may be directly viewable by Participant Member Cache, ACS All Participant Member access must be controlled by policy. Cache Records must be labeled on disclosure SLS Incoming records must be labeled else rejected Cache records must be labeled Cache records may be automatically updated/label on schedule (e.g. every 24 hrs) EHR EHR may have a view on labeled records or as required by law/policy EHR records may be exported to Cache EHR, Cache Received Records may be integrated into HER