Thursday, July 30, 2020

Panel Moderation: ONC Tech Forum - Advancing Trust of Third-Party Applications

Coming up shortly is an ONC Tech Forum ( August 10-11) virtual event. There are many tracks that I would recommend engaging with. 

I have been asked to moderate the afternoon Track 3 on Monday (1:00-2:30 pm Eastern Time)

Track 3: API Standards and Innovation
Advancing Trust of Third-Party Applications: Issues and software solutions
The 21st Century Cures Act Final Rule requires that Health IT Modules provide a standardized API for patient services, including the ability for patients to use third-party applications of their choice. This session will explore industry implications of direct-to-consumer health IT products, privacy and security policies and considerations for the future.

As a moderator I will be guiding the content and questions to the participants. So anyone that wants me to ask their question can feed their question to me via this blog article or email.

The panelists are made up of people who are very active in the API security space. I am very happy to have them be the focus of the topic.


Thursday, June 18, 2020

IHE ITI Work Items summer 2020

ITI Tech has 5 projects happening and each have made progress in the past few weeks. I encourage participation, even if you are not a typical IHE participant. All of our projects are using GitHub, so let me know if you want to engage and have not yet gotten assigned to the proper GitHub teams. I need your GitHub username.

IHE use of IG Build tool (not exclusively ITI, but we do dominate active members)
* kanban board for this project
* github where we doing most of our work
* example of PIXm profile converted from word/pdf supplement to IG build 
* example of MHD profile using FSH/sushi authoring
* example of the SANER project using FSH/sushi authoring and Keith magic (NOTE this is an HL7 project, but Keith offers this layout as inspired by the IHE supplement layout)

HIE White paper update
* kanban board for this project
* github where the work is happening
* html rendering of current work for committee review (not proper external publication)

IHE publications in html
* kanban has not been started as too much is in flux
* publications github where we are doing our work
* html rendering of current work for committee review (not proper external publication)

IUA upgrade 
* strong use of github issues
* Team is going forward editing in markdown for supplement publication (not word doc)

SNIF White Paper promotion (more of an ITI Planning task)
* Formally published at Survey of Network Interfaces Form – Published 2020-05-29
* GitHub repo for experiment publish as html and use of GitHub Issue Tracking
* html rendering of github markdown authored for committee review
* Note we are experimenting here with using Github page publication
* Main goal at this point is to promote this to get feedback on interest in developing this further

ATNA profile specific patterns using Gazelle
* There has not been much work, but the idea is to leverage the fact that Gazelle has and needs the ATNA Audit Message patterns to enable testing.
* Future (likely the above html publications) publications of supplements and technical framework will not include the ATNA audit message pattern table inline, but rather this pattern will be defined in Gazelle and that instance will be pointed to by the IHE specification.

Tuesday, June 16, 2020

Web API security as foundation for #FHIR

I am a standards geek, and as such I am a strong advocate for standards developed and maintained by experts in their field. HL7 and IHE are where I focus my personal standards development. In the space of things that are special in Health IT. 

I resist when projects are brought to IHE or HL7 that want a standard developed or a profile developed in a technology space that is foundational to Healthcare, but where the specialization for healthcare is not needed. The following are some pointers to "Standards" that healthcare should use as is. This is not to say that there could be no specialization for healthcare, but rather that the fundamentals of these standards need to be followed first before anything special for healthcare is ever needed.

Web API Security -- OWASP Top 10 Web Application Security Risks

  1. Injection. Injection flaws
  2. Broken Authentication. 
  3. Sensitive Data Exposure. 
  4. XML External Entities (XXE). 
  5. Broken Access Control. 
  6. Security Misconfiguration. 
  7. Cross-Site Scripting XSS.
  8. Insecure Deserialization. 
  9. Using Components with Known Vulnerabilities. 
  10. Insufficient Logging & Monitoring. 

OAuth 2.0 Security Best Current Practice

This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0.

IETF Best Current Practice in security

  • BCP038 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing
  • BCP046 Recommended Internet Service Provider Security Services and Procedures
  • BCP061 Strong Security Requirements for Internet Engineering Task Force Standard Protocols
  • BCP072 Guidelines for Writing RFC Text on Security Considerations
  • BCP106 Randomness Requirements for Security
  • BCP136 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)
  • BCP140 Preventing Use of Recursive Nameservers in Reflector Attacks
  • BCP188 Pervasive Monitoring Is an Attack
  • BCP194 BGP Operations and Security
  • BCP195 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
  • BCP199 DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers


Wednesday, April 8, 2020

Disaster use of HIE is a PurposeOfUse

In the USA there is a project called Patient Unified Lookup System for Emergencies (PULSE). It is an exemplar of functionality that can quickly enable healthcare treatment use-cases that are within the purpose of a Health Information Exchange, yet are also dynamically deployed as necessary.

The video gives a good background that is important. I will let the video describe it.

Essentially it is a very thin web front-end that enables authorized users to gain READ-ONLY access to health information on patients for Treatment use only. It thus needs to

  1. manage authorized sites using the access system. These sites need to be carefully managed to be quickly deployed, yet there needs to be confidence that when one site is deployed that it is authorized.
  2. manage users at that site. where these users are often temporary workers that have migrated to the disaster area to help out. Thus the system needs to provision user accounts, while making sure that policy and procedures assure that the users are all legitimate users
  3. track all users actions so that there is traceability and accountability
  4. patient discovery mechanism
  5. document discovery of list of documents 
  6. display of user selected document 

Putting it together using Interoperability

When the system makes a request to the network for patient discovery (IHE-XCPD), document lookup (IHE-XCA), and retrieval of a document (IHE-XCA); the request must be recognized as coming from an authorized site and an authorized individual recognized at that site (IHE-XUA). This authorization confidence is what is the hardest part for a system like this. That is it is hard to express to ALL of the participants in a health network, especially a very large one like the USA nationwide network as a collaboration of thousands of participant organizations. Especially given that the PULSE is a temporary site created just yesterday.

The method should leverage the certificate management system that is used to manage trust within the network. The new site would be issued a new certificate within the Certificate Authority, and it would be given attributes that make it clear it is a Disaster provisioned site, and that it is authorized under a broader authority. These certificates naturally are trusted through the normal certificate authority chain.  

This likely needs to be part of a regular testing of the network, where a short-term certificate gets provisioned and each participant is tested that it would respond. This test does not need to expose patient data, as a Patient Discovery of a test patient would return Zero-Results-Found if the trust was working, vs Authorization-Failure if that partner was not handling the certificates appropriately. This regular testing is necessary as failure demurring a disaster is unacceptable. 


Certificates are important for trust, but don't convey the intended purpose. It is possible to embed the purpose in the certificate, but there is a more dynamic mechanism already available in the IHE-XUA profile, which is a specification for how SAML would be used in a network of networks. There is a PurposeOfUse element that carries the purpose for which the request is being initiated for, and for which is promised to be the only use for which results will be used. Thus any data released is released only for the explicit purposeOfUse requested.


Seems logical to me that these requests are clearly for the purposes of Treatment (TREAT). There would not be use of this kind of a system for Payment ( HPAYMT) or Operations (HOPERAT); where as these would be typical of a normal organization requests of the network.

plus Disaster

But it seems that these requests should also include another PurposeOfUse value that indicates the specific urgency of the care setting. I recommend that the Disaster (DISASTER) PurpoeOfUse be added to the Treatment.  In this way the custodian organization has better knowledge that it can use for Access Control purposes and for Audit Logging. For example with the addition of Disaster to Treatment, the organization could have special handling within their Privacy Policy that authorizes access for Disaster access. This would be important as the Disaster site could not have been recognized during normal times, so the patient could not have had the ability to explicitly permit or deny authorization.  Thus this would be a recognized authorization implicitly.

UPDATED: I think Disaster PurposeOfUse could also be a signal that the retention of any data returned is only for the duration of the episode/encounter and no longer than the declared Disaster. If this is not folded into the PurposeOfUse of Disaster, then it needs to be addressed in the Disaster Site Certificate policy. Somehow retention is different, and as such needs to be expressed as different.

Write access

Today PULSE is just READ-ONLY, and that is likely all that is needed. However with COVID-19 there is a potential need for some results (Positive or Negative) to be published so that future treatment settings can be aware. This likely would be done today through a recognized normal healthcare treatment organization. That is to say that these Disaster settings are often (always?) associated with some formal treatment organization. So there is methods available today. It is not clear this needs to be changed. But it is a use-case that must be supported somehow.

Tuesday, April 7, 2020

Privacy-Preserving Proximity Tracing -- well done #PbD

I am impressed by @PeppPt Privacy-Preserving Proximity Tracing for use in situations like #COVID19 -- Impressive #PbD Privacy by Design. Their detailed design document with Privacy Considerations, and Security Considerations is available here.

The use-case they are addressing is discovering who someone has been close to, when later that individual is found to be positive COVID-19 infected; while maintaining everyone's privacy.

Their documentation shows good design thinking and transparency of risks, mitigation, and residual. It shows that when one includes Privacy-By-Design from the beginning of a project, that one can preserve privacy while creating a system that meets needs. There is further FAQ on issues

Not only is this a good design of a system, it is excellent exemplar of a specification that includes Privacy Considerations and Security Considerations. These sections outline the persona of attackers, motivations of attackers, and methods these attackers might use. They then go into the design mechanisms that they have included to thwart these attacks. They do also include references to regulation/law that would be used against successful attackers. I like this inclusiveness of technical design and policy enforcement.

Some concerns I did not see addressed, although these seem small. These are more operational issues than privacy risks:

  1. They never express the storage usage on the mobile device. It seems that someone in a very populated area would harvest many EphID. So it is not clear how much storage space is needed. The nice part is that this is stored on the device. They do hint at this in a FAQ that asks about upload, where they express that some might need to upload 600MB daily, which tells me that I might need to store on my device 600MB * 14 day window = 8.5Gig. And this is with compression they outline. FAQ
  2. They did not address the risk that a mobile device will have some backup (or storage space harvesting) that might expose the data to those beyond the individual using the mobile device. They seem to expect that everyone has perfect control over their own device, which many flashlight applications have proven is a fallacy.
  3. They don't explain how the end-user is convinced that they have a distributed model of the solution and assured that there is not a centralized exposure. The security and privacy features they have put into place are hard to explain to a typical end-user. I think this is mitigated by the very nature that there is an application that must be installed for this to work. That application will be scrutinized by privacy and security professionals. And further if it is found to be not following the design, it can be revoked from the app-store.
  4. They don't address well the case where an attacker has motivation to monitor one individual. In this case the attacker can grab EphID for a very short time, where it is known only the targeted individual is present. Then monitor positive individuals looking only at that one targeted individual. Likely a high-value individual, so that kind of an individual should be careful in using this kind of an app. Note that high-value might be overall high-value, such as a sports figure; or may be a local high-value individual, like an estranged spouse.
  5. They indicate some location data would be recorded, but I couldn't find what that is. They only indicate that the EphID and gross time is captured. I think this is all that is needed, but it is not clear that is all they keep.
  6. Their proximity detection is only for proximity of the two humans. It does not address when an infected individual leaves virus behind that is picked up much later. The virus can survive in the air for a period of time, and on surfaces much much longer. So there will be many false-negatives.

Wednesday, March 18, 2020

IHE Public Comments

Now that everyone has more time on their hands, with no commute to work and no social hour over coffee,  I want to remind you all about opportunity to provide YOUR comments to Healthcare Standards Organizations like IHE.

I am going to focus on IHE because they have stuff to comment on right now. HL7 will be coming up soon.

What is a ballot?

A ballot is the term we use to indicate a specification that we want comments on, and also your comments submitted are your ballot.

Who can comment?

  • IHE - ANYONE can comment, you do not need to be a member.
  • HL7 - you need to be a member or signup as a one-time participant

Where do I find things that are available for pubic comment?

How do you comment?

Both organizations have slightly different, yet very similar methods. Generally a comment can be as simple as an observation there is a typo, to a complaint about a given sentence, to questions about concepts, to directions to other relevant standards we might have missed.  The more specific the better. Even better if you recommend how you would like the text to change, you might be right.  

Each of these would be an individually recorded comment, within a set of comments. You would submit the set of comments. In this way we can review each comment, along with others comments on that same sentence or concept. Thus we get a feel for not just your concerns, but also the concerns of the community consensus.

Can I provide Positive comments?

YES. We love it when people point out when they agree with specific things too. This helps us weigh positive comments against others who provide negative comments.

IHE Ballot comment submission?

IHE has a web form that you submit your comments. Best case is you use a spreadsheet to record your comments, and submit the whole spreadsheet as one electronic submission. You can also submit then via an email.

Here are some ballots from IHE that are ready right now. If you read my article after today, this list might be out of date. So go to

Note: IHE YouTube Channel

Tuesday, March 17, 2020

Public Health is a PurposeOfUse -- PUBHLTH

As I covered in yesterdays article, PurposeOfUse is a critical prime vector that a data custodian will use to make access control decisions. Where PurposeOfUse is the intended reason the data is needed, and equally the restriction on how the data can be used. When I indicate a restriction, I mean that data released under a specific set of PurposeOfUse must not be used for other purposes beyond that which was clear during the access control decision that released it.

Public Health is a defined PurposeOfUse -- PUBHLTH -- To Perform one or more operations on information for conducting public health activities, such as reporting of notifiable conditions.

Thus when data are requested for Public Health needs, the PurposeOfUse would be PUBHLTH. When this PurposeOfUse is seen, then the access control decision checks that the request is from an authorized Public Health authority. There would be the typical checks that the requested data is within the scope of the Public Health purpose, etc.

Public Health authorized access often is an exception to any Privacy Consent restrictions the patient might place upon their data. Thus in this case the access control decision, when starting with Public Health PurposeOfUse does not need to check a Patient specific Consent, or a Patient specific restriction.

During a declared National Health Emergency, such as we have now with COVID-19,  the rules might be adjusted to include more organizations? or more kinds of data that can be requested? or more organizations?

This PurposeOfUse would be used with a FHIR Bulk Data access where the data are being gathered for Public Health monitoring.

This PurposeOfUse value would also be attached to messages (e.g. HL7 ADT, or FHIR Message Bundle) that are PUSHED rather than queried for. The indication of -- PUBHLTH -- is an indication to the recipient that the data is restricted to Public Health use, and shall not be repurposed for other uses beyond Public Health.

Monday, March 16, 2020

Custodian access control decision differences between Clinical and Individual

There is a fundamental difference between access requests for Personally Identifiable Health Data when a PHR requests access vs when a Clinical application or other EHR asks for access.  The difference is keyed off of the Purpose Of Use (PurposeOfUse) in the request. Let me explain.

Too often networks today are single purpose. That is that the HIE is designed for ONE purpose. For example a Health Information Exchange (HIE) that is designed for supporting Treatment. When a network is single purpose, then this simplifies the access control decision. However this does not scale to Purposes beyond Treatment. Thus one needs to carefully design the security tokens in ALL requests so that they declare what Purpose is driving the request for data. This has been built into the IHE security token profiles from the beginning:
It is also built into the HEART specification from the start.

It is being considered to be added to SMART-on-FHIR, but is not fundamental there. Today a custodian trusting SMART-on-FHIR must presume Purpose from the indirect means. I encourage participation so that this is informed by an active consensus.

Why is PurposeOfUse so important?

It is the first critical attribute because it sets the context for the request and how the data will be used. This vector is critical to business concerns, and also critical to Privacy (e.g. Consent and Authorizations). It is also critical to recording the audit log, that might inform an accounting of disclosures.

How is PurposeOfUse used?

From a Security/Privacy perspective, the fundamental
difference between an EHR and a PHR with regards to authorization is that a PHR is accessing a patient record onbehalf of that patient, with the data accessible on that PHR only by that patient. Yes the patient can then provide access to others, but it is a assignment action by that patient.  YES one must know that the PHR is trustworthy to be upholding the desires of the Patient. The Patient must be the one responsible for holding the PHR accoutable for upholding their desires. Thus when the Patient wants only themselves to have access, it is the PHR that holds access to only that Patient.

An access by a PHR onbehalf of the patient, would use a PurposeOfUse of PATRQT (Patient Requested). There are some sub-codes that can be used for family, power of attorney and support network; but these are unusual.  Thus a Patient Requested request is explict to the Patient. The Access Control decision can then focus on proving that the USER is the Patient. If the USER is not the Patient, then access Deny. If the USER is the patient, then further checks can be done (for example often lab results are held for some number of hours to allow a clinician to address 'shock' concerns).

vs Treatment

Where as an EHR or clinical application requesting access to data will incorporate the results into the EHR (or clinical application) where role-based-access-control will allow others to access it for Treatment, Payment, and Operations. Under the treatment purposeOfUse the hope is that it is constrained to legitimate relationship (care Team) with appropriate 'safety' exceptions, etc. The reason is that once data has been used by a practicing clinician within an organization, then that data is part of the legal medical record of that organization. That organization has obligations they must uphold around medical records retention and health safety. 

Thus when a Treatment PurposeOfUse is asserted, the access control decision knows that the result is not going to be limited to the USER making the request, it is a request on behalf of the ORGANIZATION, and the retention expectation would be for the life of the medical record retention at that organization and the future access controlled by that organization policies. Thus a access control decision to release for Treatment (which should explicitly include Payment and Operations; but often these are implied), must be made based on the ORGANIZATION requesting, not the USER. 

The USER, ORGANIZATION, PurposeOfUse, etc... MUST be recorded in audit logs, as the request was triggering by a specific user for a specific purpose. 

These are NOT bright lines, they should be more bright than they are. But this is how I get to an understanding that an authorized Treatment PurposeOfUse is onBehalf of the organization requesting; where a Patient Request is onBehalf of THAT patient, not the PHR agent. Yes the PHR agent does need to be trusted, but that trust should be in the hands of the Patient, not in the hands of the custodian making the access control decision to release data. 

Note Research and PublicHealth PurposeOfUse are closer to EHR than they are PHR; but I expect them to be project specific within that broad purposeOfUse. Thus my overall statement that PurpseOfUse is critical vector in any request for data from a custodian.

When the custodian is a research data lake, or a PHR, or etc... the same rules apply, that PurposeOfUse is the primary access control vector.

PurposeOfUse is more important than data-link authentication?

No, not really; but that is handled usually automatically at a much lower level. So I presume you didn't get to any access control decision without passing link or message authentication.

GDPR requires PurposeOfUse declaration

GDPR is very clear that one must declare what purpose is being asked for, and that data released for a given purpose can not be repurposed.

PurposeOfUse is core principle of Privacy

I base these on the Privacy Principles

PurposeOfUse is not enough.

Many other vectors are important. I am just pointing out that PurposeOfUse is the FIRST vector, the primary vector. See Sensitive Health Topics, putting the patient at the center of an HIE, deep article on Controlled HIE, and all other Privacy topics.

Thursday, March 12, 2020

My Mother

I lost my mother this week.
She lived a long and productive life. She is survived by my father. Both the ripe old age of 92, having been together from the age of 15.  A Lutheran and Catholic getting married back in the 40s. My brother, three sisters, and I are all very close. Yet we are also spread from east to west coast and many locations between; including a foreign exchange brother in Switzerland.

My mother was the inspiration for my technology, science, and healthcare views and goals. I was told that while in High-School she worked in the chemistry department, and after graduating, worked as a Lab tech in healthcare. She would tell of counting white blood cells, and other lab tasks.

As computers appeared, during my lifetime, she was always talking about them. So I worked hard to buy my own first computer, a Commodore 64 when they were first introduced to the market.  She always encouraged my technology interests.  She was active early and continually on the internet, with a desktop computer.  Using many services, email, and skype. Often doing video conference with her grand-children.

Equally she encouraged me to always have a scientific mind, always question why something is the way it is, to always build upon the advancement of others that came before me.

All of these very open perspectives while being a devoted Catholic. Helping me understand that these different perspectives do not necessarily need to conflict.  I am so glad I grew up in a very open community, understanding church, and welcoming family. Far more could be said about this, but I think I am leaving the scope of my blog, and getting teary-eyed. 

Wednesday, March 4, 2020

HIMSS 2020

I made the mistake of not listening to good advice to NOT Watch the Movie "Contagion".  I am scheduled to go to HIMSS next week, and a wedding later this month. The Movie has some very obvious over-dramatized aspects, like the virus morphs on the timescale of days. But the Movie has so many points that are right-on, and specifically right-on in alignment with COVID-19. The in-real-life daily TV news actually over-dramatizes COVID-19 more.

I am not really more fearful, I already had a rational level of concern. I had changed my behavior as I have just finished 5 weeks on-the-road including Sydney. I am not feeling confident that I am immune. Each day is another opportunity to get sick, with all sorts of illnesses.

I am currently still planning on going to HIMSS. My biggest concern right now is that the HIMSS attendance will be next to zero, that the only people that will be there to talk to are other vendors or people demonstrating or speaking. That will make HIMSS less helpful than not having the event. I am not advocating for canceling, just hoping that people put on their big-boy-pants and come to HIMSS anyway. DON'T COME IF YOU ARE SICK!!!

I will be there, and have three speaking slots:

Promoting Safe Health Information Exchange Through Granular Privacy Protections

8:30am - 9:30am Wednesday, March 11
Session ID: 100
Orlando - Orange County Convention Center W207C

Description: Standards such as DS4P and C2S allow for granular tagging of sensitive data elements to support patient privacy preferences while promoting interoperability but have not been widely adopted and they do not address many common clinical pain points for providers and patients. A developing workgroup of multidisciplinary experts is building on work started by the DS4P/C2S standards in order to produce recommendations for future standards development and a consensus-driven implementation guide to facilitate industry-wide adoption. We have defined two use cases to frame relevant issues from various stakeholder perspectives. We seek input from relevant stakeholders as we identify ongoing leaders for this work and identify discrete deliverables and next steps for this project. Join us to advance the conversation with a broad stakeholder group so patients and families can benefit from accurate exchange of information with confidence that their wishes regarding data privacy are respected.

Learning Objectives
  • Discuss current standards designed to promote the safe exchange of health data by allowing patients granular control over their data
  • Recognize common clinical use cases not addressed by current granular data tagging standards
  • Identify implementation challenges and opportunities for consensus-driven guidance from the industry

IHE USA and ONC's Cooperative Agreement to Advance Real-World Interoperability

4:00pm - 5:00pm Thursday, March 12
Session ID: 309
Orlando - Orange County Convention Center

Description IHE USA was awarded a 5 year cooperative agreement with the Office of the National Coordinator in September of 2019. The purpose of the agreement is to help accelerate the development of new and updated IHE profiles and associated real world testing that support advancing FHIR. Learn more from experts from IHE and ONC as they discuss the collaboration activities with ONC, new and upcoming IHE profiles that support FHIR, how these collaboration efforts will advance interoperability, accelerate the maturity of FHIR, and drive adoption throughout the industry. Session attendees will also learn how and where they can participate in ongoing efforts.

Learning Objectives
  • Identify the key suite of IHE profiles that support emerging regulatory requirements and the use of FHIR
  • Explain how IHE Connectathons support real world interoperability testing and adoption of standards and implementation guides
  • Recognize and share important feedback and lessons learned by the standards community through profiling exercises and real world testing
  • Outline how IHE and ONC will be working together in a cooperative agreement to advance the regulatory agenda

The Untethered PHR: The Journey Beyond Your Provider Organization

1:30pm - 2:30pm Thursday, March 12
Session ID: ISED22
Orlando - Orange County Convention Center
Hall E - Booth 8300 - Education Theater

Description In this session, learn how FHIR® and standards based on IHE on FHIR® profiles support bi-directional information exchange in veteran owned and controlled Personal Health Records (PHR) and comprehensive care management across multiple care providers.

Learning Objectives
  • Understand how FHIR can be used to continually synchronize information with the Veterans Health Administration (VHA) bi-directionally.
  • Demonstrate how organizations can engage providers using FHIR and FHIR-based apps.
  • Recognize how information exchange impacts care delivery beyond the VHA, inclusive of all providers using FHIR.
  • Define over a dozen different foundational profiles by IHE that support FHIR in the real world.

Saturday, February 29, 2020

Have MHD Clients? What Infrastructure should you deploy>

I am working up a set of decisions around the use of XDS vs XCA vs MHDS. In the past XDS was used when one wanted to create a Document Sharing HIE, and XCA was used to federate XDS Document Sharing HIE and add in EHR based Document publications. Now IHE has the MHDS infrastructure, so the question is likely to come up.

Mostly if you have XDS clients, you need to continue to use XDS or XCA. -- Add MHD as an API to enable MHD clients
If you have no legacy, then it is possible that MHDS is the right platform for you.

There is likely future IHE projects that will federate MHDS, enable connection of MHDS to XCA federations, and add XDS api to MHDS. All of these are unusual configurations, so will need market demand to come to the table to make it clear they are needed, vs simply being academic gaps.

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.


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...