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.

 

Lloyd McKenzie on Woody Beeler

Guest post: My close friend Lloyd wanted to share his thoughts on hearing the news about Woody.

My recollections of Woody are similar to Grahame’s.

I started my HL7 international journey in 2000.  In my case, it was in an attempt to understand how I could design my v2 profiles so they would be well aligned with v3.  I quickly learned the foolishness of that notion, but became enamored of the v3 effort.

HL7 was an extremely welcoming organization and Woody played a big part in that welcome.  I was a wet-behind the ears techy from Canada and he was an eminent physician, former organization chair and respected elder of the organization.  Yet he always treated me as an equal.  Over the years, we collaborated on tooling, data models, methodology, processes and the challenges of getting things done in an organization with many diverse viewpoints.  In addition to his sense of humour and willingness to get his hands dirty, I remember Woody for his passion.  He really cared about making interoperability work.  He was willing to listen to anyone who was trying to “solve the problem”, but he had little patience for those who he didn’t sense had similar motivations.

His openness to new ideas is perhaps best exemplified by his reaction to the advent of FHIR.  Woody was one of the founding fathers of v3 and certainly one of its most passionate advocates.  Over his time with HL7, he invested years of his life advocating, developing tools, providing support, educating, guiding the development of methodology and doing whatever else needed to be done.  Given his incredible investment in the v3 standard, it would not be surprising for him to be reluctant to embrace the new up-and-comer that was threatening to upset the applecart.  But he responded to the new development in typical Woody fashion.  He asked probing questions, he evaluated the intended outcomes and considered whether  the proposed path was a feasible and efficient way to satisfy those outcomes.  Once he had satisfied himself with the answers, he embraced the new platform.  Woody took an active role in forming the FHIR governance structures served as one of the first co-chairs of the FHIR govenance board.  To Woody, it was the outcome that mattered, not his ego.

Woody embraced life.  He loved traveling with his wife Selby (and his kids or grandkids when he could).  He loved new challenges.  He loved his work, but he wasn’t afraid to play either.  He was an active participant in after-hours WGM poker games.

It was with reluctance that Woody stepped back from his HL7 activities after his diagnosis with cancer, but as he expressed it at the time, he had discovered that he only had time for two of three important things – fighting his illness, spending time with his family and doing the work he loved with HL7.  He chose the right two priorities.

While version 3 might not have had the success we thought it would when we were developing it, the community that evolved under HL7 v3 and the knowledge we gleaned in that effort has formed the essential foundation and platform that enabled the building of FHIR.  I am grateful to have had Woody in my life – as a mentor, a co-worker and a friend.  I am grateful too for everything he helped build.  Woody’s priority was to focus on really making a difference.  In that he has set the bar very high for the rest of us.

Thank you for everything you’ve done Woody.  We miss you.

Woody Beeler has passed away

Today, Woody Beeler passed away after battling cancer for a few years. Woody was a friend, an inspiration, and my mentor in health care standards, and I’m going to miss him.

I first met Woody in 2001 at my first HL7 meeting. It was Woody who drew me into the HL7 community, and who educated me about the impact that standards could have. Many people at HL7 have told me the same thing – it was Woody that inspired them to become part of the community.

When I remember Woody, I think of his humour, his passion for developing the best standards possible, and his commitment to building the community out of which standards arise. And I remember the way Woody was prepared to roll up his sleeves and get his hands dirty to get the job done. To the point of learning significant new technical skills long after retirement age had come and gone. Truly, a Jedi master at healthcare standards.

For many years, Woody was the v3 project lead for HL7. Woody wasn’t blind to the issues with v3, but it was the best option available to the community at the time – so he gave everything he had to bring v3 to completion.  And it was Woody who mentored me through the early stages of establishing the FHIR community.

It’s my goal that in the FHIR project we’ll keep Woody’s commitment to community and healthcare outcomes – and doing whatever is needed – alive.

Vale Woody

(pic h/t Rene Spronk, who maintains a history of HL7 v3 – see http://ringholm.com/docs/04500_en_History_of_the_HL7_RIM.htm)

FHIR Product Priorities for Release 4

Now that we’ve published Release 3 of FHIR, it’s time for us to consider our main priorities for the next FHIR release. This is my draft list of product priorities that we’ll be discussing – and trying to execute – at the Madrid meeting next week:

  • Normative: push to normative for
    • Foundation / API / XML / JSON / Bundle / OperationOutcome
    • Terminology Service (ValueSet / CodeSystem / ExpansionProfile)
    • StructureDefinition / CapabilityStatement
    • Patient / RelatedPerson / Practitioner / Organization / ?Endpoint
  • Position a core set of clinical resources (‘health base’?) for normative in R5 (or Observation | AllergyIntolerance | MedicationStatement normative for R4?)
  • JSON: ? use manifest for extensions, parameters resource (see blog post) (note that discussion on this didn’t go very well – probably will be dropped)
  • RDF: more ontology bindings + resolve status of JSON-LD
  • Data Analytics: support for a bulk data analysis bridge format (Apache Parquet?)
  • API: better control over retrieving graphs, and value added query support (tabular format?)
  • Patterns: change the W5 framework to a pattern (logical model), tie the patterns to ontology, and use of patterns to drive more consistency (and how to do this without decreasing quality)
  • Services: more services. Candidates: conformance, registry, personal health summary?, etc?
  • Deployment: get a clear standards path for smart on fhir / cds-hooks (and alignment with UMA/Heart)
  • FM: work on alignment between FM resources and the rest of FHIR

Note that this list is written anticipating that the normal standards development process occur, and the content as a whole is maintained. I’d expect that this would amount to 1000s of tasks. So this list is not a list of ‘what will change in R4’, but an indication of where particular focus will be applied by the FHIR leadership (so don’t be concerned if a particular issue of yours is not on this list, as long as it’s in gForge)

Proposal for #FHIR JSON format change: @manifest

There’s a long running discussion in the FHIR community about the way the JSON format handles extensions, and operation invocations (“Parameters”) resource.  Various implementers keep proposing format changes to the JSON format around extensions, but the last time we made an attempt to change this, it was roundly quashed at ballot.

The underlying problem is that there’s 2 different (though overlapping) communities that use the JSON format for FHIR:

  • the interoperability community, who value consistency and robustness
  • the app writing community who value conciseness much more

From the perspective of the second community, the current JSON format doesn’t work well for representing either extensions, or the parameters of an operation. With this in mind, and drawing on the practices of the JSON-LD community, I’d like to advance a proposal for a manifest approach to extensions and parameters in the FHIR JSON format.

The way this would work is that we start with the existing format, and add a “@manifest” property, which contains information about how extensions and parameters have been represented in the json format. Applications reading the JSON format can either read the properties directly, based on their implicit knowledge of the manifest, or read the manifest and process accordingly.

As an example, consider this example Patient resource:

{
  "resourceType": "Patient",
  "id": "ex1",
  "extension": [
    {
      "url": "http://example.org/StructureDefinition/trials",
      "valueCode": "renal"
    }
  ],
  "active": true
}

This uses an extension following as specified in FHIR Release 3. The same resource rendered using a manifest might look like this:

{
  "resourceType": "Patient",
  "id": "ex1",
  "@manifest" : {
    "trials" : {
      "extension" : "http://example.org/StructureDefinition/trials",
      "type" : "code",
      "list" : false
    }
  },
  "trials": "renal",
  "active": true
}

Note: It’s important to note that processing the JSON directly and ignoring the manifest is a convenient but fragile approach; changes in naming or type would be transparent to an application that processed via the manifest, but would likely break an application that processed using the ‘trials’ name directly. That doesn’t mean that applications should not do this; just that it should only be used where the client and server are fairly closely linked and managed.

Aside: I think of this as ‘interoperability’ vs ‘operability’. At heart, FHIR is a specification for an API between disparate systems with different designs and life cycles (and customers – see ‘drive-by interoperability‘). But lots of people are using it as a client/server format for singly maintained applications (often because there’s no strong technical boundary between the internal and external use) – and it’s in that tightly managed context that the manifest approach brings the most benefit with a manageable risk.

It’s also possible to take the manifest and move it out of band:

{
  "resourceType": "Patient",
  "id": "ex1",
  "@manifest" : "http://healthintersections.com.au/patient.manifest.json",
  "trials": "renal",
  "active": true
}

And then, at http://healthintersections.com.au/patient.manifest.json:

{
  "@manifest" : {
    "trials" : {
      "extension" : "http://example.org/StructureDefinition/trials",
      "type" : "code",
      "list" : false
    }
  }
}

Of course, if the manifest is not available at the nominated address, applications that use the manifest will not be able to process the instance correctly – if at all. So that’s an obvious risk that needs to be managed.

Readers familiar with JSON-LD will have seen the obvious similarities with JSON-LD’s @context. We’re not actually using ‘@context‘, though, because while what we are doing is structurally similar, we’re using it for a different purpose.

You could use the same technique with regard to parameters on an operation. Take, for example, this input to the $expand operation:

{
  "ResourceType" : "Parameters",
  "parameter" : [
    {
    "name" : "coding",
    "valueCodeableConcept" : {
      "coding" : {
        "system" : "http://loinc.org",
          "code" : "1963-8",
      "display" : "test"
      }
    }
  },
  {
    "name" : "valueSet",
    "resource": {
      "resourceType" : "ValueSet",
    [etc]
    }
  }
  ]
}

With an in-line manifest, this might look like this:

{
  "ResourceType" : "Parameters",
  "@manifest" : {
    "code" : {
      "parameter" : " http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code#coding",
      "type" : "Coding",
      "list" : false
    }
    "vs" : {
      "parameter" : " http://hl7.org/fhir/OperationDefinition/ValueSet-validate-code#valueSet",
      "type" : "Resource",
      "list" : false
    }
  }
  "code" : {
    "coding" : {
      "system" : "http://loinc.org",
        "code" : "1963-8",
    "display" : "test"
    }
  },
  "vs" : {
      "resourceType" : "ValueSet",
    [etc]
    }
  }
}

Or, we could refer to a manifest defined in the specification itself:

{
  "ResourceType" : "Parameters",
  "@manifest" : "http://hl7.org/fhir/r4/validation.manifest.json",
  "code" : {
    "coding" : {
      "system" : "http://loinc.org",
        "code" : "1963-8",
    "display" : "test"
    }
  },
  "vs" : {
      "resourceType" : "ValueSet",
    [etc]
    }
  }
}

Several Questions I’ve had from the few people who’ve looked at this idea already:

  • Why not do this in XML too? Well, we could. But I don’t think it has value, because people using FHIR in tightly bound client/server type environments (where the @manifest approach is nost beneficical) are almost exclusively using JSON. So the cost/benefit is not there for XML. Also, in XML, schema validation matters more.
  • What about JSON schema then? It’s possible to generate a JSON schema for this, if the generation tooling knows what the manifest is going to say. No such tooling exists right now, but it could be written. Or else someone could easily write a convert to convert from the @manifest form to the existing normal form.
  • What about the reference implementations? They’d be enhanced to support this transparently on read, and there would be some kind of configuration to allow the user to control the manifest, and then it would write according to the manifest.
  • Would this be instead of the existing approach? I propose that it’s an additional approach: the existing extension and parameter format is still valid, and can still be used, but implementations can use the @manifest if they want – and can mix and match. e.g. some extensions represented using @manifest, and others (not known in the manifest) represented the existing way

For follow up / discussion, see fhir.chat.org, though comments here are also welcome.

#FHIR Testing is Coming

The FHIR Team has been working with the HL7 Education Work Group to introduce FHIR certification testing so that members of the FHIR community can demonstrate their knowledge of the specification. There’s going to be 2 levels of certification test.

FHIR Proficiency Test

This test ascertains whether a candidate has basic knowledge of the FHIR specification – what areas it covers, what resources, data types, and profiles are, some basic overview of the way RESTful interfaces work. This test is open to anyone, and it works very much like the existing V2 and CDA tests – though it’s a little easier than them.

Anyone can sit – and pass – this closed book test.

FHIR Professional Credentials 

This is a much harder test – it explores the functionality of the FHIR specification deeply, and to pass it requires considerable experience working with the specification. The idea of this test is that if you pass it, you’ve met our expectations for being an expert and providing advice to other implementers about how to implement the specification properly.

This is an open book test – you have a copy of the specification when sitting it – and it has pre-requisites including demonstrated practical experience in healthcare IT, and ongoing exposure to the FHIR community. The credentialing process will itself be approved by the appropriate authorities so that if you have met the credentialing criteria (including passing the test), you’ll be allowed to put letters after your name. The Professional Credentials will require ongoing maintenance.

Introducing the tests

There’s not a lot of detail here – we’re still working to resolve the process and requirements for the tests. So I can’t tell you, for instance, how much the tests will cost. At least, not at this stage. These details will be released as final decisions are made. The education committee plans to announce the proficiency test at the Madrid HL7 meeting in a few weeks, and then have it available by the September meeting. The Professional Credentials will follow.

At this point, I just wanted to give everyone a heads up about what is coming

Note: Some HL7 insiders have already worked with us prototyping the tests – we thank you for your support, and we’re planning to grandfather you in when the time comes.