I have played with Open GPT Chat for a couple of weeks. Mostly being scared at how good it is, laughing at the mistakes, and having it write FHIR code. I have seen other bloggers asking Open GPT to write in their voice, so I gave it a try... I didn't know I had a style, let me know if you agree with the style. I will continue to write blog articles myself...
Note the FHIR code was the worst, first because it was trained on the internet long ago so it only knows only about FHIR STU3, and it clearly doesn't understand the FHIR model as when I asked for how to expire a Consent it just added json element - `expires`.
Write a blog on Healthcare Privacy Consent in the voice of John Moehrke.
As a healthcare professional, I am well aware of the importance of protecting patient privacy. This means not only safeguarding sensitive medical information, but also obtaining the proper consent before sharing that information with others. In this blog, I want to talk about healthcare privacy consent and why it is so crucial.
First, let's define what we mean by healthcare privacy consent. This refers to the process by which a patient gives their permission for their personal medical information to be shared with others. This could include healthcare providers, insurance companies, or even family members.
Obtaining healthcare privacy consent is not just a matter of good manners, it is also required by law. The Health Insurance Portability and Accountability Act (HIPAA) sets strict guidelines for how and when personal medical information can be shared. Failure to obtain the proper consent can result in fines and other penalties for both the healthcare provider and the individual who disclosed the information.
But why is obtaining healthcare privacy consent so important? For one thing, it gives patients control over their own medical information. They get to decide who gets access to their records and who doesn't. This is especially important in cases where the information could be sensitive or embarrassing, such as mental health or sexual health records.
In addition, obtaining healthcare privacy consent helps to build trust between patients and their healthcare providers. When patients know that their information will only be shared with others who have their permission, they are more likely to be open and honest with their healthcare provider. This, in turn, can lead to better care and better health outcomes.
Obtaining healthcare privacy consent can also help to prevent medical errors. When multiple healthcare providers are involved in a patient's care, it's important that they have access to all the relevant information. Without the proper consent, some information may be withheld, leading to gaps in the patient's medical history. This could result in the provider making decisions based on incomplete information, which could have serious consequences.
So, what can healthcare providers do to ensure that they are obtaining the proper healthcare privacy consent? The first step is to make sure that patients are informed about their rights and the importance of consent. This can be done through informational materials, such as pamphlets or posters, or through verbal communication during the patient's visit.
Next, it's important to have a clear and concise consent form that is easy for patients to understand. The form should clearly state who will have access to the patient's information, why they will have access, and how long the consent will remain in effect. It should also give the patient the option to withdraw their consent at any time.
Finally, healthcare providers should make sure that they are keeping accurate records of when and how consent was obtained. This will help to ensure that they are in compliance with HIPAA and other relevant laws, and will also provide a record in case there are any disputes about consent later on.
In conclusion, obtaining healthcare privacy consent is crucial for protecting patient privacy and ensuring that they receive the best possible care. As a healthcare professional, it's my responsibility to make sure that I am obtaining the proper consent before sharing a patient's information with others. By doing so, I can help to build trust, prevent medical errors, and ensure that my patients receive the best care possible.
IHE has agreed to work on the Privacy Consent on FHIR implementation guide. This is the work that I hinted at in IHE FHIR Privacy Consent IG. I am so happy that it won't be called BPPCm, although I am not all that happy with "FHIR" in the name as the name should invoke an understanding of the problem being solved, not the solution. But we tried out many alternatives and "PCF" seemed best.
I have started work on the implementation guide. You can follow the github repo, or the CI build. There is not much to look at right now, but by the time you read this article I might be much further along.
I have some questions and request some feedback...
Stepping Stone Maturity Levels
I have often considered Privacy Consent to be something for which one approaches with some stepping stones. The ultimate Privacy Consent features are actually very complex, and truthfully impossible to reach. Certainly impossible to reach in one step. So I have built in some "stepping stones", I have heard others ask for "maturity levels". However you call it, there are simple use-cases and increasingly more complex. The simple use-case "should not" be acceptable to anyone, but starting simple gets the infrastructure started and ready for the next step.
So I have come up with four levels, each builds upon the prior:
Implicit Consent -- simply that a system declares that it can handle a default policy to be used when there is no Consent on file. This default policy support would include: deny all, deny except for break-glass, permit for treatment only, permit for any otherwise authorized.
Explicit Basic Consent -- support for explicit Consent with a few patient specific parameters to enable the Consent to identify specific agents that can/can't access for a small number of purposeOfUse, and where the data to be protected can be identified directly or by timeframe of authorship.
Explicit Intermediate Consent -- support for named PurposeOfUse research projects, data identified by author of that data, and data identified by relationship to identified objects such as an Encounter or CarePlan.
Explicit Advanced Consent -- Support for data sensitivity tagging. This requires implementation of a Security Labeling Service, but does not define an Actor for this. The expectation is that a Security Labeling Service is a more intimate systems-design, and would not likely be implemented as an abstract Actor. This approach allows for multiple architectures.
As I indicated in my proposal, I think there are maturity beyond this that eventually might be approachable. But at this time these far more advanced use-cases are not realistic. Most interesting to me are the ability to propagate residual obligations and refrains. So my intent is to focus on these approachable solutions, and work on the use-cases beyond later. I know that there are real use-cases that need more, I am just looking to make progress.
Note that even these stepping stones might not be reasonable... so please let me know what you think.
Actor gymnastics
The Actors involved in capturing consent are very simple. This is simply a RESTful interface of Create, Read, Update, Delete, and Search. The Consent resource will be profiled for the stepping stones, but that is also rather simple FHIR profiling.
The hard part is diagramming how a participating FHIR Client application doing typical FHIR REST interactions with a participating FHIR Server can be enhanced such that the Client will not get any
data that it should not get. The systems design engineer in me wants to show the systems design, but this is not the diagram modeling of abstract actors. Add to this that the likely solution for this is to use OAuth, which is already very complex diagramming at the system level.
I tend to want to separate the Actor that will make the Access Control decision based on the Consent, from the Actor that will enforce that decision. This is a typical abstraction in Access Control, and is also fundamental to oAuth. But it makes for really strange abstract Actors.
Further, these Consent Decisions are based upon predicate Access Control decisions that allow the client application to make a request, and the user to make the request based on a user identity. My understanding is that the term "Cascading oAuth" is used to explain this. Simple form of this in SMART-on-FHIR is that the SMART access control decision is based upon an oAuth interaction with the Open-ID-Connect. So adding in Consent Access Control is adding one more layer to this, or "cascade".
Help Me
So this is a request to help me out. Are these Maturity Levels useful and proper? How might I better diagram the enforcement side?
The HL7 FHIR Security & Privacy classroom tutorial 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).
This will be a refreshed version of the Tutorial I have given mostly annually to HL7. 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 is additional detail in slides that I don't cover during the tutorial.
I will have to compress these into just two parts, so look for some of this to not be covered
IHE IT-Infrastructure has agreed to start a new work item on the topic of Privacy Consent, using FHIR. This minimally would be a re-evaluation of the use-cases in BPPC for use with FHIR Consent, but likely will go beyond that scope simply because of modern needs, modern toolings, and ease at which the FHIR Consent can support them.
I really don't want to call this new IHE-Profile "BPPCm", the BPPC acronym is hard enough to say without tacking on an 'm'. What should this implementation guide be called? The inclusion of the technical solution (FHIR) is discouraged as it indicates a solution before the problem is identified. The name could be very generic, like Privacy Consent IG, but we do tend to indicate in the title the scope limits in the use-cases.
Proposed Scope
Much like BPPC does for XDS community. This Implementation Guide (IG) would do for FHIR community. This IG could be used with MHDS, which already has some of the framework for more specific Consents, but BPPCm would be more complete than what is indicated in MHDS. This IG could also be used for organization use or community use beyond MHD/XDS, which would include use-cases like QEDm, and IPA. This would leverage BasicAudit to record access control decisions and recording of consents.
This IG would
Define a set of privacy policies with canonical URI and/or code.
Define a set of Consent patterns that are foundational.
Define actors for creation/update of Consent, Registry of Consents, Decision actor, and Enforcement actor.
This section 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.
Consent Policy
some policy URI could be defined for common consent terms. Not clear that these will be detailed enough to use in practice, but would be useful categorization of policy types.
Explicit Permit (patient elects to have some information shared) is required which enables document sharing
Explicit Deny (patient elects to not have information shared) stops all document sharing
Implicit Permit allows for document sharing
Explicit Deny of sharing outside of use in local care events, but does allow emergency override
Explicit Deny of sharing outside of use in local care events, but without emergency override
Explicit Permit authorization captured that allows specific research project
Change the consent policy (e.g., change from Permit to Deny)
In each of these cases the provisions of the instance of Consent could further constrain.
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).
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.
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.
Some patient specific provisions
Authorizing or Denying access to:
who by a given Practitioner, CareTeam, RelatedPerson
why by a given Purpose Of Event codeswhy by a given named Research projects
data by Confidentiality class (Normal, but not Restricted) -- presumes a mature SLSdata by sensitivity class -- presumes a mature SLS
data by authored timeframe
data by authorship (authored by someone in organization XYZ)
data by identifier (explicit reference)
when specific period of time data can be accessed
Not likely to be in scope
These seem to be possible with Consent resource in R4, but not clear they are priority or even possible.
Use of Consent besides Privacy (consent to treat, advanced directives)
.action -- this is not well enough defined in Consent
applied obligations or refrains -- no clear place where these go in Consent
.class -- this is not well enough defined in Consent
data related to an identified data resource (e.g. all data related to this Encounter)
Add a Generate Metadata that adds the ITI-106 operation that allows for one structured/coded document to be published.
Add a Simplified Publish option that allows for one DocumentReference with the document in the .data element to be published, expecting the Document Recipient to create the SubmissionSet derived off of the DocumentReference and Community mapping policy.
Add an ITI-65 FHIR Documents Publish option with support in ITI-65 to include a FHIR Document Bundle as an alternative to Binary. This makes less the burden on the Document Source to serialize the content into an appropriate Binary format, as that requirement is moved to the Document Recipient. There are use-cases where the Document Recipient will use the FHIR Document Bundle directly, and there are requirements on the Document Recipient to serialize the FHIR Document Bundle when grouped with non-FHIR Actors like XDS/XDR/XDM.
Each of these new options may survive or may be removed. Please voice your interest, and sign up for IHE-Connectathon to test these options. Based on interest these Options may survive or be removed.
better clarity on types of Identifier
a method has been added to support DocumentReference replace that is used by the Document Source to mark the old/replaced DocumentReference instance as superseded.
There are no functional changes or breaking changes. This release is primarily to address validation messages that have been made more strict by HL7 than when 1.1.0 was released.
clarify explanation of each structureDefinition profile
cleanup examples with explicit slice use to eliminate validation warnings
Expanded scope of services that can be secured beyond XDS Retrieve
These releases are continued improvement and advancement of the Document Sharing Health Information Exchange, and enabling of Community exchanges that are more than Document Sharing. Very focused on #FHIR, but also enabled by existing and successful XDS/XCA Health Information Exchange.
In development
The IT-Infrastructure committee is continuing to advance the state of the art. There are three specifications in development at this time.
New Implementation Guide on Scheduling (aka calendar). This work item is taking lessons learned from the Argonaut project on scheduling that has stalled at STU3. The work is in cooperation with the Argonaut project approval. The project is focusing on simple appointments with proposed #FHIR Operations for finding appointment slots, holding an appointment slot, and booking an appointment slot. Current committee draft
A whitepaper that focuses on how various Health Information Exchange topologies can be architected. Indicating the various design decisions, with benefits and drawbacks. These topologies that will be described will start with simple single-depth, but will be more focused on the complexity as multiple-depth networks are needed and where various sub-networks have different architectures. Current committee draft
XCPD Revoke Transaction - This was a CP, but has become a work item due to the scale of the changes -- The XCPD Health Data Locator and Revoke Option supplement adds a Revoke message to ITI-55. The Revoke message is really an entirely separate message, with its own Message Semantics, Trigger Events, Expected Actions, etc. separate from the main Cross Gateway Patient Discovery message in ITI-55. Therefore, it would make more sense for the supplement to introduce this message as its own transaction rather than add it on to ITI-55.
A FHIR centered Patient Privacy Consents Implementation Guide -- The name of this will be determined sometime in the future after the set of use-cases are decided upon. Initial scope is to replicate the BPPC functionality except using FHIR Consent rather than CDA. There may be some of APPC brought in given the functionality of FHIR Consent. Thus the use-cases would tend to be around the same Consent functionality at controlling HIE access to Document scoped data. Future versions might expand to data scope at the FHIR resource level.
I welcome participation in IT-Infrastructure to help with these work items, and propose work items of your own. IHE is a much lower overhead than HL7, yet focuses on producing tightly conformance specifications that are formally tested at IHE-Connectathon.
Data may be “Normal” medical data or “Restricted” medical data. The distinction is for this IG focused purely on data classification for sensitive topics.
The various clinical Resources in FHIR are very complex and highly variable. Although Observation is the most often used Resource, sensitive data may exist in ANY other FHIR resource including Allergies, Procedures, CarePlan, Medication, Problems, DiagnosticReport, DocumentReference, ImagingStudy, Genomics, etc… By assessing the sensitivity classification and placing that assessment into a well-known location found in all FHIR Resources - .meta.security, the Access Control does not need to be aware of the kind of FHIR Resource, it can just process the data as a DomainResource and simply look at the .meta.security element.
The classification of data into sensitive topcs is the role of the Security Labeling Service (SLS). The SLS inspects the data, and may use the context of the data to identify the sensitivity classification. It is expected that most data will not be considered sensitive, aka “Normal”.
Data tagging Considerations
Some data are direct and clearly in a sensitive category. But there can be indirect relationships, such as three medications prescribed together are a clear indication of a sensitive category but are not individually.
Some data may also not be sensitive in the coding, but rather sensitive in the narrative, this would be poor data quality but it is a reality that should be considered. Thus an SLS may need to include some Natural Language Processing to find sensitive human words in narrative.
Some approaches use well-defined ValueSets, where others use a list of words. The list of words can be search across the data without regard for the data structure, which has the benefit of not needing to have the SLS data schema aware. The list of words can be codes, such as snomed numeric codes.
Architecture approaches to data tagging
When the SLS is executed is a systems design decision. General alternatives are:
Pre Tagging data
Tagging the data as it is created, updated, or imported.
Which has the advantage that the access to the data does not need to assess the data, it just uses the existing sensitivity tag.
This solution is likely to be more performant on use of data, but may not have as accurate sensitivity tags due to the dynamic nature of policies around sensitivity, and dynamic nature of data relationships. This solution also requires that the EHR database support data tags. Use time tagging data
Alternative is that the data are temporarily tagged prior to use, thus the sensitivity is freshly determined and used only for that access enforcement
This solution does not require that the EHR database be updated to support tagging of data, but may incur a performance impact on data use.
Example ValueSets
One way to understand a very basic SLS is that it looks for clinical codes in the data. It might do this using ValueSets, but likely would need to do this in a more performing way.
There are some valueSets that were authored 9 years ago by SAMSA (requires a free login to see the details). This was during a critical point in the early development of the use of Security Labeling. These valueSets are old, but they are informative. Any standards based managed ValueSet would need to be used as input to a organizational use in an SLS. So the fact these are 9 years old is not as important as that they are a well informed base to start with. I have put the SAMSA valuesets into some ValueSets of my own.
This is a quick article on a requirement of the MHD Document Responder that may be less obvious to some. The specific requirement is related to chained search parameters, like `patient.identifier`; `source.given` and `source.family`; and `author.given` and `author.family`. These search parameters have a `.` that indicates that one is to search deeper, aka chaining the search value to a different kind of resource and use the results in the primary search.
The requirement is hinted at being special with a mention of FHIR Chaining Parameters:
But these hints might not be enough, because they do not tell you how to solve the requirement, and this is because there are many ways to solve this, and the implementation details of your system are more important than any factor.
The hints just indicate that the parameter provided is to be matched in a chained way. For example with patient.identifier the parameter is an identifier that should be first looked up with the Patient Identity Manager to find the Patient resource that is then used to find the DocumentReference resources.
That hint tells the Document Responder, that when the Document Source chooses to use `patient.identifier` rather than `patient`; that the Document Source is expecting the Document Responder to do this lookup, rather than the Document Source to do that very same lookup. So, it seems reasonable that queries using chained search parameters might be slower than those that are not.
There are cases where this is inverted, such as when the MHD has an XDS or XCA backend; in these cases the use of patient.identifier that is from the Affinity Domain or Community is better than providing the Patient link. As when a Patient link is the search parameter then a MHD front end to XDS or XCA would need to convert the patient link into the Affinity Domain or Community. This case is likely to be a system such that the Document Responder can quickly do this lookup.
Another place where patient.identifier is going to be preferred are environments that have a national patient identifier. In these cases the national patient identifier is more readily available to both Document Consumer and Document Responder. In these cases it is possible that the DocumentReference.subject element could hold both the Patient id link and the national patient identifier.
The chaining of given name and last name are similar but different in how one must support them on the Document Responder given the system design you have.
as to the different Consent Standards.. I likely don't know about all of them, but here are some. I am also not indicating that there should be no improvement or even new standards. I just don't want historic lessons-learned to be lost.
There are some projects that claim to be profiling Consent, but they are not yet published.
There is work in FHIR to add a Permission Resource. This would possibly be used by Consent in the future, but that future is likely 5 years out - http://build.fhir.org/permission.html
Four publications released from IHE IT-Infrastructure, three in development:
Release for Public-Comment -- Sharing of Valuesets, Codes, and Maps (SVCM) -- This is now published in Implementation Guide format, previously in PDF supplement format. This IHE-Profile (aka Implementation Guide) provides guidance on how to implement the sharing of terminology ValueSets, CodeSystems, and ConceptMaps. It is not a full Terminology Service, just the basic starting point that can be used to get a Community aligned.
Release for Public-Commet -- Secure Retrieve (SeR) -- This is now a html publication, previously in PDF format. In addition to the conversion, the scope of the Access Control Decision and Enforcement is expanded beyond the Document Repository to the other services in a Health Information Exchange -- Community.
Release to Trial-Implementation -- Patient Master Identity Registry (PMIR) -- This is newly converted to Implementation Guide format, previously in PDF supplement format. The release recognizes the reconciliation of public comment. This IHE-Profile (aka Implementation Guide) provides for a Health Information Exchange Community to cooperate on a golden (master) identity for the Patients. This is distinct from a PIXm, which is a Community cooperation on cross-references of many identities for each patient. The PMIR does not forbid local participants from having their own internal identifier for patients, but rather expects that organization utilize the Community agreed to Patient Identity when communicating outside the organization.
Release to Trial-Implementation -- Mobile Care Services Discovery (mCSD) -- This release is in Implementation Guide format, and has also been improved to support Communities using a variety of network topologies. The mCSD provides a Directory/Registry feature to enable a Community and/or Cross-Community discovery of Organizations, Facilities, Locations, and Endpoints.
These releases are continued improvement and advancement of the Document Sharing Health Information Exchange, and enabling of Community exchanges that are more than Document Sharing. Very focused on #FHIR, but also enabled by existing and successful XDS/XCA Health Information Exchange.
In development
The IT-Infrastructure committee is continuing to advance the state of the art. There are three specifications in development at this time.
Improvement to Mobile Health Documents (MHD) to support more simple Document Source applications. Recognition that the current methods for Publishing or Pushing documents is not always needed to be fully implemented in Document Source actors. Thus there is developments to support a more Simplified Publish, an operation that will extract the metadata out of a well-formed CDA or FHIR-Document, and a few more clarifications. Current committee draft
New Implementation Guide on Scheduling (aka calendar). This work item is taking lessons learned from the Argonaut project on scheduling that has stalled at STU3. The work is in cooperation with the Argonaut project approval. The project is focusing on simple appointments with proposed #FHIR Operations for finding appointment slots, holding an appointment slot, and booking an appointment slot. Current committee draft
A whitepaper that focuses on how various Health Information Exchange topologies can be architected. Indicating the various design decisions, with benefits and drawbacks. These topologies that will be described will start with simple single-depth, but will be more focused on the complexity as multiple-depth networks are needed and where various sub-networks have different architectures.
I welcome participation in IT-Infrastructure to help with these work items, and propose work items of your own. IHE is a much lower overhead than HL7, yet focuses on producing tightly conformance specifications that are formally tested at IHE-Connectathon.
Future projects
Some potential next projects, based on interest and resources:
I was asked to explain how Break-Glass works. There is not a solitary answer, as the context is very important.
Define Break-Glass
A method used by authorized clinical people to gain access to information that the patient has indicated they want held more confidential, when that clinician has made a medical assessment that there is a safety concern that the confidential information may help shed light.
Used only in Treatment use-cases. It would be inappropriate for a Billing/Payment use-case to invoke Break-Glass.
Not the Emergency-Room use-case. The Emergency-Room tends to focus on stabilizing the patient and this can often be done in complete absence of historic data. Further when data are available, the clinicians in the Emergency-Room tend to already be operating at elevated privilege.
Used only by authorized users. Not all clinicians are going to be given this authority.
Medical safety concern. The clinician is expected to be making a medical safety decision. This concern is often gathered as rational for invoking Break-Glass.
Post analysis. Break-Glass events should happen very rarely, but when they do the Audit Log must be relied upon to provide transparency to the activities. Thus, the Audit Log might be more detailed during a Break-Glass activity. The activity of Break-Glass should cause a post analysis, where the Audit Log is examined for if the declaration of Break-Glass was necessary and appropriate.
Patient Privacy Consent restricts some data for Treatment. Note that if no restrictions for Treatment are given, then Break-Glass doesn't apply as it would result in no additional data access.
Patient Privacy Consent does not forbid Break-Glass. There are some settings where it is allowed for a patient to indicate they would rather suffer safety concerns than have the data exposed. Most settings don't allow this kind of thing, trusting their clinicians more.
So, by this point we know there this is a use-case where break-glass applies, the patient has authorized break-glass, there is a need to blind some information from this clinician, and that the clinician does possess the permission to declare break-glass; so it is only now that we need to do something special.
Internal logic of the EHR. If the use-case does not need to extend outside of the EHR, then there is no need for a standardized solution.
Some workflow mechanism. It is possible for Break-Glass to be supported in ways that have nothing to do with the Security layer. These solutions tend to treat Break-Glass as a pathway thru the other clinical flows.
Thus for Security layer solutions tend to focus on use of
PurposeOfUse of BTG (Break-the-Glass). Typically, clinical flows use TREAT as the PurposeOfUse to indicate the request is triggered by a normal treatment use-case and that the data returned would be used for normal treatment use-cases. The BTG would be an additional PurposeOfUse to indicate that Break-Glass has been appropriately declared.
How BTG is declared is covered below...
How does User know Break-Glass could be used?
This section is looking at how the user would know that Break-Glass 'could' be used. In theory, the non-authorized users would not be told that there are data that are blinded to them. Thus, only the users that hold the authority to declare Break-Glass would be notified that there are data that are blinded to them under normal treatment.
It is possible that there is no feedback mechanism. Thus, those with the authority to Break-Glass would simply declare Break-Glass when they "felt" that data might be being blinded that might have some impact on safety.
The advantage of this is that the clinician is never presented with some indication. There have been incidents that some clinicians overly focus on the blinded data if they know that there are data that are blinded.
The disadvantage of this is that unnecessary Break-Glass events will be declared. This disrupts the clinician's flow, forcing them to detect if the Break-Glass action gave them more data or not; and causes safety / privacy investigation of many Break-Glass actions.
An advantage is that this does not require any additional detection logic on normal transaction requests, and does not have an atypical response.
This approach might be useful as a steppingstone to a more mature solution.
FHIR OperationOutcome. All responses to requests in FHIR can carry a OperationOutcome. The OperationOutcome could indicate that BTG could be used. This would be indicated with an issue in the OperationOutcome that is clearly just information / informational. But would require that there be some yet-to-be-defined code to indicate that Break-Glass may be useful
The FHIR Bundle that is returned might have a Bundle.meta.security tag that indicates that some data were redacted (REDACTED). This is a Bundle security tag, as it is about the transaction results, and not about any specific data inside the Bundle (actually about data not in the Bundle). This tag would not be included for those users not authorized to declare Break-Glass.
There might be a service request to see if data are blinded. Might be a simple service that returns true if some blinding rules are found in the patient's Consent.
With OAuth, if the JWT was exposed (possibly thru an introspection API), then the conditions in the JWT might indicate if blinding rules are expected to be applied. This does not indicate they were needed to be applied, just that there are residual obligations to be enforced at the Resource Server / Enforcement Point.
???? I don't know of another method. There might be something in http? I don't know of anything that would be linked to OAuth or any profile of OAuth.
FHIR Technical Solutions for declaring Break-Glass
At this point we know that the clinical user has the rights to declare Break-Glass, and has come to some clinical decision that it is appropriate to invoke Break-Glass. I think this looks different in the case of an end-user app accessing data via FHIR, from a clinical organization requesting healthcare data from another clinical organization.
Business-to-Business
In the case of Business-to-Business, where both businesses are part of a Trust-Framework that has enabled Federated Access Control, the initiating organization would have some logic within that organization that checks that their user is authorized to Break-Glass, and some mechanism for that user to declare Break-Glass. Thus in the Business-to-Business use-case the only thing that gets exposed at the Interoperability layer is that the requesting organization security token needs to look different for normal Treatment from Break-Glass. This nicely fits in the PurposeOfUse.
OAuth. The OAuth flow could provide the User-Interface that the Clinician uses to request and get Break-Glass permission. The token issued would indicate normal or break-glass in some token opaque way (many tokens are opaque to all but the OAuth authority and the resource-service enforcement).
OAuth using the BTG PurposeOfUse. There are JWT mechanisms for encoding PurposeOfUse in the JWT in the IHE Implementation Guide on using OAuth with FHIR.
SAML. Predating the use of OAuth is the use of SAML within nationwide health exchanges (XDS/XCA using SOAP). In the SAML flow it has always been one organization declaring the context of their request to the other organization. This SAML assertion would include the user identity that triggered the event, but the request authorization was always an organizational request. These SAML assertions relied on PurposeOfUse to set much of the context. And thus the use of BTG (or historically ETREAT) was the indicator for Break-Glass.
Break-Glass service. It is possible to have a workflow mechanism that is invoked to indicate that Break-Glass is being invoked. This would not involve the security layer. This would require some state management at the server side.
An advantage of this is also that the declaration of Break-Glass is later followed by a return to normal. Which tends to follow the flow seen at the Clinician side, meaning the clinician is not exposed to each FHIR request/response; they are presented with a set of data retrieved over many FHIR request/responses; they then declare a Break-Glass and then more FHIR request/responses happen.
It is possible this is simply an AuditEvent that indicates that Break-Glass is declared. Thus the Enforcement Point would look to AuditEvent for a Break-Glass declaration that is outstanding.
It is also possible that some other FHIR Resource is used.
It is also possible that no FHIR Resource is used, but some non-FHIR mechanism
This mechanism is not using security mechanism, so it should not be seen as a security solution. It would be very easy to hack the FHIR API to add this.
Note this solution could also be used to carry the other PurposeOfUse indiators, like TREAT
End-User-Client
I separate this as End-User-Client often are more driven by the OAuth authorization service. I think that most of the Business-to-Business solutions can happen here. I simply think that the OAuth authorization service might get more involved in the User Experience at declaring Break-Glass, capturing the reason for the Break-Glass. I am not clear on how the user / app would indicate to the OAuth authorization service that a Break-Glass UX should be brought forward. I look to OAuth experts on that front.
Conclusion
I am so sorry that there is not one solution. I assert that the reason there is not one clear solution has to do with the very fact that there is not much discussion of this flow in public spaces. I think that if there were a public discussion, we could eliminate some of these with rational as to why they are not as good as others, and likely come up with solutions I have not thought of.
Description. Information exposure through query strings in URL is when sensitive data is passed to parameters in the URL. This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data.
Do you have any thoughts or guidance on this topic? Break the standard (and REST) and implement these GETs as POSTs? Create a proxy table that maps sensitive ids to external ids and require the usage of the external id on the query parameter?
OWASP is fantastic resource. Everyone should use it.
However on the topic of GET vs POST for search in FHIR, I do have some further emphasis and guidance:
The FHIR core specification addresses the basic support, and thus why Search is supported on POST as well as GET. All the examples are using GET, but that is just because it is easier to show in examples.
The OWASP article does recognize that using TLS is helpful against untrusted infrastructure. Fully protecting against them. Communications about patient data better be protected using TLS as any request (GET or POST) will be returning patient data, thus the query parameters are just as vulnerable as the query response. So, using TLS will prevent all of the Internet infrastructure from grabbing any patient identity or sensitive data.
The problem, as the OWASP article points out is that logging or inspection might happen on the Client or on the Server on either end of the TLS communication. What they don't say in the OWASP article is that the vulnerability is due to failure to secure the endpoints. Again, patient data will be flowing, so to be worried about query parameters and not data is silly. Either an endpoint is designed and secured properly, or it should not be trusted with patient data. So the distinction between POST and GET is really odd. You either have control and can be trusted; or you don't have control and not trusted. If you can't be trusted with GET then you can't be trusted with POST.
Body logging
If your logging is out-of-control, then I assert you must assume your audit logs are recording the content of the body. Thus the POST body is logged, as is the Response body.
Protect the whole System
Servers can certainly protect themselves fully. Any logging can be controlled to log high quality logs and protect the log storage and access fully, or to not log anything. We are trusting these servers to have secured patient data, so certainly they should be expected to be able to securely store log files too. Even cloud based servers that have scale functionalities can be properly secured. If you just secure your database engine, then you have not secured your server. You must secure everything, not just the easy stuff.
So, clients are the biggest exposure point. Applications (aka not browser hosted code) have full control of their environment and thus can also be designed to NOT log things.
Browser apps that leverage the browser for display and networking are not securable, at all! They should not be trusted with patient data, say nothing about allowing them to use GET vs POST. The exception that is often allowed is when the whole client computer is controlled, such as a Clinician application. So, are browser apps forbidden, no. But, like Servers a whole Client can be secured. If the whole Client is secured then there is no problem, if anything in the Client isn't secured then the patient data is just as at risk as the logs.
Any service, intermediary, or client that can't be trusted to maintain secure logs should not be trusted at all. Anyone that puts patient data on a service that can't maintain logs securely is the actual problem.Anyone that allows a insecure client to gain access to patient data is the actual problem.
Patients have rights
Note one exception that as a Patient advocate I must remind everyone... Patients are empowered to make stupid decisions for themselves. It is useful to explain that the patient has chosen an insecureable client, but it is not proper to forbid using the application the patient has chosen. In this case the patient has the right. Privacy Principles favor giving the data to the patient over using security as an excuse to not give them the data. Warn the patient first, but if they say they understand and really want it to happen, then do it.
Not all of FHIR is patient data
That said, there are many uses of FHIR that are not about patient identifiable data. Infrastructure resources, Directory resources, vocabulary resources, definitional resources, etc.
And there are uses of FHIR on synthetic data, or properly de-identified data.
Conclusion
I have rallied against this security theatre against GET. POST is not more secure than GET. It is not. In fact GET enables better, for example in that it supports cache control with trusted infrastructure. GET is also expressly idempotent, where POST is not explicitly (although POST search very likely is).
Comment with arguments for/against this position. I feel confident, but I also know that I don't know everything.
I agree, but the way people are fixed to this speaks to a lack of confidence in managing log access. Which is typically true for general web servers, but cannot be true for servers handling PHI / Clinical data
Note that FHIR Paging forces the use of GET for next / previous page. So, one needs to address securing GET
Note that POST URL parameters are part of the http specification. So just changing to POST changes nothing. One must change to POST NOT using URL parameters, but content type application/x-www-form-urlencoded with the parameters in the body.
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:
When the Patient is a minor and the representative is a parent.
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).
When the Patient does not have competency to manage their medical records, thus some representative is assigned.
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.
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
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.
As a healthcare professional, I am well aware of the importance of protecting patient privacy. This means not only safeguarding sensitive medical information, but also obtaining the proper consent before sharing that information with others. In this blog, I want to talk about healthcare privacy consent and why it is so crucial.
