JASON and the EHRnauts

TOPICS:

Posted By: Roberta Mullin October 27, 2014

Boone_Keith

By Keith Boone, Healthcare Standards
Twitter: @motorcycle_guy

I thought I was done with JASON and the EHRnauts for a little bit, when this query popped into my inbox via Will Ross over at Redwood MedNet. He points to this bit of wisdom:

From the report:

To the extent that query capabilities are included in MU Stage 3, we are at an awkward moment in standards development: Older standards such as XDS/XCA are mature but inherently limited, whereas newer API-based standards are not yet ready for large-scale adoption. We believe it would be detrimental to lock the industry in to older standards, and thus, we recommend that ONC mobilize an accelerated standards development process to ready an initial specification of FHIR for certification to support MU Stage 3.

I love it when people raise the point about limits, without delving into what those limits are. It always sounds so authoritative. Yes, documents are limited.

Here are some of the limitations of documents:

  1. You can only operate on what appears within documents.
  2. You have to have some idea about which documents you want.
  3. When dealing with multiple documents, you have to deal with redundancy and ambiguity.
  4. Documents are coarser grained than some problems want to deal with.

There are also benefits to documents:

  1. A document can be operated on by a human using very little technology (Human Readability), or by a computer.
  2. Documents link each fact reported to an encounter or visit, a healthcare provider and and institution (Context).
  3. A document provides the complete record of the encounter or visit, not just individual parts that can be interpreted out of context (Wholeness).
  4. The content of a document can be retrieved at any point in time in the future in a way that is repeatable (Persistent).
  5. A document links data to the organization that gathered, uses and manages it (Stewardship).
  6. A document can be signed by a healthcare provider (Potential for Authentication).

Anyone who has studied CDA will recognize where these properties come from.

Now, as to the limits, all of these can be overcome, the question is who does it. The fundamental organization of data in an EHR around information documented during an encounter isn’t likely to change whether you look at a large grained document-centric approach, or a finer-grained data item-centric approach.

You’ll only ever be able to find information that has been gathered, or the fact that it hasn’t been gathered. The document based approach means that you need to look at several documents to determine that for a time period, a finer grained approach means that the system you ask for that information must look at all data items in that time period.

You will always have to have some idea about what you want to ask for. In the document-centric approach, that can be based on document metadata such as who, where, what or when. Those questions are often asked at the first level of the physician’s workflow in their search for more information. Finer-grained approaches will allow more detailed questions to be addressed that come later in the evaluation of the patient: Did they have this test? If so what were the results? Was ____ ruled out? When was the last time ___?

When dealing with multiple facts over time, you will have to deal with redundancy, ambiguity and disagreement. It is quite possible in an EHR today to have one physician assert something, and another deny that same thing, and both may be correct, or they may conflict. This is true regardless of whether the data items are accessed through coarse- or fine-grained mechanisms. Documents increase the degree to which this occurs because of the wholeness principle, you get all of the relevant data about the encounter, not just a few small pieces of data. But you should be able to readily resolve those issues, because you will always have them to deal with as soon as you have multiple data sources. Documents just make that problem visible sooner, because each document can be (and often is) treated as a single data source, whereas it only shows up in fine-grained access mechanisms once you have more than one data source.

The key issue is that some folks want to get right down into the computer automation of tricky bits, which means that they often don’t want what they consider to be the excess baggage of documents. Agreed, we need a better way, and the industry is working on it.

I also love it when I hear “lock in”, because frankly, when something better comes along, people will use it, regardless of what the government says or does (consider how mobile has driven healthcare). In most cases, the best thing it can do is get itself out of the way 😉

To say (as the JASON Task Force does) that “There is currently no industry- or government-led plan or effort focused on ubiquitous adoption of standardized Public APIs.” is technically correct. But let me ask you, where was the plan to adopt HTTP and HTML and CSS for the World Wide Web? XML and Schema? MIME and SMTP and POP for eMail? If anywhere, it was in the minds of the creators of those standards and the implementers. There was no government program driving adoption.

Right now, HL7, CDISC, DICOM, IEEE, OpenEHR, and IHE have all rallied around FHIR as the way forward for a variety of different use cases (see for example IHE’s Mobile Access to Health Documents effort). Major vendors, national programs, industry consortia, and other organizations have publicly announced support for FHIR in products, programs and services currently being developed. This kind of thing is nearly unprecedented in health care. To come upon if after the fact and try to impose some US federally crafted plan to make it happen is just a bit ambitious don’t you think? After all, it worked so well the last time with Direct.

My advice is to tread carefully, as ONC has already been doing. Offer support and assistance, encourage communication among different groups, maybe even fund some development. However, I think HHS needs to avoid the arrogance of thinking that it could plan this much better than is already occurring naturally in the industry.

I leave you with these thoughts: The Web took about five years to be widely used, and another five to really mature. FHIR has been with us for a bit more than two years. Rather than asking whether we can we afford to wait, consider if it will be worth it to rush. It won’t be too much longer.

— Keith

P.S. I was very impressed with the JTF report. It was a very thoughtful response to the original work.

This article was originally published on Healthcare Standards and is republished here with permission.