So, thinking on this a little more, there is a way that we could use a very lightweight BPPC document to trigger the SHR into not disclosing document retrieves by indicating the patient “opts-out”. Basically the steps are:
-
SHR receives a document which is a BPPC policy document (i.e. patient wants policy X enforced)
-
SHR performs a simple meta-data update to apply (or clear) the policy on the registry (best practice)
Here is an example of what a document like that might look like (apologies if this looks hideous I’m pasting from Outlook):
<hl7:ClinicalDocument xmlns:hl7=“urn:hl7-org:v3”>
<hl7:typeId root=“2.16.840.1.113883.1.3” extension=“POCD_HD000040”/>
<hl7:templateId root=“1.3.6.1.4.1.19376.1.5.3.1.1.1”/>
<hl7:templateId root=“1.3.6.1.4.1.19376.1.5.3.1.1.7”/>
<hl7:id root=“2c589cf6-c38f-47e2-a92e-946c9aebd6f8”/>
<hl7:code code=“57016-8” codeSystem=“2.16.840.1.113883.6.1” displayName=“PATIENT PRIVACY ACKNOWLEDGEMENT”/>
hl7:titleApply Opt-out</hl7:title>
<hl7:effectiveTime value=“20131002131211.044-0400”/>
<hl7:confidentialityCode code=“N” codeSystem=“2.16.840.1.113883.5.25”/>
hl7:recordTarget
<hl7:patientRole>
<hl7:id root="1.2.3.4.5.6.7.8" extension="1234"/>
<hl7:patient>
<hl7:name use="L">
<hl7:given>John</hl7:given>
<hl7:family>Smith</hl7:family>
</hl7:name>
<hl7:administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>
<hl7:birthTime value="20131002"/>
</hl7:patient>
</hl7:patientRole>
</hl7:recordTarget>
hl7:author
<hl7:time value="20131002131211.044-0400"/>
<hl7:assignedAuthor>
<hl7:id root="1.2.3.4.5.6.7.8" extension="12"/>
<hl7:assignedPerson>
<hl7:name use="L">
<hl7:given>Robert</hl7:given>
<hl7:family>Dolin</hl7:family>
</hl7:name>
</hl7:assignedPerson>
</hl7:assignedAuthor>
</hl7:author>
hl7:documentationOf
<hl7:serviceEvent>
<hl7:templateId root="1.3.6.1.4.1.19376.1.5.3.1.2.6"/>
<hl7:id root="2c589cf6-c38f-47e2-a92e-946c9aebd6f8"/>
<hl7:code codeSystem="2.1.2.3.5.3049.1" code="OPTOUT" codeSystemName="OpenHIE Consent Policies"
displayName="Opt-Out"/>
<hl7:effectiveTime>
<hl7:low inclusive="false" value="20131002131211.044-0400"/>
</hl7:effectiveTime>
</hl7:serviceEvent>
</hl7:documentationOf>
hl7:component
<hl7:structuredBody>
</hl7:structuredBody>
</hl7:component>
</hl7:ClinicalDocument>
Cheers
-Justin
···
From: Derek Ritz (ecGroup) [mailto:derek.ritz@ecgroupinc.com]
Sent: Wednesday, October 29, 2014 11:24 PM
To: ‘Justin Fyfe’; openhie-shr@googlegroups.com
Subject: RE: Confidentiality Codes in ODD CDAs
Ok… so we had this issue come up when I was a project team member regarding Canada Health Infoway’s Privacy and Security infrastructure working group. My recommendation, then and now, is for there to be a “flag” in the CR that indicates if a use has opted out of sharing their data with care providers. Basically, sharing SOME (but perhaps not all) data with SOME (but perhaps not all) care providers is wickedly difficult. However, to either share ALL data with ALL care providers or NO data with ALL care providers is binary… and easy.
There are +13 million citizens in the province of Ontario, Canada (where I live). At the time (2007) when I was working on the Infoway work item there were 535 citizens who had established consent directives regarding their health information and all of those 535 citizens were 100% opted out (as in, NO data sharing with ALL care providers). To be really blunt about this, the complexity and cost of anything except a big ON/OFF switch was simply unjustifiable.
In my view, this should be treated as a sociotechnical problem not a technical problem. If someone wants “out” of eHealth that should be their right and we need to respect it. There should be a break-the-glass (BTG) privilege for the physicians if the jurisdictional laws allow for that (Ontario’s does). [BTG means the physician can, for reasons of patient safety, choose to override the big ON/OFF switch and see the patient’s eHealth records in their entirety.] But however theoretically possible it might seem to allow some data to be masked for some providers… this quite simply isn’t a practical option, or a necessary one.
Other than this, I have no opinion on the matter. 
Warmest regards,
Derek.
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com
This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.
From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Justin Fyfe
Sent: Wednesday, October 29, 2014 4:51 PM
To: openhie-shr@googlegroups.com
Subject: Confidentiality Codes in ODD CDAs
Hello All,
I was just doing some further documentation on the ODD module and realized that the ODD module does not currently adhere to the confidentialtyCode that was imported via the cdahandler (import) module. The import module stores the confidentiality code for the inbound document, but I am struggling with how to implement or enforce this when generating outbound CDAs.
There are a few ways to handle this:
-
Push the responsibility to the consumer, that is the ODD module will simply generate all records in the CCD for the patient and if any are restricted will append a restricted confidentiality code on the outbound ODD document, or
-
Create two ODD entries, one containing only “normal” data and the other containing “normal+restricted” data. This would be identified in the “confidentiality” slots of the XDS meta-data sent to the registry (i.e. the restricted document will carry a restricted policy on XDS meta-data so the registry can perform necessary policy enforcement, this is how OSCAR works). The challenge here is to, in the “normal” document, identify that data is missing because it is restricted, I’ve never had to deal with this, my sense is emitting entries where all properties are nullFlavor=“MSK”.
-
Determine who the user is on the end of the XDS request and have the ODD module include/not include records based on the user assertion. This is by far the most elegant solution however also the most complex as it would involve implementation of XUA to pass user assertions around. There is the SeR profile from IHE which allows the repository to get a policy enforcement decision from a policy manager (similar to a claim token if I remember correctly), however this profile is as new as PDQm so I’m not sure it is any easier.
Personally I think that #1 or #2 are good options, #2 is a little more complex however not out of the realm of possibility. I’d like to get everyone’s opinion about handling masked/restricted data in CDA, if you know of any other ways to do this please share.
Cheers
-Justin
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
