JASON and the EHRnauts

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.

Right almost by accident: The JASON Report on HealthIT Infrastructure

I've finally read through the most recent JASON report on A Robust Health Data Infrastructure.  It fails to live up to one pundit's description as the "Son of PCAST" widely reviled by the Healthcare industry.  It failed to live up to its billing.  The PCAST report had some semblance of professionalism about it.  However, the JASON report is amateurish by comparison, full of outdated references, pedantic writing and unjustified opinions.  Even so, its more right than wrong, but probably for the wrong reasons.

My favorite quote from the most recent JASON Report is:

Innovation in health care appears to be frozen by a deluge of overly ambitious, insufficiently practical, and often conflicting advice

Never have I seen such a well qualified self-referential statement statement in a report before, and I have to completely agree with it.  In this case, I'd also have to add confusing advice.

The report relies on out-of-date references in citing the slow growth of adoption of electronic medical records by healthcare providers.  We are in the midst of a technology revolution in terms of adoption.  In four short years, the US has emerged from the bottom of the pack of all nations with respect to Health IT to being near the top, and if the pace continues we will shortly be at the top.  With such rapid change, there is no question that there will be fits and starts and growing pains, and that we won't have gotten it right in the first try.  The critique that we aren't moving fast enough:

The level of interoperability set forth through the CMS Meaningful Use criteria, as a result of the HITECH Act, is too low to drive meaningful progress

Fails to indicate what pace is fast enough, and how we could expect to achieve that pace.  Meaningful Use is starting its second cycle this year.  Systems conforming to the 2014 criteria are being deployed and used and haven't even been in place for half a year.  And yet somehow, we've already learned enough to state that Meaningful Use stage 2 is also a failure.

The criteria for Stage 1 and Stage 2 Meaningful Use, while surpassing the 2013 goals set forth by HHS for EHR adoption, fall short of achieving meaningful use in any practical sense. 

I would like to see what the authors define to be meaningful use and how they can expect a program that has been in place for three years has failed so significantly.  The first two-year stage jumped the national adoption level of Health IT from 30-40% to nearly 80% according to the CDC.  In four short years we've bent the adoption curve faster than any first world country.  And this is too slow.

And once again, we need "scientists" to tell us:

With respect to data formats, the current lack of interoperability among the data resources for EHRs is a major impediment to the effective exchange of health information. ... However, simply moving to a common mark-up language will not suffice. It is equally necessary that there be published application program interfaces (APIs) that allow third-party programmers (and hence, users) to bridge from existing systems to a future software ecosystem that will be built on top of the stored data.

But who fail to recognize that Blue Button Plus is in fact a published API to do just that.  No, to them it's a business model that has yet to succeed (see page 16 of the report).

And what is Blue Button Plus based on?  A standard API (called FHIR) that allows third party programmers to bridge from existing systems developed by one of the hundreds of standards organizations that could only be mentioned by name ONCE in the entire report (HL7), and not even in the context of organizations developing standards.

And while the report remarkably makes mention of connect-a-thons (using the NFS spelling), the authors remarkably make no mention of any current such events occuring (such as a couple of weeks ago in Vienna), or next week in Phoenix (although some might argue that's not quite a connectathon yet).

Of course the report is full many other opinions and absolutes such as:

Current EHR systems do not interoperate at all, and in many cases are unable to even exchange data between hospitals running the same system from the same vendor.

I could spend the entire day ripping the rest of the report apart, but I won't, because there are two things it got right (perhaps for the wrong reasons).

The JASON report fails to make a distinction between the lifetime longitudinal Electronic Health Record, and the electronic medical record systems, payer databases, care management and other Health IT systems from which the EHR will become an emergent property.  But, it properly recognizes that:

EHRs should not be things that one buys, but rather things that evolve through cultural change aided by technology

But fails to distinguish between the components of the EHR (the Certified electronic medical record systems confusingly called EHRs in the Meaningful Use program), and the emergent property that will be the EHR supporting patient care, population health and clinical research.

And secondly:

The architecture must be based on open standards and published application program interfaces (APIs) and protocols. 

There is work led by HL7, and supported by IHE, DICOM and others under development over the last three years, known as Fast Healthcare Information Resources (FHIR) that supports the API that JASON is looking for.  If only someone on the advisory committee had mentioned it to them (or perhaps they did, but it was remarkably unreferenced in the JASON report).

I beg ONC that when they next commission a report, be it from PCAST, JASON or whomever else, that they include on the team of advisors someone who can point the team to current standards work so that it can at least be evaluated, and also give them some up-to-date references, so that they don't embarrass themselves by referring to data that is woefully inadequate.

And, yes, ONC please continue to support HL7 efforts on FHIR, because I truly think that's the open API that you are looking for.