Tuesday, July 23, 2024

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.

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. 

This should be available for Public-Comment in the coming weeks at the IHE IT-Infrastructure Public Comment section


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
This should be available for Public-Comment in the coming weeks at the IHE IT-Infrastructure Public Comment section

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 will be publishing 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.

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.

Tuesday, July 9, 2024

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


Wednesday, June 12, 2024

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.

Sunday, May 26, 2024

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


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.

Wednesday, May 15, 2024

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.

Thursday, May 2, 2024

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.

Tuesday, April 16, 2024

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!

Friday, April 5, 2024

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

Thursday, March 21, 2024

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.

Saturday, March 2, 2024

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.

Monday, February 19, 2024

IHE IT-Infrastructure Winter 2024

Updated with final announcement: IHE IT-Infrastructure with two major new profiles (DSUBm, and PDQm match), and three minor updates (BALP, PIXm, and PCF), all on #FHIR. https://mailchi.mp/ihe/ihe-iti-tf-documents-published-2024-02-29

IHE just completed our winter quarter face-to-face meeting, held in Oak Brook IL at the RSNA headquarters. We primarily focused on two IHE-Profiles, and a set of other tasks. The update to PDQm and DSUBm will soon be formally published for Trial-Implementation.
  1. PDQm 3.0.0 - adding support for $match operation.
  2. DSUBm 1.0.0 - subscription to document sharing.
Other tasks worked on:
  1. Scheduling for Mobile - incremental development of transactions.
  2. Downgrade PCF 1.1.0 to R4 for greater usability.
  3. Minor Bug fixes in BALP 1.1.3 profiles.
  4. Minor Bug fixes in PIXm 3.0.4 profiles.
  5. FormatCode 1.1.1 vocabulary inclusion of status active.
  6. Plan for support of sex and gender profiling.
Next quarter's work:
  1. Continue developing Scheduling for Mobile.
  2. Add to DSG, support for JSON Web Signature (JWS).
  3. Develop Finance and Insurance workflow.
  4. Update HIE Whitepaper and MHDS with newest Profiles.
  5. Continue to work with IPA for suitability for QEDm use-cases

PDQm support for $match operation

Patient Demographics Query for mobile (PDQm) version 3.0.0 now has support that is more in alignment with the original use-cases with the addition of support for $match operation. The $match operation allows a client to provide all that it knows about the subject and enables the server to utilize algorithms to get the best match. Previously PDQm supported only the FHIR query, which does not give the server the power to utilize algorithms. 

Both query and $match are now available in PDQm, as there are clear use-cases where one wants to use query, such as at a registration desk where a human would then further match. Whereas the $match may be more beneficial where some information is known about the patient and a best match is needed.  

The PDQm server (Patient Demographics Supplier Actor) must support the search transaction and has an option to declare support for the $match. The PDQm client (Patient Demographics Consumer) will need to declare at least one option indicating that it will use either query, $match, or both. Support for the normal FHIR dynamic discovery using the metadata endpoint returning a CapabilityStatement is used in operational environments to detect server support.

Document Subscription for Mobile (DSUBm)

The Document Subscription for Mobile (DSUBm) version 1.0.0 profile describes the use of document subscription and notification mechanisms for RESTful applications. In a similar way to the DSUB profile, a subscription is made in order to receive a notification when a document publication event matches the criteria expressed in the subscription. 

The DSUBm allows clients to subscribe to specific kinds of changes in the Document Sharing system, such as new documents, updates to folders, and replaced documents. For example, subscribing on a given patient for a new lab report. DSUBm also adds support for MHD clients to get subscriptions about these activities in an XDS environment and adds support to DSUB to enable searching on subscriptions that are not supported in DSUB. A significant portion of the documentation is guidance on assembling these various subscription capabilities across different Document Sharing methods. These are the documented use-cases that drive the solution and show the breadth of support:
  1. Document Subscription for Mobile application in MHDS Environment
  2. Document Subscription for Mobile application in MHDS Environment using Folder Subscription
  3. Document Subscription for Mobile Device in XDS on FHIR Environment
  4. Document Subscription for Mobile Device in XDS on FHIR Environment extending DSUB with DSUBm
  5. Document Subscription for Mobile Alert System
  6. Document Subscription for Mobile Device in XDS on FHIR Environment with availabilityStatus update
  7. Document Subscription for Mobile Device in XDS on FHIR Environment with document metadata update
  8. SubmissionSet Subscription in a XDS Environment where DSUBm is Grouped with DSUB
This Profile is using FHIR R4 to be consistent with the other IHE Document Sharing infrastructure and uses the HL7 Subscriptions R5 Backport. This enables support in R4, using the newer subscription methodology developed in FHIR R5. The support for FHIR R4 is stronger in the marketplace, with very little interest in FHIR R5. Both IHE and HL7 have received strong feedback from the implementer communities that FHIR R4 will continue to be the focus until FHIR R6 is readily available. Note that there are some trickery being used to utilize this newer subscription methodology in an FHIR R4.

Clients can discover the kinds of subscriptions available [ITI-114], search on current subscriptions [ITI-113], and subscribe [ITI-110]. When a subscription is triggered, a notification is sent [ITI-112]. The other transaction [ITI-111] enables backend infrastructure between the Document Sharing environment and the notification environment.


Downgrade PCF to R4 for greater usability. We have found that one can't depend upon a FHIR R4B implementation guide in a FHIR R4 implementation guide and further profile. Given that PCF is intended to be further refined by more advanced use-cases or regional needs, this was creating problems. The only reason we started with R4B was that there was a bug in the FHIR R4 build around an example in Consent that caused an IG build error. This is no longer a problem, so we downgraded PCF to R4. 

Bug fixes in BALP profiles. There were some observed profiling bugs that were reported by the community (big thank you to all you in the community that report these things). The changes made were to the intended constraint. The changes make the constraint more specific, correct, and better for further profiling.

Bug fixes in PIXm profiles. A helpful community comment observed that the PIXm specification was improperly profiling how an error would be returned.

FormatCode vocabulary inclusion of status active. Previously only the codes that were deprecated had a status on them. The current vocabulary infrastructure was thus not seeing any active codes. So, all the codes that are not deprecated now have a status of active. This will result in proper valueSet expansions. I am in the process of updating the HL7 valueSet that includes the IHE codes.

Spring Quarter

We looked at FHIR R5 this last quarter. We were not looking to move to FHIR R5, but rather to evaluate the impact if it was needed. We found that some of our Profiles will convert easily, but we also found significant problems with FHIR R5, significant enough that we created HL7 jira tickets requesting that these be fixed before FHIR R6. We will continue this effort with the intent that the effort that we take now will provide more insights to better the FHIR R6 release. We have strong marketplace indications that FHIR R4 will continue to dominate until FHIR R6, specifically that FHIR R5 will only be used for specific isolated use-cases.

We have been looking at the possible impact of the HL7 lead cross-SDO effort on Gender Harmony. IHE, especially ITI, have many Profiles that touch upon the concept of the patient (HL7 v2, v3, CDA, and FHIR) so it is important that we assess the impact. At this time our approach is to look for any problems where our profiling is contra to the Gender Harmony recommendations. We are finding that the impact is mostly an opportunity to inform our reader that when they need to communicate the concepts developed in the Gender Harmony specifications that they MUST use the approaches developed there. This approach helps encourage the correct behavior.

Scheduling -- a vendor agnostic specification providing FHIR APIs and guidance for access to and booking of appointments for patients by both patient and practitioner end users, including cross-organizational workflows. First developed in Argonaut on STU3, the further development has been cooperatively transferred to IHE. The IHE specification is based on FHIR Version 4.0.1, and references the Schedule, Slot, and Appointment resources. This workflow profile defines transactions that allow a scheduling client to obtain information about possible appointment opportunities based on specific parameters, and based on that information, allow the client to book an appointment. 

Add to DSG, support for JSON Web Signature (JWS). There is market interest in using JSON Web Signatures (JWS) rather than XML-Signature. The use-cases will be the same as in the current Document Digital Signature (DSG), that supports whole document signature. The likely impact will be a new option to support JWS signatures, which will predominantly be a new MIME-TYPE of DSG document object. The JWS will likely use the JAdES profile on JWS for long-term signature, like today is in DSG using XAdES for XML-Signature.

Develop Finance and Insurance workflow. Outside the USA there is interest in a general use Finance and Insurance workflow. This is mostly needed in the developing countries where there isn't an existing model, or where the existing model needs radical changes. The model will take inspiration from the work of OpenHIE Finance and Insurance Services Workflow

For those that want to participate, please contact me. IHE always welcomes new participants.

Wednesday, January 31, 2024

Provenance use in AI

I have been engaged in a few initiatives around AI/ML, both inside healthcare and broader. I have been engaged to work on a variety of different needs, that all use a variation of Provenance. The following is not a tutorial, but rather an outline of the various ways that Provenance is useful in AI. Useful is not to say that these are currently used.

  1. Provenance on dataset that is available for various uses, including being used as a learning dataset.
  2. Provenance on the learning dataset showing where each data came from. 
  3. Provenance on a ML model node showing which data influenced this node.
  4. Provenance on an AI output showing which nodes influenced this AI output (decision, observation, derivation, etc)
  5. Provenance on some action taken because of some AI output.
These steps are simplified and generalized. Especially inside of various architectures of AI/ML the concept of a node is not always identifiable. There is a push to use Provenance to enable explainable and trustworthy AI that would be able to explain why an AI output came to be. So, the above presumes that some node(s) in the knowledge model is identifiable.

These Provenance artifacts are also illustrated here purely as provenance details. That is to say that the Provenance does not carry the inputs or outputs; but certainly, points at them. Thus, one can't look to Provenance to embody the "AI Output", that AI output would be encoded in some other artifact.

I also speak of Provenance broadly. Within FHIR, the FHIR Provenance works fine. Outside of FHIR, the W3C PROV model works fine. But it is also possible that one has some other metadata structure that carries the artifacts of Provenance.

Provenance on dataset

This use of Provenance addresses the situation that those looking to teach an AI/ML, need data. The data may already be known, but there may be cases where one looks to a library of data looking for appropriate data. Where appropriate may include quality indicators, fit for use indicators, authorization rights. These are typical "Provenance What" attributes. As well as classic provenance attributes: Who owns the data, Where is the data, When was the data collected, Why was the data collected. 

The key here is to identify all the useful attributes that might be needed, and thus profile how that is expressed as part of Provenance. Some use-case needs:
  • How was this data collected? User questionnaire, Survey, Synthetic, Combination, Subset, etc
  • Is there a regulation covering this data?  Indicate the regulation
  • What region was this data collected within?
    • Is the data region locked?
  • Is the data about human subjects?
    • Is there subject authorization? 
    • Is the data de-identified? To what risk level?
  • Use obligations? Must be used in aggregation, must be de-identified, must get individual authorization, must be encrypted, etc
  • Allowed uses vs Forbidden uses?

Note that a source dataset may be derived from other source datasets. This is something that is key to Provenance. To be able to say this data is derived from that data using how methodology. In this way a Provenance can indicate that a dataset imports three other datasets. This said, the above What attributes would also need to be combined in appropriate ways. For example, I pull in three EHR datasets with de-identification that supports longitudinal consistency, and because the data are de-identified the original HIPAA regulation requirement is eliminated, yet the region covered is expanded. As such, there needs to be the ability to navigate back to the source of this derivation, but that pathway is likely privileged so not possible to navigate by all users.

Provenance on Learning dataset

This is very related to the Provenance on source dataset, but the distinction is that the source dataset doesn't always come with Provenance. But the learning dataset should know where all the data came from. Thus, the use-case need here is more classic Provenance holding simply where the data came from. This is not to say that one can't include the full details, but would be unnecessary if one can navigate from the learning dataset provenance to the source dataset provenance. Being able to navigate from one kind of provenance to the other is a key feature of provenance.

If there is a specific obligation that comes with some source data, this might be traceable using Provenance as well. I would think a simplifying methodology would be to have the obligations managed independently, so that the obligations have their own Provenance back to the source of that obligation. In this way a learning dataset may have a functional obligation that is sourced from more than one source dataset. This is simply one obligation (rule) with many Provenance. 

Similar to the source dataset discussion around derivation from multiple sources. The Learning dataset would have a wholistic Provenance that expresses the derived state, in addition to Provenance on each of the datasets that were imported.

Provenance on ML node

I will use the concept of a ML node, as an identifiable portion of a ML knowledge model. If there is a very specific ML model concept of a node, this works for me, but I didn't intend only that. I also know that some ML models don't have identifiable sub-divisions of the model, in that case then Provenance will be only possible to the Provenance on Learning dataset. Thus, the concept that a ML node is not always possible, but it certainly is important to explainable and trustworthy AI

The details of how the node was derived from the identifiable data is likely to be less describable. But where it can be explained, that explanation can be recorded in the Provenance as a how attribute.

Provenance on AI output

An AI model will take some input against the current model and produce some output. This input, current model, and output; are clearly attributes for Provenance of that output. The key use-case here is to track that some output is attributable to AI, and attributable to a given model. Use-case would also then be able to tack these outputs based on a given model, thus if the model is found to be defective, then those outputs can be re-evaluated or put into question.

Here I first put some emphasis on output being a subject of Provenance, so let me be clear that Provenance itself is not a way to encode the output. As with all artifacts, Provenance presumes that inputs, outputs, agents, algorithms, etc; are all encoded in some relevant and good standard and are able to be referenced by the Provenance.

Provenance on Actions taken because of AI output

This is getting a bit beyond AI/ML, but one uses an AI/ML to do something, and that something is what I am referring to here. I simply indicate that Provenance is applicable here too. So that one can indicate that some action was taken because of some output from an AI.


Provenance is not the core of AI/ML, but the general concept of Provenance is very valuable to the use of AI/ML

Tuesday, January 30, 2024

VIP Patients in #FHIR

The FHIR security tag `VIP` is used to indicate that a patient's health information is considered to be highly confidential and requires heightened security measures. This may be due to the patient's public profile, occupation, or other factors. VIP is a designation of a person, not a designation of the data. 

To use the VIP security tag, simply add it to the security tag of any FHIR resource that contains the patient's health information. For example, the following code shows how to add the VIP security tag to a Patient resource:

{ "resourceType": "Patient", 
 "id": "1234567890", 
 "meta": {
   "security": [ { 
     "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", 
     "code": "VIP" } ] }
... other content ...

This is an example of tagging the Patient resource to indicate that the patient is a VIP, and thus implies that all the data associated with this Patient needs to be treated as VIP patient data. Once the VIP security tag is added to the Patient, the patient's health information should be treated with heightened security measures. This may include restricting access to the information, encrypting the information, or auditing access to the information.

Here are some examples of how the VIP security tag might be used:
  • A hospital might use the VIP security tag to protect the health information of famous patients or patients who are in the public eye.
  • A government agency might use the VIP security tag to protect the health information of high-ranking officials or other sensitive individuals.
  • A research institution might use the VIP security tag to protect the health information of participants in sensitive clinical trials.
It is important to note that the VIP security tag is just one way to indicate that a patient's health information is considered to be highly confidential. There are other security tags that can be used, such as the Confidentiality or Sensitivity security tag codes. The specific security tags that are used will depend on the organization's policies and procedures.

Typically, VIP patients are limited to a subset of the clinical staff, such as a clearance or role. This might be implemented purely in the security infrastructure or might leverage FHIR CarePlan or PractitionerRole. All accesses to VIP patient data often will trigger stricter scrutiny of accesses. On a regular basis (e.g. daily) all accesses to VIP patient data are reviewed, and inappropriate accesses are investigated with potential corrective actions against the user.

Standards for Accounting of Disclosures

I was asked lately if there are standards that support "Accounting of Disclosures". The use-case of Accounting of Disclosures is specific to the USA, but the broader concept is an expected Privacy Principle. The broader concept of an Access Report, or a Report of Data Uses, would inform a data subject of any use of their data both those that were authorized by the patient (e.g. Consent) and those that were against that authorization. The USA concept of Accounting of Disclosures is a much smaller subset, and in my view a useless subset as this subset is made up of only those uses of the data that the patient explicitly authorized outside the normal Treatment, Payment, and healthcare Operations.

So, are there standards? YES. The standards don't produce a human readable report, but rather would provide the raw material that is used to fill out a human readable report. This is an important distinction, although it is a common distinction between technical standard and User Experience. For example, the technical standards for encoding a lab result are not fit for patient consumption, but they are key contributors to the human readable report that is given to the patient. The report includes context setting, and assistance with understanding the details.

Are their interoperability standards?

Yes, there is a long history of Healthcare and general standards that are designed to support Accounting of Disclosures, Access Log, and many other use cases.

  • ASTM E2147 - Setup the concept of security audit logs for healthcare including accounting of disclosures
  • IETF RFC 3881 - Defined the Information Model (IETF rule forced this to be informative)
  • DICOM Audit Log Message - Made the information model Normative, defined Vocabulary, Transport Binding, and Schema
  • IHE ATNA - Defines the grouping with secure transport and access controls; and defined specific audit log records for specific IHE transactions.
  • NIST SP800-92 - Shows how to do audit log management and reporting - consistent with our model
  • HL7 PASS - Defined an Audit Service with responsibilities and a query interface for reporting use
  • ISO 27789 - Defined the subset of audit events that an EHR would need
  • ISO/HL7 10781 EHR System Functional Model Release 2
  • ISO 21089 Trusted End-to-End Information Flows

More specifically does FHIR have this?

Yes, the AuditEvent resource has as a use-case to provide support for Accounting of Disclosures. The AuditEvent resource is a collaboration between HL7, DICOM, and IHE.

In FHIR R4 - http://hl7.org/fhir/R4/auditevent.html

IHE has a relevant Implementation Guide – Basic Audit Log Patterns (BALP)

within BALP IG, which is all relevant to Security/Privacy audit log recording and access to that recording using FHIR, there is a specific profile of the AuditEvent resource for recording a known disclosure.

IHE has a supplement on ATNA that brings in FHIR AuditEvent

With this linkage between FHIR and ATNA, the events can be recorded using FHIR restful create, and can be accessed using FHIR search. 

Which brings up ATNA (Audit Trails and Node Authentication) which is the long-standing solution in IHE. 

Further IHE governance has each Profile that IHE writes should have in it how that Profiles transactions would be logged in the audit log. These would be in Volume 2, in the Security Considerations section.

Must I record using ATNA or FHIR AuditEvent?

No, one of the benefits of the supplement adding FHIR AuditEvent to ATNA is to provide a search mechanism that produces a FHIR Bundle of AuditEvent records. These records do not need to be originally stored in ATNA or FHIR AuditEvent, just made available in FHIR AuditEvent format. Much like clinical APIs to EHRs that expose the clinical data in FHIR clinical resources, while not mandating the format of the database to be FHIR.

Thus a system can record the event using whatever mechanism it wants to, which might be native database and web-server formats. 

Are there implementations of BALP?

Yes: The following commonly used FHIR Servers have BALP implemented within them. You just need to turn it on. For more details:


IHE is a recognized standards organization focusing on profiling standards. The use of AuditEvent is recognized broadly for support of Security and Privacy audit log requirements.