#FHIR Paradigms

Many of the FHIR tutorials show this diagram:

The goal of this diagram is to show that FHIR defines 3 different ways to exchange FHIR resources:

  • Using the RESTful interface – the most high profile way to exchange data
  • Packaging the resources in messages, and pushing them between systems (similar architecture as HL7 v2)
  • Packaging the resources in documents, with a managed presentation (similar architecture as CDA)

Also, what this diagram is intending to show is that in addition to the 3 ways defined by the FHIR specification itself, there’s other ways to exchange resources. Since the most common alternative method is to use some enterprise web services framework (say. some kind of SOAPy thing) – we called it ‘services’.

But that’s misleading; a ‘service’ is some orchestration of exchange of FHIR resources, and most implementation projects build their services using some combination of RESTful interfaces, messages, and documents, along with other methods of transfer. And that’s a combination that the FHIR community thinks is perfectly valid. So calling the 4th ‘other’ category “services” is… misleading… to say the least.

However there’s something beyond that missing from this diagram. In the last year or so, the FHIR community has gradually become more focused on what is emerging as a distinct 4th paradigm: using persistent data stores of some kind or other to exchange data between systems. Classically, this is associated with analytics – but it doesn’t actually need to be. The typical pattern is:

  • Create some kind of persistent store (can be an SQL database, a nosql db, a big data repository, an RDF triple store)
  • Applications generating data commit resources to the store
  • Applications using the data to the store find and retrieve data from the store at a later time

We haven’t really acknowledged this paradigm of exchange in the specification – but it’s what the RDF serialization is really about. And all the uses I’ve seen have one uniting characteristic: there’s a need to reconcile the data when it is committed, or later, to help with subsequent data analysis. There’s 2 kinds of reconciliation that matter:

  • detecting, preventing or repairing duplicate records
  • matching references (e.g. resolving URLs to their target identity in the database, and storing the native link)

One of the subjects I’d like to discuss in New Orleans next month is to gather the various disparate strands of work in the community around a ‘storage paradigm’ into a single coherent whole – if that’s possible. It’s something that we’ve been slow to take up, mainly because HL7 classically agrees to focus on the ‘interface’ and keep away from vendor design. But that’s happening in the community now has moved past this.

In particular, there’s really interesting and energetic work using new databases (or new features of old databases) to store FHIR resources directly in the database, and performing the analysis directly on the resources. Google presented some really interesting work around this at DevDays in Amsterdam a couple of weeks ago, and we’re working towards hosting a publicly usable example of this.

Clearly, we’ll need a new diagram to keep up with all these changes.

 

(Chinese Translation)

9 Comments

  1. Thomas Lukasik says:

    Grahame..

    While the idea of using a database to exchange data has been around for quite some time ( Martin Fowler wrote about it more than a dozen years ago here: https://martinfowler.com/bliki/IntegrationDatabase.html ), it’s generally discouraged today, and widely considered to be an “anti-pattern”.

    Fowler even recognized an “Integration Databases Considered Harmful” attitude way back in 2004, writing:

    “On the whole integration databases lead to serious problems becaue the database becomes a point of coupling between the applications that access it. This is usually a deep coupling that significantly increases the risk involved in changing those applications and making it harder to evolve them. As a result most software architects that I respect take the view that integration databases should be avoided.”

    I realize that using a standard like FHIR could mitigate *some* of the downsides he states, but I’d be very interested in hearing your thoughts as well as those of other readers RE the FHIR community formally promoting use of this technique by including it in a new diagram, or by using it for other than a limited set of use cases such as integrating internal applications.

    TJL

    • Grahame Grieve says:

      well, I disagree with Martin Fowler reluctantly, but the thing about integration is that it’s hard. And using a database or not only moves the problems around. They don’t suddenly appear because you used a database, instead of any other option. So I hink it’s better to be clear about what you are doing, and why, rather than calling database mediated interoperability an anti-pattern. (Unless you call integration an anti-pattern generally)

  2. Peter Jordan says:

    I’d be inclined to re-name the current ‘services’ box to ‘workflows’ and call the new (Big FHIR) paradigm ‘data services’. WRT to Thomas’ remarks, I think that persisting data in the format in which it is exchanged via APIs mitigates those risks.

  3. Thomas Lukasik says:

    Peter

    RE “persisting data in the format in which it is exchanged via APIs mitigates those risks.”

    I certainly may be misunderstanding something, but I’m thinking that persisting data using a data exchange format (which I expect would be FHIR) would create as many problems as it solves.

    Wouldn’t the integration database need to support a specific FHIR version? That seems to be how the handful of existing FHIR databases work today.

    It’s one thing to rely on a code library that can include simultaneous support for any number of versions of the standard (think HAPI, for example) but that extensibility and flexibility would seem to go away once you have to declare a FHIR aware database schema.

    Am I missing something?

    TJL

  4. Peter Jordan says:

    If multiple versions of FHIR resources can be handled at the application object and data exchange layers, then I don’t understand how this couldn’t be done at the persistence layer. It’s really down to the version (which might be a profiled version) of individual resources and if those resources are stored as JSON, that version is just a property value, not a schema version.

  5. Thomas Lukasik says:

    Peter

    RE “If multiple versions of FHIR resources can be handled at the application object and data exchange layers, then I don’t understand how this couldn’t be done at the persistence layer.”

    The difference between handling multiple versions at the application object or exchange layer vs at the persistence layer is that the former only requires adding new code that can be dynamically loaded into memory at run time to match as many FHIR versions as needs to be supported whereas the latter requires having to maintain multiple database schemas on disk in order to faithfully persist specific versions of FHIR Resources.

    Again, Peter.. anyone.. if I’m missing something please point it out.

    Thanks,
    TJL

  6. Peter Jordan says:

    The FHIR standard isn’t prescriptive about persistence strategies and there are many ways to skin that particular cat. Some will store complete resources in their exchange format and the version will be a property of each individual instances and/or any metatdata – rather than ‘shredding’ the data and placing it in an atomic RDBMS schema. My view, thus far, is that FHIR versioning is more challenging at the data exchange level.

    • Thomas Lukasik says:

      Peter

      While “The FHIR standard isn’t prescriptive about persistence strategies”, Grahame stated “One of the subjects I’d like to discuss in New Orleans next month is to gather the various disparate strands of work in the community around a ‘storage paradigm’ into a single coherent whole – if that’s possible.”, so that may change going forward.

      I for one would be very interested in the results of any New Orleans discussions, so hopefully any ideas floated and/or conclusions arrived at will be documented and published if that conversation does take place.

      TJL

  7. Thomas Lukasik says:

    Grahame

    RE: “One of the subjects I’d like to discuss in New Orleans next month is to gather the various disparate strands of work in the community around a ‘storage paradigm’..”

    Did that conversation ever take place, and if so, were any of the ideas, discoveries and/or conclusions that emerged documented anywhere?

    TJL

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*

%d bloggers like this: