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.

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.

Notable

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.