Thursday, December 3, 2020

IHE releases IUA, HIE-Whitepaper, and html published Technical Framework

Big day for me, and the IHE team. I am so pleased at the way the IHE ITI workgroup membership, and IHE support personal, worked on all of this. I would say this is the biggest impacting release that IHE has done since XDS. This is bittersweet as we recently lost the father of XDS, Bill 

Today IHE releases three very important products:
  1. An update of IUA, the profile of OAuth that IHE has defined. This is an alternative to SMART-on-FHIR, and not intended to be conflicting. Each cover unique spaces with some overlap.

  2. An update to the HIE-Whitepaper, bringing in the newly build FHIR based profiles. Profiles like MHD, MHDS, mXDE, QEDm, PMIR, SVCM, mCSD, ATNA, and IUA.

  3. Brand new publication method for the ITI Technical Framework using html. This is just the final-text, does not include trial-implementation supplements, although they are included in the publication framework.
These three publications are all using the html publication framework, and they cross-link into the technical framework. see This is the new home for html published works from IHE.

I will be writing more articles pointing out specific things of each of these publications. coming soon, right here, and possibly elsewhere...

IHE IT Infrastructure Technical Framework Documents Published.
Is this email not displaying correctly?
View it in your browser.

Important IHE IT Infrastructure Technical Publication News:

The IHE IT Infrastructure (ITI) Domain has been working towards the goal of publishing some ITI documents in HTML versus the current PDF format. Their efforts have produced the following:
  • An updated public comment version of the Internet User Authorization (IUA) supplement 
  • An updated public comment version of the Enabling Document Sharing Health Information Exchange Using IHE Profiles white paper
  • An HTML version of the complete IHE IT Infrastructure Technical Framework
Please see below for further details about these publications.

IHE IT Infrastructure Technical Framework Supplement Published for Public Comment

The ITI Technical Committee has published the following updated supplement for public comment from December 2, 2020 through January 15, 2021:

  • Internet User Authorization (IUA) - Rev. 2.0
Note: This revision of the IUA supplement, published as HTML, updates the IUA profile originally authored in 2013. This new version aligns IUA with the latest OAuth specifications and adds some new deployment options. A summary of changes is noted in the README on the GitHb repository.

This document is available at Comments submitted by January 15, 2021 will be considered by the ITI Technical Committee in developing the Trial Implementation version of the supplement. Comments can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.

IHE IT Infrastructure White Paper Published for Public Comment

The ITI Technical Committee has published the following updated white paper for public comment from December 2, 2020 through January 15, 2021:
  • Enabling Document Sharing Health Information Exchange Using IHE Profiles - Rev. 2.0
Note: This revision of the HIE white paper, published as HTML, has been updated to include advancements in Document Sharing Health Information Exchange support, including the use of FHIR® infrastructure, and support for consuming FHIR® Resources.

This document is available at Comments submitted by January 15, 2021 will be considered by the ITI Technical Committee in developing the subsequent version of the white paper. Comments can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.

IHE IT Infrastructure Technical Framework Published as an HTML document

The ITI Technical Committee has converted the complete ITI Technical Framework to HTML. It is available here.

Important Note: This HTML version of the IT Infrastructure Technical Framework is published in parallel with the current ITI Technical Framework (Revision 17.0) published in PDF format. Any discrepancies between the HTML and the PDF are unintended and the PDF shall take precedence. 

The ITI Domain expects that the next revision of the ITI Technical Framework will only be published in HTML form and the domain will stop producing PDF Technical Framework Volumes. A reader can use a browser to produce PDF extracts and IHE plans to provide more comprehensive functionality to extract PDF next year.

Comments on the HTML version of the IT Infrastructure Technical Framework are welcome at any time and can be submitted via traditional methods at ITI Public Comments or by creating a GitHub Issue.

Wednesday, December 2, 2020

XDS/MHD Community input needed - MHD move away from DocumentManifest

I have asked this on the various discussion lists for XDS and MHD. I have gotten positive response. I am very interested in concerns, and help.  I have started this work, IHE MHD Github Repo

Hi MHD implementer community 

As many of you know, I am the author of MHD and also part of the HL7 FHIR core team. 

ASK: Please consider this message and provide feedback. I want to represent the interests of the MHD community, but also need that community to be active in HL7 and IHE. I am especially interested in concerns with the approach described below. I am also eager to get engagement in the ITI-Tech work we are starting on MHD (see below).

I have been thinking about a maturity problem that is coming up in FHIR R5 related to the FHIR Resources used by MHD. 

Patient is already normative.

DocumentReference is likely to be pushed to be normative in FHIR R5. It is part of US-Core so has a group of people beyond MHD working on it.

List (MHD uses for Folder) is used by a couple of use-cases outside of MHD. So there is multiple groups working on it.

but DocumentManifest is not getting the proper attention to help move it to normative state. If that does not happen, then MHD will stay as Trial Implementation when it should be a consideration for Final Text.

Many of the MHD use-cases are recognized in US-Core, but they use only DocumentReference and don't have use-cases for DocumentManifest or List (Folder). I bring in US-Core only to express where the motivation is to push DocumentReference to normative. IHE is of course Internationally focused.

The only use of DocumentManifest is in MHD...
  1. We (IHE) can do what is necessary to make this normative. I will still need the IHE community to step forward within the HL7 community to push the workgroup owning DocumentManifest to do HL7 governance. Note that this is a big problem as well since DocumentManifest is still owned by Struct Doc WG; where DocumentReference has moved over to OO. Thus this pathway has many organizational challenges.
  2. We (IHE) can switch MHD away from DocumentManifest, using List. There would then be two kinds of list in MHD, one as the SubmisstionSet, the other as a Folder.
  3. We (IHE) can switch MHD away from DocumentManifest toward some other resource. 

ITI-Tech has agreed to #2. That is to stop using DocumentManifest for SubmissionSet, and profile a use of List for SubmissionSet functionality. This might produce some update requests to List to add elements necessary for that use-case. Adding elements to List should not be seen as a problem. List maturity would be needed by MHD for Folder anyway, so putting our efforts toward the same resource would be helpful.

Yes there are functionality differences between a SubmissionSet and a Folder. These differences can easily be profiled into the same List resource.

Note that ITI-Tech is also going to formally move MHD out of supplement form, and into the IG Authoring form. Thus we would benefit from community engagement, such as providing examples and review.

Thursday, November 12, 2020

Open-Source Audit Log conversion

 I was made aware of an open-source project that has addressed converting classic DICOM Audit Messages into the new FHIR AuditEvent. This open-source project is managed on this github repository. I helped the authors with some background and understanding, but I take no credit for the work they have done. 

I am sure they welcome comments, suggestions, and assistance. 

My blog articles on Audit logging for Security, Privacy, and others

Wednesday, November 4, 2020

Patient Master Identity Registry

The Patient Maser Identity Registry is a new profile (Implementation Guide) from IHE. It is designed to address a new environment that has no existing HL7 v2 or v3 patient identity management solution, that needs a multiple organization Patient Identity Management. It defines the following actors. This is the typical IHE model of defining abstract actors, not systems. Thus these actors can be grouped in various ways inside a system that one might more typically understand.

At the center is the Patient Identity Manager, as described in the PMIR profile, this is a very simplistic actor that has no intelligence, it is just a FHIR Server that supports the transactions. Often times a real-world system would have intelligence to detect potential conflicts, or mistakes, or opportunities for linking. A system like that would defined that is is both a Patient Identity Manger, and a Patient Identity Source. This does not mean there are not other Patient Identity Source actors in a network.

There would likely be a Patient Identity Source at each organization. It would likely be in a system that is also a Patient Demographics Consumer. An example would be a Registration Desk.

There would also be typical client apps that would be Patient Demographics Consumers or Patient-Identity Cross-reference Consumers. Note that the Patient Identifier Cross-reference Consumer actor would typically be used in cases where national identifiers are issued to patients, thus a lookup is done using just an identifier. The Patient Demographics Consumer can lookup by identifier, but also can lookup by any of the demographics or identification characteristics.

The Patient Identity Subscriber and Patient Identity Consumer are used together by any system that would like to be notified of changes to a Patient Identity. This would be used by data holders (Data Servers), so that they could correct any data they have. Important is to correct the data when a Patient Identity is merged.

Patient Identity flow

The following shows the flow of these systems

First shown is that a Data Source (a typical FHIR Server) would subscribe to be notified.

Second shown is a flow at a Registration Desk

  • If there is only one Patient found, and all the demographics are correct, then there is nothing more needing to be done. That one Patient found can be used within the community. 
  • There are three alternatives shown: where one patient needs demographics or identifiers updated, where there is no patient found, and where more than one patient are found.  
    • In the first case after clarifying that there is a need to make the demographics or identifier change, the Registration desk informs the Patient Master Registry of the  update to the demographics, which causes the Patient Master Registry to record these changes AND inform all the interested parties such as the Data Services that has subscribed.
    • In the second case after confirming that no patient has found (e.g. a newborn, or new emigrant), the Registration desk informs the Patient Master Registry of the new patient with given demographics, which causes the Patient Master Registry to record this new Patient AND inform all the interested parties such as the Data Services that has subscribed.
    • In the third case after confirming that the patients found are indeed all the same human, the Registration desk determines which patient entry should be merged into the other. The Registration desk informs the Patient Master Registry of the merged patients with specific instructions on which identity should be used and which identity should not be used anymore, which causes the Patient Master Registry to record this merge Patients AND inform all the interested parties such as the Data Services that has subscribed.

This solution is not expected to work everywhere. It is designed for environments that don't have existing Patient Identity infrastructure, and it is designed for places that want to manage a master identity (golden) at the center of multiple organizations.

I do expect that variations will eventually be worked up as well.

Wednesday, October 28, 2020

Webinar on Document Sharing HIE on FHIR

Webinar recording is available that covers the Document Sharing Health Information Exchange (HIE) on FHIR. 

Covering topics of:
  • Document Sharing (concept, XDS, XCA, MHDS)
  • FHIR access to Documents
  • MHD as API
  • Support profiles: IUA, PDQm, PIXm, mCDS, …
  • MHDS as a full FHIR stack solution
  • Support profiles also include PMIR, SVCM
  • Consuming Elements/Resources (mXDE + QEDm)
  • Add Provenance – to get back to source documents


This is available on the IHE YouTube channel  The slide deck with embedded recording is in the IT-Infrastructure github repo 

The content for this presentation are baked into the IHE Mobile Health Documents Sharing (MHDS) profile.

Monday, October 26, 2020

Patient Generated Health Data

Some background on what the broader government (HHS) under the office of the national coordinator (ONC) is saying about Patient Generated Health Data (PGHD). This is not a very mature definition yet, mostly because of wildly divergent abilities given to patients among the 6000 healthcare provider organizations in the USA. However the details outline here have held up well. This is what we wanted 5 years ago, it is still what we want. This includes the risks outlined 5 years ago, they are still risks today. The details on this page are mostly from January 2018.

The bad news is that we have not progressed as much as we thought we would have 5 years ago.

​The infographic is the most useful thing on this page. It covers the points quite nicely and clearly.

Wednesday, September 16, 2020

IHE-Connectathon in November to be Online

 Brussels face to face Connectathon transformed to ONLINE, 2-6 November

IHE-Europe Connectathon takes place online

After thorough consideration and evaluation of the current COVID-19 developments, we are urged to announce that the 2020 IHE-Europe Connectathon scheduled to take place on November 2-6 in Brussels, Belgium will be taking place online. IHE’s globally-developed, standards-based, open-source interoperability testing platform together with experienced monitors will support the testing event.


When we made the decision to postpone IHE-Europe’s 2020 Connectathon Week from March to November 2020 due to COVID-19 imposed lockdowns, we had hoped that the global health environment would have improved sufficiently to hold a successful in-person event. While there have been successes and challenges managing COVID-19 impact across the world, at the moment travel warnings and restrictions are in place for many areas relevant to Connectathon participants, including Brussels. Since improving the health of people is at the heart of IHE, we do not think it is appropriate to bring together people from across Europe and other parts of the world together in-person for these IHE events at this time.

We will be collaborating with IHE domains from across the globe to hold the online IHE Connectathon utilizing IHE’s interoperability testing platform at the same dates as initially planned: 2-6 November. Current registrants' registration fees will be honored for the online event in case they register for it again, and will be refunded if they choose to not make use of this great opportunity to advance the interoperability of healthcare products and to shape the possibilities to test the interoperability of these products online.

All registrants will receive more detailed information soon on:

  • fees and registration dates
  • list of available IHE-profiles
  • vendor connectivity test session before the Connectathon week
  • instruction sessions

And more.

We look forward to receiving your registration for Europe’s first ever online IHE Connectathon, performed from November 2-6 in the European time zone, once the registration has opened. You may indicate your wish to participate in advance via

As announced in parallel by IHE USA, the IHE North American Connectathon in March of 2021 has been planned from the beginning as a fully online event, facilitating participants from the North American time zone. The NA Connectathon will build upon lessons learned in the European Connectathon and leverage an enhanced version of IHE’s online interoperability testing platform, Gazelle.

IHE World Summit postponed

We regretfully decided to postpone the IHE World Summit which was supposed to be held from 3 to 4 November during the IHE-Europe Connectathon week and to continue to monitor the COVID-19 global situation in order to determine a new date. We are currently aiming for a date in 2021, but this strongly depends on the development of the crisis. All World Summit participants will be refunded their fees. We thank you for understanding and we will keep you informed on the developments.