Thursday, September 9, 2021

#FHIR Basic AuditEvent for generic RESTful actions

I have drafted a prototype Implementation Guide covering the AuditEvent profiling for generic FHIR RESTful actions.

For any FHIR REST operation there is a well-defined AuditEvent specified in this implementation guide. The appropriate AuditEvent shall be recorded by Client and Server applications that claim conformance to this implementation guide. The resulting set of AuditEvents are made available to a client authorized to retrieve them. The AuditEvent in this case is useful for the typical privacy office and security office use, but is also useful to enable a Patient facing app that can inform the patient when and how their data are used.

Basic Auditing where there is a known subject of the data involved. This profile is a formal specification of the guidance given in the FHIR Core AuditEvent under Common Scenarios

This guide does not cover all AuditEvents. It does not cover
  • how accesses to data where their is no subject, such as a Provider Directory. Although this is likely similar, just without the mandated Patient entity.
  • how failures are recorded. Failures are recorded with the .outcome that is not success, and is thus a very large body of possibilities. Failures are logged with best-effort and with verbose content. This makes the AuditEvent of a failure very hard to characterize, vary hard to automatically process, and possibly exposing of privacy or business secrets. These might be access control denials, which the patient would be interested in but for which it is not clear they would be due these kinds of notices. These might be infrastructural failures, which are too hard to characterize.
The AuditEvent profiles here could be used as a prototype for a more specific AuditEvent profile in a use-case specific Implementation Guide. Where a use-case specific Implementation Guide defines an AuditEvent profile, those profiles should be used rather than the Basic AuditEvent profiles found here. Both could be recorded without harm. 

Actors defined in the Implementation Guide



Data using Client

Requesting application in a REST relationship with the Server.

Note that the Client may also record the appropriate AuditEvent into the Audit-Repository. For security use-cases it is very helpful for the client to record the AuditEvent too, as this sets up a pattern of normal operation that can be watched for deviations. Deviations such as the client stopping audit logging should be investigated, a possible cause is that the client credentials have been stolen and are being used by another application than the one authorized.

Data Server

Responding server that holds the data the Client is requesting thru REST. Server records the appropriate AuditEvent into the Audit-Repository.

Audit Repository

FHIR repository holding the AuditEvents created, and provides access to the AuditEvents to Audit-Clients. The Audit-Repository would typically not allow Update or Delete of any AuditEvent previously recorded. Thus only allowing Create, and Read of AuditEvents.

Note that the Audit-Repository may be the same system as the Server.

Audit using Client

A Client that retrieves AuditEvents for some functionality. Where the functionality is not constrained or defined here. The Audit-Client queries AuditEvents for a given Patient.

Purpose

The reason for me to have written this Implementation Guide is for two specific reasons
  1. To provide a structureDefinition Profile set of these basic audit even patterns. Which does test the FHIR core AuditEvent specification.
  2. To provide a pattern for an Audit using Client that uses the AuditEvent(s) for various purposes. Including the purpose of providing a  Patient Engagement - Access Log

References

Monday, August 16, 2021

FHIR Document Digital Signatures

I was asked about Digital Signatures for FHIR documents:

I am working on _____  IG that is FHIR document based and we need a means to prove authenticity. The model is relatively simple in that a document and all of its parts represent a single thing that needs to be “signed”.

I have looked around for examples of this in IGs and in example documents and I have not found anything. I see a lot of references to CDA documents and signatures, but not much in the ay of FHIR documents. Can you point me in the right direction? Are there example FHIR IGs and documents out there. Where should I start?

Documents are good

The right way to do this is to have the signature cover the whole document, you have gotten to that point well. This is important as the signature covers all of the contents, including identity, date/time, context, etc; and also the meat of the content you are needing signed.  The point here is that a Document does not rely on references to outside data that might change, but rather a document should copy within itself everything that needs to be protected with the signature.

A FHIR-Document is not different than a CDA Document or any other kind of document. It is seen by the digital signature as simply a bucket of bits. Thus anything you see showing a digital signature on a CDA document is likely just as applicable to a FHIR-Document. 

The wrong way to do this is to believe that one can include a signature within the document (or within anything that is signed -- for example a FHIR Resource that contains a signature element). As soon as you need to exclude something in the bucket of bits, you open up the opportunity for other things to be excluded from the signature. So, always sign a whole bucket of bits, and a whole bucket of bits that is internally complete (doesn't rely on outside data).

The solution

A signature over a document is a document itself. It is a document of type XML-Signature.

There is already a specification for this from IHE – Document Digital Signature (DSG); and is what the FHIR core specification recommends. https://profiles.ihe.net/ITI/TF/Volume1/ch-37.html

Both documents would have DocumentReference that point at the bits (My preference is using a Binary, but the enclosed base64 data is an alternative).

The two documents would have a relationship. The digital signature (DocumentReference) would have a .relatesTo with the .relatesTo.target of the DocumentReference with the content; and the .relatesTo.code of ‘signs’.

Some more context on this https://healthcaresecprivacy.blogspot.com/2017/04/ihe-document-digital-signature-dsg.html

Note the concept of having everything needed (document) in one blob to be signed is very similar to what the COVID-19 credential does, but they strip things down to the bare minimum in order to fit in a reasonable QR code. They do use a JSON signature and encapsulate the content. So it is logically similar to the above, but practically it looks very different.  (Updated to be more correct)

My other articles on Digital Signatures

Tuesday, August 10, 2021

FHIR data in existing Nationwide Health Information Exchange

In the USA and elsewhere, there are Document Sharing based Health Information Exchanges. These exchanges have been built up over the past ten or so years. They have security models, privacy models, patient identification models, record location models, and data format models.  They also have mature testing tools, events, and have been specialized for many projects.

The solution is to leverage this existing solution, and just add FHIR. 


The exchanges in the USA include a PUSH model as well as a Query / Retrieve model. The PUSH model is used to convey information to a specified recipient. This can be done by way of the IHE-XDR protocol or the Direct Project (which uses IHE-XDM). The point I make below applies here, but I am not going to focus on PUSH models, simply for simplifying the message.

Nationwide Federated Exchanges

The Query / Retrieve models are based on the IHE-XCA, which is a federated query model that is designed to enable query of various types of patient data among a federation of partners. This model is used at the state level, and has three flavors at the national level, with interoperability between them... Thus a Federation of Federations.

Both the PUSH and the Query/Retrieve models today are dominated by the


C-CDA content specification. This is a good specification, and many organizations have gone to great lengths to build up their skills at creating the C-CDA, and also at consuming the C-CDA. Thus many want to continue to use CDA to preserve this investment. My point in this article is that this does not need to be a restriction on those that do want to move on to FHIR.

Ready for anything


The IHE-XCA implementation guide is designed to be content agnostic, focusing on a set of metadata that describes the document. These metadata are well talked about. They are designed to be minimal, yet powerful. Defining who the Patient is, Who the Author is, where was the content created, why was the content created, what are the privacy considerations, what are the relationships to other healthcare workflows and things. 

The metadata is not specific to CDA. Indeed the metadata schema was defined back when CDA was just emerging, when there were other content formats that might have become dominant. So the design of the metadata planned for a future when different formats would exist.

And, where the exact same content might be needed in two or more different formats. There is a specific type of relationship between metadata entries to indicate that the two content objects have the same context, with just a different technical encoding.

Just add FHIR

FHIR is a content format. There are Implementation Guides already published for a "Medical Summary" that is using the FHIR content format encoding. The International Patient Summary (IPS) is a FHIR Document that covers the same need as the C-CDA Medical Summary. Thus for those that want a FHIR content format, the choice would be the IPS rather than the C-CDA.  IHE has provided an Implementation Guide that takes the IPS content and explains how to communicate it within the Document Sharing infrastructures. So IPS over XCA.

Transition with no disruption

The best part is that the transition from everyone using C-CDA to everyone using IPS can be easy. There needs to be no change to Patient Identity, Security, Privacy, Records Discovery, Records Retrieval. By Just adding FHIR, the whole nationwide exchange that is functioning today just works.


Those organizations that can publish an IPS, just indicate in metadata entries that they can also provide an IPS. Those organizations that would prefer to consume an IPS, can detect those that are willing to provide an IPS. This addition of FHIR does not get in the way of those that are stuck in the C-CDA encoding. But it automatically enables those that want to speak FHIR.

The key is that there is an association between the C-CDA and the IPS content to indicate that they are about the same context, just different encodings. This association is shown above as a linkage between the FHIR content (IPS) and the CDA content (CCDA). In this diagram the C-CDA content is the master, but it does not need to be that way. An organization could focus on creating FHIR content and have a derived C-CDA for those partners that need C-CDA. This is all about making the transition smooth.

Conclusion

The existing nationwide networks provide many capabilities that have matured over time and are working, we should leverage this. The design of XCA is such that this transition is possible with no disruption, just add FHIR.

The use of FHIR in the existing networks does not mean that we should give up on designing solutions that use FHIR RESTful API. I encourage this too. This setting will need to solve for all of the capabilities that the existing nationwide networks have already solved for, so it will take some time, but it will eventually work.

My message is that the existing networks can be better, just add FHIR.

See the HIE-Whitepaper - section 2.7 Document Relationships where this is discussed.

Thursday, August 5, 2021

Book: IHE Profiles for Health Information Exchange

 I am late to promoting this book, should have done it back in March when it was released. It is called a book, but is available for free download in multiple formats.

IHE Profiles for Health Information Exchange

By Keith Boone

He is the author, but he gives credit for pulling from many sources including my blog.

It goes a bit deeper than the IHE HIE Whitepaper. 

Tuesday, August 3, 2021

InScope podcast: #FHIR security

I was honored to be on the In Scope podcast, and excited to be paired up with Alissa Knight. We talked about FHIR security and such.  The host Mike Murry, who I worked with at GE for many years. He doesn't get to be in the pretty picture (Not my best picture, well I don't think I have better. Really sorry to Alissa for what I bring to the picture ). 

In the podcast, the combination of Alissa, Mike, and I is powerful as we all focus on different parts of security applied to FHIR: Design, Protection, Vulnerability.

The link to the episode on apple or general feed on inscope site, but you can find it on your favorite podcast app searching for "In Scope Security". They even have transcripts.

I hope this is just the first podcast on this topic. I would love to discuss more intersections between design, protection, and vulnerability. I would like to get into Mike and my passion for audit logging and analysis (hoping to catch Alissa). 


Friday, July 16, 2021

HIMSS presentation on FHIR CarePlan

 My next speaking engagement is at HIMSS. This will be from the perspective of my employer By Light, as we have been the developer of the current Patient Portal at the VHA - My HealtheVet, and are the implementers of the original Blue Button. I work with the team on the transition to FHIR.

I am not physically going, as I am still very concerned about COVID-19, specifically Delta and whatever comes next. I trust that HIMSS is doing everything they can to provide a good experience, but the Virus does not care about the good works of HIMSS. Further the COVID-19 Vaccine Certificate they are recommending is thru CLEAR : CLEAR Health Pass Validation, and I don't trust CLEAR with my personal data. There are two other alternatives, but they are equally unclear. I am not disappointed, this is likely the only solution that is ready at scale today.  There are standards really close, although I am worried about all solutions.  It is also the likely solution you would have needed to use to fly to Vegas -- In AUGUST!!!

The details on my speaking engagement at virtual HIMSS are that it is about the opportunity that is coming (not yet here) enabled by FHIR and the CarePlan resource in FHIR. I am very excited about the opportunities of Care Plans. They will initially be used as workflow processes within a hospital encounter, but they have so much more to offer.


I think that Care Plans will really be valuable when

  1. The CarePlan actively engages the Patient. Giving the Patient tasks to accomplish. Enabling the Patient to have apps that know what the Patient should be doing, and recording what they do.
  2. The CarePlan enables care participants from outside the hospital system. Where the Patient can choose which physical therapy to use. When the Patient can choose which laboratory to use. All coordinated by a CarePlan
  3. The library CarePlan patterns (Plan Definitions) becomes a formally managed knowledge. The "best" pattern is picked using Clinical Decision Support and customized for the specifics of that Patient. With feedback loops that make the library better based on experiences of the Patients.
  4. Where the system gets mature enough that a Patient can declare their own Goals and intelligent systems aid them picking out a good Plan Definition from the Library, customizing it for their needs, helping them find a Care Team, and leading them to meeting that Goal.

The state of art is... unfortunately far from this. But I can feel it is just over the horizon. The main thing that will prevent this is "the businesses that are healthcare today". The patient will want and strive for this. The Clinicians (doctors, nurses, etc) will strive for this. I would even think that Payers may strive for this. Those that care about improving health will strive for this.

Thursday, July 15, 2021

Tutorial Links

 Having completed the HL7 FHIR Security and Privacy tutorial, I have found that there are links in my presentation that might be useful to itemize in a more web friendly way. Some people can't go to google presentation, some struggled with quickly typing them in. So here are the links from my presentation.

The presentation slides are at http://bit.ly/FHIR-SecPriv

I always edit them there, so any improvements made over time will appear. So using that link you will always get the current slides.

HL7 does have recordings of this weeks presentation. Those that signed up, have access to these recordings. Those that did not sign up can pay to get access. 

The FHIR core specification has the following main security pages

IETF Best Current Practice for 

SMART-on-FHIR presentation at November 2020 DevDays - https://youtu.be/2QENYKqF78U?t=2157

IHE profile on OAuth for business to business http REST
Current real-world security failure
Here is a security hole found in the Spanish COVID Vaccine Credential system that exposes personal demographics (might be more). Likely because there is no access control check if you are providing an id. Creative use of an API must always be considered in a system design.

My personal project to develop a Basic AuditEvent Implementation Guide



Draft efforts to create a Permission resource in FHIR (future)

FHIR Data Segmentation for Privacy Implementation Guide

FHIR Validated Healthcare Directory Implementation Guide

Multiple-Servers with one proxy - Presentation given by Grahame Greve at November 2020 DevDays - Presentation available at https://youtu.be/stFGtk-YKPQ

Ongoing Discussion: 
  • FHIR Security call on Mondays 12 noon eastern

Tuesday, July 6, 2021

User Management on FHIR

 The FHIR standard is a data-model and interface (API) specification for access to health-care data. As such this is a domain of data that is specific to the health of subjects. This is a very big domain, but not all encompassing. When interacting with domains outside of health-care, links between the data is done via Identifiers. FHIR has a data type structure for an Identifier that is designed to hold any kind of globally unique identifier. This identifier data structure thus would hold identifiers such as

  • Social Security Number
  • Drivers License Number
  • Medical Credential Number
  • Employee Number
  • Organization Identifier (Employer Tax Identifier, domain name, etc)
  • National Provider Identifier (NPI)
  • bank account number

and

  • User Identity (username, userId, etc)

Note that Identifier is also used for things besides human identifiers. Such as legal-case-number, global-shipment-identification-number, vehicle-identification-number (VIN),  device-serial-number, animal-identification-number.

All of these are information managed in another domain outside of FHIR. 

User Management is driven by Organization needs

The user management within an organization will be driven by the needs of the organization. Often this will be driven by early applications (aka the oldest application). Many organizations use Microsoft Active Directory, which does support Authentication and Authorization standards of SAML and OAuth. 

Other platforms for User Management would be Apache Directory, Open LDAP, or an external OAuth provider like Google/Facebook etc.

RESTful standard for User Management

There is a RESTful standard API defined in IETF -- System for Cross-domain Identity Management: Protocol (SCIM) -- RFC-7644

This has not received enough interest to be put into the FHIR security pages as a recommendation. I understand that Grahame has leveraged this in his reference server. There is an old, and unmanaged, page that Grahame created comparing SCIM to FHIR models., and his blog. The Health Samurai also indicates it supports SCIM.

I note that Microsoft Azure Active Directory seems to use SCIM as their API for user management. I am not an expert on Microsoft Active Directory, so I might be wrong. Would love to get comments confirming or redirecting my understanding.


Wednesday, June 23, 2021

FHIR Security & Privacy Tutorial

HL7 FHIR Security & Privacy

The HL7 FHIR Security & Privacy online class describes how to protect a FHIR server (through access control and authorization), how to document what permissions a user has granted (consent), how to enable appropriate access by apps and users and how to keep records about what events have been performed (audit logging and provenance).

Update: Here is a later article with links to the recording ($$) and with the links we spoke of and were embedded in the presentation.


This will be a refreshed version of the Tutorial I have given within HL7 before.

My slides are freely available on google sheets at this easy to type address http://bit.ly/FHIR-SecPriv. Each time I give the tutorial I update these master slides. So each time you go there you will see the latest set of slides. Some slides do have notes, and there are additional detail in slides that I don't cover during the tutorial.

In the past, I have had to compress these into two parts, but will be able to give them in the natural three parts

Part 1 - Basics

  • Security Principles
  • Privacy Principles
  • Basic Security and Privacy Considerations
    • Anonymous Read
    • Business Sensitive
    • Individual Sensitive
    • Patient Sensitive
    • Not Classified
  • HTTP[S] - TLS
  • Authentication & Authorization
    • SMART on FHIR
    • IUA
    • Mutual-Authenticated TLS
  • Access Denied Responses

Part 2 - FHIR capability

  • Provenance
    • Basic
    • Digital Signature
  • Audit Logging
    • Audit Reporting
    • Audit Purging
  • Consent - for Privacy
    • HEART
    • Permission 
  • Attribute Based Access Control
    • Security Tags
    • Compartments / Clearance
    • Obligations
  • Break-Glass
  • De-Identification

Part 3 - Practical application

  • Multiple Organization Provider Directory
    • using relational linking
  • Multiple Organization Profile Directory
    • using security tags as compartments with clearance
  • Extra-Sensitive Treatment
    • Share with Protections
  • De-Identified Research

Note that ALL of these topics have been covered in this blog. See Security TopicsConsent/Privacy, and FHIR for index to these articles.
   

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 https://profiles.ihe.net/ITI. 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

Conclusion

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 Patient.meta.security 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 (Immunization.meta.security) 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 Patient.meta.security 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 .meta.security 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.

Conclusion

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 Patient.meta.security 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.

UPDATE

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.