Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Thursday, October 11, 2018

Challenges using SMART on FHIR for Multi-Vendor Authorization

Challenge by Nick Youngson CC BY-SA 3.0
One of the challenges for application developers in implementing SMART on FHIR is that of metadata endpoint discovery.  In order to initiate the SMART on FHIR authorization flow, the application developer needs to know the metadata or Conformance endpoint for the FHIR Server it is going to communicate with.  However, this endpoint is going to vary based on the vendor supplying the FHIR Server, the version of FHIR that is supported, and possibly even the healthcare organization deploying it.

The problem here is in the use of metadata as a way to discover the authorization endpoint, when in fact, the challenge for application vendors is configuring to support multiple endpoints with the same application.  If you use MyChart or other apps to access your health records (as I do), you can see how this plays out when you go to login as a patient.  The first step of your login process has you identify your state and healthcare practice (this shows up in other applications as well).  I'm certain that somewhere in that application and others like it, that selection process is doing something to resolve the practice specific endpoint details.

In a single vendor environment, it's pretty easy to address this, but when developing an application to support multiple environments, this can be quite challenging for the application developer.

NO, this isn't a claim that we need a global SMART on FHIR endpoint directory (although that is one way to resolve this issue).  It's more a statement that we've combined the process of conformance inspection with the problem of endpoint discovery.

Think about it: If your authorization endpoints are different, it is also likely that FHIR conformance associated with those endpoints could be different.  Why should they both use the same mechanism.

This creates a challenge for patients, because it means that App developers are likely unable to support as broad a variety of endpoints as they'd like simply due to the configuration challenges presented to them.

Smart SMART developers will obviously work around this.  One possibility is to modify the Launch sequence so that the application first asks the patient where their practice is located through some sort of internally managed directory, so that the application first selects the practice, and then the directory resolves the authorization endpoints AND the actual FHIR conformance endpoint the application can use to customize its operations based one what capabilities are available.

This would allow patient facing SMART applications to support multiple versions of FHIR from multiple provider organizations.

There are a lot of other challenges.  Like anyone else, you have to get your product into the vendor's App store, and there's a lot more vendors than one has to typically deal with for smart phone applications (two covers a lot of territory here, whereas you need 5 or 6 for EHRs to get the same coverage).  And of course, you also have to get your app into the smart phone stores too.  Those aren't problems I'm going to try to solve here.


Wednesday, October 10, 2018

But We're Different

The number of times I hear this phrase no longer astounds me. In making this statement the speaker rejects an offered solution because of a perceived difference based on a special need. I've often seen that the special need is similar to other special needs where the proposed solution is already in use elsewhere (Healthcare people sometimes act as if they are the only ones operating in a regulated industry).

Some years ago I led a diverse workgroup across three quite distinct stakeholders trying to solve (what appeared to me to be) the same problem. By "lead", I mean cajoled, bugged, spanked (verbally), herded, out-waited, out-witted, listened, learned, fumed, and eventually rejoiced. Over the course of a year I watched this group evolve three completely separate white papers and approaches into one, and after that evolve into an IHE workgroup (QRPH). That workgroup now looks more deeply into their commonalities than they do their differences.

In my most recent dive into medication management I see a similar opportunity for CDS Vendors, EDI vendors, PDMPs, eRX & CPOE developers, payers and pharmacies to come together around a singular solution for improving medication orders.

The challenge for this group is quite different though. Unlike QRPH, which faced a lack of solutions, attention and funding, medication management has a plethora of all of the above. The poverty in what we have is commonality, dare I say it "standards".

"Oh, yes we do too have those." it will be argued. And I will agree, the solutions have standards in the same way that an organization with 10 priorities has any priorities.  And the challenge we face in replacing 10 with 1 is best summarized by this (de-facto) standard response.

Uses with Permission from XKCD

HAPI FHIR BDD Testing using Serenity and RESTAssured for DSTU2

One of the challenges I've had with using Serenity and REST Assured for testing with the HAPI Server is related to the Content-Type header used with STU2 implementations.

In STU2, that content type is application/xml+fhir and application/json+fhir respectively.
In STU3 and after, these changed to application/fhir+xml and application/fhir+json.
This is discussed in more detail in HAPI FHIR Issue 445.

I finally figured out (I think) where to make the changes to address this in Serenity to handle appropriate reporting.  The key challenge is that I wasn't able to track down the content body of requests in error (or even those that were successful).  That detail can be found in Serenity-core Issue 448.

Unfortunately, what this requires is a hack around the given() method in which one intercepts the given() call, gets the response back, checks to see if it is of an appropriate type, and changes the RestResponseHelper method to appropriately format the response body (an exercise left to the reader).

I'm testing this now (because I have nothing better to do at 3 am).


Thursday, October 4, 2018

Deep, Significant and Detailed HL7 Contributions

One of the points of the Ad Hoc Harley award is to recognize unsung heroes in heath IT standards. Almost all past awardees have been people I've worked with directly in standards development. While I have met the current awardee in person we've not spent much time collaborating on anything together, even though he's a fellow New Englander. Even so, I've still benefited from his work in standards, and his open source contributions.

According to two very smart people I know (one a past awardee), he's one of the smartest people they know. In addition to being a brilliant computer scientist [an assessment I heartily agree with having read, used and tweaked his code], he is also an accomplished singer who can harmonize with anything, a person of great humility, and a devoted family man.

While he was unable to be at the HL7 Working group this week, his work was demonstrated in several committee meetings.

His contributions include:

  • CQL
  • CDS Connect
  • Maintenance of the Quality Data Model
  • Invaluable feedback on the CDC Opioid prescribing guidelines.
  • Synthea’s Generic Module Framework

Without further ado:

This certifies that
Chris Moesel of MITRE

has hereby been recognized for deep, significant and detailed contributions to HL7 standards.

Tuesday, September 25, 2018

Clinical Workflow Integration (part 2)

Continuing from my last post, let's look at the various technologies that need to be integrated for medication ordering workflows.
  1. The EHR / CPOE System
  2. Clinical Decision Support for
    1. Drug Interactions
    2. Allergies
    3. Problems
  3. BPM drug formulary
  4. Medication vocabulary
  5. ePrescribing
  6. Prescription Drug Monitoring Program portal
  7. the provider's Local formulary
  8. Prior Authorization (for drugs which require it)
  9. Signature Capture (and other components needed for eRX of controlled substances)
Add to that:
  1. Custom Forms
  2. A Workflow Engine (props to @wareFLO)
  3. Integration with drug pricing information
  4. Medication history
Each of these 13 technologies potentially comes from a different supplier. I can count at least a baker's dozen different standards (n.b., If I went to all of the meetings for the SDOs publishing those standards I could do NOTHING else).  Some of these components want to control the user interface.  Nobody supplies all the pieces in a unified whole.  Then as you probably already understand, some of the same technology is also applicable to other workflows: refills, medication reconciliation, medication review, et cetera.  And many of these technologies are also applicable inside information systems used by other stakeholders (pharmacists, payers/PBMs, public health ...).

Many physicians ePrescribing workflows look like the starter house on a quarter acre lot, that then got a garage, and hot tub, a later addition to have more room for the kids, a pool, and then a mother-in-law suite.  There's precious little room for anything else.  That's because, like the starter house, it grew over time without appreciable planning put into all the eventual users and uses in which it is used.

Paper based PDMPs have been around for a long time, electronically for more than a decade, but real time integration into medication workflows didn't really start to occur until about 4-5 years ago, and only in the last few have they become prevalent.  Legislation now requires integration into the physician workflow in several states (with more mandates coming).

ePrescribing of Controlled Substances has been around for a lot less time (first authorized federally in 2010 regulation), but electronic integrations started a bit sooner in many markets than did integration with PDMPs.

Many physicians ePrescribing workflows look like the starter house on a quarter acre lot, that then got a garage, and hot tub, a later addition to have more room for the kids, a pool, and then a mother-in-law suite.  There's precious little room for anything else.

It's time to rethink medication workflows, and rethink the standards.  Just about everyone in the list of stakeholders in the previous post wants to make recommendations, limit choices, get exceptions acknowledged, get reasons for exceptions, et cetera.  And everyone wants to do it in a different (even if standard) way, and to make it easier, just about everyone supplies proprietary data and APIs.

We need to unify the components so that they can work in a common way. We need to standardize the data AND the APIs.  We need to have these things take on a common shape that can be stacked and hooked together like LEGO® blocks*, and run in parallel, and aggregated.  We need to stop building things that only experts can understand, and build them in a way that we can explain it to our kids.

   -- Keith

* Yes, I know it's a tired metaphor, but it still works, and you understood me, and so would a
   six-year-old, making my last point.

Sunday, September 23, 2018

Who is responsible for clinical workflow?

RACI Chart 02
Dirk Stanley asked the above question via Facebook. My initial response focused on the keyword "responsible". In normal conversation, this often means "who has the authority", rather than "who does the work", which are often different.

I applied these concepts from RACI matrices in my initial response. If we look at one area-- medication management, physicians still retain accountability; but responsibility, consulting, and informing relationships have been added to this workflow in many ways over many decades, centuries and millennia.

At first physicians did it all: prescribe, compound, and dispense. Assistants took over some responsibilities for the work, eventually evolving into specialties of their own (nurses and MAs).  Compounding and dispensing further evolved into its own specialty apothecaries and pharmacists taking on some of the responsibilities. This resulted in both the expansion and contracting of the drug supply. More preparations would be available but physicians would also be limited by those available in their suppliers formulary. Introduction of these actors into the workflow required the physician to inform others of the order.

The number of preparations grew beyond the ability of human recall requiring accountable authorities to compile references describing benefits, indications for and against, possible reactions, etc; which physicians would consult. I recall as a child browsing my own physicians copy of the PDR -- being fascinated by the details. This information is now electronically available in physician workflows via clinical decision support providers.

Compounding & preparation led into further specialization, introducing manufacturing and subsequent regulatory accountability, including requirements for manufacturers to inform reference suppliers about what they make.

Full Accountability for what can be given to a patient at this stage is no longer under direct physician control.

Health insurance (and PBMs) changed the nature of payment, farther complicating the matters and convoluting drug markets well beyond the ability of almost anyone to understand. The influence of drug prices on treatment efficacy is easily acknowledged. But most physicians lack sufficient information to be accountable for the impact of drug pricing on efficacy and treatment selection. PBMs are making this information available to physicians and their staff. EDI vendors are facilitates this flow of information.

Physicians, pharmacists and payers variously accept different RACI roles to ensure their patients are taking / filling / purchasing their medications. In some ways this has evolved into a shared accountability. I routinely receive inquiries from all of the above, my own responsibility to acquire, purchase, and-take my medications has evolved into simple approval for shipping it to my home.

Attempts to improve availability of drug treatment to special populations (i.e.Medicaid) via discount programs such as 340B add to physician responsibilities. They must inform others of their medication choices for their patients.

Recently, information about prevalence of opioid related deaths and adverse events have introduced yet another stakeholder into the workflow. State regulatory agencies are informed of patient drug use, and want to share Prescription information with physicians accountable for ordering medications.

My own responsibilities as a software architect require me to integrate the needs of all these stakeholders into a seamless workflow. One could further explore this process. I've surely missed some important detail somewhere.

And yet, after all this, the simple question in the title remains ... answered and yet not answered at the same time.

     -- Keith

P.S. This question often comes up in a much different fashion, and one I hear way too often: "Who is to blame for the problems of automated clinical workflow in EHR systems?"

Wednesday, September 19, 2018

Loving to hate Identifiers

Here's an interesting one.  What's the value set for ObservationInterpretation?  What's the vocabulary?

Well, it depends actually on who you ask, and the fine details are rather weak on their effect in the eventual outcome.

Originally defined in HL7 Version 2, the Observation abnormal flags are defined as content from HL7 Table 0078.  That's HL7-speak for an official table, which has the following OID: 2.16.840.1.113883.12.78.  It looks like this.

Below low normal
Above high normal
Below lower panic limits
Above upper panic limits
Below absolute low-off instrument scale
Above absolute high-off instrument scale
Normal (applies to non-numeric results)
Abnormal (applies to non-numeric results)
Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units)
No range defined, or normal ranges don't apply
Significant change up
Significant change down
Better--use when direction not relevant
Worse--use when direction not relevant
For microbology susceptibilities only:
Moderately susceptible*
Very susceptible*

When we moved to Version 3 with CDA, we got ObservationInterpretation and it looks something like the following.  It's OID is2.16.840.1.113883.5.83.  The table is even bigger (click the link above) and has a few more values.  But all the core concepts below (found in 2010 normative edition of CDA) are unchanged.

One or more codes specifying a rough qualitative interpretation of the observation, such as "normal", "abnormal", "below normal", "change up", "resistant", "susceptible", etc.
LvlType, Domain name and/or Mnemonic codeConcept IDMnemonicPrint NameDefinition/Description
1A: ObservationInterpretationChangeV10214
Change of quantity and/or severity. At most one of B or W and one of U or D allowed.
2  L:  (B)10215Bbetter
Better (of severity or nominal observations)
2  L:  (D)10218Ddecreased
Significant change down (quantitative observations, does not imply B or W)
2  L:  (U)10217Uincreased
Significant change up (quantitative observations, does not imply B or W)
2  L:  (W)10216Wworse
Worse (of severity or nominal observations)
1A: ObservationInterpretationExceptionsV10225
Technical exceptions. At most one allowed. Does not imply normality or severity.
2  L:  (<)10226<low off scale
Below absolute low-off instrument scale. This is statement depending on the instrument, logically does not imply LL or L (e.g., if the instrument is inadequate). If an off-scale value is also low or critically low one must also report L and LL respectively.
2  L:  (>)10227>high off scale
Above absolute high-off instrument scale. This is statement depending on the instrument, logically does not imply LL or L (e.g., if the instrument is inadequate). If an off-scale value is also high or critically high one must also report H and HH respectively.
1A: ObservationInterpretationNormalityV10206
Normality, Abnormality, Alert. Concepts in this category are mutually exclusive, i.e., at most one is allowed.
2  S: ObservationInterpretationNormalityAbnormal (A)V10208AAbnormal
Abnormal (for nominal observations, all service types)
3    S: ObservationInterpretationNormalityAlert (AA)V10211AAAbnormal alert
Abnormal alert (for nominal observations and all service types)
4      L:  (HH)10213HHHigh alert
Above upper alert threshold (for quantitative observations)
4      L:  (LL)10212LLLow alert
Below lower alert threshold (for quantitative observations)
3    S: ObservationInterpretationNormalityHigh (H)V10210HHigh
Above high normal (for quantitative observations)
4      L:  (HH)10213HHHigh alert
Above upper alert threshold (for quantitative observations)
3    S: ObservationInterpretationNormalityLow (L)V10209LLow
Below low normal (for quantitative observations)
4      L:  (LL)10212LLLow alert
Below lower alert threshold (for quantitative observations)
2  L:  (N)10207NNormal
Normal (for all service types)
1A: ObservationInterpretationSusceptibilityV10219
Microbiology: interpretations of minimal inhibitory concentration (MIC) values. At most one allowed.
2  L:  (I)10221Iintermediate
2  L:  (MS)10222MSmoderately susceptible
Moderately susceptible
2  L:  (R)10220Rresistent
2  L:  (S)10223Ssusceptible
2  L:  (VS)10224VSvery susceptible
Very susceptible

It's got a value set OID as well.  It happens to be: 2.16.840.1.113883.1.11.78.  Just in case you need more clarification.

Along comes FHIR, and we no longer need to worry about OIDs any more.  Here's the FHIR table.  Oh, and this one is called: That should be easy enough to remember.  Oh, and it has a value set identifier as well:  Or is it  

Just to be safe, FHIR also defined identifiers for Version 3 code systems.  So the HL7 V3 ObservationInterpretation code system is:  Fortunately for us, the confusion ends here, because it correctly says that this code system is defined as the expansion of the V2 value set.

And, so, through the magic of vocabulary, we have finally resolved what Observation interpretation means.  Which leaves us pretty much right back where we started last century.

I'm poking fun of course.  This is just one of the minor absurdities that we have in standards for some necessary but evil reasons that do not necessarily include full employment for vocabularists. The reality is, everyone who needs to knows what these codes mean, and we've been agreeing on them for decades.  We just don't know what to call them.  This is one of those problems that only needs a solution so that we don't look ridiculous.  Hey, at least we got the codes for gender right .. right?  Err, tomorrow maybe.