Atom

Like PCAST before it, we now have a JASON report to cause all kinds of chatter. If you don't know either of these, then you are not missing anything useful. The most frustrating part of both PCAST and JASON report are that they don't use the common terminology but insist on introducing new terminology. They both introduced the term "Atom" as a term to indicate the granularity for which health data would be communicated and managed. The implication is that if we could communicate and manage the smallest of data then we will have the most powerful of Health Information Exchanges. I don't disagree with this, but must point out that "Atom" is not a helpful word.

An Atom is not clear

First we need to make clear that the definition of 'Atom' need to be carefully defined based on use-case. As with the chemical use of "Atom" there are very large atoms and very small atoms; yet all atoms are made up of sub-components that must not be further broken-apart (or bad things happen).

An Atom must be meaningful

The example clinical case that is often used is that clearly one would not just communicate the systolic-blood-pressure, and often it isn’t even enough to simply pair up systolic and diastolic taken at the same time, as one may also need to know if this is a resting BP, exercising BP, drug induced BP, or drug-influenced BP and what was the body position of the patient. Further it can be important to know if this data was gathered by a calibrated machine, drug-store machine, trained professional, etc. These are not metadata, these are critical components of the clinical-fact; aka the smallest Atom that can be communicated.

FHIR Atom is a Resource

FHIR is defining Atom in a reasonable way that is informed by history on 'clinical facts'. These Atoms in FHIR are 'Resources'. Here is the list of resources
http://hl7.org/implement/standards/fhir/resourcelist.html

Metadata. – there is also pointers (a form of metadata) to the patient identity, provider identity, setting, etc…

For each resource there is provenance, security-tags, conformance-tags, etc…

XDS Atom is a Document

Second, we need to recognize that sometimes the Atom that gets communicated needs to be larger and more self-contained. This is the case with HIE today where "Document" is what defines an "Atom". In that case (e.g. XDS, XCA, XDM, XDR, MHD) there is appropriate metadata per Atom.  There are some really critical concepts of a Document that Resources and Messages don't have.

FHIR Atoms can make Documents

FHIR can also take this analogy further and make Molecules, for which one of these examples is a Document. This is especially confusing as to do this FHIR uses the ATOM 'standard' to do this composition of multiple resources.

FHIR can also be the 'last mile' API to XDS, XCA, and XDR.

FHIR can also be used to access a decomposed Document. That is a document can be submitted or communicated; it can be decomposed into the parts which can be accessed using FHIR. One could even build a "Service" that you send it a CDA document, it decomposes it and offers it up as FHIR resources, and flushes when the use of those resources are no longer needed.

Concluding Atom

We can NOT let the shiny new thing – aka FHIR – distract from very good progress on the Document Sharing model. We have already seen negative progress due to Direct distraction. I am absolutely committed to FHIR as the future model, especially for edge-device API. However FHIR is still under-development and unproven. Now is the time to work to get FHIR developed and proven.

I simply recommend we start with fully self-contained Atoms (Document), and work toward more discrete Atoms (Resources).  The last-mile API should prioritize use of FHIR at the Resource level, backbone used between organizations should prioritize use of Documents.