Patient data embargo management

There are legitimate reasons for data to be embargoed for some timeframe. I am not a fan of these reasons, but as a Privacy and Security subject matter expert, I get asked how to solve these business needs. Many think this is an easy problem to solve, just slap a security tag on the data, but it is a much bigger systems-engineering problem.

Embargo Use-case

The clearest embargo reason is a patient safety reason, preventing a Patient from seeing a particularly damaging observation, until their primary care physician can have a one-on-one discussion. For example, a lab result that clearly indicates cancer. The clinical expectation is that the primary care physician can break the news more carefully or provide a more complete explanation.

The timeframe is not always clear, and most timeframes get cut short when some activity happens. Such as the above example, once the primary care physician has had the conversation then the embargo should stop.

These embargo timeframes can be just a few hours but can also be many months. I understand from a discussion on FHIR chat that there are countries that have regulations. That allow for timeframe to be up to six months. 

Oh, and data embargoed from the Patient would also need to be embargoed from their delegates (parent, guardian, etc).  

I don't know of embargo use-cases for Clinicians, no idea either on Payers. I could imagine that authorized research would or should be embargoed with the same rules as for Patients.

Meta Data

The security label (.meta.security) is not a great place to handle this, due to the variability. The security label could be used to tag data as falling into the category where an embargo might apply, subject-to-embargo. This would not indicate that an embargo does apply, just that the data qualifies for a potential embargo. Not clear what initial data analysis would be able to set this tag, but it is possible that there might be some set of codes and conditions that would be detectable. It might also be that all data is presumed to be subject to an embargo until data analysis or clinician explicitly marks it as not-subject-to-embargo. 

So, at this point we have a tag that says the data is either subject-to-embargo, or not-subject-to-embargo. Either method gives us the same state, that of a method to determine which data needs to have some timeframe applied vs which data does not.

When a clinician has a discussion with the Patient, and thus the embargo timeframe should be cut-short, then the clinician can just remove the subject-to-embargo or change it to no-longer-subject-to-embargo. Thus, the mechanism for counting-down the timeframe no longer applies.

Preliminary data status

An alternative that does not use the .meta.security tagging is to just use the .status element on the data. Most, likely all, data that would be potential subject to an embargo has  a .status element and the vocabulary available for the .status element has a preliminary code. This alternative has all data first published as preliminary, and only after some data analysis does it get set to final. This data analysis might be automated or might be clinician driven. In this case any data marked as preliminary would be embargoed from Patient access. One might expect that a Patient might not be given any data that is not in the final status.

The benefit of this method is that it is leveraging elements that have other clinical uses, but the drawback is that the security infrastructure must be aware of specific FHIR Resources like Observation. Further this method will only work for FHIR Resources that do have a .status element. Where the .meta.security is in the exact same place in all FHIR Resources, so the security infrastructure only need to understand the most basic of FHIR Resource.

Another potential drawback is that this dual purpose of the .status element may interfere with appropriate lifecycle management of the data.

Timeframe Management

As indicated in the use-case, the timeframe for automatic expiration of the embargo often varies by setting, data type, and clinician assessment. Where any timeframe exists there needs to be some mechanism to address the timeframe, but where the length of the timeframe is not fixed this makes the problem more difficult.

Count Down Clock

First solution, come up with some set of timeframes that fit the need, and assign them a code. Use that code on the .meta.security.

• embargo-2-hours
• embargo-2-days
• embargo-1-week
• embargo-2-weeks
• embargo-1-month
• embargo-2-months
• embargo-6-months

As you can see this would be possible if the number of quanta are a few. But gets out of control really quick.

Another alternative is to add an extension with an integer. The integer would be similar to the above in that it would identify some time that would need to elapse.

Both a set of codes and an integer present the problem of time-elapsed-relative-to-what? The _lastUpdated element is available, but it will get updated whenever the data change. Thus any update resets the count down clock.

You could use a Resource specific element, like Observation.issued. Like above with using the Observation.status, using the Observation.issued is elegant but does mean the security layer does need to know about Observation rather than just Resource.

End Time

I would recommend that if an extension is being added, that it rather be a datatype of dateTime, or Period. The meaning of the value would be the date/time after which the embargo is lifted. In this case there is no need to look elsewhere. 

For efficiency's sake, once the time has expired; then the .meta.security should be set back to not embargoed. Thus the date comparison only needs to be done on those with active, or about to expire, data.

Permission

The security wg is working on a Permission resource. It is very drafty at this point, not worth looking too closely at, although we are welcoming use-cases to help drive our design. Note that in this case I am going to use Permission in a negative way, that is that the Patient is Denied access while the Permission is valid. For efficiency, the use of Permission would seem tied to data with a .meta.security with subject-to-embargo. The flag would tell the security layer to go look for a Permission resource instance that applies. That Permission resource has a .validity element that would indicate when the Permission expires.

Note that although Permission has a .validity element, it does not have a way to express Deny.

Note, like the FHIR Permission, the IT Security infrastructure might be able to do everything with no evidence in the FHIR world. That is, an XACML or other access control engine could be given the embargo information for a given resource identifier, it would enforce that rule, and it would flush that rule out when it expires. Thus there would be no FHIR evidence of this rule. 

Expiring the embargo

Some of these mechanisms will automatically expire the embargo, some can have automated expiration of the embargo, but other mechanisms would require a human to disable the embargo. There should be mechanisms in place to assure that the embargo does eventually expire. Such as when status of preliminary is used, some mechanism should detect that the data was in preliminary state for too-long. This detected status might simply alert the primary care physician, or might automatically disable the embargo.

Abuse for Illegitimate reasons

The method used for these use-cases can certainly be used for illegitimate reasons. I suspect that many "data blocking" activities are using these legitimate excuses when there is not a legitimate reason. The concern of all Privacy professionals is this abuse. Many would prefer we have no mechanism for legitimate embargo, but that is not reasonable. Thus my approach is to have mechanisms that are clearly designed, and transparent. 

Transparency is key to Privacy. When a patient is allowed to know how their data are used, and why restrictions are in place, enable the Patient to be more informed. Thus I would prefer the Patient has access to an Audit Event log of all uses, or attempts to use, their data.  see IHE Basic Audit Implementation Guide

Conclusion

Given all of this. I would first look at the use-cases and see if they are always applying to Observation. If so, then I would use the Observation.status and Observation.issued. I next would ask if there is a fixed, or small number of fixed, increments. If there are, then a code could be used for that fixed time. I am familiar with a fixed 2 days timeout, after which the embargo automatically expires. I would then have a security label code for subject-to-embargo, and no-longer-subject-to-embargo. I would have the second code so that it was clear that an embargo was enforced. I would always want the subject-to-embargo code to get removed at some point so as to limit the overhead for the vast majority of data, data that has never been subject to an embargo or data that has an expired embargo.

Explaining #FHIR Consent examples

UPDATE: October 2023 -- the article is the source for an Explainer on FHIR Consent section of the IHE-Patient Consent on FHIR Implementation Guide. I recommend you use that text as it has been improved by committee review and has explanation of Policy and also data security tagging.

-----------------------------------

This article includes explanation of some example scenarios and points at example Consent resources for them. These example scenarios are provided for educational use only, they are not an endorsement of these scenarios.

Notice of Privacy Policy

Some realms only require that the patient be given access to the organizations privacy policy. In these realms the patient is not given the choice to accept, reject, or change the terms of privacy policy. The expectation is that the patient can stop the engagement with the healthcare provider if they don't like the privacy policy (yes, we know this is a fallacy in many situations).

These realms may use the Consent resource to indicate that the ceremony of providing access to the privacy policy has happened, when it happened, who presented the policy, and which version of the policy was presented. The specific version of privacy policy recorded can also be helpful to know when a given patient needs to be presented with the new version of the privacy policy.

• status - would indicate active
• category - would indicate patient consent specifically a notice of privacy practices
• subject - would indicate the Patient resource reference for the given patient
• dateTime - would indicate when the privacy policy was presented
• grantor - would indicate who presented the privacy policy
• grantee - would indicate the Patient resource if the patient was presented, a RelatedPerson for parent or guardian
• controller - would indicate the Organization who presented the privacy policy, and which is going to enforce that privacy policy
• policyText - would indicate the privacy policy that was presented. Usually, the url to the version specific policy
• provision.type - permit - given there is no way to deny, this would be fixed at permit.

Other elements would not be needed.

example

Given:

• Patient: Peter James Chalmers
• dateTime: March 11, 2022 at 12:22 pm
• grantee: is the patient
• grantor: Registration Desk Clerk - John Moehrke
• controler: Burgers MC
• policyText: policy at https://example.org/privacy-policy-v1.html

sushi:

Instance: example-notice
InstanceOf: Consent
Title: "Example of a Notice of Privacy Policy"
* status = #active
* category[+] = https://loinc.org#59284-0 "Patient Consent"
* category[+] = http://terminology.hl7.org/CodeSystem/consentcategorycodes#npp
* dateTime = 2022-03-11T12:22
* subject = Reference(Patient/example)
* grantee = Reference(Patient/example)
* grantor = Reference(Practitioner/example-clerk)
* controller = Reference(Organization/f001)
* policyText = Reference(DocumentReference/example-privacy-policy-v1)
* provision.type = #permit

support resources

Instance: example-privacy-policy-v1
InstanceOf: DocumentReference
Title: "Burgers Organization privacy policy"
* status = #current
* docStatus = #final
* type = https://loinc.org#57017-6 "Privacy policy Organization Document"
* category = https://loinc.org#57017-6 "Privacy policy Organization Document"
* content.attachment.contentType = application-pdf
* content.attachment.url = "https://example.org/privacy-policy-v1.html

Instance: example-clerk
InstanceOf: Practitioner
Title: "Registration Desk Clerk example"
* active = true
* name.text = "John Moehrke"

Security / Privacy Considerations

Organizations that never allow a patient to be in a deny mode never need to look at Consent for access-control reasons as there is no difference if the Patient has been given notice or not. In these cases the Consent is there for record keeping only. See Change to opt-out below.

Basic signed acknowledgement

This section covers the most basic of privacy consents, that simply records an acknowledgement to a given privacy policy permitting data sharing. This is only slightly different than the Notice of Privacy Policy, in that with this example, there is some evidence captured from the ceremony. Such as a patient initialing or signing a form indicating they have received the Privacy Policy. Similar to the Notice of Privacy Policy, the Patient is not given a choice to reject or change the terms of the privacy policy. The specific version of privacy policy recorded can also be helpful to know when a given patient needs to be presented with the new version of the privacy policy.

The Consent is the same as with Notice of Privacy Policy with the following additions:

• sourceReference - would hold a DocumentReference that has an image of the form that the patient signed. This image may be scanned copy of the ink on paper signature from the patient, or may be a digitally captured signature from the patient.

Other elements would not be needed.

example

Given: the same example attributes as above with the addition of a signed form. Thus the only addition is the sourceReference, which points at a scanned image of the signature in a DocumentReference resource.

sushi:

Instance: example-acknowledge
InstanceOf: Consent
Title: "Example of an acknowledged Notice of Privacy Policy"
* status = #active
* category[+] = https://loinc.org#59284-0 "Patient Consent"
* category[+] = http://terminology.hl7.org/CodeSystem/consentcategorycodes#npp
* dateTime = 2022-03-11T12:22
* subject = Reference(Patient/example)
* grantee = Reference(Patient/example)
* grantor = Reference(Practitioner/example-clerk)
* controller = Reference(Organization/f001)
* policyText = Reference(DocumentReference/example-privacy-policy-v1)
* provision.type = #permit
* sourceReference = Reference(DocumentReference/example-signed-acknowledgement-20220311)

support resources

Instance: example-signed-acknowledgement
InstanceOf: DocumentReference
Title: "Patient Peter James Chalmers signed an acknowledgement of the Privacy Policy"
* status = #current
* docStatus = #final
* type = https://loinc.org#57016-8 "Privacy policy acknowledgement Document"
* content.attachment.contentType = application-pdf
* content.attachment.data =  "SGVsbG8gV29ybGQ="

Security / Privacy Considerations

Organizations that never allow a patient to be in a deny mode never need to look at Consent for access-control reasons as there is no difference if the Patient has signed a consent or not. In these cases the Consent is there for record keeping only. See Change to opt-out below.

Change to deny sharing

This section covers the case where a basic permit has been used, but for some reason the authorization is revoked or rejected. An example might be where the organization does allow the patient to reject a previously permitted action, and the patient has expressed they want to deny sharing now. Another example might be where legal action has happened compelling an organization to revoke the consent.

The example scenario here describes methods where there would be only one Consent on record for a given Patient. Thus the current status would be simply discoverable by looking for the Consent for a given Patient and checking the .status element and .provision.type. This logic presumes that where no Consent is found, that an implied permit is the default. Thus one must look for both the existence of a Consent for the given Patient, and that the Consent.provision.type is permit.

Alternatives are shown:

1. One possibly is that the existing Consent instance is revised to change the .status to inactive. When this is done the .lastUpdated will automatically indicate the date and time this change happened.
2. If more details are needed, this change to the Consent instance could be tracked with a Provenance resource to indicate who made the change, what change was made, why the change was made, and other details as necessary.
3. Advanced alternative possibility is to record a new Consent with the details of the change in Consent.status, the existing Consent would be marked as inactive same as above, and the Provenance would further indicate the new Consent replaces the old Consent.

Note that at some point after this, the consent may go back to active. This transition would follow the same process with the .status changes in the other direction.

example

Alternative 1 is not shown, as it is simply changing the .status.

Alternative 2

Given:

• existing Consent resource example-acknowledge is revised as Alternative 1
  • for visibility the examples assumes that the server supports versioning. This is not required of the alternative.
• Provenance states
  • who - Lawyer David Pyke
  • when - March 3rd, 2022 at 4:56pm
  • why - Legal hold

sushi:

Instance: example-change-consent
InstanceOf: Provenance
Title: "Consent revoked"
* target = Reference(Consent/example-acknowledge/_history/2)
* entity.what = Reference(Consent/example-acknowledge/_history/1)
* entity.role = #revision
* dateTime = 2022-03-11T16:56
* activity = http://terminology.hl7.org/CodeSystem/iso-21089-lifecycle#hold
* patient = Reference(Patient/example)
* agent.type = http://terminology.hl7.org/CodeSystem/provenance-participant-type#enterer
* agent.who = Reference(Practitioner/example-lawyer)
 
Instance: example-lawyer
InstanceOf: Practitioner
Title: "Corporate Lawyer example"
* active = true
* name.text = "David Pyke"

Security Considerations

That organizations that never allow a patient to be in a deny mode never need to look at Consent for access control reasons as there is no difference if the Patient has been given notice, or signed anything. In these cases the Consent is there for record keeping only. With the support for Change to opt-out, there is now a need for access-control to always look for Consent status. The most simple access-control will simply look for the existence of a Consent, check that it is .status = active, and that it is .provision.type = deny; if it is anything else then the access-control rule is that which is represented by the privacy policy.

Some patient specific provisions

The above examples were recording blanket agreement or disagreement by a given patient to a given policy. This is not as flexible as the Consent resource can support. The Consent resource can also record deviations, and special cases. These are recorded in the .provisions structure. The root level .provision simply sets the context as shown above. There is nested .provision(s) that can exist within the root level .provision, and even within other nested .provisions. Each level of nesting would contain the exceptions to the rules set down in the prior level, thus each successive level of nesting reverses the permit vs deny. In this way one can encode situations where broad sharing is allowed, but not sharing with Dr. Bob. The following is an example fragment of just the .provision. Note that the second nested provision is a deny provision with the only other element populated is the actor.reference of Dr. Bob.

...
* provision.type = #permit
* provision.provision[0].type = #deny
* provision.provision[0].actor[0].reference = Reference(example-dr-bob)

Instance: example-dr-bob
InstanceOf: Practitioner
Title: "Dr. Bob"
* active = true
* name.text = "Dr. Bob"

AND relationship between elements

Each .provision has elements that describe the setting for that permit or deny. Each element within a given .provision is in an AND relationship with the other elements in that given .provision. An element that is not populated indicates that for that kind of element there is no constraint. Thus in the above example, the deny provision for Dr. Bob has none of the other elements in that .provision filled out, so this means that Dr. Bob is forbidden access regardless of the role he might take on, or the purpose of use, or the action, or the class of data, or the dataPeriod timeframe of the data, etc.

Thus to say that Dr. Bob is not to get access to the data, except for patient directed purpose of use; one would have a Deny of all access by Dr. Bob, and a nested Permit of Dr. Bob AND patient directed purpose of use AND normal confidentiality data (not restricted). Note that it is not really necessary to repeat Dr. Bob in the third level, as logically the second level already restricted this branch to Dr. Bob.

...
* provision.type = #permit
* provision.provision[0].type = #deny
* provision.provision[0].actor[0].reference = Reference(example-dr-bob)
* provision.provision[0].provision[0].type = #permit
* provision.provision[0].provision[0].actor[0].reference = Reference(example-dr-bob)
* provision.provision[0].provision[0].purpose = http://terminology.hl7.org/CodeSystem/v3-ActReason#PATRQT "patient requested"
* provision.provision[0].provision[0].securityLabel = http://terminology.hl7.org/CodeSystem/v3-Confidentiality#N "normal"

OR relationship within an element

Repititions within an element are in an OR relationship. Thus to say that Dr. Bob is allowed this access on not just patient requested, but also family requested, and power of attorney; one would just put them all as alternatives on the purpose element.

...
* provision.type = #permit
* provision.provision[0].type = #deny
* provision.provision[0].actor[0].reference = Reference(example-dr-bob)
* provision.provision[0].provision[0].type = #permit
* provision.provision[0].provision[0].actor[0].reference = Reference(example-dr-bob)
* provision.provision[0].provision[0].purpose[0] = http://terminology.hl7.org/CodeSystem/v3-ActReason#PATRQT "patient requested"
* provision.provision[0].provision[0].purpose[1] = http://terminology.hl7.org/CodeSystem/v3-ActReason#FAMRQT "family requested"
* provision.provision[0].provision[0].purpose[2] = http://terminology.hl7.org/CodeSystem/v3-ActReason#PWATRNY "power of attorney"
* provision.provision[0].provision[0].securityLabel = http://terminology.hl7.org/CodeSystem/v3-Confidentiality#N "normal"

time scoped provisions

The provision.period is used to indicate that this provision is only active during a period of time. This is useful to indicate that Dr. Bob should be denied access until 2024, because I will be moving away from Dr. Bob in 2022.

...
* provision.type = #permit
* provision.provision[0].type = #deny
* provision.provision[0].period.end = 2024
* provision.provision[0].actor[0].reference = Reference(example-dr-bob)

timeframe for data

The provision elements are very powerful. We are not going to explain examples of all of them.

The provision.dataPeriod element is very useful, as it is not uncommon for a patient to remember a timeframe when they had a specifically sensitive healthcare episode. Thus it is easy to give a timeframe, where any data that was authored or last updated within that timeframe would be the context of that provision. The further advantage of this mechanism is that there is no indication of why or what is sensitive; just a timeframe.

For example, deny access to any data authored or last updated in 2018. This will block all data, regardless of what kind of data, or who is asking for the data.

Other examples

Not all of the examples given have been explained above.

IHE ITI Spring

The IHE domains of IT-Infrastructure, PCC, QRPH, and RAD had our workgroup meetings last week. Radiology met in-person at the RSNA, so got to socialize. I don't have details for RAD, PCC, or QRPH.

IT-Infrastructure met virtually all week. We did not make as much progress as we wanted to, due to  the lack of progress in the past few months. However we did make significant progress.

All formal publications will be available this month at https://profiles.ihe.net

Release for Trial Implementation:

• Basic Audit Log Pattern (BALP) will be released for Trial Implementation. This release will happen over the next few weeks.
• GitHub project - https://github.com/IHE/ITI.BasicAudit
• Publication - https://profiles.ihe.net/ITI/BALP - Version 1.1.0, Published May 4th
• This project focused on defining AuditEvent patterns for various general purpose auditable events. Specifically all FHIR RESTful interactions, and and Accounting of Disclosures. Augmentations of these to embellish the Patient as subject, and the user/client that is auth using SAML, or OAuth.
• This IG can be implemented directly. This IG will more be used as a foundation of the AuditEvent profiles, such as PMIR will show. 

Release for Public Comment:

• Mobile Care Services Discovery (mCSD) -- significant comments and changes to improve the usability and features. Because of these changes, we decided to publish for another Public Comment. 
• GitHub project - https://github.com/IHE/ITI.mCS
• Publication - coming soon

• Patient Master Identity Registry (PMIR) -- this is simply converting the specification from WORD/PDF into using the IG Publisher. There is no intended new feature. However given the new publication tooling there will be additional specification. One is that this IG will depend on BasicAudit as the pattern for some of the AuditEvent profiles.
• GitHub project - https://github.com/IHE/ITI.PMIR
  
• Publication - coming soon

Current Projects Kanban

• Scheduling for Patients or Providers 
• GitHub project - https://github.com/IHE/ITI.Scheduling
• Project Plan
• This will be inspired by the work done with the work done 4 years ago by Argonaut but is not constrained to the same solution.
  
  
• Mobile Health Documents  - Improvements based on current feedback
• GitHub project - https://github.com/IHE/ITI.MHD
• Project Plan
• Kanban board - https://github.com/orgs/IHE/projects/4
• CI Build - http://build.fhir.org/ig/IHE/ITI.MHD/branches/Improvements-2022/index.html
  
  
• MHD to a Federation 
• likely will transition to a Whitepaper covering all forms of multiple-depth federation support. With a focus on use of the features that this project has added to mCSD and MHD.
• use-cases for PUSH to a partner multiple hops away
• use-cases for Query to a partner multiple hops away
• Project Plan
• GitHub project -- tbd
• This will be a new whitepaper. 
  
  
• Extension to Secure Retrieve (SeR) Profile to support other HIE services
• This project will take the SAML/XACML mechanism defined for Secure Retrieve, and defined how it can be used to address other services in an XDS/XCA community such as patient lookup.
• Project Plan
• This will be an updated Supplement (WORD/PDF) 
  
  
• Update publications 
• We are now integrating the changes approved through the CP process.
• Incremental Quality improvements have been submitted to some of the ITI Implementation Guides and Technical Framework. When these are simply cleanup the changes are accepted as github issues, and pull-requests. These changes are available in the "current" Continuous-Integration (CI) builds; and will be moved into formal publication based on need and impact.

Next virtual Meeting is July 18-22

Other Activities

• The IHE profiles.ihe.net now has full analytics, so ITI can now tell specifically which parts of the technical framework are being used.
• The IHE profiles.ihe.net now has the DEV and RAD domains represented. QRPH is coming soon.
• Quality Improvements and templating improvements as identified.