Is honoring a Patients Consent a form of forbidden Information Blocking

As I work hard to enable a patient to express the privacy rules around how their health information can be used and by whom for what reasons; I hear that there is worry that an organization that honors those wishes by blocking the data for a given use, that this Organization may be seen as violating the regulations forbidding Information Blocking.

In HTI-2 there is some discussion around some sensitive data that has been expressed as being a special case. However, this is just one kind of data that is or might be considered sensitive by a patient.

My concern is wider than just the ONC HTI-2 and the USA Information Blocking regulations. There are other state level regulations that might force data to be shared in circumstances for which the patient does not want to share. This is not to say I am against some required reporting, but to recognize that there is a wider overlap between potential sensitive classes of data and unreasonable expectations to mandate data sharing.

I am a fan of defining classes of data that are sensitive, that are generally stigmatizing health topics. These defined classes need a specific and actionable definition, so that it is clear to all what is within that class and what is not within that class. This is important to be sure policies work together when bridged. The reality is that these classes are not as distinct as we would like, but today they are hardly even given names of the classes.

One class that is discussed is sexual health topics; which seems clear but is not clear at the detail and technical level. 

The Patient should be empowered to define what is sensitive to them. The use of sensitive classes of data should be a starting point, but the patient should also be allowed to restrict data within a timeframe, or data associated with a specific treatment episode/encounter, or even to identify specific data by identifier.

When these complex Consents can be implemented by an organization, and that organization allows more refined Consent provisions; then these restrictions should not be seen as a forbidden Information Blocking. We should not be questioning the patient's choices.

Healthcare AI - Provenance of AI outputs

AI is the focus of the HL7 Workgroup Plus meeting this week. As I sit in on the presentations, I find that there are some efforts that the Security WG has already put in place that are not understood. So this article will expose some of the things that Security WG has already put in place to support AI.

AI Output Provenance

First up is that there is a concern that any diagnosis, notes, observations, or other content that is created by AI, or assisted by AI, should be tagged as such. With this provenance any downstream use of the data or decisions are informed that the data came from an AI output.

An important aspect of this is to understand the background of the data, the Provenance. This might be a positive aspect, or might be seen as a drawback. The Security WG is not trying to impugn or promote; we are just wanting to provide the way for the data or decision to be tagged appropriately.

There are two methods.

Provenance Tag

There is a data tag that can be applied to any data to indicate that it came from AI.

AIAST - Artificial Intelligence asserted  --- Security provenance metadata observation value used to indicate that an IT resource (data, or information object) was asserted by a Artificial Intelligence (e.g. Clinical Decision Support, Machine Learning, Algorithm).

This might appear on the top of the FHIR Resource in the .meta.security

           "resourceType" : "Condition",
           "id" : "1",
           "meta" : {
              "security" : [{
                "system" : "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",             
                "code" : "AIAST" }
                ]
              },
           ... other content etc.....
         }
 

This can also be used using the element level tagging defined in the DS4P - inline security labels

Using this would cover a DiagnosticReport that has one .note element that is the output of an AI analysis of the data. The DiagnosticReport would indicate that there is an inline label, and just that one .note would be tagged as being AI Asserted.

Non-FHIR - The AIAST code is available for use elsewhere. Such as in HL7 v2, CDA, DICOM, and IHE-XDS. As a code it is very portable. These other standards include ways of carrying security tags, and thus this AIAST code.

Provenance Resource

The Provenance resource would be used when more than the tag is needed. This Provenance would take advantage of the AIAST tag, to indicate that the purpose of this Provenance is to indicate details about the AI Assertion.

The above Provenance Tag might still be useful to use, with the Provance Resource providing the details of the provenance of that assertion.

The Provenance Resource might also use the target element extension or target path extension. to point at the specific elements of the target resource that came from AI Assertions.

The Provenance Resource can also indicate the specific AI algorithm using a Device resource. In this way one can understand the revision of the AI that was used. Possible that if there is then determined to be a problem (bias) with that version of the AI model, one can find all the decisions that were recorded from it. This might also include parameters and context around the use of the AI algorithm.

The Provenance Resource can indicate the data from the patient chart that were considered by the AI algorithm.

The Provenance can also indicate other traceability, such as what portion of the AI model were used.

As with any Provenance, the other elements can be filled out to provide details on when, why, where.

AI use of Provenance

AI will often look at a patient record to determine a NEW diagnosis or write a new note. These interactions by AI should be aware of data that has the AIAST tag, so that the AI can distinguish data that has been entered as new, from data that was derived by previous AI use. This is often referred to as “model collapse” or “feedback loops.” One possibility is that AI will ignore any data or data elements previous authored by AI.

Speaking at free #HL7 #FHIR #HealthIT #Cybersecurity Event

Excited to announce that I'll be speaking at the HL7 FHIR Security Education Event on September 4-5! This virtual event is packed with insights and discussions tailored for everyone in the health IT community.

Two Tracks to Choose From:

1. General Track: Perfect for those looking to deepen their understanding of FHIR security without getting too technical.
2. Developer Track: Designed for health IT architects, developers and engineers who want to dive into the details.

Join me and other experts as we explore the latest in FHIR security. Don’t miss out on this opportunity to enhance your knowledge and network with fellow professionals!

Register free at: https://info.hl7.org/hl7-fhir-security-education-event-0

#FHIR #HL7 #HealthIT #Cybersecurity #FHIRSecurity

Simple definition of ABAC and #FHIR

ABAC: data has "attributes" (elements), that may be summarized into "sensitivity tags" (SLS) that are also attributes. Policies indicate "classifications" of data that indicate how data are to be protected based on some attributes (may be sensitivity tags, but can be any attributes). Policies indicate what "clearance" (aka roles) have access to each data "classification". Users are grouped into "clearances" (aka roles); this might be a FHIR PractitionerRole, CareTeam, RelatedPerson, and Group; but might be something non-FHIR (aka OAuth, LDAP, etc).     

Thus: 

• user have one or more "clearance"
• data have one or more "classification"
• access is granted if "clearance" permits "classification" (often said to be clearance==classification)

Note key ABAC words are quoted above: "attributes", "classification", "clearance" are the most important.

Now, that is just formal.... adjustments can be made for complexity of policy or simplicity of policy or risk addressing policy...

Must security tags be used?

No, ABAC is based on Attributes. So any attribute can be used.

A good example is Observation.category code of 'vital-signs' -- indicates vital signs that are normal health information of no stigmatizing sensitivity. No real need to dig deeper (maybe).

Some ABAC rules can't be implemented with security tags. For example rules related to the author, or rules related to a timeframe, etc. These would address these attributes (elements) in the data.

Then why use security tags?

Using security tags, and a security labeling service, allows for the Access Control implementation to be less aware of the data structure. Meaning that the Security Labeling Service is where all the knowledge of the data model and information model exists. The SLS must understand FHIR. The SLS must understand medical knowledge, and the relationships between the complexity of medical knowledge. The SLS boils all that down to a set of codes and places those codes into a common place in all the FHIR resources, the .meta.security element.

Thus the Access Control decision and enforcement need only look at that one element. There is no need to understand that Observation.code is an important attribute.

Thus the above 'vital-signs' rule would be in the SLS, not needed to be implemented anywhere else.

Does the patient tag the data?

It is possible for the data to be tagged by the patient, however this is not all that popular of a way to implement the need for patients to be able to identify sensitive data. Better for the Patient's Consent to list out the identifier of those resources that they consider sensitive and thus an explicit rule would exist in the FHIR Consent.provision covering these data. This has the added benefit that the data do not get changed when the patient decides they are sensitive or decides later they are not sensitive. Thus the data are always only Created or Updated by the custodian of the data.

Does the clinician tag the data?

It is possible for the data to be tagged by the clinician (Practitioner). This is typical in the Military Secret workflows, but has been shown to be not workable with clinicians. Thus this idea is generally not accepted as a way for the tags to get set.

Do data security tags change over time?

anything is possible, but the assessment of the data should be purely about the data. That assessment should not be based on how the data are to be protected or made available. Thus a piece of data that is sensitive to "gender issues" will always be about gender issues and not change.

The one thing to consider is that medical knowledge does change. There was a time when specific drugs were for their original and non-sensitive reasons; but we learned that that drug is also helpful for addressing drug addiction. Thus getting that medication would now be sensitive when it was not before. Thus there is sometimes when medical knowledge changes that data may need to be reassessed.

Here are some of my previous articles on Access Control

FHIR Security Labels and ABAC

I am rather excited that I have been asked about FHIR Security Labels lately by people getting started at implementing. I have tried to find out who has implemented this, but it is a security/privacy topic and thus everyone wants to be covert about it. Thus, I can't tell how widely it has been implemented. 

The concept is founded in Attribute Based Access Control (ABAC) that is a common IT access control standard that is especially important in data domains with sensitive information like healthcare, finance, military, etc. I would recommend looking at the generic ABAC details and implementations first. This is foundational to what we have put into FHIR.

The main useful publications are:

• https://build.fhir.org/security-labels.html -- The FHIR Specification has the core of a security labeling and ABAC built into FHIR Resource model, and the vocabulary and explainer are on this page.
• https://hl7.org/fhir/uv/security-label-ds4p/ -- The Data Segmentation for Privacy (DS4P) is an Implementation Guide that further explains how to use this, and adds some extra capabilities that are far more advanced than any system will need for a long time
• https://profiles.ihe.net/ITI/PCF/index.html -- The Privacy Consent on FHIR (PCF) is an Implementation Guide that explains Privacy Consent profiling, and has a section on Security Labeling (in Appendix P) and profiles of Consent for when using data labeling
• https://www.drummondgroup.com/shift/ -- An organization that I participate, that is trying to advance the state of the art of Privacy protection using security labels. This group spans technology to policy, with a much larger focus on the policy part that HL7 and IHE can't specify.

The co-chair of CBCP - Mohammad Jafari - has been developing an open-source implementation. He has also worked on all the above with me, and demonstrated various implementation prototypes many times over the years.

• https://jafarim.net/blog/ -- His blog where he discusses these topics, and will likely announce anything he does.

I have a few blog articles, but most of that content has made it into the above publications.

FHIR Digital Signatures

There is a FHIR leadership desire to have the FHIR Data Type "Signature" normative in FHIR R6. The ballots leading to FHIR R6 will give us a chance to test with the community their interest in this Data Type being ready to be called Normative. However so far to date it has not received much attention.

The FHIR Signature Datatype is less concerning than all of Digital Signatures. That is to say that what would be declared normative in the FHIR Signature Datatype is the FHIR structure. The actual digital signature is a blob, that is ruled by other standards such as XML-Signature and JSON Signature. This makes the FHIR Signature Datatype not all that risky to make normative.

The FHIR Signature Datatype just exposes in easy to process FHIR structure some of the important elements of a signature. These elements are expressed as copies for convenience, and thus if you must trust these values, you must process the digital signature blob and pull the values from within that signature blob. This because the Signature Datatype is not cryptographically protected, but the Digital Signature blob is.

Electronic Signature

If you don't need the protection provided by a Digital Signature, but only need an Electronic Signature, then the FHIR Signature Datatype is all that you need. In this case you would not have a Digital Signature blob. You would be trusting your infrastructure, and the Signature datatype carries

• What does the Signature mean
• When was the Signature applied
• Who Signed
• Who was the signer signing on behalf of (delegated signature)

An Electronic Signature can be considered a legal signature in many jurisdictions and for many purposes. An Electronic Signature trusts the infrastructure, but is still important as it provides for tracking the act of signing in a standardized way.

An addition to the above simplified Electronic Signature, could be some kind of an image of an ink on paper or equivalent (like is common on kiosks asking for a scribbled signature on the keypad). This would be recorded in the Signature.data (aka blob) but the mime-type would indicate that it is a JPEG or PDF. Thus not cryptographically proven, just a rendering.

Digital Signature

Digital Signatures add a standards based cryptographic proof. Thus the technology does not need to be trusted, and does not need to be the same technology throughout the process. Cryptographic signatures use a Cryptographic Signature standard such as XML-Signature or JSON-Signature; to create a mathematical proof of the content at the time of signature, that can be validated at the time of use of the content.

Critical to a Digital Signature success:

• Agreed Key Management
• Agreed signature standard
• Agreed timesource or timestamp signature use
• Agreed encoding of the FHIR content that is signed (could be both forms if you need that)
• Agreed elements of the FHIR content that must not change (and thus what elements are allowed to change) -- aka canonicalization (see later)
• etc.

I'm not going to cover all of these. Just some of these that might be able to be nailed down by FHIR standard or by Implementation Guides that are purpose specific and/or regional specific.

Digital Signature Standard used

There are some profiles of XML-Signature and profiles of JSON Signature directly below the FHIR Signature Datatype. These are based on standards that are more broadly used that FHIR, so we have some confidence that they are good standards to recommend. These do emphasize "long-term" need for the Digital-Signature, this is a specifically recognizing that there may be months or years between the signing event and when that signature will need to be validated. When there is a "long-term" need, there is more requirements. With short-term, one can presume that the validator has the same kind of environment (such as time, revocation checking, pki access) as the signer. The use of short-term or long-term is a profiling possibility.

Canonicalization

Canonicalization is a very important part of Digital Signatures. The canonicalization algorithm assures that the validation is looking at the same elements in the same order with the same encoding as the signer used. The concept of canonicalization is more mature with XML, but is understood in JSON too.

Within that section we do point at some canonicalization rules that have been defined

• for XML -- https://hl7.org/fhir/xml.html#canonical
• for JSON -- https://hl7.org/fhir/json.html#canonical

Within these there are canonicalization for everything, the mostly static stuff, just narrative, etc... These were things you were asking about. We do have these.

Use-case specific Canonicalization

An important part of selecting a canonicalization algorithm is tied to your use-case. Specifically, what should be allowed to change over-time, while still proving that what the signer intended is preserved. An example given on a zulip thread is Medication Prescription. That which is prescribed is a subset of the elements of the MedicationRequest resource over time, as the MedicationRequest will be embellished to follow the prescription path and workflow. For example when the prescription is written, the prescriber would be only intending it as a prescription, and thus the MedicationRequest.status as active, yet when the MedicationRequest is exhausted it is marked complete. This status is not important to the prescription signature proof; so it should be excluded. So, this is a good example of a need for an Implementation Guide to cover prescription digital signature workflow, and define a canonicalization algorithm.

The signature blob would indicate the canonicalization algorithm used, so the validator can be checking properly. However, this means that the validator must agree with the use of that canonicalization algorithm, signature purpose, signing time, and signer.

Note that the signer and the signature-validator do need to agree on what form (json/xml) will be signed, and what canonicalization is needed. We do have the Signature datatype able to carry many signatures, for those environments that want to force a signer to sign many ways.

Signature Chaining with Provenance

Any exclusion from the signature is a potential problem. The whole resource should be signed. This can be done with some infrastructure. First, your server would need to be preserving history (versioning), thus the original signed resource is known not just by the id, but also the version.

Later, when the medication status changes from "active" to "complete", a version of the medication is created, AND new Provenance will be recorded for that change. This new Provenance expresses who/what/where/when/why that change was made. This new Provenance can state that prior to the change the signature was validated, and after the change was made this is the new signature.

How do you do this? You do it in the digital signature object itself so that there is cryptographic proof. In this way you are using digital signature standards to do what digital standards are designed to do. Thus, the Provenance.signature blob on an update covers both the original, and the updated.

You just need a policy for how the signature is derived when an UPDATE happens, vs when a CREATE happens. This is that policy that the signer and validator need to agree upon. The cryptographic proof is solid.

This method of using resource versioning, and Provenance signature transition proofs will work for any change. Even those pesky maintenance ones... provided the validator agrees that the maintenance signatures are acceptable... proving yet again that the validator must check everything. In this case, they must check all the Provenance.signature going back to the original, one by one.

Conclusion

The FHIR Signature Datatype is likely good enough to go into Normative when FHIR R6 happens. But I am sure there is still plenty of work to do on the Digital Signature front. What standard, what encoding, what canonicalization, what timestamp, etc. I think the important next steps are some high-value use-case specific Implementation Guides. I am not confident that there is any easy generic solution.

Archive of articles 

• Sign all the FHIR IPS
• IHE IT-Infrastructure Summer 2024 - Document Digital Signature with JSON signature option
• FHIR Document Digital Signatures
• Blockchain Provenance Service
• IHE Document Digital Signature (DSG) Profile approved for Final Text
• Extending the FHIR standard to handle provenance
• On-Behalf-Of - FHIR Signature datatype update
• IHE MHD and DSG now open for Public Comment
• Digital Signatures on FHIR
• CDA Digital Signatures inside
• IHE - Privacy and Security Profiles - Document Digital Signature
• Signing CDA Documents
• Using both Document Encryption and Document Signature
• Non-Repudiation is a very old art

Sign all the FHIR IPS

The International Patient Summary (IPS) is gaining more and more visibility as it gets more mature. The IPS is a Document, and there is a definition for this document using CDA and using FHIR. The FHIR Document is the one most are interested in. At the technical level, they are equivalent, and they meet the same abstract definition defined by ISO/CEN. But FHIR is the hot new standard, so everyone wants to use it. More details on IPS background and process is available.

The IPS can be carried in all of the Document Sharing methods that IHE has available. This is explained in the IHE Sharing of IPS Implementation Guide. 

The IPS can also be carried by many other methods. Including where the patient just emails it, or uploads it, or otherwise shares it.

Is it Authentic

So, when an IPS is consumed, how does one know that it is authentic to what the author intended?

This could be simply trust in the transports that got the IPS to you. IHE Document Sharing includes trust frameworks. Most patients are not out to deceive, so they tend to provide authentic data.

But any method of getting you the content has the possibility of having 'trusted intermediaries' or 'malicious intermediaries'.  Some IPS may bounce around many places before getting to you. Anyone that is between you and the author have the possibility to change the content, so how can you detect a change?

CDA and FHIR Documents don't come with a form of integrity check. So, changing them along the way is easy.  The change might be an appropriate change, like adding consistent clinical codes to all the data so that it is easier to consume. These changes may be beneficial, or malicious. These changes might be appropriate, or dangerous. So detecting changes is important but not enough, see discussion at the end of this article.

Thus, how do you have "end-to-end", vs "point-to-point" trust?

Digital Signature

The only way to get end-to-end authenticity proof is to have Digital Signatures. A Digital Signature uses cryptographic algorithms, not to encrypt the content, but to provide a mathematic proof that the content you got is the content that was signed. It is important to know that a Digital Signature does not keep the content from being seen or copied; and there is no way to keep the Digital Signature from being removed. But if there is a Digital Signature available, then it can be used to validate that the content you got is exactly what was the content that was signed.

FHIR R4 has some Signature datatypes and recommendations. But there is very little experience with these, and there is not a defined way to sign a FHIR Document. That is to say that the 'canonicalization algorithms' that are defined for use with digital signatures do not exclude the Bundle.signature element, and thus will fail to work. This method of signing is a focus for FHIR R6, so experience and improvement.

IHE Document Digital Signature

IHE has a Document Digital Signature (DSG) profile that can be used to sign ANYTHING. Thus it can be used to sign a CDA document, and also a FHIR Document. The DSG has historically profiled XML-Signature but has now been updated with a profile JSON Signature. 

DSG is mostly used with IHE Document Sharing, where the document is shared normally and there is an association to the signature document. The signature document is either an XML-Signature or a JSON Signature. The signature technology has no relationship to the technology of the signed document. Thus, one can use JSON Signature to sign a CDA document, and you can use XML-Signature to sign a FHIR Document encoded in JSON. The signature is across the bytes that are stored of the signed document. Thus, there is no canonicalization of the signed document, just the serialization to put that document into Document Sharing. With this method, when you have a document received over Document Sharing, you can look for a SIGN association to find any signatures. You can then validate that signature against the document you received.

DSG also has options for enveloping of the document. This would tend to be used when Document Sharing is not used. In this method the signed document is enveloped within the Signature. The benefit is that the signature and document are in one object, thus less likely to be accidently lost. But, any use of the document must pull it out of the envelope, which makes use of the document significantly harder.

Long-Term Infrastructure 

The signing of a document is rather easy, many tools are available that can do these for you. The validating of a signature is also mostly easy, using available tools. 

The hard part is that when validating a signature, you MUST check the date/time stamp and validate that the signing certificate was valid at that date/time. 

And to support that, the PKI must be designed and managed to support this certificate validation well into the future. Thus, the signature must be able to meet "Long Term" requirements, and the certificate management must also meet "Long Term" requirements. This is unusual with Certificate Management today, which focuses on TLS (https) certificates that don't need to be remembered for decades.

Governance of Signing

It might be a good idea for all authors of IPS documents to sign them. However, this might also not be helpful overall. So, let's look at some factors involved in the signing.

• What is the meaning of the signature. The signature will/should include an indication of the intended type of the signature. Such as ProofOfOrigin, ProofOfCreation, Author's Signature, Source Signature, or Timestamp Signature.
• The signature may be applied by someone other than the author as an endorsement of the IPS content: Review Signature, Modification Signature, Addendum Signature, etc.
• What format of digital signature will be used and what encoding of the IPS will be signed. Any conversion of the IPS (e.g. from FHIR XML to FHIR JSON) will break any signature, thus you want to be sure to sign the encoding form that the recipient will get.

Governance of Validating

With Digital Signatures there is an important need for governance on how to handle receiving an IPS.

• Do you process an IPS that has no signature?
• Do you warn the user that there is no signature, but continue to process?
• Do you not validate the signature? 
• not unusual to only validate the signature when there is a specific need, such as a legal challenge.
• What do you do when a signature is present, but it is invalid?
• Do you not process the IPS at all?
• Do you allow the user to continue to process the IPS?

Authorized modifications

Any modification will break the signature. However, there are methods that can be used to support authorized modifications. 

When using IHE Document Sharing, the original document will still exist, and the modification can have an association with the original. This one can validate the original and new.

A more general solution would leverage the trust in the authorized modifier. This authorized modifier would be required to validate the signature of the content it consumes, and it would be required to place a signature on the new content. In this way the new signature on the new content is a proof of authenticity on the new content, and by way of the purpose of the signature it can also be viewed as a statement that the original signature was validated.  

This could be done using FHIR Provenance, but that is a much more detailed article.

Conclusions

This article started with an assertion that all IPS should be signed by the author of that IPS. I point out that the signing and validating technology is very mature; but that the long-term need presents special requirements for the PKI supporting the signing identities. 

One could rely on Document Sharing to provide the infrastructure for making the signatures available, or one could use enveloping signatures. The enveloping signatures add even more requirements regarding signature format, content encoding, content serialization, and content accessibility.

I have been involved in the Digital Signature domain for 30 years. Not much has changed in that time, but there is also no broad use of Digital Signatures as described above. This is because the infrastructure and governance are far more difficult and expensive than the benefit that signatures bring.  There are far more to it than I have expressed here. There is no shortcut, these are all needed.

IHE IT-Infrastructure Summer 2024

This summer IHE IT-Infrastructure has been working on three very different work items. All are very clear IT-Infrastructure scoped projects, but two of them are very new territory.

Updated 8/14/2024 to include published links

Announcements

• PCC - QEDm
• ITI - FAIS and Scheduling

Document Digital Signature - JSON signature option

This work item is updating a long standing, and "Final Text" profile, the Document Digital Signature (DSG). The original DSG used XML-Signature standards, as that was the signature standard of choice back then. This original DSG is still available, as there are environments that want to use XML-Signature standards. 

With the XML-Signature we additionally leveraged the profiling of the XML-Signature standard done by ETSI in the XAdES-X-L standard profile for Long Term signatures. Using Long Term signatures as Documents in an HIE (aka Document Sharing) would tend to be available for a long time, and over a broad distance. 

The new work is to add an Option that uses the JSON Signature standards. The JSON Signature standards are getting mature and are gaining in interest. One of the key milestones for us is that ETSI has released their Long Term signature profile of the JSON Signature - JAdES-B-LT.

This work item has been out for Public-Comment. We are still trying to work out some specific details about how IHE Document entries are to be indicated in the JSON Signature. As part of this we will be providing examples and pointing at some code that people could use.

The details are in the supplement that is still available for review and comment.

Finance and Insurance Service (FAIS)

The Finance and Insurance Service (FAIS) stores, categorizes, and facilitates the administration of centralized claims and finance related data to care provision to patients within the HIE. The service receives claims/financial data from Point of Service applications (including financing applications acting as a point of service interface outside of other PoS systems) and curates the management of them.

This collection of workflows allows an external system to save and retrieve Finance and Insurance Information. The workflows are designed to support the following types of data exchanges with systems.

1. A point-of-care system can enroll a beneficiary
2. A point-of-care system can check a beneficiary’s eligibility
3. A point-of-care system can run a pre-determination, pre-authorization and claim
4. A point-of-care system can track a claim’s status

This is a very new ground for IHE and is coming from the emerging markets where they have this need and don't have existing solutions. 

The FAIS Implementation Guide

Scheduling

The IHE FHIR Scheduling Profile is a specification providing FHIR APIs and guidance for access to and booking of appointments for patients by both patient and practitioner end users. This specification is based on FHIR Version 4.0.1 and specifically the Schedule, Slot, and Appointment resources.

This work item is based on the previous work of the Argonaut Project.  This is an evolution in cooperation with the Argonaut Project.  The following are some of the major differences from the Argonaut IG:

• The IHE Profile is based on FHIR R4
• The IHE Profile is intended for international use, and it does not have required bindings or any dependencies to national profiles
• The operations described are $find, $hold, and $book
• A separate transaction describes the use of FHIR Search for the Appointment resource

The Scheduling Implementation Guide

New Projects

Given that all of the current work items are in Public-Comment, and that we still need to resolve any comments we get, we are being conservative at adding new projects. 

Sharing Verifiable Health Links

This said we are picking up a new work item proposed by the WHO (Who brought the DSG JSON, and Finance projects). This new work items are also backed by Canada and Australia. The new work item looks to profile a portable Verifiable Health Link, to enable patients to provide specific access to their current health data, such as an International Patient Summary (IPS). 

This project will leverage other IT-Infrastructure profiles where appropriate, such as MHD and sIPS.

Ongoing Projects - aka Important Change Proposal work

• Integrating the Sex and Gender support into the existing appropriate Profiles, such as PDQ/PDQm.
• Increasing support in XCA and XCPD for searches to be targeted to a given home community, so as to limit the unintended visibility of searches (aka Privacy). 

Mention simply because it was my contribution (QEDm)

PCC has published for Public-Comment the conversion of the Query for Existing Data for mobile (QEDm) from a PDF publication to a full Implementation Guide. This should be very similar intent as the existing PDF, but as an IG is far more specific and includes examples. This also adjusted to the update that ITI made to mXDE last year regarding Provenance. This will be followed with efforts to build QEDm upon HL7 IPA in a future public-comment.

The QEDm Implementation Guide

Join and Help

Please look to join IHE as a member, or benefactor. If these are not possible, then please do continue to watch for Public-Comment and help out with your comments. IHE does not require that you are a member in order to comment.

Consent is a small part of Overarching Policy

There is always so much focus on Consent, and Consent is highly important. But what often is missed is that Consent is just a portion of the overall policies that control the activities. The relationship to the Overarching policy is merely an element in the Consent Resource (Consent.policy), but that linkage is not simple. 

That linkage is contextual. Meaning the linkage involves all of the context in the Consent resource, such as who the patient subject is, and who the grantee is. Such as who is the organizational party that is equally agreeing to this Consent, and who is the custodian of the data that will be expected to enforce the terms. There are other context like dates, expirations, provisions, etc.

Therefore, within an organization there would be many thousands of Patient(s) and their Consent(s). So, we are getting closer to the topic of this article, the Overarching policy.

The Overarching policy is what I want to stress as being far more critical, and far less understood. This is not to say that those that write these 'corporate policies' don't know what they are doing, they surely do. These Overarching policies tend to be written by the legal division of an organization, and thus are exacting, long, and impossible for anyone other than the authors to understand. It is these overarching policies that are often the scorn of "Privacy Policy... yeah, I didn't read it". I can't solve that problem, as they are indeed very important to be exacting and comprehensive.

Comprehensive is a good word that I want to point out, because the topic I have had to explain multiple times in the past few weeks is that the Overarching policy MUST cover the normal activities but must also cover abnormal activities. Some so abnormal that they are covered simply by some section about how to handle abnormal activities not covered in the Overarching policy.

As you can see from my outline. The Overarching policy must explain how the organization is structured. Who are clinicians, what kind of clinicians have access to what kind of data. Who are employees / contractors that have limited access to data, such as food-service employees have access to patient allergy and careplan information that would affect what food they would serve. Where there are other employees / contractors, that have to the Patient resource and the scheduling so as to handle registration desk duties. These Roles and Clearances are important to define. These data access activities are important to define. 

Safety vs Privacy is an example of risk management that would need to be addressed. There needs to be rules as to who is allowed to say that safety risk is more important than a privacy violation, possibly using a Break-Glass mechanism. When break-glass is used, what remediation and followup is performed by the Safety and Privacy office to assure that the violation was acceptable?

Overarching Policy covers Consent decision impact

Last thing I want to point out is that the Overarching policy has sections in it that express

• The activities that are permitted or denied when there is no Consent on file
• The activities that are permitted or denied when there is a Permit Consent.
• The activities that are permitted or denied when there is a Deny Consent

That is to say that the definition of a Deny Consent is just as reliant on the Overarching policy explaining what is allowed as is a Permit or an absence of a Consent. For example, as with the absence of a Consent, the Deny Consent likely still authorizes Emergency Department minimal access to enable stabilizing of the patient. Such as being able to access allergies and medications to assure safety. This level of access is not the same as normal treatment would have access to, but it is not a complete blocking of life critical data. So it might not give the ED access to the total list of medications. 

This is all the kind of details that need to be considered when writing the Overarching Policy. For a deeper dive please see the IHE Privacy Consent on FHIR Appendix P

 

Enhancement of Patient Demographics Query for Mobile (PDQm) with FHIR $match operation

IHE has enhanced the Patient Demographics Query for Mobile (PDQm) with a FHIR $match operation to enable more powerful Patient identity matching to produce better matches and reduce false matches. The original search is still available and fits specific use-cases, where now the $match operation can be used as well. This presentation will introduce PDQm, and describe these two methods that are now available.

Why does IHE-XDS not have a Delete Document?

This also applies to IHE: MHD, MHDS, XDS, and XCA. To some extent it applies to normal use of FHIR R4 DocumentReference

The IHE Document Sharing model is focused on document lifecycle, and thus supports Create, Append, Transform, Replace, and Signs of a document. When an existing document is replaced with a new document, the Replace action is used. This marks the old document as superseded and the new document points to the old document (in XDS the Association Object is bidirectional, but in FHIR the new document points at the old). Thus, when someone finds the document they have, they can see that it has been replaced.

This is a well understood model when one thinks about a clinical document. That clinical document may have various revisions, each replacing the prior document. With a clinical document the final version is left available forever (or for as long as the legal persistence policy identifies). This is the typical lifecycle, that is that eventually one gets to a final version of the document.

However, there are some documents that need to be deleted / removed / revoked / deprecated / etc. Some examples:

• Basic Patient Privacy Consent -- when the consent is revoked by the patient
• Advanced Directives -- when the advanced directive is revoked by the patient
• Entered in Error -- when a document gets incorrectly registered, and needs to be removed because of this error

With only Replace, these needs seem to be unachievable in XDS/MHDS.

Native FHIR R4

In FHIR R4 DocumentReference one can set the status to entered-in-error, but there are two very important considerations

1. This status is not supported in XDS, so it is not going to interact properly with any exchange that uses IHE Document Sharing. I will cover this later in the section on Just delete it.
2. This status does not include any evidence for why the document is marked as entered-in-error.  Meaning that there is often a need to explain why it was marked as entered-in-error. 
3. The status of entered-in-error is reasonable when a mistake was made. But the first two use-cases are cases where the original publication was not an error, the change is to indicate removal.

In FHIR R4 DocumentReference one can set the status to superseded, but there are is an implication that it has been superseded by another DocumentReference. This is not a requirement, so it is not a problem.

One could use an extension in FHIR DocumentReference that can carry a more refined status code... but that is not going to guarantee that everyone understands it... And those extensions will not be understood by IHE Document Sharing transports. Most important is that the .status codes in the Event pattern does not have a 'deleted' status.

Just delete it

FHIR Resources can be deleted, provided policy allows. A Deleted resource can be handled in multiple ways. If the FHIR Server supports versions, it can mark the version as deleted in a way that one could retrieve the deleted resources. 

XDS does have some methods available for document delete - Remove Metadata and Documents (RMD). The problem with delete in XDS is similar in that it does not convey the deletion to those that might have used it before, and certainly doesn't understand why it was deleted.

Document Sharing -- Recommended Approach

In Document Sharing, one would Replace the current document with a new document. The new document likely will be a brief summary of why the document was revoked or replaced. This kind of a flavor of the document would need to be profiled anyway to support the use-cases.

The new document could be an empty document, provided the policy allows that. 

The new document metadata could be either

1. A variation of the original document, so that it is discoverable in the same way the original is discoverable
2. Very different metadata that clearly indicates deletion. 
3. A variation of original content to support some discoverability, but also clear indication of the deletion.

So, how can the Metadata (e.g. DocumentReference) look like to indicate to everyone that might have pulled the previous document?  Well, realistically the fact that the previous document was Replaced, is the signal to any previous uses of the previous document. 

But, should the Metadata (e.g. DocumentReference) be good to have an indication that the previous has been rejected and that there is no new content. Meaning, a way to send a terminal signal using just the Metadata?

• In pure FHIR, the DocumentReference.docStatus  could indicate this, especially in newer versions of FHIR (given that FHIR R4 has a very limited vocabulary on docStatus).
• However, this element is profiled out of IHE Document Sharing
• The DocumentReference.type or .category could be different to indicate this is a Terminal document; but this might make it harder to find. So likely these should be the same as the original.
• The DocumentReference.content.format is the indication of the profile / formatCode of the document content. If one defines a new profiled document for this use-case of a Terminal / Revoked / Removed document. Then one could put this value here.
• The DocumentReference.context.event is the MOST USEFUL. This in both FHIR and XDS is a general useable code. Thus any code can be put in here. 

So, use DocumentReference.context.event and define a specific code to indicate a Terminal state of the previous document. I don't know if there is a useable code, but likely there is a code in CDA. Or you could put the Composition Status code from the updated CodeSystemComposition Status code from the updated CodeSystem in here

Conclusion

So, my conclusion is

1. Use Replace, with some differently profiled document

2. This document would be defined to indicate the context of the Removal / Revocation / Rejection / etc.

3. This document would have a defined set of codes to use inside the document

4. This document would have a different FormatCode / profile

5. This document would profile the Metadata (e.g. DocumentReference) to indicate this terimal status document. This could be all of the above, but most likely would be the FormatCode and an Event code.

Meaning this is a normal use-case analysis that results in a specific profiled document that replaces the previous document. This will be understood in simple FHIR Server, and would be understood in XDS / XCA / MHDS. Thus it has the broadest useability and clarity.

FHIR Security and Privacy - Open Educational Session

For those going to HL7 WGM in Dallas. I will be available Wednesday afternoon in an open educational session on FHIR Security and Privacy:

The best case is that everyone that comes to the session would have reviewed the freely available recorded tutorial sessions, and/or the freely available slides; so that we can have discussions and solve the world's problems regarding FHIR Privacy and Security.

- Recorded session -- https://vimeo.com/853094845/671e02f6db

- My slide deck -- http://bit.ly/FHIR-SecPriv 

Bonus points if people come having reviewed my IHE Privacy Consent on FHIR webinar

Super excited if people come with FHIR Security and Privacy problems that I have not yet written about. I would love to come out of this session scratching my head and inspired to create more solutions.

Why does IHE-MHDS not have a Document Repository?

The IHE-MHDS does not define a Document Repository Actor but does include architecture support for distributed FHIR Servers and thus the concept of a Document Repository is included in MHDS. The MHDS profile specifies how a collection of IHE profiles can be used by communities for exchanging health information, which includes support for patient identification, health document location and retrieval, provider directories, and the protection of privacy and security https://profiles.ihe.net/ITI/MHDS.

The Document Repository and Document Registry is an architectural construct that is foundational to XDS, but not necessarily part of Document Sharing. For example: XCA also does not make a distinction between a Document Registry or Document Repository, having a Responding Gateway Actor.

The MHDS profile defines a Document Registry Actor that persists, manages, and provides access using the MHD access methods. This supports IHE Document Sharing as described in the Health Information Exchange: Enabling Document Sharing Using IHE Profiles White Paper. The central HIE infrastructure defined in MHDS profile might be a single FHIR Server implementing all the defined central service actors or may be a virtual cloud of systems implementing the defined profile actors.

IHE-MHDS does not define the Document Repository Actor, as the concept of a set of distributed FHIR Servers is very natural to REST architecture. Thus IHE did not add complexity by defining a formal Document Repository Actor, as the concept can be addressed naturally with REST. For more detail see the Storage of Binary section in the MHDS profile. This is also explained in the HIE Whitepaper in section 3.2 Centralized Discovery and Retrieve

If you're looking for details on the functionalities or its implementation, the MHDS Volume 1 documentation would be a good resource to explore further. It outlines the core business functions provided by the MHDS Profile, including the publication of document-based information, persistence and lifecycle management of documents, and patient identity management among others. For broader discussion on the Document Sharing concept the whitepaper is more inclusive.

recording of my IHE Privacy Consent on FHIR webinar

I thank Health Samurai for making the recording of the Access Control meetup sessions available. Here is my presentation, and from that you can find the others.

Meetup on #FHIR Access Control

I will be speaking at an event coming up on Access Control. This is not just me speaking about IHE-PCF, but much more.

Join us for the FHIR® Access Control Meetup where we'll take a closer look at the real-world challenges and solutions.

 

Here's what you can look forward to:

• Privacy Policy Foundations: Dive into the essentials with John Moehrke, HL7 Security Workgroup Co-Chair. A great chance to understand the backbone of healthcare data security.
• Authorization Nuances: Explore the complex world of authorization with Josh Mandel, Microsoft Healthcare's Chief Architect. Perfect for those looking to navigate the intricacies of access control.
• Data Segmentation for Privacy: Learn from Mohammad Jafari, a Senior Privacy Consultant, about segmenting data to enhance privacy. An invaluable session for anyone interested in data protection.
• FHIR Label-based Access Control: Gain insights from Mike Kulakov, Health Samurai's Product Manager, on the innovative approaches to access control using FHIR labels.

Plus, you'll have the chance to ask questions to the speakers and engage in a round-table discussion.

 

Can’t attend? Register anyway and we’ll send you a recording after the meetup!

Sharing IPS (sIPS)

This Implementation Guide ready for Trial-Implementation.  Formal Publication -- https://profiles.ihe.net/ITI/sIPS

The Sharing of IPS (sIPS) IHE Profile provides for methods of exchanging the HL7 International Patient Summary (IPS), using IHE Document Sharing Health Information Exchange but does not modify the HL7 IPS specification, nor is there any need to change IHE Document Sharing Health Information Exchange. This means that any existing XCA/XDS environment needs NO change to support the IPS.

The International Patient Summary (IPS) content,
as defined in the ISO 27269 data model specification, utilizes IHE’s document sharing infrastructure including cross-community, HIE, direct exchange models, and more. It has been designed specifically to remove barriers to adoption, by leveraging architectures that are currently implemented, well-established, and robust. 

The sIPS Profile provides implementation guidance to vendors and implementers and joins a growing suite of IPS standards artefacts contributed by a variety of Standards Development Organizations (SDOs) and coordinated by the Joint Initiative Council for Global Health Informatics Standardization (JIC).

YouTube presentation, long, and short.

If you want a purely FHIR transport for this FHIR IPS, then look to the
Mobile Health Document Sharing (MHDS) Profile

CyberSecurity recommendation

My top recommendation is to look to experts in that field. I mostly participate in healthcare standards organizations such as HL7, IHE, and DICOM. These standards organizations focus on health informatics interoperability, they are not experts in CyberSecurity. These healthcare standards always recommend that you use standards developed by appropriate standards organizations. See the 2023 HL7 Cyber Security Event with all recordings available now. My HL7 FHIR Security and Privacy Education track.

My second top recommendation is to make it very clear that Security (and Privacy, and Safety) are risk domains. Meaning that you must manage them according to risk, not a checklist. A checklist can help you be comprehensive in your analysis, but it can't help you determine the actual risk, and it can't decide for you what level or risk you are willing to accept. I covered risk in a blog article 12 years ago, and it is still relevant.

• I prefer NIST Cybersecurity Framework (CSF) because it is free, and it is very readable. This is a high-level roadmap for managing comprehensive cybersecurity risk.  It can be used by large and small organizations.
• I know that some are forced to use ISO 27001 and 270002. I am okay with these, but accessibility to ISO specifications is a big problem. This is international specification, so is seen as appropriate everywhere outside the USA. There is a large number of consulting firms that can help with the implementation of this.
• In the USA the HITRUST organization, although expensive, has a crosswalk of all the cybersecurity frameworks; and a methodology to record evaluation and decisions. This would be my recommendation if an organization didn't have experts on staff and needed to get started.

HITRUST and NIST are just as applicable outside the USA, but I also recognize that some see anything with a USA focus to be bad for use outside the USA.

• For specific things like a FHIR or even a SOAP interface, is where I would add the prioritization and clarity that OWASP brings. 

Of course, we leverage other standards by security experts including IETF(https, tls, s/mime, oauth, certs), and W3C (signatures, prov, p3p, soap), ETSI (XAdES, PAdES, JAdES), NIST (AES, SHA), etc. 

What is your recommendation?

PS, sorry about the AI authored answer a few weeks ago - Give me a cyber security check list for FHIR RESTful API Systems, but you will note it is similar.

Give me a cyber security check list for FHIR RESTful API Systems

So I asked Gemini, googles latest AI...

Cyber Security Checklist for FHIR RESTful API Systems

FHIR (Fast Healthcare Interoperability Resources) is a standard for healthcare data exchange. It is important to secure FHIR RESTful API systems to protect sensitive patient data. Here is a checklist to help you secure your FHIR API system:

Authentication and Authorization

• Implement strong authentication: Use a standard like OAuth 2.0 or OpenID Connect to authenticate users and clients. This will help to ensure that only authorized users and applications can access the API.
• Implement authorization: Use a fine-grained authorization system to control what users and applications can do with the API. This includes what data they can access, what operations they can perform, and what resources they can create, read, update, and delete.
• Use strong passwords: Enforce strong password policies for all users. This includes requiring a minimum password length, complexity requirements, and regular password changes.

Data Security

• Encrypt data at rest and in transit: Use strong encryption algorithms to protect patient data at rest and in transit. This will help to prevent unauthorized access to the data, even if it is intercepted.
• Mask sensitive data: Mask sensitive data, such as Social Security numbers and credit card numbers, before returning it from the API. This will help to prevent unauthorized disclosure of the data.
• Implement logging and auditing: Log all API access attempts, including successful and failed attempts. This will help you to track who is accessing the API and what they are doing.

Other Security Measures

• Keep software up to date: Regularly update your FHIR server software and any other software that is used to access the API. This will help to fix security vulnerabilities that could be exploited by attackers.
• Perform regular security assessments: Regularly assess the security of your FHIR API system to identify and fix any vulnerabilities.
• Monitor for suspicious activity: Monitor your FHIR API system for suspicious activity, such as unauthorized access attempts or unusual data access patterns.

By following these recommendations, you can help to secure your FHIR RESTful API system and protect sensitive patient data.

Additional points to consider:

• Rate limiting: Implement rate limiting to prevent denial-of-service attacks.
• Input validation: Validate all input to the API to prevent malicious attacks, such as SQL injection attacks.
• Error handling: Handle errors gracefully and avoid returning sensitive information in error messages.
• Security awareness: Train your staff on the importance of security and how to protect patient data.

By following these recommendations, you can help to ensure the security of your FHIR RESTful API system and protect sensitive patient data.