Thursday, February 27, 2020

Mobile Health Document Sharing (MHDS) Profile

This profile shows how to build a Document Sharing Exchange using IHE profiled FHIR® standard, rather than the legacy IHE profiles that is dominated by XDS and HL7® v2. This profile will assemble profiles and define a Document Registry.

The MHDS Profile specifies how a collection of IHE profiles can be used by communities for exchanging health information. These IHE profiles include support for patient identification, health document location and retrieval, provider directories, and the protection of privacy and security. MHDS shows how several IHE profiles work together to provide a standards-based, interoperable approach to community health information sharing. The IHE IT Infrastructure Domain has published several resources to support document sharing:

Document Sharing on FHIR

This MHDS Profile defines a Document Sharing Exchange that is based around the HL7 FHIR standard, following the principles described in the Health Information Exchange: Enabling Document Sharing Using IHE Profiles whitepaper. This Document Sharing exchange requires the same management of metadata as described in the Document Sharing Metadata Handbook.

The MHDS Document Registry

This profile orchestrates actors in many existing IHE profiles and creates one new actor. The actor that is specific to this profile is a Document Registry. The following Figure shows a detailed Actor diagram for the MHDS Document Registry.

The Document Registry is grouped with a set of actors from other profiles to provide the following functionality.
  • MHD - Document Responder supports publication requests by the MHD Document Source. The Comprehensive Metadata Option is required.
  • MHD - Document Recipient supports the discovery and retrieval of documents by MHD Document Consumer.
  • PMIR - Patient Identity Consumer provides patient identity synchronization and specifically the merge function to be applied to any data managed in the Document Registry.
  • SVCM - Consumer enables the Document Registry to gain access to ValueSets that the Registry is enforcing Metadata consistency.
  • mCSD - Consumer enables the Registry to have access to Organization and Practitioner resources.
  • IUA – Authorization Server and Resource Server enforces access control decisions.
  • ATNA - Secure Node enable the Document Registry to be secure, record audit records, and support secure transactions.
  • CT - Time Client assures that all records of time done by the Document Registry are aligned with the Time Source.

MHDS Options

  • SVCM Validation Option -- The Document Registry will do metadata validation against ValueSets managed in the SVCM Terminology Repository
  • UnContained Reference Option -- The Document Registry will allow author, authenticator and patient references rather than forcing contained resources
  • Authorization Option -- authorization using IUA is included in the Document Registry
  • Consent Manager Option -- Patient Privacy Consent Management is included in the Document Registry for simple Permit and Deny (requires Authorization Option)

HIE Central Infrastructure

In MHDS, the Document Registry is part of a Document Sharing Health Information Exchange (HIE). The Document Registry relies upon services that would be hosted within the HIE Central Infrastructure with a set of Service endpoints as illustrated in the yellow “HIE Central Infrastructure”. The HIE also contains systems, illustrated in green, that submit and consume documents.

The Document Sharing Health Information Exchange will also host a set of Services based on IHE Profiles as shown in the figure. These provide services to the Document Sharing Community (aka Community):
  • CT Time Server – to provide consistent time to all participant systems
  • ATNA – Audit Record Repository with support for the ATX: FHIR Feed Option – to capture audit events and provide appropriate audit log access for security and privacy use-cases
  • PMIR – Patient Identity Source and Patient Identity Manager – to provide patient identity lookup by demographics or identity, and to receive create and update of patient identity from participants
  • SVCM – Terminology Repository – Provide vocabulary and value set management within the Community
  • mCSD – Care Services Selective Supplier – a Provider Directory to enable endpoint lookup and optionally provider identity management

There are other useful actors that are compatible with MHDS, but are not required by the MHDS Profile:
  • NPFS – File Manager – Provide files that are needed in the community but are not patient specific such as policy documents
  • mXDE – Data Element Extractor – to enable QEDm access to data elements derived from published documents
  • QEDm – Clinical Data Source – to enable access to data elements (aka FHIR clinical Resources)
  • mACM – Alert Communication Manager – to enable community supported alert communications

In addition to these IHE-defined actors, the Community will also select how they will manage Digital Certificates through a Certificate Authority, and other functionalities and non-functional requirements such as response-time, service-level-agreements, remediation-planning, remediation-access, etc. The Document Registry and the supporting services listed above provide a set of services that make up a Document Sharing Infrastructure that is based on FHIR. This set of services enable Systems that Publish Documents and Systems that Consume Documents.

Additionally, the mXDE profile may be used to make the information in the Document Sharing infrastructure more consumable as FHIR Resources using QEDm. These client of the MHDS services use the existing profiles and are not specifically constrained by the MHDS profile. See section X.6 for more details on Cross Profile Considerations of System that publishes documents, System that consumes documents, and System that consumers clinical data elements.

Public Comment #2

This supplement will be in Public Comment in March. This is a second public comment phase in order to assure it gets broad and deep review.

Tuesday, February 25, 2020

IHE Winter 2020

The IHE Winter 2020 face-to-face capped off a 5 week road-trip for me. I am so very glad to be home and able to sleep in my own bed, work at my own desk, surrounded by my kittens and family.

The ITI committee has finalized three work items that will soon be seen open for Public Comment: Public Comment on a whitepaper, and two profiles (Implementation Guides).

SNIF - Survey of Network Interfaces Form 

This is a whitepaper outlining a problem that is faced by many healthcare software or device vendors when they attempt to integrate with a customer environment such as a hospital or clinic. The problem is that there are some critical networking details that are needed to make the connection successful. Things like, what is the IP address of the patient registry.

The whitepaper is attempting to bring together those that manage a network, with those that will eventually need to be integrated into the network. There are a large list of potential ways that this critical information can be managed, but none of them are dominant or comprehensive. By bringing this group together, IHE is attempting to get these stakeholders to work together to a common agreed solution.

One leading proposal is based on our experience running IHE Connectathons, the schema behind Gazelle and how it manages partner testing.

SVCM - Sharing Valuesets Codes and Maps

This profile addresses defining reusable Actors for managing and using terminology using FHIR. There is not much constraints within the IHE profile, but rather setting well defined abstract actors to enable use-case orchestration. There are two actors defined: Terminology Repository and Terminology Consumer. There are seven defined transactions between them. All of the use-cases are focused around use of terminology. There is no intention of supporting the 'management' of terminology, the management is an important functionality of a system declaring the Terminology Repository.

MHDS - Mobile Health Documents Sharing

This profile went through one public comment, so this will be an unusual second public comment. The reason for the second public comment is to assure that we get broad review. The first public comment was on a far less mature text, and was over the Christmas break and January. So we expect that the second public comment can get comment more deep. The biggest improvement is in the diagrams.

MHD defines a full Health Document Sharing infrastructure by assembling many profiles such as the SVCM, mCSD, ATNA, and PMIR. There is one new Actor, the MHDS Document Registry, that takes on the central Document Registry. This Document Registry actor is required to act as a document repository, but this does not force organization sourcing documents from managing their document repository within their organization like is set forth in XDS. The following shows a detailed Actor/Transaction view given two stereotypical clients "System that publishes documents" and "System that consumes documents" pictured in green on the left. The supporting infrastructure is represented in the middle in yellow, this supporting infrastructure is simply the use of these services from the given supporting Profiles.

I will cover more on MHDS in a follow on article.

Tuesday, January 21, 2020

Mobile Health Document Sharing (MHDS) - First Public Comment

MHDS is published for public comment. This is the first of two Public Comment periods, with the next one this spring. We are doing two public comment phases in order to get broad set of review.

The Mobile Health Document Sharing (MHDS) Profile is a 100% FHIR Document Sharing infrastructure leveraging many IHE FHIR profiles including MHD. Where MHD has historically been an API to an XDS or XCA environment; MHDS introduces a new Central Registry actor and discusses how to build a complete Document Sharing infrastructure using other IHE Profiles.

This Document Sharing includes support for sharing FHIR-Documents, but is content format agnostic, thus equally capable of sharing CDA documents, PDF documents, or imaging. The big difference with MHDS is that one does not need to have an XDS or XCA backbone, as the backbone of MHD is purely a FHIR server.

Please review and comment. Good and bad. We need to reach a new #FHIR audience, new markets, new solutions. Here is the announcement and details on how to review and comment Note that the deadline for comments is February 14th, a bit shorter than normal, but we need to get comments in by the next IHE face-to-face meeting scheduled for the following week.

Here is the public comment forum and link to the MHD supplement

Included is support for

a system that is publishing documents

a system that is consuming documents

a relationship to mXDE enabled consumption of FHIR resources

Thursday, January 2, 2020

2019 wrap

I am not impressed by 2019. Not personally, not for the healthcare industry, not for my country, and not for our world. This is depressing, but also gives me many things to work on. It is working on fixing problems that gives a Systems Designer something to look forward to in the morning.


On my blog, I only posted 28 articles, which is average more than two a month. But realistically I had a few months where nothing was posted, and other months where a set of four posts happened.

  • Segmentation and Security Labeling: 1, 23, and 4
  • Blockchain: 1
  • Provenance: 1, 2, and 3
  • HIE on FHIR: 1, 2, 3, 4, 5, 6, 7, and 8
  • IHE: 1, 2, 3, 4, and 5
  • Patient Empowerment: 1, 2, and 3
  • Speaking Engagements: 1, and 2


My engagements with standards have been the most productive part of my work life. It is hard to come up with describable milestones, but I know that I have succeeded at many milestones.
  • The IHE profiles from ITI are all now aligned on FHIR R4, and all have FHIR conformance resources published. This is not all me, in many cases I was just the one pushing the authors 
  • I am now part of a team funded by the cooperative agreement between ONC and IHE-USA to position IHE as a major organization for standardization of FHIR based Profiles (aka Implementation Guides)
    • Catalog IHE Profiles that utilize the FHIR standard to enable cross community health information exchange
    • Identify and prioritize new profiling opportunities to leverage the FHIR standard.
    • Accelerate the development of robust, real world testing processes and adoption of the updated FHIR-focused IHE profile and HL7 implementation guides 
    • Actively engage with HL7 and IHE International on lessons learned through profiling improvements and real-world testing
  • IHE use of the HL7 Implementation Guide publication system is coming along. It is taking longer than anyone wants, but we keep coming up with instances where the tooling is (a) hard to use, (b) unstable, and (c) missing important features. In all cases we are working with HL7 leadership together to make this tooling better for everyone.  


The big win for the year was a 60 pound weight loss (4.25 stone) on a Keto diet. The bad news is the last three months have been flat. I wish that was my plan, but I really want to loose another 50-60 pounds. Injury to legs and feet have kept me from exercising.  I feel a bit better, and do enjoy doing things that last year would have exhausted me. But not good enough, yet...