Friday, April 2, 2021

IHE Mobile Access to Health Documents (MHD) - Implementation Guide

Public Comment now open until May 2.  - The main purpose of this release is to author and publish the MHD Profile using the Implementation Guide Publisher format. There are breaking changes, so this is a new version.  (See below: Significant changes since MHD Version 3.2)

IHE IT Infrastructure Technical Framework Supplement Published for Public Comment

The ITI Technical Committee has published the following updated supplement (in HTML vs. PDF form) for public comment from April 2 through May 2, 2021:
Mobile Access to Health Documents (MHD) - Rev. 4.0.0

The document is available at Comments submitted by May 2, 2021 will be considered by the IT Infrastructure 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.

Thursday, April 1, 2021

A good hot beverage on #FHIR

Given that #FHIR heats a hot beverage.
Dave Pyke and I collaborated on a FHIR Implementation Guide on how to brew a good hot beverage, following RFC-2324 from April 1st 1998 -- see the our "Hot Beverage FHIR Implementation Guide"

Tuesday, March 30, 2021

Elitism is Vaccine Credentials Passport

 A Vaccine Credential or Passport is an important effort to get society moving again, but it could really result in elitism that we really should not accept.

Vaccine Credentials fundamental use-case 

There are appropriate uses of a Vaccine Credential or Vaccine Passport. I am not arguing against proof of vaccine for International Air travel, or admission requirements for school or college. These have been in place and are working fine. They often are simply self-declarations, or are unprovable printed vaccine forms. These cases also are handled at a pace that allows for exceptions to be made. These are handled at a pace that allows for assistance to be given to achieve the proper vaccine levels. These are successful in spite of the fact that there is no world-wide self-validating Vaccine Credential. These will continue to succeed without a self-validating Vaccine Credential.

Vaccine Credential at scale need

COVID-19 has uncovered a "need" for a self-validating Vaccine Credential. That is a credential that can be used at point-of-entry, that carries TRUE/FALSE level facts, that can be proven to be valid / legitimate, and can be proven is linked to the subject identity.  This all without exposing unnecessary medical or identity facts - #Privacy.

This need comes from the scale, and not the fundamental use-case. As I state above the fundamental use-case is handled today, and that solution could absorb COVID-19 just fine. The fundamental use-case does not need to scale.

So, what is the scale problem? The scale problem is when the fundamental need is applied to ALL public and private gatherings. This includes Trains, Buss, Tram. This includes sporting events, entertainment events, political events. This includes dining, dancing, partying. This includes leisure, work, hotels. This scale applies to everything outside your house... well, it might apply at your own front door when others come visiting. So, you might be the bouncer-at-the-door.

The scale problem is the "bouncer-at-the-door" needs a very fast and accurate true / false fact to allow you into the event/facility; or to reject you.

Vaccine Credentials Considerations

What I am worried about is a technical solution becoming a tool to show elitism. This worry should not be used to prevent the technical solution from being created. I am actively involved in three different efforts to define a Vaccine Credential / Passport. I think it is important to design these solutions as best as possible. They need to address as many requirements as possible. They need to be privacy preserving. They need to work for those without technology. They need to be fast. They need to be robust. They need to be as resistant to falsification as possible.  I am actively engaged (wish I had more time).

What I am worried about is those that can't obtain the COVID-19 vaccine being shut out of participating in society without any ability to plea their case. I am specifically worried about society failing to get these people vaccinated, and the cases where the vaccine can't safely be given. These people are being treated as a lesser-class of people, they are not part of the elite class.

There are activities that are being proposed to requiring a Vaccine Credential to participate that are basic survival. Grocery store, Bus, and other. This is the scale that worries me the most.

Not the solution for vaccine deniers

I am not liking that people are not vaccinating. I certainly want everyone to get a vaccine. I got mine as soon as I could. I don't want to be in the presence of people who willingly refuse vaccine. I simply think that requiring a Vaccine Credential everywhere is not the way to get these people to get the COVID-19 vaccine.  These people will not react well to a Vaccine Credential mandate. These people will dig in harder. A Vaccine Credential is not the solution to vaccine deniers. Some will never be able to be convinced, they will always be a risk across society. Many simply need time to see the safety and effectiveness themselves. Some are needing information and access to the vaccine.

Some legitimate concerns

  • medical conditions that put the subject at risk (allergic reaction)
  • spouse or parent that objects to vaccines (subject would be endanger if vaccinated)
  • police (subject has reason to be arrested)
  • protected-identity (subject needs to stay non-identified. witness protection)
  • no identity available (subject has no formal identification due to age or events)

some reasonable worries

  • concerns with the safety given the "emergency use authorizations". This will eventually pass
  • access to vaccines. The young and healthy have not been allowed to get the vaccine. Some regions are struggling with getting the vaccine, or putting in place the facilities
  • outreach - there are people that have not yet understood the situation or the opportunity
I had a much more exhaustive list, but lost it... so please feel free to comment if you have some other legitimate concerns


I am pointing out a management problem, a problem that technology can't solve. I will continue to work on the technical solution. But I am very concerned about the elitism that will come from having the technical solution, and using it at the scale being proposed.

Thursday, March 11, 2021

Healthcare use of Identity level of assurance

There is discussion going on in the FHIR chat on this topic. I wanted to capture details as it seems that most of the problem is getting everyone understanding the same thing. The discussion is specific to an open system for recording and showing that an individual has received a COVID-19 immunization. (see HL7 effort on vaccination credentials and  broader outreach). There are other COVID-19 immunization trancing efforts, the above just is the one I am most closely working with.   

The summary is that there is likely good valid use for having a IAL like vocabulary to be used in to indicate to which level of assurance was this identity proofed. This because it is not uncommon to have some patients able to bring a government issued picture ID like a passport or REAL-ID, where other patients will not have this kind of an identifier, and other patients might have nothing, and others that are completely un-identifiable.

Where the use of an AAL vocabulary is theoretically useful as an attribute of the Immunization.subject binding to the Patient; but this is not as obviously needed. More realistic is that the whole of the Immunization resource ( could hold an integrity confidence value. But event that is not likely to be needed as the system likely has a required assurance needed before ever giving an immunization and thus there is not a need to indicate the assurance as all records will be at the same level by policy.

Basics of Assurance Levels

There are two concepts that are very important and important to understand. I will use NIST 800-63, but the overall use-case is not a USA specific thing. The use of NIST here is simply because the discussion was USA specific, and the NIST specification are easily accessible. I welcome someone providing me the ISO equivalent, but ISO is too expensive and hard to access.:

Note I am not going to address FAL, thus the key concepts are IAL and AAL.

Wrong but useful

Very important to recognize that NIST 800-63 is focused on Remote connection using IT technologies. Where as much of what I am going to address in healthcare is not exactly only scoped to this. However the use of the Vaccine Credential is a remote access use, but in that use-case we are focused on data assurance levels, not user assurance levels. So there is dissonance, but it is the best I have to use as a model.... as George Box said, All models are wrong, but some are useful.

IAL is broken down into three conceptually defined levels 

  • IAL1: There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the authentication process are self-asserted or should be treated as such (including attributes a Credential Service Provider, or CSP, asserts to an RP).
  • IAL2: Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.
  • IAL3: Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained representative of the CSP. As with IAL2, attributes can be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.

AAL is broken down into three conceptually defined levels

  • AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.
  • AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two distinct authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.
  • AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device MAY fulfill both these requirements. In order to authenticate at AAL3, claimants SHALL prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.

Note that NIST only defines these conceptually. NIST does not define them tighter as the tighter definitions would need to be cast within a Policy, Procedure, and Technical space. The Levels are useful, but they are not explicit. This is most easy seen with the AAL definitions.

The NIST 800-63 specification is very easy to read, and understanding of the distinction between IAL, AAL, and FAL are very important. Please do not continue without understanding the distinction between IAL and AAL.

Use of Assurance Levels in healthcare workflow

The use-case that I will use for illustration here is a standalone system that is recording COVID-19 immunizations. I am not going to say that this is a good use-case, but it helps focus on the impact of IAL and AAL. So in this use-case there are three important activities.
  1. getting the Patient identification information.
  2. recording the immunization that was given to the patient
  3. relying-party using the immunization credential to allow the patient to do something
Note that there is other steps and considerations that I am not covering: medical, safety, procedural, cleanliness, etc. So, yes I presume that the patient will be asked about allergies, that the immunization site will be cleaned, etc... 

Step 1: getting the Patient identification information:

In step 1, there will be some Patient identification information captured. I am also not addressing the process of looking up the patient to see if they exist already, vs creating a new, vs resolving duplicates, etc... that is important, but I am focusing on specifically how SURE is the system that the human present is the one described by the Patient resource that will be used in step 2. So some data are requested of the Patient, some process is used to confirm that the identifications presented are valid and appear to be the patient. Likely the Patient is physically present, and that some government issued picture identification is provided. Thus, it is not hard to have a procedure that gets to IAL3, but some patients might not have a government picture identification. Thus the need to record "to which level of assurance was the patient proofed at the time the Patient resource was created or selected?"

An IAL is a statement of this "proofing" level of assurance. This level is persistent statement. Meaning the next day the FACT of this IAL is still true. Because the IAL is a proofing of identity.  Note that step one could have been done ahead of time, via online portal or phone or other methods. 

Step 2: recording the immunization that was given to the patient:

In step 2 is specific to some activity, such as administering the vaccine. For example, the step 1 proofing might have been done the prior hour, the prior day, or the prior month. But Step 2 is needed to be done at the time the vaccine is being administered. 

Note that some argument that NIST 800-63 is focused on IT concepts, and not physical acts. However I think that it is not specifically focused on IT activities. Certainly it is used mostly regarding IT concepts. There is certainly some application of AAL to physical access (door locks), and in this immunization an activity.

So when the vaccine is administered there are many other things going on other than Authenticating the patient. Indeed in medicine there is a concept of "The Five Rights". One of the Five is to confirm that you have the "Right Patient", which is a step to make sure you are not giving a medication (vaccine) to the wrong patient. Typically this process step is the nurse looking at the wrist ID band. However the step is done, this is an "Authentication" step. Thus the question of how sure are you that you have the right patient?

This making sure you have the Right Patient at this activity of giving an immunization is based on the strength of the identity of the patient. So it is true that step 2 is based on step 1.

Step 3: relying-party using the immunization credential to allow the patient to do something

Step 3 is unusual to talk about in healthcare, but is ultimately the goal of an immunization credential. The whole purpose of this is to enable the patient to carry on life as normal because they have evidence that they are free from infection. Above I am only addressing the case where a vaccine has been given, but the overall also includes some means for lab test results as well.

So at this point the relying party might need a light-weight or moderate-assurance; as the event is a family event or an event where risk is low; but the relying party might be needing a very high assurance such as an international flight. The relying party does need additional security mechanism to prove that they are authorized to get the patients immunization credentials, and also that the results only go for that purpose. I am not addressing these classic security topics. They are significant, just not on the topic of this article.

The relying party would like a clear and simple result. Thus they don't want to get complex listing of the methods used to provision or authenticate the patient; they want a simple YES or NO. Thus they need a value similar to the three IAL values. 

Some relying parties might want to know the methods used, so it might not hurt to also have a second vector recorded which is the method used.

The relying-party is very unlikely to care about the step 2 assurance at each immunization. Not because it isn't important, but because it is less important overall.

IAL of the Patient Resource.

Both step 1 and 2 are important to step 3. overall. The question is if they both must be recorded in the FHIR resources.. I had given the example of (2) being part of the process behind the Five Rights. If your procedure is strict, then recording that you followed the procedure with a (2) kind of record is not needed. The same can be said for (1), for example if a Patient Registry requires that the patient was highly proofed before they were given a Patient record, then the Patient resource does not need a (1).

So it is important to understand which of these is going to be variable within your data. If you know that (1) is going to vary within your data, then you need a way to record which value of (1) each Patient resource has been proofed at. If you know that (2) is going to vary within your data, then you need a way to record the (2) for each reference.

Step 1 can be handled with the with a valueSet of IAL vocabulary. This seems appropriate as it is "meta" about the contents of the "Patient" resource. The vocabulary is unclear, but the concept is clear. An IG specific vocabulary (which the vaccine-credentials project seems to be doing) seems reasonable.

AAL of the link between Immunization and Patient

Seems that if 2 is variable, then this needs an extension on the Immunization.patient element to indicate the AAL of the patient binding to the Immunization activity. This would need a different vocabulary, as AAL is different from IAL. (Even though NIST 800-63 uses numbers for both).

Further (2) is not security meta about the content of the Immunization.patient element; it is specifically an AAL of the linkage confidence. Thus this is not a general extension carrying at the element level (which is a task that DS4P is likely to add). The AAL need is different.

General method of recording confidence of References

This (2) might be first needed in this Immunization use-case, but one could see that this is generalizable such that any Reference anywhere in FHIR might need some evaluation of level of assurance that the reference value given is absolutely correct.  Further in FHIR a reference is a technical term referring to Reference datatype, but the concept of a reference also includes all uses of the Identifier datatype (which is included in the Reference but sometimes stands alone). So the concept is needed on both Reference and Identifier datatype.

We surely expect that any Reference in FHIR is always highly sure, we all know mistakes happen. We all know that sometimes an Identifier is recorded without high assurance, like the Patient brought in a photocopy of their passport.  What is not clear is if there is a true generalized need for the FHIR DataType Identifier/Reference to add a core extension for tracking the confidence of the reference values.  This might be a useful exercise, and as an extension would not be too invasive.


So, now that I have elaborated about the need for (1) and (2) theoretically... which ones are actually needed in the vaccine use-case, and which ones might be more generally needed? These both seem unusual to be needed as values, vs simply being baked into procedure/policy.

The IAL at the Patient level seems realistically needed, given that some individuals already have high assurance identifiers such as Passport or Real-ID that can be used during provisioning of the Patient resource; where as clearly other patients will not have this, and realistically there are others that will have nothing to base the identity proofing activity upon.. So does seem useful.

Where as the AAL of the binding between Immunization and the Patient seems more theoretical, and the use of "The Five Rights" tend to elevate the confidence to a high level. Thus it seems this is mostly theoretical, thus not urgently needed. This is not to say it isn't ever going to be needed. Just not the main focus need today.

With IAL on Patient; there seems to be a need for two evaluation vectors. A policy vector much like IAL from NIST, this policy vector states a conclusion made at the time the activity happened. This IAL like value would consider policy, procedures, technology, evidence, etc... A second vector would be more concrete, there should be a valueset of codes that identify current-practices. This vector on the Patient would support the IAL value, but would also allow a relying-party to more dynamically adjust their reliance on the assurance level. 

Tuesday, March 9, 2021

IHE is on #FHIR

 This was just reported in an IHE-Europe news letter. I wanted to stress it here as I am finding many people do not understand that IHE has many Implementation Guides (IHE-Profiles) that leverage FHIR. IHE has published 32 Implementation Guides that use FHIR.

There is very active implementation and testing of these at IHE-Connectathons. This graphic brings the message home

And yet, that graphic is representative of the IHE-Europe Connectathon. Last week was the IHE-USA Connectathon, so this grows even more. Here are my other FHIR articles.

Wednesday, March 3, 2021

Why use current Exchange infrastructure rather than starting over?

I proposed an agile approach to improving Healthcare Information Exchange. Why should we keep the current? I covered this mostly with simply "that it is functioning", but did not enumerate why this is such a big deal. Many will say that http RESTful is functioning on a global basis with Google, Facebook, LinkedIn, Wiki, and Blogs. This is true, but these are all monolithic servers. Healthcare is a mass of 10 thousand organizations all with different systems. So Healthcare is special. This does not diminish the benefits of http REST, just points out that Healthcare is building on-top of an important concept, but that important concept has not addressed many of the things that Healthcare has needed to to give us the Nationwide Health Exchanges that we have.
The following already exists and is functioning nation wide today. These should be leveraged going forward, not ignored and re-invented.
  • Federated infrastructure 
    • technology, 
    • domain name, 
    • directory of endpoints
  • Trust agreements  
    • legal policy language
    • evaluation of language, 
    • implementation in access rules
    • policy bridging
  • Trust infrastructure technologies 
    • Certificate Authorities
    • Revocation system
    • Proven change of CA methods
  • Identity of organizations 
    • Directory, and 
    • TLS connection authentication
    • SAML assertion mechanism
  • Identity of initiating user 
    • Directory, and 
    • SAML assertion mechanism
  • Purpose of use 
    • vocabulary, 
    • mapping to policy, and 
    • SAML assertion mechanism
  • Provenance 
    • Home Community ID
    • Registry/Repository IDs
    • SubmissionSet, DocumentEntry, and Folders - Metadata
    • CDA Content specifications
  • Patient identity discovery and management 
    • XCPD mechanism, 
    • policy on minimal elements, 
    • acceptance criteria for cross-reference match
  • Patient Privacy Consent and Authorization 
    • normal treatment use, 
    • point-of-care-Consent, 
    • access authorizations
  • Notification of patient movements 
    • XCPD, or 
    • PIX feed
  • Data content agnostic
    • supports historic data that might only be available as scanned document
    • supports CDA, CCD, C-CDA, 
    • supports FHIR
    • supports HL7 v2 like lab results
    • supports Imaging like DICOM, XDS-I, and other image formats
    • supports text formats like BlueButton
    • supports non standard such as coma-separated-values (CSV) 
    • supports future standards
  • Timeframe of service 
    • document metadata, and 
    • query parameters
  • Data integrity and signatures 
    • hash/size, 
    • transport (TLS), 
    • Document Digital Signatures
  • Static and dynamic data 
    • Static, 
    • On-Demand, and 
    • Delayed-Assembly
  • Audit logging and remediation 
    • ATNA, 
    • log characteristics, 
    • policy for incident investigation
  • Proven system for Emergency response
    • Edge system that can be deployed to natural disasters such has been seen in CA and TX
  • ValueSets and Vocabulary agreed to by the community
    • types of documents
    • types of locations
  • Various Participating Organizations
    • Major Vendors
    • Treatment Organizations
    • Regional HIE
    • Payer Organizations
    • CMS
    • Research
  • IHE-Connectathon - mature testing for the Document Sharing exchange 
    • test tool based testing
    • peer-to-peer testing
    • formal test plans/procedures
    • formal test results tracking
  • Standards deployed and in use globally
    • existing networks globally communicate likely close to a billion documents each month
    • Not just a USA effort
    • maturity benefits everyone

Are all of these perfect? No, but the infrastructure includes them, meaning they are ready to be used, rather than some future hope. 

Does that mean we don't move to nationwide http RESTful FHIR? No, we will get there. I expect, as I have said before, that the green-fields will/should use http RESTful FHIR. But this should not be a default choice, this choice should be based on evaluating the "best" solution. 

My main concern is that we are trying to apply http RESTful FHIR to the hardest problem (Treatment, Payment, and Operations) when we already have a solution there.  The use of http RESTful FHIR at the edges or point-to-point make good sense. But it is not logical to start with federated access to 10,000 organizations, while those organizations already have a network-of-networks.

I don't explain these in this article, but you likely will find that I have explained them in my other articles and the HIE-Whitepaper. That said, I am happy to have my comments challenged, or reinforced. So comments welcome.

Tuesday, March 2, 2021

COVID-19 Immunization Summary Document - use-case analysis

 I am noticing that the healthcare standards community are doing a good job of leveraging the standards we have, vs creating something new... BUT I think the COVID-19 vaccine use-case is significantly different in a very important way.

I have not been engaged in any specific project, but know of many. So it is possible that some of them are thinking about the point I bring up here.

I am hearing some promote that the International Patient Summary (IPS) should be used for the proof that individuals would present to show that they have received COVID-19 vaccine.  It is very true that this document does include a Immunizations Section. It is good that the Interop standards community wants to use standards. 

The purposeOfUse threat environment

BUT, the IPS is designed to support "Treatment" purposeOfUse. When the request is coming from a Treatment organization, or some organization that is authorized for Treatment purposeOfUse; then the full IPS is the right solution.

However when the need is for getting physical access to an event, or to Fly, or take a Train, or etc.. These are not Treatment purposeOfUse. The are to support Public Health (PUBHLTH), or a new purposeOfUse value that is not today in the vocabulary.  

So, when the purposeOfUse is public health, then it is inappropriate to expose anything other than what is minimally necessary for that public health use. So IPS can not have the required Medication Summary, Allergens and Intolerances, or the Problem List. These are not appropriate to expose to the kinds of people that the COVID-19 vaccine proof audience. The recommended and optional sections should also not be populated. I might even suggest that the Header information should also be degraded as much as possible.

The Content Profile

Although the IPS has what is needed, it has too much. We can leverage what it does have, but likely need to further constrain too:

* Composition should include only elements needed by this PurposeOfUse. Likely just the government issued identifier.

* Only one section for Immunizations -- use the Immunization profile found in the IPS implementation guide.

* Only Immunizations that are relevant to COVID-19 (some valueSet can express this subset)

* might further constraints be needed on the Immunization to eliminate privacy risk?

Lets call this the "COVID-19-Immunization-Summary-Document" (C19ISD)

YES, it is a "D" Document. Even though we have degraded the Composition, there is likely information there that is important... and...(see next section)

Digital Signature

The Document would be covered by the IHE specification for Document Digital Signature. Thus the digital signature is covering the header and immunization details. This is why the Document is a Document.

The Transport

There should be no surprise that I will recommend that the Document Sharing solution be used for Transport. But there is important profiling here too.

* Trust-Framework -- there is still a need for a trust framework. It is simply not the same as we use for Treatment. It is designed the same, and uses the same standards. It is just much broader. It would leverage organizations like airline industry, event planning industry, etc. The reason to get into the Trust-Framework might be easier, but is still needed.

* Digital-Signature support. There would need to be a Certificate Authority issuing certificates for Digital-Signatures. This would be a subset of organizations, those that are authorized to publish these COVID-19-Immunization-Summry-Documents (C19ISD). There should be infrastructure to support certificate revocation checking. And would be a good idea to have a service that can check the digital signature and just return success/failure./

* All authorized access would be based around Public Health purposeOfUse.

* All accesses will be logged, so that abuse can be investigated

* Patient lookup should only be by government issued identifier. No ability to lookup by name, phone number, etc... Not sure what the actual constraints are, but want to start constrained.

* Given a patient identity, the Document Sharing query would be for the latest IPS. Yes, I said you would ask for the latest IPS. BUT because your purposeOfUse is Public Health; you will get the degraded COVID-19-Immunization-Summary-Document

* Note that the DocumentEntry (DocumentReference) would be marked with security labels indicating the appropriate PurposeOfUse of Public Health, and the confidentiality of  Moderate

Advanced use of Document Sharing Associations

Not critical, but simply good to think about.... In Document Sharing there are "Associations" between various Document Entries. These are different kinds of links. If we consider that this COVID-19-Immunization-Summary-Document (C19ISD)  is a degraded International Patient Summary (IPS); and the Document Registry service can support request for PurposeOfUse of Public Health and also Treatment; then there could be a Document Entry for the full fidelity IPS with a "Transforms" association link to the C19ISD document. Then the system need only look at what they are authorized to receive in order to give them the full IPS or the C19ISD.


It was pointed out to me that this C19ISD might also need to have a constrained lab-results section for COVID-19 lab results that might indicate COVID-19 negative.

Set of documents that are very focused #FHIR

 I outline in the last article that a Document Sharing "document" does not need to be a "Document". I propose that there might be a set of documents that are very focused on specific concepts, or Document sections. I think we have a ready structure for this in the current International Patient Summary (IPS). This is a real Document, but it is made up of sections that are interesting on their own. So, I suggest that we take the sections of the IPS and declare a way for that section to be made available as a  "document" in Document Sharing.

Here is the diagram from IPS,  the BLUE (header) stuff is already handled by the DocumentReference (XDS DocumentEntry)., so each of the Red, Orange, and Green blocks could be a standalone "document".

 Which is simply a Bundle of type searchSet holding the information profiled for that section.

And those sections are already defined. This is an excerpt from section 5.3

Following are the profiles that have been defined for each section. (R) denotes a required section (i.e. must be present in an IPS), (S) denotes a recommended section, the others are optional:

So we just need (a small Implementation Guide written)

  1. A formatCode defined for each of the above. 
  2. A constrained DocumentReference to make sure that it is covering all that is in the  Blue section of the IPS. Mostly this is just a use of the IPS Composition profile applied to the DocumentReference (see FHIR core mapping between Composition and DocumentReference).
  3. Additional requirements on DocumentReference based on the Composition.section details for that type of content.  This likely sets the typeCode, classCode, etc.
  4. The Bundle profiled. I propose a search set Bundle, but am not sure that is the right Bundle type. I prefer it as that type of a bundle is well supported today, and realistically this whole concept could be seen as a search result.
  5. Define if this is only available as a On-Demand? Should this allow snapshot, or forbid? Is there a Transforms relationship to the full IPS, or is that through referenceIdList?

The result is about 15 new document types. Thus if one only wants to get the immunizations, they only need to pull the immunizations. The IPS is there if you want it, this is not an attempt to degrade the need or concept of a Document. This is simply to recognize that sometimes (most?) there is just a need for a section, not the whole summary.

Who is with me?

Saturday, February 27, 2021

When is a document not a Document but still a document?

Documents have a bad perception, they are big, unfocused, and hard to process or view. I'm going to propose something that is counter to the perception, driven by current healthcare use of CDA documents and the HL7 Principles of a Document. Something supported by IHE Document Sharing (XDS/XDR/XDM/XCA/MHD), something enabled and using #FHIR.

When is a Document a Document?

Some background that is important can be found in the IHE HIE-Witepaper in the section on "Principles of IHE for Health Document Sharing". The the most important part is the HL7 defined Principles for a Document. Found in "2.3 Distinction between Documents and Messages"

The HL7 standard for Structured Documents Section describes the document vs. message distinction as follows “A document is designed to be persistent for long periods of time, whereas messages are more often expected to be transient. There is a place for both of these constructs in healthcare.” HL7 characterizes a document by the following properties:
    • Persistence – Documents are persistent over time. The content of the document does not change from one moment to another. A document represents information stored at a single instance in time.
    • Wholeness - A document is a whole unit of information. Parts of the document may be created or edited separately, or may also be authenticated or legally authenticated, but the entire document is still to be treated as a whole unit.
    • Stewardship - A document is maintained over its lifetime by a custodian, either an organization or a person entrusted with its care.
    • Context - A clinical document establishes the default context for its contents
    • Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.

I am not going to say that these principles are not good Principles. I really believe they are critical principles. But sometimes they become a burden when one wants a "document" and not a "Document". What I am describing is something that is short of these Document Principles, but still meets the need.

What is a document vs a Document?

The Document Sharing system from IHE is focused on "document", not "Document". I don't think that IHE always makes that distinction, but I will make it here for the purposes of this article. I use  "Document", with an upper-case "D", when the object meets (or is intended to meet) the principles listed above. These are the best kind of Documents, I am not arguing that these principles are not the best.

I use "document", with a lower-case "d", when I am referring to an object that meets the Internet's definition of a document. As in the "http" transport is defined to move documents. All that the Internet cares about a document is that it is a set of bytes that have a mime-type and possibly other metadata. These mime-types and other metadata in the case of http are carried in the http header. But they are simply metadata, that is to say they are data that describes the document. the mime-type is the most visible, and the mandatory one.

The IHE Document Sharing infrastructure has almost this same requirement. A document in XDS need only have a mime-type and a Patient identity. The additional requirement of a Patient identity is because of our Healthcare need.

FHIR-Document is a Document

In FHIR there is a formal definition of a FHIR Document, that is intended to be able to meet the above HL7 defined Principles of a Document. Most of the Principles are carried in the FHIR Composition Resource that must exist in a FHIR-Document Bundle. Everything else in the Bundle is just FHIR Resources. The problem with a FHIR-Document is that there is not as much experience with it, vs experience with http RESTful FHIR. So, although I could propose that FHIR-Document concept be used, I am going to deviate back to "document"

What is this document?

Given that there is much experience and interest in using http RESTful FHIR, and given that there is a nationwide exchange for Document Sharing. How can we use this exchange to get at RESTful FHIR results? So what I propose is that there is a well established set of typical queries used in the RESTful space. It is not as big as one might imagine. I am not saying that the full spectrum of FHIR queries are not needed or used, just that the vast majority fall into a few typical needs. This is especially true in Treatment usecases in cross-organizational need.

I propose that we define a set of canned Queries that are needed often. Each of these would be defined as a FormatCode with a set of metadata appropriate to the need. The document in this case is then the FHIR search set Bundle that would result from a http RESTful query. In this way the document is not fully a Document, but it is a Bundle that is more commonly consumed by clients today.

A system supporting these FormatCodes would publish a "On-Demand" entry advertizing each of these that they are willing to produce. A consuming application can discover these "On-Demand" entries, and retrieve the "document". That "document" is a SearchSet Bundle holding the query results. Likely the use of Snapshots to preserve each response would not be needed.

Some suggestions would need to be discussed. I suspect the following are a good start:
  • Current Medications
  • Current Allergies
  • Current Problems
  • Current Immunizations
  • etc...
Some design needs to be done, The list is likely not more than 10 or 20. There might need to be consideration of huge results, that might be addressed through better query specifications, or might have some other solution.

Consuming FHIR

This solution gives a similar result to the one described in "Consuming data as FHIR Resources" in the HIE Whitepaper. But does not require a "decomposition" step as the original source is producing the FHIR SearchSet Bundle.

Friday, February 26, 2021

Agile improvements toward #FHIR

The healthcare IT exchange for Treatment has been improving from the dark ages to today. This article is where I muse about getting to that beautiful future based on #FHIR.

Break Everything

One possibly that some advocate is turn off what we have today, and everyone and everything switch to using http RESTful FHIR. Even to just leave what we have running, and build new only using http RESTful FHIR, would ignore current successes. There are some things we have learned getting to where we are that are unique to healthcare, for which http REST has not yet needed to solve. This "off/on" solution is not smart, agile, incremental, improvement.

Note I am not saying that using http RESTful FHIR is a bad idea, for green-fields it is a good choice, likely the best choice. Just that nationwide, there are considerations that are beyond http REST concept, that are indeed special in healthcare.

Another  possibly is to just encourage anything and everything, hoping that someone will hit upon a successful solution. This is often referred to "let many flowers bloom", and is the model I hate the most. Yes this is the way evolution in nature works, but evolution in nature doesn't have the brains, lessons-learned, and planning power that humans have. We should not be using "let many flowers bloom" be used, it is not human.

Note, I am not saying that "let many flowers bloom" is always inappropriate. I do think that it is most of the time inappropriate.

Agile improvements

Agile approach builds on working systems, and pivots against non-working solutions. So let me explain an agile path.

We have a very mature and functioning nationwide healthcare exchange. We have two transports that can cross communicate, aka Karen's Cross. This pair of transports now has a third FHIR mode, so Karen's Cross is now three dimensional.

imagine a fancy graphic here that shows three sources each of the types: e-mail, SOAP, and REST talking to three consumers each of the types: e-mail, SOAP, and REST

For a good explanation of these transports, I refer you to the HIE-Whitepaper by IHE.

These transports are content format agnostic, so can carry old content, current content, or future content. Might be PDF, or CCD, or C-CDA, or v2-lab, or DICOM, or Tiff, or text, or comma-separated-values (CSV), or FHIR.

The query / retrieve model enables publishers to offer various formats of the same content.  Meaning the same content could be offered in many formats. This might be published objects, or dynamically generated, or deferred creation entries. Thus a consuming system can select what is best for them. 

Again, I will refer you to the HIE-Whitepaper by IHE.

CDA is here and it works

Much investment has gone into CDA. It has many positive attributes. People know how to make it do things therefore taking on new needs with small changes.  CDA can take on new use-cases just as well as FHIR can. I am not going to try to argue that CDA is just as easy to understand as FHIR, but realistically when the content developers already know CDA, it is easier for them to improve CDA than it is to throw away their knowledge and learn FHIR, simply because there is a perception that FHIR is easier. It is not easier for them.

FHIR is not yet here, but it will be

FHIR is the new hotness, and it will most likely be the future, but it is new and it is still evolving. Likely 5 years yet before it is mature, it is a high-schools graduate able to flip burgers and dig ditches. Powerful and useful, but needing some more maturity. Note it took 5 years to get here, 5 more seems long but it will be here quick. Along the way FHIR will do good things.

First incremental step

So given that I do agree that the future will likely be far more of the FHIR based, I think the best way to get there is to make incremental steps toward that goal. Each step is going to be a bit unsatisfactory, but each step should move us toward that goal. 

The reason incremental will work, is that the current systems already do function. So we are not starting from a broken system, we are starting from a sub-optimal system (some argue it is optimal, but I am willing to allow for saying current system is sub-optimal).

The Document Sharing Exchange allows for new content types to be easily supported. So where we might today be using C-CDA, the next incremental step might be to publish BOTH a C-CDA and a FHIR-Document (IPS). Include an association type linkage between them, so that a consuming system can know that they contain the same information in different formats. In this way a consuming system that has only ever understood C-CDA can pull the content it understands, and a different consuming system that prefers FHIR can pull the IPS content. 

Again, I will point you at the HIE-Whitepaper - section 2.7 Document Relationships where this is discussed.

Saturday, February 20, 2021

IHE ITI February 2021

The IHE ITI-Tech committee finished our meeting this week a bit overtime, but very satisfying.

We finished with a toast to Bill Majurski. The ITI committee and the whole Healthcare Information Exchange market has benefited from, The originator of the concept that became XDS.

Accomplishments this Quarter:

This week the ITI committee has moved three work items along on their milestones:

IUA - the Internet user authorization profile needed some revisions to update it to the latest standards from OAuth community. Along the way we added clarity and features like introspection.  

HIE-Whitepaper -- the whitepaper needed to be updated to include the FHIR based models that we have published in the MHD family. This was somewhat addressed in the MHDS profile, but the whitepaper addresses the need and all the solutions that IHE has to offer. This also includes the use of QEDm and mXDE to make FHIR Resource level data available from the shared documents, making consumption more easy. This update also links deeply to the newly published html rendering of the ITI Final-Text Technical Framework.

MHD - MHD is our first IHE-Profile to be published using the Implementation Guide publishing platform. This platform, managed as an open-source platform, originally developed by HL7 (Grahame) for FHIR based Implementation Guides. It is widely expanding beyond this scope, and IHE is looking to use it for our publication needs. The Implementation Guide publisher encourages use of conformance resources (e.g. StructureDefinition) and inclusion of examples. Thus a major benefit of this publication means is more accuracy and more specificity. In addition to this, MHD version 4.0 is moving away from using DocumentManifest toward using List FHIR Resource., This to aid with moving toward Normative status.

Each of these works has received conditional approval by the committee, where the condition is to cleanup some minor issues expected to be cleaned up soon. Each of these will get formally published on the new IHE web site in html form only. This may take 2-3 weeks to achieve.

Next Quarter: 

Given that we have moved two moderate sized work items off of our plate, we have accepted two new moderate sized work items from our prioritized backlog:

mCSD whitepaper - Since mCSD doesn't require a particular set of FHIR resources to support, there is a need to define various implementations and the additional requirements they would have. For example, a Facility Registry would require supporting mCSD with Location and Organization resources, and a Health Worker Registry / Provider Directory would require Practitioner resources. This whitepaper would describe these various use cases and how mCSD can be utilized to support various implementations. 

MHD to a Federation - The concept of federation is relatively underspecified in FHIR at this time. The notion of "home community" is used by numerous IHE profiles to enable complex, large-scale heterogeneous networks. See [IHE ITI TF-1] E.9 "XCA Integration with XDS and non-XDS communities" for a number of examples of federated deployments enabled by XCA. FHIR does not have an explicit analog for home community. We would like to add this to the IHE FHIR-based profiles. This would support all-FHIR cases requiring federation (for example, crossing security boundaries) as well as bridging FHIR with non-FHIR mechanisms such as XCA. Our initial use cases address mCSD and MHD, but other profiles could be considered, as well as Appendix Z for common capabilities, such as a consistent encoding of HCID as a business identifier.

We will continue to improve the html rendering of the Final Text Technical Framework

We will continue to work on Change Proposals across the portfolio.

Lastly, there has been fantastic input on our PMIR profile that will likely result in some improvements of the profile and possibly some new work items. This is an excellent example of a group trying to develop to our specification and finding difficulty, bringing that difficulty to the committee, and we ALL benefit from clarity that will result.

This was a fantastically successful week. Proof that virtual face-to-face can be successful.

As these get formally published, i will post more articles. The committee drafts will take some care and feeding until they get formally published. A few weeks.

Friday, February 5, 2021

IHE whitepaper on Health Information Exchange models

The Integrating the Healthcare Enterprise (IHE) standards profiling organization has developed a collection of profiles which can be leveraged for use by healthcare communities for the purposes of document sharing. One of the most significant applications of healthcare information technology is the exchange of health information among disparate clinical information systems and otherwise unaffiliated care providers. Across the world, various communities have developed or are developing methods for exchanging health information among healthcare providers, patients, and other authorized parties. The purpose of this white paper is to provide an overview of the collection of IHE profiles which are intended to be used by communities for exchanging health information. The collection of profiles includes support for patient identification, health document location and retrieval, provider directories, and the protection of privacy and security. This white paper will show how various profiles work together to provide a standards based, interoperable approach to community and cross-community health information sharing.

Here is the HIE-Whitepaper

Those looking to deploy a Health Information Exchange will find guidance on recognized principles and mechanisms. There are solutions that are intended to support small, medium, large, and federations of communities. Where an exchange is based on legacy IHE profiles of XDS or XCA, there is guidance on how to enable a more easy on-ramp and off-ramp in the MHD profile that uses FHIR for the API. There is important considerations on how to evolve from a working legacy exchange to an exchange that enables modern technology. There is also a model in MHDS for those that have no legacy environment that builds the full infrastructure using FHIR services.

There is guidance on how to enable more fine grain access to the data already available in your network through the use of mXDE and QEDm. This model enables FHIR clients to access Observations, Allergies, Medications, etc; as if they were published as FHIR resources, while preserving Provenance back to the Documents and Organizations that published the data. Giving credit where it is needed, and providing critical context for the fine grain data.

The clinicians will find that this paper recognizes their interests in being properly recognized as authors of documentation. Some clinicians are comforted with the document concept, some clinicians are more comfortable with the fine grain access that FHIR brings. Both models are described as integrated.

The Health Information Exchange model presented is an Infrastructure, it is not constraining the content. Today it is common to communicate CDA documents, but the future may switch over to FHIR Documents. Along the way there may be fragments of FHIR bundles dedicated to a specific need, such as the patients current allergies, or the patients current medications. These may not be seen as a fully qualifying document in the eyes of CDA, but they are perfectly legitimate in the Document Sharing infrastructure.  

The patient is not to be left out of the discussion. Like the clinician the patient is a recognized potential participant in these Health Information Exchanges. The patient based application is more likely one that will need and want a FHIR based interaction, so the MHD based on-ramp and off-ramp are very important to the Patient access. The Patient would also be a participant in setting rules of access in their Consent. This paper discusses three different Consent mechanisms that IHE offers to enable this. The actual accessibility and control is driven more by policy.

The population health communities can also be a participant on the Health Information Exchange. They typically would not be publishing documents, but would be consuming documents published, receiving content that is pushed to them, and analyzing the data for population trends and reporting.

All of these communities would need to be carefully managed, carefully authenticated, authorized, and monitored. The paper goes into the interoperability solutions in Privacy and Security that are foundational to local policies to be enforced. There is some additional papers that discuss some of these policy considerations, and how the policy interacts with the infrastructure.

Lastly the whitepaper is stressing the use of FHIR available today, while showing that there is a much bigger and better future that gets built upon the legacy and FHIR tooling. 

Thursday, February 4, 2021

From Implementation-Guide to IHE-Connectathon

So you have an Implementation Guide (aka IHE-Profile), and want to test at IHE-Connectathon....

The following is mostly based on what happens when an IHE Profile (aka Implementation Guide) is written. Much of what I outline is not as visible as it should be. Often these tasks are done by the IHE Connectathon staff, with a bit of help and oversight by the Profile writers and co-chairs. I am working to move some of this more visible, and sooner in the process.

I am not yet convinced that IHE is ready to take on the task of testing a specification not written by IHE. This is talked about a lot, but not much resources have been put toward it. First up was SANER, but it is a bit stalled. I started a TestPlan in the SANER implementation guide, and Keith has improved it. I am just not sure how comprehensive the SANER test plan is. 

I am a fan of using IHE-Connectathon for more comprehensive and formal testing, vs using the FHIR-Connectathon more for specification validation and experimentation. See my past articles on "What is a Connectathon", "Maturing FHIR Connectathon without confusing the marketplace". and "Introduction to IHE Connectathon and Projectathon".

So the idea of IHE-Connectathon testing of a developed IG goes something like this.
  1. IHE develops a test plan -- this is the overall plan for how the actors would be tested independently, and how scenarios would test a set of products.
  2. IHE develops test procedures for everything in the plan
  3. IHE develops or selects test tools to simulate peer actors for actor testing
  4. IHE enters the IG, actors, and any optional pathways into Gazelle
  5. Products sign up for testing
  6. some IHE-Connectathon happens (virtual or physical or adhoc)
  7. Products test using the actor test test procedure and tools
  8. Products submit their results to proctors
  9. Proctor checks the results with the expected results and passes them or sends them back to try again
  10. Product is paired up with peers for cross-product testing
  11. proof of cross-testing is submitted to proctor
  12. After final review products are given a gold-star

Generally today this starts with #4, and only after 3 or more products sign up for connectathon are steps #1-3 done. We could do this with HL7 Implementation Guides, but I would think we should look for interest before we enter them into Gazelle. Although the theory is that with IG publication and the CapabilityStatements in these IGs, this Gazelle registration could be automated.   

Generally today 1-3 is done by two IHE experts. These steps are often done in isolation, and in the first year done very quickly. As the signal that an Implementation Guide needs these written is very close to the time at which the IHE-Connecathon happens. This is why I want step 1 to be done as part of the specification writing. Doing step 1 as part of the specification writing will also assure that the goal of the Implementation Guide is clear.

Step 1 is where I and a few others are thinking Gherkin comes in. Step 1 is a critical step to have cooperation between the specification writers, product implementers, and test writers. Theory is that if we had a mature Gherkin infrastructure and writing, then many of the other steps could be less hard, and the testing could potentially be automated. The use of Gherkin fits nicely because it is very Behavior based, and is considered a critical tool in Behavior Driven Development (BDD). Gherkin promises to provide a well pattered sentence structure (Given, When, Then) so that the sentence structure can be parsed by regular-expressions and glue-code. These regular-expressions and glue-code are the magics, and are special to every project. Theory is that IHE might find some of these reusable.

Here is an example of a test-plan as part of my MHD IG that I am developing, this test plan only covers 25%. It is not using Gherkin (yet), but rather is just a minimally expressed set of test scenarios that are envisioned would be necessary to test comprehensively:

Here is SANER. I started this page, but it has taken on a life beyond my efforts. So I am not exactly sure if it is a good example. But it is again high-level set of scenarios

Similar setup can be done with a "Projectathon", which starts with the above already done, and focuses on project specific further refinement. Where projects tend to be regions, countries, or other community. Possibly I will write about this in a future blog article.

The above has not been outlined as well as I just did... so this is just my first try at expressing this.  Each step is likely 20-60 hours of work to do it right. Thus to get to step 6, means at least 100 hours expended. I will see if others agree.