RelatedPerson Consent - how to record the #FHIR Consent that authorizes a #FHIR RelatedPerson

This article summarizes a concept that came from my blog reader. This is actually published in a personal Implementation Guide at -- https://johnmoehrke.github.io/RelatedPersonConsent/ . This concept has not been proposed as a formal work item, but I think it would fit nicely in IHE Basic Patient Privacy Consents for Mobile that I have proposed (more on that soon).

This IG focuses on a use-case where the existence of a representative (e.g. guardian) is backed by a rationale and agreement from the Patient. Specifically some cases:

1. When the Patient is a minor and the representative is a parent.
2. When an adult Patient is physically or mentally competent, but still wants to appoint a representative to manage his/her medical records (e.g., a Lawyer).
3. When the Patient does not have competency to manage their medical records, thus some representative is assigned.
4. When the courts appoint a representative.

There may be more, but this list gives us a set of perspectives upon the reason why there is a need for a Consent to back the representative.

Thus

• Patient resource is used to identify the Patient
• RelatedPerson resource is used to identify the representative
• Consent resource is used to document the Patient agreement with the representative. This might further be used in advanced cases to define what the RelatedPerson is allowed to do, and thus differentiate between multiple RelatedPerson resources a division of responsibilities.

Relationship between RelatedPerson and Consent

The RelatedPerson resource would be the way that most will document a relationship between a patient and a representative (e.g., guardian). It is a clear link between the Patient and the other person. However the RelatedPerson does not have anywhere to explain the details of why the relationship exists, or any conditions on the relationship. There is a RelatedPerson.relationship that can be used to differentiate some roles, but this is very coarse level.

• RelatedPerson.relationship has a clear code for Father, Mother, etc.

It is not clear to me that the RelatedPerson needs to have some indication that there is a Consent explaining the rationale. One would determine this by searching for Consents that point at the RelatedPerson instance. It is possible that the RelatedPerson.relationship could hold normal codes explaining the relationship, and one more that indicates that a rationale is available. Not clear that is proper or needed. It is also possible that there should be an element in RelatedPerson to point at the Consent, but I am not sure yet about that either.

Thus for any given RelatedPerson, one can look for Consent.provision.actor.references that include the RelatedPerson.id value. this can be done by searching on Consent using the actor parameter:

GET [path]/Consent?actor=RelatedPerson/1234

might be good to make sure the Consent is for that patient, and that the Consent is PERMITing that RelatedPerson… etc…

There are other rules that might be possible to do with invariants, but I just itemize them:

• The RelatedPerson.patient must be the same as the Consent.patient
• The Consent.provision.agent.reference must be the same as the RelatedPerson.id
• The Consent is authorizing (permit) the RelatedPerson, and is not expired.

Authorizing Consent Extension

This may seem cumbersome, so I was thinking that an extension in RelatedPerson that explicitly points at the Consent would be more appropriate.

• Extension for indicating a Consent justifies / authorizes

Thus in this IG there is a minimal profile on RelatedPerson that simply indicates that this extension is needed.

Note that this extension does make the creation of the Consent and RelatedPerson resources difficult as they both reference each-other. Thus from a purely REST perspective one needs to create the RelatedPerson resource, then create the Consent that points at the RelatedPerson, then UPDATE the RelatedPerson to add the extension that points back at the Consent. This kind of double pointers is discouraged in REST and in FHIR.

Consent profiling

As with any Consent, often there is paperwork that ultimately holds the legal details. This legal paperwork is critical to overall legal precedent, and represents the ceremony of the act of consent from the patient. These details should be captured by a DocumentReference and Binary. The Consent.sourceReference would then point at that DocumentReference. (Could use Consent.sourceAttachment, but I am not a fan of bloating the Consent with that detail).

The Consent then would need to be profiled. The main difference from the FHIR core Consent I outlined in my Consent article is that this might be a specific kind of Privacy Consent delegating authority, and the RelatedPerson instance would be indicated specifically in the .provision.agent.

• status - would indicate active
• category - would indicate patient consent, specifically a delegation of authority
• patient - would indicate the Patient resource reference for the given patient
• dateTime - would indicate when the privacy policy was presented
• performer - would indicate the Patient resource if the patient was presented, a RelatedPerson for parent or guardian
• organization - would indicate the Organization that presented the privacy policy, and that is going to enforce that privacy policy
• source - would point at the specific signed consent by the patient
• policy.uri - 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.
• provision.agent.reference - would indicate the RelatedPerson resource
• provision.agent.role - would indicate this agent is delegated authority
• provision.purpose - would indicate some set of authorized purposeOfUse

In the case where the court or some actor that is not the Patient is compelling the RelatedPerson relationship, then the Consent.performer would indicate that the Patient is not the one granting the relationship, but rather the guardian or the courts.

using Consent to enable access control

One advantage of using a Consent resource as defined here is that there would be a natural set of provisions in a Consent that would be processable by an Access Control engine that understands Consent. This Access Control engine would not need to understand RelatedPerson, other than to know that a given user is a RelatedPerson (vs Patient, Person, Practitioner, etc). Thus the Consent.permit rules are used to mediate access to that Patient’s data by that given user.

Consideration

Given this setup, a newborn would need a Consent drafted as soon as that newborn has a Patient resource to enable the parents’ access. This could be done by the system creating the newborn Patient resource. This could also be done using Implied Consent mechanisms, which is a default policy that is used when no Consent exists for a given Patient->agent relationship.

Same is true for any new Patient for which there is some precedent for implied consent representative.

Forcing a Consent to exist does prove that the representative relationship is explicit, and is thus more transparent. Implied representative relationships are common, but not very transparent.

Workflow of capturing the Consent

The Consent resource is not intended to be used to drive the workflow of the capturing of the Consent. The Consent is following the “Event Pattern”, which means that it is the output of an event. The workflow that preceded this event would need to be managed by other resources in the Request pattern

The Task resource is generic and can do this work. There are some specializations of Task, so we could end up at some kind of a Task derivative that is specific to the workflow leading up to a Consent. However it is first best to see if Task can be profiled to address the workflow.

For example a use-case where the Patient nominates a potential Person to become their RelatedPerson; that triggering a GP to review and approve it; that triggering some legal review and approval; resulting in a Consent instance and the creation of the RelatedPerson. This workflow could be profiled into an ActivityDefinition… I like the power of this modeling concept, but have not done it formally so am not sure of all the possible issues.

Note we have tried to keep workflow states out of the Consent.status; but some states have gotten in that I don’t think are proper. But at this time we allow them in until there is a more formal task flow.

Examples

There is a basic example of a Patient delegating their father as their RelatedPerson. The resource objects are clickable to their examples.

• Patient
• Father as Related Person
• Consent from the Patient authorizing the Father as a Related Person

IHE-Connectathon around the world and back

IHE-Connectathon is scheduled for September 12-16, 2022.

• IHE-USA -- https://www.iheusa.org/ihe-na-connectathon -- Atlanta
• IHE-Europe -- https://connectathon.ihe-europe.net/connectathon-2022 -- Switzerland
• Everywhere -- virtual -- anywhere around the globe or space-stations

Many FHIR based IHE - Profiles (Implementation Guides) will be tested, in addition to the other popular Interoperability specifications from IHE. There will even be some testing of HL7 published Implementation Guide.

I will be present in Atlanta, as hard as I have tried to be sent to Switzerland.

IHE Most Salient - based on specification use analytics

IHE, especially the IT-Infrastructure domain, has been publishing specifications in HTML format and Implementation Guide format on a new web site -- https://profiles.ihe.net.  

This web site is enabled with Google Analytics. Thus there is some data available that indicates which parts of the IT-Infrastructure specifications are of interest. Presuming they are interesting because they are used. Google Analytics data is not perfect, there will be no analytics from people using script blocking Browsers. So, there is likely 25% more activity than the analytics show.

Just looking at the data for May 2022. The first view is that the IHE specifications are of global interest. This is dominated by the USA, but is quickly followed by Germany, Italy, France, India, Netherlands, Austria, China, Canada, and Switzerland.  From the picture, there is interest almost everywhere. Actually, I wonder why not everywhere? 

The next perspective is to just growth over time. So over the month of May the number of users (as defined by google analytics, don't ask me to explain that) is growing. Fun part of this diagram is the purple line that shows that the readership does indeed, mostly, take the weekends off. 

Last perspective is to simply look at the traffic per page, as viewed as traffic interest per Profile/Specification. So the following is the ranked list of IT-Infrastructure Profiles in the order. I have included some fun graphics. No, I am not going to explain the graphics.  Note that 40% of these are #FHIR  based.

1. Cross-Enterprise Document Sharing (XDS.b)

2. Audit Trail and Node Authentication (ATNA) Profile

3. Mobile Access to Health Documents (MHD)

4. Patient Identifier Cross-referencing (PIX)

5. Cross-Community Access (XCA)

6. Patient Demographics Query (PDQ)

7. Patient Demographics Query for Mobile (PDQm)

8. Internet User Authorization (IUA)

9. Patient Administration Management (PAM)

10. Cross-Community Patient Discovery (XCPD)

11. Cross Enterprise User Assertion (XUA)

12. Basic Patient Privacy Consents (BPPC)

13. Consistent Time (CT)

14. Patient Identifier Cross-reference for Mobile (PIXm)

15. Cross-Enterprise Document Reliable Interchange (XDR)

16. Basic Audit Log Patterns (BALP)

17. Mobile Health Document Sharing (MHDS)

18. Patient Master Identity Registry (PMIR)

19. Cross-Enterprise Document Media Interchange (XDM)

20. Mobile Care Services Discovery (mCSD)

21. Comprehensive FormatCode Vocabulary

HL7 Security & Privacy Tutorial: July 12-14

HL7 FHIR Security & Privacy

The HL7 FHIR Security & Privacy online class describes how to protect a FHIR server (through access control and authorization), how to document what permissions a user has granted (consent), how to enable appropriate access by apps and users and how to keep records about what events have been performed (audit logging and provenance).

Virtual Classroom : July 12-14

This will be a refreshed version of the Tutorial I have given annually to HL7 2021, 2020, and 2019. Each year I do update and enrich the content. More, if you ask questions.

My slides are freely available on google slides at this easy to type address http://bit.ly/FHIR-SecPriv. Each time I give the tutorial I update these master slides. So each time you go there you will see the latest set of slides. Some slides do have notes, and there are additional detail in slides that I don't cover during the tutorial.

In the past, I have had to compress these into two parts, but will be able to give them in the natural three parts

Part 1 - Basics

• Security Principles
• Privacy Principles
• Basic Security and Privacy Considerations
• Anonymous Read
• Business Sensitive
• Individual Sensitive
• Patient Sensitive
• Not Classified
• HTTP[S] - TLS
• Authentication & Authorization
• SMART on FHIR
• IUA
• Mutual-Authenticated TLS
• Access Denied Responses

Part 2 - FHIR capability

• Provenance
• Basic
• Digital Signature
• Audit Logging
• Audit Reporting
• Audit Purging
• Consent - for Privacy
• HEART
• Permission 
• Attribute Based Access Control
• Security Tags
• Compartments / Clearance
• Obligations
• Break-Glass
• De-Identification

Part 3 - Practical application

• Multiple Organization Provider Directory
• using relational linking
• Multiple Organization Profile Directory
• using security tags as compartments with clearance
• Extra-Sensitive Treatment
• Share with Protections
• De-Identified Research

Note that ALL of these topics have been covered in this blog. See Security Topics, Consent/Privacy, and FHIR for index to these articles.

   

Notes and references that I posted after last years presentation

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.