FHIR support for OpenMRS

posted Aug 4, 2014, 8:33 PM by Chandan Datta

CDA Experts on FHIR

posted Aug 4, 2014, 8:32 PM by Chandan Datta

FHIR and the cost of standardization

posted Jul 7, 2014, 10:54 PM by Chandan Datta

In an article about FHIR, Eliot Muir is quoted as saying:

Not everyone is enthusiastic about FHIR. Eliot Muir, CEO of the Toronto interface engine developer Interfaceware, was initially quite positive about the FHIR standard “since at a high level the message is very positive,” but he says that when you look closely the standard is too complex and overly prescriptive. “I think manufacturers and software companies can build better RESTful web service APIs into their products, which will be simpler and more cost-effective that trying to follow the FHIR standard,” Muir says. “My own economic interests are served best in an environment with lots of APIs with useful data, which increases the usefulness of good integration technology. Clunky standards inhibit my business model.”

This is pretty much what Eliot said to me personally. And really, this is the core of the standards problem. If the vendor develops something bespoke, something that matches their internal model exactly, then of course that will be simpler and more cost-effective – that is, for the vendor, the first time.

But it’s not good for their customers – every one of them will now face an integration problem, where different vendors who produce different products with different APIs need to be integrated. They’ll have different information models, implicit business processes, business events, and transaction boundaries. Really, the vendor is simply engaging in moving complexity around – that is, externalising the cost to their customers.

It makes for a good sales price, but their customers will pay more overall. So in the end, vendors are driven to come to HL7 to collaborate and drive their customers costs down. Unless, that is, they can capture the market and overcome the cost a different way – but they will have an epic challenge to maintain that approach. I find it interesting to see how the old Apple and the new Apple have a different approach to standards – it really does make a difference to your bottom line, even if many people wish it were otherwise.

If the venders externalise the cost of interoperability to their customers, then the beneficiaries of that are businesses that help customers with integrating data – that is, interface engine companies. Like Interfaceware. So when Eliot says “My own economic interests”, he’s speaking the truth, but he’s not talking about his customer’s economic interests at all.

Actually, though, Eliot is wrong at the end: Clunky standards empower his business model, because people can’t make them work well. On the other hand, good standards – ones that vendors can use well – that’s what threatens Eliot’s business model. And that’s what we’ve tried for with FHIR.

So why do some interface engine companies support FHIR? I guess because selling interface engines is only part of their business, and they are more aligned with their customer’s interests. 

FHIR: Useability vs Reusability

posted Jul 7, 2014, 10:53 PM by Chandan Datta

I regularly get requests to look at a RESTful API for healthcare data from some company out there. Generally, people ask me one of 3 questions:

  • Should this company use FHIR?
  • Is this compatible with FHIR?
  • Why is FHIR not as simple as this API?

Whenever I look at one of these API’s , 3 basic themes stand out:

  1. These APIs solve a single problem
  2. These APIs can be changed
  3. These APIs are unsafe

1. A single Problem

The first is the biggest point; the company has designed the API to do exactly what they want, and it is perfectly tailored to their solution to that problem. They don’t need to ask painful questions like “what if the institution uses a different coding system?”, or “what if information is structured differently in some cases?”. Companies generally can simply decide what to do, and do it. So their APIs will always be simpler than the equivalent FHIR API, where we have to confront the need to deal with these things. Compared to FHIR, the companies API will be more usable. Well, actually, it will look more useable – and if you write denovo code to integrate with it (e.g. a greenfields client) then it will actually be easier – that’s actually ‘operability’. But if you have an already existing system with a different set of assumptions, it will get very difficult really quickly, or may even be impossible. FHIR, on the other hand, spreads the pain around (as equally as we can) – this means that everyone pays a higher price, but ‘interoperability’ is possible. In this way, the FHIR interface is much more reusable across multiple systems and use cases, at the cost of being less easy to use.

Here’s an example. A company doing diabetes monitoring might say, for instance, that a set of vital signs consists of the following JSON:

  "HBA1C" : "[value as %]",
  "CrCl" : "[value as mL/min]"

But that FHIR could never adopt this kind of approach – it serves only that single use case, and not a more general one involving lab results.

2. Dealing with Change

Part of the reason that companies can make these APIs simple is because if it turns out that the API is insufficient, they can just decide to extend it. That will work varyingly well for them, depending on how tightly the partner applications are linked to the host application life cycle. The slower it is to upgrade the clients (perhaps you have a 4 week app store cycle to deal with, or a 15 month institutional upgrade approval process to deal with), the less you can rely on fixing things as you go, and the more you have to get it right in advance.

As a standard, FHIR changes much more slowly than that again; that’s both it’s great strength and it’s weakness. So FHIR will be more reusable over time too, but this also must come at the cost of not being as easy to use.

3. Unsafe APIs

This is my final theme. Again and again I see that the underlying clinical content model is too simple; it doesn’t deal with the exceptional clinical cases. 99% of patients – the mainstream – will fit the simply model just fine, but the other 1% – either they cannot use the API, or they have to provide flawed or fictional data, or the data is too simple and subsequent analysis services the company claims to provide will be misleading. FHIR can’t afford to do that – the underlying clinical content model has to be robust.

The single most common way that this appears is in the codes – typically, a company will only allow a simple code system, with no exceptions for text, for instance. I understand this – dealing with text exceptions is one of the most painful parts of dealing with H7  content.

I suppose most of these companies will say that the problems I am concerned about simply don’t arise in practice, and if they did, they can respond by changing their API (see #2), but often, the patients affected are the most sick and most needy, and also the least able to express their position. However, as connected health information and the mobile/social web for health becomes more pervasive, this will become a political issue about access, like disabled access (which is relevant to the apps, but not the APIs). In the meantime, the FHIR API has to work in all these cases; this means that it has to be more complex for the simple case.

Usability and Re-usability are very often in conflict with each other.

p.s. FHIR is known for it’s core data element philosophy (sometimes described as it’s 80% philosophy), and so some readers might think my comments above are surprising. But no, this is an important part of the core rule – while we say that we do what 80% of systems do, we never think in terms of 80% of clinical cases. All clinical cases will flow across FHIR interfaces. (When I write operational clinical systems, my rule of thumb is: “1 in a million cases happen every week” in the systems, since roughly a million cases flow across them every week)


posted Jun 9, 2014, 6:40 AM by Chandan Datta

The FHIR community has made rapid progress in developing a clean, open, specification for granular data access, along with a consistent means to provide for document retrieval. 

FHIR provides a compelling scope of data models out-of-the-box, along with a principled framework for resource extension and resource constraints (“profiling”). 

Together, these characteristics provide a forward-thinking standard whose benefits should facilitate effective—and cost-effective—implementation. As conceived, the FHIR standard could provide a powerful way forward for remediating a long list of informational bottlenecks in HIT.

SMART changed the API to be based on the FHIR draft standard for trial use

posted May 28, 2014, 9:40 PM by Chandan Datta

SMART changed the API to be based on the FHIR draft standard for trial use. FHIR is notable for being well-suited for RESTful interfaces that are lighter weight and more fine-grained than prior HL7 standards.

1-6 of 6