1. Share with Protections
6/18/2019

2. 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.

3. 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.

4. 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.

5. 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.”

6. 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.”

7. 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

8. 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.

9. Use Case Descriptions

10. 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.

11. 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