Friday, January 18, 2019

Asking for Help with Grace and Dignity

Although she may claim otherwise, one my my standards colleagues has asked for help with great grace and dignity.  In case you haven't heard, Lisa Spellman has been diagnosed with colon Cancer.  Her prognosis is good, but the treatment (radiation and chemotherapy) is challenging (as some of you are well aware) in many ways.  One of the ways that the treatment is challenging is financially, and that's where you can help.

I know many of you already know Lisa from her work in standards.  She's been involved in standards at IHE, HIMSS, ISO and most recently DICOM.  She has always brought great energy and excitement to what for many would be the dull observation of pork, spice and fillers being ground and stuffed into sausages by a bunch of geeks spouting technobabble.

Her sister started a Go Fund Me to help with the financial impacts of treatment, if you want to participate, check it out at

Next week, I'll return with a summary of the January HL7 Working Group meeting.


Saturday, January 12, 2019

There is Always Another Way

There's more than one way to skin a cat, or route to a solution. When presented with a problem, a good software engineer can usually think of at least two ways to solve a problem.  And most often, the next thing we do is pick one and invest time and effort into it.  The choice selected may not be the best one, it may be a compromise based on competing factors.

So then, let me unpack this tweet (shown below from Thomas Beale, a well-regarded expert in OpenEHR):
"What we should have: a universal health content model library. What the message people always do: impose their own content 'standard' rather than cooperate with mature approaches to modelling. What we get: dissonance."

There's a little bit of sour grapes in this because of the long-standing competition between HL7 (the message people) and OpenEHR.  These are competing standards in the Health IT spectrum that take different approaches, for which there are pros and cons for each.  HL7 focuses more on exchange and OpenEHR more on data modeling.  Both have their target markets for adoption which overlap to some degree.  HL7 has a significant (order of magnitude) advantage in general adoption, OpenEHR has a significant advantage in existing clinical models, their physician engagement model and clinical validation of content (models which HL7 CIMI workgroup and the AMA (separately) are also developing).

Thomas goes on further in blog post he links to the above statement to say (emphasis mine):
My view is that the only scalable way to create the semantic specifications is for them to be artefacts outside of both vendor products and outside of specific communications formats.
Where healthcare computing needs to go is a complete separation of models of semantics of healthcare and the technologies used to implement solutions at any given time.

You can see where I'm going here when I highlight "the only scalable way" and "complete separation".  As soon as one starts talking about the "only way", the discussion has been elevated from one at layer 7 of the protocol stack, to layer 8 or 9.  Absolutist statements such as these don't allow for compromise.  When the rubber hits the road, compromises are needed, because to a working solution is by definition one that has shipped, and perfection is the enemy of the good.  FHIR R4 has shipped, FHIR is already available in Health IT products covering better than 87% of the US hospital market and 69% of the ambulatory market (the numbers are surely better given the age of my reference and the data it used [it's at least 6 months out of date]).

I generally agree with Tom's statement about separation of model semantics and technologies, but I don't come to the same conclusion about completing the separation between models and technologies.  FHIR is a new technology that is meant to make Health IT software deliverable, and it seems to be delivering on that promise. R4 shipped in late December (a couple of days after Christmas).  IHE just completed updating three profiles to R4 and published those specifications for public comment last week.  HAPI on FHIR is on track to deliver an implementation of R4 in a few more weeks.  The US Core for R4 is out for ballot. That's delivery.

Back to the original tweet, FHIR specifies a content standard for resources, it takes some aspects of the semantics into the implementation of the technology to make life easier for developers.  That's OK, I'm willing to live with that compromise in order to ship.


P.S. If I wanted to be snarky, I'd point out that there are probably better words than "mature" to describe well-established or proven methods in technology, preferably ones that don't imply lack of change.

Tuesday, January 8, 2019

A Bet on Standards for the next round of Certification

It's been pretty clear that ONC is putting its money behind FHIR, and we know that 21st Centrury Cures will require new certification requirements, and are pretty much certain that (based on the last round of regulation), that a standard for APIs is going to be specified.

I see two choices: FHIR DSTU2 with Argonaut, or FHIR R4 with US Core, either of these with SMART on FHIR.  Having read through the new US Core over the last week (for the HL7 ballot cycle), it's pretty clear it essentially replaces most of what was found in the original Argonaut specifications.

So, I'm placing my bets on FHIR R4 with US Core and SMART on FHIR.

What I'm NOT placing bets on is when the regulation is actually going to show up.  HHS has some appropriations already, and ONC is still moving some things forward, but OMB is on furlough and the Federal Register site is non-operational, and NIST has also shut down (not that they are essential for publishing the rule, only afterwards in implementing it).

Given the current situation, I'd rather the rule had showed up on December 24th.


Friday, January 4, 2019

What's a Standard?

What's a standard supposed to look like? What does it tell you?

These aren't as simple as you think:

Consider the following different kinds of "standards"

  1. A standard for light bulb bases.
  2. A collection of functional requirements that CAN be applied to a particular type software.
  3. A collection of functional requirements that HAVE been applied to a particular type of software.
  4. A protocol specification such as HTTP.
  5. The specification for a markup language.
  6. The specification for a specific implementation of a markup language (or perhaps this is it).
  7. A standard for a programming language.
  8. A standard for performing a particular test.
  9. A standard for performing a particular task.

All of these are standards.
ASTM recognizes six types of standards: test method, specification, classification, practice, guide, and terminology.
NIST recognizes a somewhat different set, one of which they describe as process, but you won't be able to use this link since the US government shutdown last year.
I even have my own classification.

HL7 publishes functional specification (see 2 and 3 above), protocol specifications (like #4, but see MLLP which is essentially the HTTP of Version 2), schemas and specifications (very much like HTML 5), and other things.  Some of them they call standards, others they call informative documents, but many use these interchangeably.  Some call them specifications, others implementation guides, and others profiles.

Some standards describe best practices, models of systems, or provide for ways to talk about things.  Others talk about bits and bytes (or octets).  That's what you were probably thinking about.

There's really nothing magic about describing what a standard is.  It's an way to do something that some group has agreed to follow.  The something part is VERY nebulous.  The some group part is very nebulous.  The enforcement mechanism of the agreement is very nebulous.  In some cases, even a standard itself is very nebulous.

The biggest distinction between what a standard is and isn't has to do with who agreed to it.  Portable Document Format wasn't a standard until it was.  The difference had to do with who agreed to it.  In the first case, it was a single company.  In the second, it was an international standards committee.
This was the "de facto" (in fact) standard for C, until is was supplanted by an earlier version of this as the "de jure" (in law/jurisdiction) standard.

People like standards because it means they don't have to think hard, just smart. And that's why "who" made it a standard is very important.  Sometimes, even when everyone agrees, it seems that nobody agrees on what the standard is (see HTML5, or perhaps you want HTML5) [but at least they agree on what it does].

I read standards like this (a very architectural cookbook), and like this (A pretty decent functional standard with some pretension of being an API as well, but with some notable deficiencies in that latter part that I hope will be corrected in the standards making process), and like this (a vaguely useful thing if you like your standards regurgitated into another publication format with a lot of reused content), and like this (something important, but possibly blown away by this, we'll see what happens when it shows up).

And yes, it's ballot season at HL7, just in case you were wondering.  How do I feel about that?  In a word: Nebulous.

In a thousand words:


Thursday, January 3, 2019

Mad Libs for HealthIT

One of the predictions I made yesterday about what isn't going to change in 2019 is that we'll still be hearing about a lack of standards and interoperability in Health IT.

Something I've learned about these phrases over the years is that the speaker drops an important adjective or prepositional phrase that prevents full comprehension of the statement, which, from their viewpoint is almost inevitably true.

Consider the following two statements:

There are no               A               Health IT standards                B                .


We don't have interoperability                      C                      in Health IT                      D                     .

For A, substitute one of the following:
  • Agreed upon
  • ANSI Approved
  • Available
  • Deployed
  • Easy to Use
  • Easy to Deploy
  • Inexpensive
  • Implemented
  • Pervasive
  • Rolled Out

For B, substitute one of the following:
  • in <HealthIT Product we use today>
  • that we are willing to use
  • that we know about
  • that won't change our workflow
  • won't impact our revenue
For C, add "between my institution and my"  and fill in with one of the following:
  • patients
  • lab
  • referral network
  • local hospital
  • public health agency
  • clearing house
  • payer
  • billing service

For D, add "because", and fill in with one of the following:
  • the vendor hasn't been selected yet
  • we don't know how to do that
  • we haven't upgraded our Health IT to support that
  • we haven't deployed that feature yet
  • we aren't willing to pay for it
  • they don't have that capability yet (because <pick one of the above and change we to they>)
  • the [regulations|measures] that we want to support aren't out yet
Some of these are good reasons for why there isn't interoperability (or perhaps even standards), and others aren't.  When this information is communicated up the chain to Health IT leaders, regulators, or legislators, inevitably, these auxiliary clarifying phrases (if they were ever uttered) are often dropped to simplify the message.

So, in 2019, before I let them allow my blood to boil, I've resolved to try to identify what might be missing in these statements when I see them.  And if and when I can figure them out, I'll try to report on them here.


Wednesday, January 2, 2019

What's not going to change in 2019 for HealthIT?

While many are offering their opinions on what will be new or interesting for this new year, or reviewing the previous year, I thought I'd offer some observations on what isn't going to be different in 2019:

FHIR is still a work in progress.  Yes, FHIR Release 4 marks the first normative version of the standard, but much remains to be done and will continue to be worked on by HL7.

Certification will remain a focus of ONC.  Yep, Meaningful Use may be dead, but there's the CMS program after that, and the one after that and the other program, all of which will continue to require certified EHR technology.

APIs are still the way forward.  Most providers now have access to APIs, but the challenge will be to move them into production.  2019 will be a critical year for many providers to get the APIs rolled out to patients.  The roll-out still allows for a 90-day reporting period, enabling providers a smaller window for demonstrating the promoting interoperability capabilities, but will require use of 2015 certified technology (instead of a combination of 2014 and 2015 as for last year).

Finally, we'll still be hearing about a lack of HealthIT standards, and a lack of interoperability in 2019.  More on that tomorrow.