#FHIR and Bulk Data Access Proposal

ONC have asked the FHIR community to add new capabilities to the FHIR specification to increase support for API-based access and push of data for large number of patients in support of provider-based exchange, analytics and other value-based services.

The background to this requirement is that while FHIR allows for access to data from multiple patients at a time, the Argonaut implementations are generally constrained to a single patient access, and requires human mediated login on a regular basis. This is mainly because the use case on which the Argonaut community focused was patient portal access. If this work is going to be extended to provide support for API based access to a large number of patients in support of provider based exchange, the following questions (among others) need to be answered:

  • how does a business client (a backend service, not a human) get access to the service? How are authorizations handled?
  • How do the client and server agree about which patients are being accessed, and which data is available?
  • What format is the data made available in?
  • How is the request made on a RESTful API?
  • How would the client and server most efficiently ensure the client gets the data it asks for, without sending all data every time?

The last few questions are important because the data could be pretty large – potentially >100000000 resources, and we’ve been focused on highly granular exchanges so far. Our existing solutions don’t scale well.

In response to some of these problems, the SMART team had drafted an initial strawman proposal, which a group of us (FHIR editors, ONC staff, EHR & other vendors) met to discuss further late one night at the San Diego WGM last week. Discussion was – as expected – vigorous. Between us, we hammered out the following refined proposal:


Summary

This proposal describes a way of granting an application access to data on a set of patients. The application can request a copy of all pertinent (clinical) access to the patients in a single download. Note: We expect that this data will be pretty large.

High-level Use Case Description – FHIR-enabled Population Services (this section provided by ONC)

  • Ecosystem outcome expected to enable many specific use case/business needs: Providers and organizations accountable for managing the health of populations can efficiently access to large volumes of informationon a specified group of individuals without having to access one record at a time. This population-level access would enable these stakeholders to: assess the value of the care provided, conduct population analyses, identify at-risk populations, and track progress on quality improvement.
  • Technical Expectations: There would be a standardized method built into the FHIR standard to support access to and transfer of a large amount of data on a specified group of patients and that such method could be reused for any number of specific business purposes.
  • Policy Expectations: All existing legal requirements for accessing identifiable patient information via other bulk methods (e.g., ETL) used today would continue to apply (e.g., through HIPAA BAAs/contracts, Data Use Agreements, etc).

Authorizing Access

Access to the data is granted by using the SMART backend services spec.

Note: We discussed this at length, but we didn’t see a need for Group/* or Launch/* kind of scopes – System/*.read will do fine. (or User/*.*, for interactive processes, though interactive processes are out of scope for this work). This means that a user cannot restrict Authorization down to just a group, but in this context, users will trust their agents.

Accessing Data

The application can do either of the following queries:

 GET [base]/Patient/$everything?start=[date-time]&_type=[type,type]
 GET [base]/Group/[id]/$everything?start=[date-time]&_type=[type,type]

Notes:

  • The first query returns all data on all patients that the client’s account has access to, since the starting date time provided.
  • The second query provides access to all data on all patients in the nominated group. The point of this is that applications can request data on a subset of all their patients without needing a new access account provisioned (exactly how the Group resource is created/identified/defined/managed is out of scope for now – the question of whether we need to do sort this out has been referred to ONC for consideration).
  • The start date/time means only records since the nominated time. In the absence of the parameter, it means all data ever
  • The _type parameter is used to specify which resource types are part of the focal query – e.g. what kind of resources are returned in the main set. The _type parameter has no impact on which related resources are included) (e.g. practitioner details for clinical resources). In the absence of this parameter, all types are included.
  • The data that is available for return includes at least the CCDS (we referred the question of exactly what the data should cover back to the ONC)
  • The FHIR specification will be modified to allow Patient/$everything to cross patients, and to add $everything to Group
  • Group will be added as a compartment type in the base Specification

Asynchronous Query

Generally, this is expected to result in quite a lot of data. The client is expected to request this asynchronously, per rfc 7240. To do this, the client uses the Prefer header:

Prefer: respond-async

When the server sees this return header, instead of generating the response, and then returning it, the server returns a 202 Accepted header, and a Content-Location at which the client can use to access the response.

The client then queries this content location using GET content-location (no prefixing). The response can be one of 3 outcomes:

  • a 202 Accepted that indicates that processing is still happening. This may have an “X-Progress header” that provides some indication of progress to the user (displayed as is to the user – no format restrictions but should be <100 characters in length). The client repeats this request periodically until it gets either a 200 or a 5xx
  • a 5xx Error that indicates that preparing the response has failed. The body is an OperationOutcome describing the error
  • a 200 OK with the response for the original request. This response has one or more Link: headers (see rfc 5988) that list the files that are available for download as a result of servicing the request. The response can also carry a X-Available-Until header to indicate when the response will no longer be available

Notes:

  • This asynchronous protocol will be added as a general feature to the FHIR spec for all calls. it will be up to server discretion when to support it.
  • The client can cancel a task or advise the server it’s ok to delete the outcome using DELETE [content-location]
  • Other than the 5xx response, these responses have no body, except when the accept content type is ‘text/html’, in which case the responses should have an HTML representation of the content in the header (e.g. a redirect, an error, or a list of files to download) (it’s up to server discretion to decide whether to support text/html – typically, the reference/test servers do, and the production servers don’t)
  • Link Headers can have one or more links in them, per rfc 5988
  • Todo: decide whether to add ‘supports asynchronous’ flag to the CapabilityStatement resource

Format of returned data

If the client uses the Accept type if application/fhir+json or application/fhir+xml, the response will be a bundle in the specified format. Alternatively, the client can use the type application/fhir+ndjson. In this case:

  • The response is a set of files in ndjson format (see http://ndjson.org/).
  • Each file contains only resources of a single type.
  • There can be more than one file for each resource type.
  • Bundles are broken up at Bundle.entry.resource – e.g. a bundle is split on Entries so the the bundle json file will contain the bundle without the entry resource, and the resources are found (by id) in the type specific resource files (todo: how does that work for history?)

The nd-json files are split up by resource type to facilitate processing by generic software that reads nd-json into storage services such as Hadoop.

Notes:

  • the content type application/fhir+ndjson will be documented in the base spec
  • We may need to do some registration work to make +ndjson legal
  • We spent some time discussing formats such as Apache Avro and Parquet – these have considerable performance benefits over nd-json but are much harder to produce and consume. Clients and servers are welcome to do content type negotiation to support Parquet/ORC/etc, but for now, only nd-json is required. We’ll monitor implementation experience to see how it goes

Follow up Requests

Having made the initial request, applications should store and retain the data, and then only retrieve subsequent changes. this is done by providing a _start time on the request.

Notes:

  • Todo: Is _start the right parameter (probably need _lastUpdated, or a new one)?
  • Todo: where does the marker time (to go into the start/date of the next follow up request) go?
  • clients should be prepared to receive resources that change on the boundary more than once (still todo)

Subscriptions

The ONC request included “push of data”. It became clear, when discussing this, that server side push is hard for servers. Given that this applications can perform these queries regularly/as needed, we didn’t believe that push (e.g. based on subscriptions) was needed, and we have not described how to orchestrate a push based on these semantics at this time


Prototyping

It’s time to test out this proposal and see how it actually works. With that in mind, we’ll work to prototype this API on the reference servers, and then we’ll hold a connectathon on this API at the New Orleans HL7 meeting in January. Given this is an ONC request, we’ll be working with ONC to find participants in the connectathon, but we’ll be asking the Argonaut vendors to have a prototype available for this connectathon.

Also, I’ll be creating FHIR change proposals for community review for all the changes anticipated in this write up. I guess we’ll also be talking about an updated Argonaut implementation guide at some stage.

 

Question: #FHIR Documents and Composition

Question

What is the relationship between FHIR Documents and  composition resources? Meaning, what is the best way to capture/store in FHIR, documents that are not necessarily related to clinical info (file, images, file reference links to external content systems etc)

If I have several documents that need to be associated to a patient and organizations and was looking for your thoughts on best practices you have seen

Answer

Documents like this – files, images, reference links to content systems – these are best handled using DocumentReference.  Composition is used for documents that have tightly controlled content. a mix of narrative and data.

Question: Extending systems to deal with non-#FHIR type content

Question

What has your experience been with developers, developing on a FHIR model that requires FHIR resources — but also has a need for non-standard FHIR data (something like supply chain data or Blockchain external hashed data). Is the recommendation to shoe horn this into extensions  or have data models that live side-by-side with FHIR?

Answer

There’s no single answer to this question, because it depends on the other kind of data. Generally, there’s 3 approaches I’ve seen:

  1. Use extensions in existing resources (particularly Basic). This approach is only good while the extensions are pretty narrow and limited, and closely related to the existing FHIR functionality
  2. Use some other content model, and figure out how the functionality links. This approach is good where there is another content model. For example, in my server, I use SCIM for managing the user accounts. I use the SCIM content to link a user account to a FHIR resource like “Patient” so that I know which patient the user represents (if any) and I refer to the SCIM user identity in AuditEvent resources (as a URL)
  3. Make up your own content but follow the FHIR patterns – effectively, custom FHIR resources. Use extensions to reference them. This approach is good where you have quite a bit of content/functionality, but there’s no external standard to follow

Which is best depends on what you’re doing.

A note about the custom resources idea: this is legal – you can do whatever you want with the names the FHIR doesn’t define. e.g. [base]/User. And if you choose to put something there, that happens to look a bit like a FHIR resource.. that’s still whatever you want. But things like ‘can I describe it from the CapabilityStatement’ and ‘can I search into the space’ are not technically legal, and there’s always a risk that HL7 will use the name in the next version of FHIR, making your solution locked in to being non-conformant. We’ve investigated making some policy around these questions to make custom resources manageable, but we’ve never managed to get the energy to push agreements over the line.

The Vendor Engagement Matrix

This is post 2 in my series on why to participate in the standards process: a reason why Vendors should engage with standards

Professional Societies

One strong feature of the healthcare eco-system is professional societies. Everywhere you look, there’s another one. See here, and here, and on wikipedia. Or for Australia, here. (And none of the ones I’m involved with – HISA, ACHI, AACB – are even listed). For professionals in healthcare, the reasons to be involved in these are obvious (see, e.g. “Top 10 reasons“). In fact, in most places I’ve worked – whether clinical labs, research labs, government agencies, or vendors, membership of and engagement with professional societies is expected (or even required) if you have a leadership role.

And most employers enthusiastically support their employee’s involvement and leadership in professional societies (witness the employer affiliations for board members of ACHI, AIIA, AMIA). It’s obvious why employees participate in professional societies, but why do employers support this, even to their apparent cost (funding time, travel, sharing implicit IP, etc)? For example:

Some employers claim that there is no time for such efforts, or that it could prove too expensive. Many worry that all they would be doing is enhancing employees’ skills for a future employer. They ask themselves what would happen if they encourage professional development and some of their employees leave.

Those are all valid concerns. But:

A better question would be to ask what would happen if they ignore professional development and their employees stay

I’m quoting from the Society for Human Resource management there. Do read the whole thing. I’m just cherry picking a choice quote:

One critical reason given for seeking employment elsewhere was that although the employees valued mentoring, training and coaching very highly, their employers were falling far below expectations in those areas.

Finally, I’ll note that it’s when an organization must trust the choices that it’s employees make on their behalf that professional societies are most compelling – in fact, that’s when they become necessary: employees are inspired and pressured to apply professional excellence in ways that an employer cannot easily reproduce. And that’s why they’re a big deal in healthcare (and IT).

Most vendors I know encourage their staff – and particularly their leaders – to be involved in professional societies. It’s a tangible demonstration of their commitment to excellence. And the vendors that don’t encourage their staff to get involved?… they’re signalling to the market where they sit on professional engagement: it doesn’t matter. And, more importantly, they’re signalling to their staff about that as well, and I’ve seen that companies that don’t do this suffer from a steady erosion in their culture.

Choosing a Vendor

When it comes to choose your enterprise information system (EIS) providers, the quality and culture of the EIS vendor really matters. It all comes down to what you are buying. If you’re buying a widget, where the delivery of quality goods is feasible to measure, and the goods are a commodity, then it makes absolute sense to choose the lowest price you can get in the market. But once you start buying things where the quality is not easily measured, or you have a high transaction cost to change supplier, you have to think differently about your choice. And EIS’s really are the epitomy of these problems (e.g. changing EIS frequently costs more than the cost of the system, and the vendor pretty much does nothing but make decisions on your behalf, ones you can’t really review).

Because of this, thoroughly understanding the culture of the vendor of the EIS – who you are effectively marrying for the duration that you’ll depend on them to assist you manage your organization – is critical. As technical lead at Kestral, I always believed that our potential customers, when choosing a vendor, focused their scoring too highly on the current features of the widget they were buying (the EIS), and not on the relationship they were entering into – because the system they were buying was not static, and a key feature of their future success was how well their EIS vendor could support them to grow their business by delivering on their future interoperability requirements. (And, if I’m not mistaken, lack of delivery on interoperability features a little in the news at the moment….)

But the problem is, how do you choose a vendor that consistently delivers based on a culture of professional excellence? well, one way is to count what % of the vendors key employees have leadership roles in professional societies. And asking the vendor to report that should be a standard feature of all EIS RFPs, and it should be scored enough to weight it against the long list of feature the EIS is being scored on.

But, you say… that’s easy for a vendor – it’s not really very costly in the overall picture to support an employee’s involvement in a professional society, and there’s no need for that to make a meaningful difference to their culture. And that’s actually partly right. Which is why the real question is not about the professional societies of their employers, but the vendor’s membership of professional societies for the vendor itself. That’s where the rubber really hits the road.

And professional societies for healthcare EIS systems are standards organizations (or their derivative, informal open source collaborations).

Involvement in Standards Organization

This means that a vendors involvement in standards is a key indicator of it’s aspiration to enduring professional competence. And it’s deep involvement over time that matters, along with consistent delivery of the standards being worked on. It’s not a magic bullet, but it’s tangible evidence that the vendor has a deep commitment to it’s own professional standards to deliver a quality product in regards to more than just the feature list that appear on sales materials.

And this is something that institutions should ask about in their RFPs: what tangible evidence can you as a vendor show that you have an organizational commitment to quality? Now obviously there’s more answers to this than just involvement in the standards process, but involvement in the standards organization not only is one good and measurable marker, it’s a particularly relevant marker given an organizations inevitable future dependency on the vendor to deal with ongoing interoperability requirements.

All this suggests that we could define a Standards Engagement Matrix which can be used to score how involved a vendor is in the standards process. It might look something like this:

SDO Membership Gold Membership Organization leaders Technical Leaders Contributions Delivery
One row for each relevant SDO 5 points for being a paid member 20 points for paying high level fees 3 points for each board member, or chair of an organizational committee 4 points for each technical committee chair

5 points for each editor of standard

5 points for major contributions of tools, drafted documents.

10 points for donating patents to the SDO

10 points for each standard implemented during the trial phase in the last 4 years

3 points for proving conformance to the standard by a recognized testing authority in the last 4 years

Then divide the point totals to the log of the company revenue, and you have a the “Standards Engagement Matrix score”

I need to be clear here: this is just a straw man to make people think about how you would score something like this. I’m sure it needs more adjustment around vendor size/income. And you’d absolutely need some kind of adaptive score for the meaningfulness of the SDO itself. And note, of course, that as vendors grow, their organization and business interests broaden, and different parts of the organization could behave differently, so again, there’s no magic bullet here.

But if we had a working consensus on something like this, then providers buying a healthcare EIS could ask, as part of their RFP, ‘what’s your standards engagement matrix score?’, and know that the score is a very good indication of their organizational commitment to excellence. Which is actually more relevant than even vendor financial viability to the long term happiness of the purchaser, in my opinion.

 

p.s. The exact same logic applies to whether providers and institutions are willing to share patient data – it’s a key indicator to their own staff of their commitment to professional excellence, not just short term profit-making. And we should be educating patients about that.

Why participate in the #FHIR Community? (Individuals & Standards)

This blog is the first of series I’m going to run in the lead up to the HL7 San Diego meeting looking at the question of why to participate in the FHIR community. For this first blog, I’m going to look at the question of why to get involved in standards at all at the individual level. (subsequent entries in the series: The vendor engagement matrix, Gender Balance and Participation, …)

A couple of days ago, I was speaking to a well-known high-profile member of the Australian Health Informatics Community – someone who’s given considerable time to the development of the profession, both academically, and to the community. I asked him why he wasn’t involved in standards development. “Not standards!”, he said, with a definite frown.

Indeed, why be involved in standard development?

In some ways, it’s easier to say why it’s better not to be involved: standards work is slow, and involves arcane and myopic focus on small details in the presence of considerable contention about what should be done. Often must deal with toxic people in difficult circumstances – it’s kind of baked into the process. And progress is slow – actually, it’s often opaque whether you’re making any progress at all. What success you do have is often not appreciated outside the standards community (not appreciated, that is, by the people with money who fund your participation one way or another).

But…

There’s an old saying that anything worth doing is costly… and I think that applies to standards. While the work can indeed be arcane and myopic at times, of all the ways to impact the community, standards development is one of the ways that offers the most leverage. Standards can alter behavior, create entirely new arrangements, and transform industries. In the case of health, good protocols for data exchange – and the data standards that underlie them – can make a substantial difference to health outcomes.

I’d love to have more patient/consumer representatives involved in HL7 (though there’s many other venues where you can contribute to data and protocol standards). But when I talk to potential candidates, most can’t imagine being involved in something with such a long term outlook, where you have to do so much work before you get any outcomes… but that’s how you get really deep and meaningful outcomes. I think that’s sad.

So if you’re interested in contributing to the community, in advocating for change in healthcare: think about playing the long game, the one with the big payoffs, and contribute through the development of standards.

 

 

Question: Validity of AllergyIntolerance extension in #FHIR

Question:

How to extend severity in AllergyIntolerance resource.  Is the following resource where severity is extended done correctly?

<AllergyIntolerance xmlns="http://hl7.org/fhir">
  <id value="uWErIN0G0" />
  <recordedDate value="05/10/1980" />
  <patient>
    <reference value="Patient/DFQA_ghn000003" />
    <display value="Newman, Alice Jones" />
  </patient>
  <substance>
    <coding>
      <system value="RxNorm" />
      <code value="1659592" />
    </coding>
    <text value="ampicillin-sulbactam" />
  </substance>
  <status value="confirmed" />
  <event>
    <manifestation>
      <coding />
      <text value="urticaria (hives)" />
    </manifestation>
    <severity>
      <extension url="http://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.3.88.12.3221.6.8">
        <valueCodeableConcept>
          <coding>
            <system value="" />
            <code value="371923003" />
            <display value="mild to moderate" />
          </coding>
        </valueCodeableConcept>
      </extension>
    </severity>
  </event>
</AllergyIntolerance>

Answer:

Severity is a code, with cardinality 0..1 and a required binding to mild | moderate | severe. You can replace the code with an extension, as is done here, so that part is valid. But it’s much better to provide both a code out of the defined choices, so that systems that only know those choices can process the information correctly, while those that know the refined list can process the refined list:

    <severity value="mild">
      <extension url="http://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.3.88.12.3221.6.8">
        <valueCodeableConcept>
          <coding>
            <system value="" />
            <code value="371923003" />
            <display value="mild to moderate" />
          </coding>
        </valueCodeableConcept>
      </extension>
    </severity>

Aside: you could map this code to either mild or moderate, yes. Choosing either is better than choosing neither.

There’s several other issues here, though:

  • The URL given that identifies the extension actually identifies the value set, not the extension (aka the data element). The correct thing to do would be to define an extension that use the value set (see at the bottom of the post)
  • According to the value set definition, this is a SNOMED CT code, and the system should be filled out
  • the recorded date format is not a valid XML date
  • the system for RxNorm is not correct
  • manifestation coding can’t be empty

Here it is corrected:

<AllergyIntolerance xmlns="http://hl7.org/fhir">
  <id value="uWErIN0G0" />
  <recordedDate value="1980-10-05" />
  <patient>
    <reference value="Patient/DFQA_ghn000003" />
    <display value="Newman, Alice Jones" />
  </patient>
  <substance>
    <coding>
      <system value="http://www.nlm.nih.gov/research/umls/rxnorm" />
      <code value="1659592" />
    </coding>
    <text value="ampicillin-sulbactam" />
  </substance>
  <status value="confirmed" />
  <event>
    <manifestation>
      <text value="urticaria (hives)" />
    </manifestation>
    <severity>
      <extension url="http://example.org/fhir/StructureDefinition/my-extension">
        <valueCodeableCoding>
          <system value="http://snomed.info/sct" />
          <code value="371923003" />
          <display value="mild to moderate" />
        </valueCodeableCoding>
      </extension>
    </severity>
  </event>
</AllergyIntolerance>

With an associated Extension definition:

<?xml version="1.0" encoding="utf-8"?>
<StructureDefinition xmlns="http://hl7.org/fhir">
  <meta>
    <lastUpdated value="2017-07-12T07:05:27.311+10:00" />
  </meta>
  <url value="http://example.org/fhir/StructureDefinition/my-extension" />
  <name value="RefinedSeverity" />
  <status value="draft" />
  <date value="2017-07-12T07:02:31.9614187+10:00" />
  <publisher value="Health Intersections" />
  <description value="My definition for FHIR extension" />
  <purpose value="an extension" />
  <fhirVersion value="3.0.1" />
  <kind value="complex-type" />
  <abstract value="false" />
  <contextType value="resource"/> 
  <context value="AllergyIntolerance.event.severity"/> 
  <type value="Extension" />
  <baseDefinition value="http://hl7.org/fhir/StructureDefinition/Extension" />
  <derivation value="constraint" />
  <differential>
    <element id="Extension">
      <path value="Extension" />
      <definition value="This is a description of the level of the severity of the problem." />
    </element>
    <element id="Extension.url">
      <path value="Extension.url" />
      <fixedUri value="http://example.org/fhir/StructureDefinition/my-extension" />
    </element>
    <element id="Extension.value[x]:valueCoding">
      <path value="Extension.valueCoding" />
      <sliceName value="Severity" />
      <type>
        <code value="Coding" />
      </type>
      <binding>
        <strength value="required" />
        <description value="This is a description of the level of the severity of the problem." />
        <valueSetUri value="http://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.113883.3.88.12.3221.6.8" />
      </binding>
    </element>
  </differential>
</StructureDefinition>

Report from joint #openEHR / #FHIR meeting

Last month, the openEHR and FHIR communities met for a day in Norway. From the openEHR community, Ian McNicoll and Silje Ljosland Bakke were present, and from the FHIR community, Ewout Kramer and myself were present, along with a group of Norwegians who are involved in FHIR and/or openEHR. My thanks to HL7 Norway, DIPS (en) and the Direktoratet for e-helse for collaborating to bring the meeting together.

The overall agenda for the day:

  • Welcome, introductions / complaints about the weather (de rigueur, but Norway was lovely, there was even some sun one day)
  • Opening presentations from Ian and myself
  • Discussion on specific model mapping HL7 FHIR – openEHR
  • Discussion on a general form solutions
  • Some general questions on HL7 FHIR – openEHR: Mapping, query, Workflow, Pub/Sub, Terminologies, Modeling

And then drinks afterwards, where we solved all the worlds problems (except for a few big ones).

I enjoyed the day greatly – there was a real positive spirit, based on a recognition that both communities are vibrant productive communities that have much to offer each other. Technically, the FHIR and openEHR communities have different scopes, with some overlap, and there’s plenty of real world problems that FHIR is not attempting to solve that openEHR has invested in – and vice versa. Given good will, and a focus on pragmatic outcomes, we can work well together and both derive benefit from that collaboration.

Given that, most of the day focused on immediate challenges faced by Norwegian implementers today. The most obvious question is ‘I have content described by an archetype, and I want to exchange that using FHIR. How do I go about that?’  Right now, there’s no clean simple answer. There’s several different paths, which work variably well. We discussed some of the issues with a focus on mapping between openEHR and HL7 FHIR of observations like body temperature. The outcome of the discussion is that the place to focus is mapping openEHR templates to/from FHIR Profiles. We’ve created a joint workspace in the openEHR Github repository so we can work together on that (as of today, it’s empty. It’s work in progress and will gradually start to fill up, and hopefully with useful stuff).

The plan is that we’ll automatically convert openEHR archetypes and templates to FHIR Logical models, and then map to FHIR resources using the FHIR Mapping language, and generate profiles and implementation guides from that. If that works well (not yet known), this would establish a single demonstrated path to interoperability. Note that I didn’t say a simple path – to make it simple will require further content reconciliation between the communities – perhaps this will provide the impetus for more investment in that (we’ve done some, but it’s hard work).

Then we discussed the different and similarities of the FHIR and openEHR approaches to forms/questionnaires, and what would be involved to interconvert between the different formats. We agreed to work on this further, including a set of activities on Form Mapping at the FHIR DevDays meeting in Amsterdam in November.

One idea that has been floating around recently is for openEHR to use the FHIR binding syntax and terminology services – we discussed this a little, and hopefully we can work towards a concrete proposal for this in the next few months to see how it flies in the wider openEHR community.

Overall, the meeting created a lot of prospects about what we can do together, but now we actually have to follow up and do them.

p.s. Thanks to Sigurd From from DIPS for keeping notes from the meeting which I used for this report

p.s. Also, thanks to the Norwegians for being great hosts. In addition to Norwegian national day, I enjoyed the fjords greatly. Now I just have to find the right supplier of Fjord Cider here in Australia, and all will be good.

Interconversion between #FHIR and HL7 v2

Question

What advice do you give for introducing FHIR in new software, while continuing to maintain HL7v2 interoperability with client applications that do not speak FHIR?

For example, are FHIR resources the way to go as an internal representation of an application’s health care data?

If yes, is it practical to convert HL7 messages into FHIR resources (e.g. Patient, Practitioner, ProcedureRequest, ReferralRequest, Appointment…)? What open source software do you recommend for converting HL7 messages into FHIR resources (and vice-versa)?

Or is it better to use FHIR for external information exchange only (with outside FHIR clients)?

Answer

I’ve worked with several projects rebuilding their products around FHIR resources. Like all development methodologies, this has pros and  cons. What you get out of the box is a highly interoperable system, and you get a lot of stuff for free. But when your requirements go beyond what’s in the specification, it starts to get hard – FHIR is an interoperability standard, that focuses on the lowest common denominator: what everyone agrees with. Whether that’s a net benefit depends on how far beyond common agreement your going to go. (This, btw, is a demonstration of my 3rd law of interoperability).

It is practical to convert HL7 messages to FHIR resources and vice versa, yes. We’ve seen plenty of that going on. But there’s no canned solution, because to do the conversion, you have to do two things:

  • Figure out all the arcane business logic and information variants and code this into the conversion
  • Figure out how to integrate your conversion logic into your application framework

The upshot of this is that you have a programming problem, and most people solve this by taking a open source libraries for v2 and FHIR in the language of their choice (most languages have one of those) and writing the business logic and application integration in their development language of choice. Hence, there’s no particular open source library to do the job other than the parsers etc. There are some commercial middleware engines that include FHIR as one of the formats that can be supported.

In the FHIR spec, we’ve defined a mapping language that tries to abstract this – so you can separate the business logic from the application integration, and a platform independent business logic that has libraries for whatever platform. That’s an idea that is gradually starting to gather some interest, but is still a long way from maturity.

With regard to using FHIR for external exchange only… what I usually say about this that is that it makes sense to implement FHIR for new things first, and then to replace old things only when they become a problem. And most new stuff is on the periphery, where the architectural advantages to FHIR are really big. But internally, v2 will increasingly become a major service limitation in time, and will have to be replaced. The open question is how long that timeline is. We don’t know yet.