Category Archives: Question

Interconversion between #FHIR and HL7 v2


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)?


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.


Question: CCDA and milliseconds in timestamp


We are exchanging CCDs over an  HIE. While consuming a CCD from a particular partner, we are having issues parsing the dates provided in the CCD. Most often, we cannot process the effectiveTime in various sections of the CCD.

We have been told that our partner is using a C-CDA conformant CCD. The CCD parser on our side cannot handle any of the effectiveTime values which contain milliseconds, such as:
<effectiveTime value=”20170217194506.075″/>

Our vendor informed us that:

“The schema you referenced (for a CCD) is the general data type specification for CDA. There are additional implementation documents that further constrain the data that should be reported. For example, the sections shown below are from the HL7 Implementation Guide for Consolidated CDA Release 1.1. As you can see, a US Realm date/time field (which includes the ClinicalDocument/effectiveTime element) allows for precision to the second.
The guides for other CCD implementations – C32, C-CDA R2.0, etc. – include identical constraints for /ClinicalDocument/effectiveTime. These constraints are the basis for our assertion that milliseconds are not acceptable in ClinicalDocument/effectiveTime/@value.”

The schemas provided for C-CDA and CDA do allow for a milliseconds value, according to their RegEx pattern. The CCDA schematrons have notes that specify:

The content of time SHALL be a conformant US Realm Date and Time (DTM.US.FIELDED) (2.16.840.1.113883.

Even though the schematron may not have the checks to flag a millisecond value, they do make that statement, which does not allow for milliseconds.

Please provide guidance on whether milliseconds are acceptable in C-CDAs and/or CCDs.  If milliseconds are not allowed, then why don’t the schemas/schematrons trigger errors when millisecond values are found?


Firstly, some background: The CDA schema is a general schema that applies to all use of the CDA specification anywhere. So the schema allows milliseconds. CCDA is a specification that builds on CDA to make further restrictions. Most of these can’t be stated in schema (because schema does not allow for different content models for elements with the same name). So these extra constraints are made as schematron, so they can also be tested for CCDA documents.

The CCDA specification says, concerning date times, that they SHALL conform to DTM.US.FIELDED, and about dates like that, it says:

1. SHALL be precise to the day (CONF:81-10078).

2. SHOULD be precise to the minute (CONF:81-10079).

3. MAY be precise to the second (CONF:81-10080).

4. If more precise than day, SHOULD include time-zone offset (CONF:81-10081).

It sure sounds like you can’t use milliseconds. But, unfortunately, that’s a wrong interpretation. The DTM.US.FIELDED template on TS is an ‘open template’ which means that anything not explicitly prohibited is allowed.

Since milliseconds are not explicitly prohibited, they are allowed.

(Yes, you can then ask, why say “MAY be precise to the second”? this is careless language for a specification, and creates exactly this kind of trouble)

Note: this answer comes from Calvin Beebe (coming HL7 chair) on the HL7 Structured Documents Email List, and I’m just archiving the answer here so it can be found from search engines.

Question: Apple CareKit and #FHIR


I am very new to FHIR and now i am trying the find out equivalent resource for  Apple carekit data. I think i can use FHIR Careplan & Goal for the CareKit data. Is that right?


I’ve not done any work with CareKit, but Apple suggested I talk to Seth Berkowitz at BIDMC, who says:

CareKit is a set of UI and database components that provide a framework to display careplans, collect patient generated data, provide insightful feedback to and from patients via their iOS phones.  By leveraging simple game mechanics and Apple’s design ethos, the UI components of CareKit help motivate patients to comply with their daily medications and activities as part of their care plan.  The assessment component streamlines the collection of subjective and objective data from patients using the phone as middleware. Objective data collection is facilitated through HealthKit, which is Apple’s centralized database on it’s phones that facilitates the sharing of objective health metrics in between apps.  The last component of carekit is a communication module that helps patients share their care plans and results with friends, family, and medical professionals

BIDMC we are integrating our CareKit app directly into our homebuilt EHR so that the app becomes a direct conduit of prescriptions and orders from doctor to patient, and patient generated data from patient to doctor.  Although our short term goal is to benefit our own population of patients, we share Apple’s long term vision of widely disseminating these engaging apps.  To that end, we are trying to leverage FHIR APIs as much as possible to serve as the connections between our EHR and the App.  The hope is that Apps like this serve as a “carrot” to promote more widespread adoption of the FHIR standard.  Our two main APIs using FHIR are a medication search bundle and CarePlan resource.  Our medication bundle leverages our institutions participation in the Argonaut projects

CareKit encompasses several functions which pose potential FHIR interfaces for data download and upload.  To date, my group has focused on leveraging FHIR for data download in order to populate the CareKit “CareCard” (a patient check list of careplan activities) and Carekit “Assessment” or subjective and objective measurements collected on the phone. An overarching question that we’ve been trying to solve is how encode UI / implementation specific data fields within the appropriate FHIR schema.  For example, a careplan activity in carekit is displayed with a title, a subtitle, and more detailed instructions.  For each careplan activity I’ve been using the following mapping

  • Title: activity.detail.code.text
  • Subtitle:  activity.detail.goal (either display or description of a contained resource)
  • Instructions: activity.detail.description

For quantitative measurements that are collected on the phone through the HealthKit database, I define an “observation” activity within the careplan.  The activity.detail.code.coding array defines a LOINC codable concept which is then mapped to Apple’s internal reference system for various physiological measurements (heart rate, blood pressure, daily sodium intake, etc)

Finally, we define certain alert conditions that may prompt a message to the patient after a measurement is obtained.  These alerts are implemented as an extension to the activity.detail.goal.  The extension includes a valueQuantity which is the threshold that triggers the alert and a referenced Flag resource which is the alert prompt to the user.

There’s much more to be done to build an end-to-end CareKit FHIR interface, but that’s what we’ve been working on so far.

Thanks to Seth and also to Pascal Pfiffner, who’s been a trail blazer with regard to FHIR use on iOS (and who maintains the FHIR Swift reference implementation).

Seth noted that with the careplan resource, it feels like they’re pushing the limits of how the careplan is being used in practice – and indeed, that’s true. There’s a lot of active projects using FHIR as the format for exchange underlying shared care/ collaborative care projects that involve the patient, and their various care teams: family, professional, social etc., and this is a new – exciting! – area where there’s not a lot of established knowledge, culture, and practice for us to fall back on. So implementers should expect more change in this area than in the well established ones (patient management, diagnostics, medication administration, billing).

Question: How do profiles fit into the overall conformance picture


How are Conformance Resource and Implementation Guide (IG) resources are linked? I understand usage of both but how both will be linked to create Profiling.  Not clear about using both of them, what scenario or use case would be that?


Well the conformance resource includes server capability or client desire for server capability and also includes what all actual Resources are supported, and links to what profiles are (or should be) supported on the system. So the conformance statement ‘creates’ profiling by making it clear what profiles the system supports.

ImplementationGuide is a primarily a publishing thing – publishing a group of conformance statements and profiles, with their supporting value sets etc, in a single logical group, with a single identifier.  The implementation guide may – and commonly does, but not always – include one of more conformance statements as examples, or requirements. So it ‘creates’ profiling by allowing for publication of  group of conformance statements and profiles. So it’s primary function is to establish logical groups of profiles.

Most uses of Implementation Guide will be publishing national standards, or project agreements (projects such as argonaut) rather than server level publishing.




Question: where did the v2 messages and events go in FHIR?


I’m relatively new to the HL7 scene having implemented a few V2 messaging solutions (A08 , A19, ORU) and the V3/CDA work on PCEHR.  I am trying to get my head around FHIR.  So far I am stumped in how I would go about for example implementing the various trigger/messages I have done in V2.  Is there any guidance?  I cant find much.  Is that because the objective of FHIR is implementers are free to do it anyway they like?  If you could send me some links that would be a good starting point that would be great


Most implementers of FHIR use the RESTful interface. In this approach, there’s no messaging events: you just post the Patient, Encounter etc resources directly to the server. The resources contain the new state of the Patient/Encounter etc, and the server (or any system subscribed to the server) infers the events as needed.

A few implementers use the messaging approach. In this case, the architecture works like v2 messaging, with triggers, and events. However, because the resources are inherently richer than the equivalent v2 segments (e.g. see, we didn’t need to define a whole set of A** messages, like in V3. Instead, there’s just “admin-notify” in the event list.

For XDS users (HIE or the PCEHR in Australia), see IHE’s Mobile Health Document Specification.


Question: Searching by extensions in #FHIR


My concern relates to search resources by extensions. I have read a lot about extensions and profiles, but the processing I have never seen.

If I need a new field on patient, like eye color, I’ve the option to extend the standard patient resource and add the new property. Persisting and loading via ID is quite easy. But how is the best way to realize a searching for patients with the new eye color value? Is there ever a solution?

Btw: I’m using the awesome HAPI from James Agnew.


This is a question that comes up occasionally because the answer is buried in the spec. When you search a resource, you nominate one or more parameters to search by. In the specification, we define a basic set of search parameters, the ones we think will come up in practice. Servers can decide which of these to support, and define their own additional ones.

Note that the parameters are not direct queries into the resource – they are a name that identifies a path into the resource. The idea is that you can use some kind of map-reduce approach to generate the indexes, or map to an existing index you already have. So for patient, the search parameter “given” is actually a search onto the path The ‘path’ there is actually a fluent path expression – and finally, in the latest version of the spec, we have all the ducks in a row to make that formal and explicit.

So to search an extension, the server defines a name – say, ‘eyecolor’ in your case – and generates the index based on the expression Patient.extension(“your-extension-url”). It’s completely transparent to the client where the search parameter refers to unless the server publishes it’s search parameter definitions, and the client processes them.

Oh – but you’ll want to know how to actually do that in HAPI – you’ll have to ask on the HAPI support forum. Btw, yes, both HAPI and James are awesome 😉

(When) Will #FHIR replace HL7 v2 messaging?


I’m working in the healthcare domain and has been hearing the FHIR developments for a while. In my hospital setting, we typically have a Patient Registration System, a EMR system, a LIS and RIS system, and some machine interface (Vital Signs, BMI). We are communicating with each other using HL7 V2 standard and is working fine.

My question is, how does the development of FHIR helps in existing interfaces? Do we need to eventually replace these interfaces with FHIR? If yes, all vendors of the respective systems needs to be FHIR ready.

I like to believe that FHIR is for a future expansion packs, and not a move to replace all existing interfaces. Meaning HL7 V2 are expected to stay.  Another question: In HL7, we dealt with messaging in asynchronous mode. But the FHIR standards, we are moving from the messaging world?


This is a pretty frequently asked question – I got it fairly often at HIMSS last week. My standard answer is:

You don’t fix what isn’t broken, so initially, no one will replace v2 messaging interfaces with FHIR interfaces. Instead, institutions will use FHIR on their perimeter, for integration between enterprises.

I say that because FHIR is able to leverage all sorts of web standards, so it’s naturally a better choice than v2 from that point of view alone, and also because this is where all the action currently is, and why would you use v2 now? Most people I hear from are using FHIR in preference to v2 even though FHIR is still a moving target.

But once that’s in place, institutions will increasingly find that what they can do on the perimeter interfaces is constrained by what the internal services can provide – and then they’ll start gradually replacing their v2 interfaces with FHIR interfaces.


Using #FHIR Observations for User fitness data

In a question on stack overflow, an implementer asks about using Observation for user -gathered fitness data:

While there is the Observation resource, this still seems best fit (!) for the EHR domain. In particular the user fitness data is not collected during a visit and is not human-verified.

The goal is to find a “standardized FIHR way” to model this sort of data.

Use an Observation (?) with Extensions? Profiles? Domain-specific rules? FHIR allows extraordinary flexibility, but each extension/profile may increase the cost of being able to exchange the resource directly later. An explanation on the appropriate use of a FHIR resource – including when to Extend, use Profiles/tags, or encode differentiation via Coded values – would be useful.

There’s no need to use extensions, but there is a need for domain specific rules. Use an observation that looks like this:

  "resourceType": "Observation",
  "text": {
    "status": "generated", 
    "div": "<div>[name] : [value] [hunits] @ [date]</div>"
  "status": "final",
  "category": {
    "coding": [
        "system": "",
        "code": "fitness",
        "display": "Fitness Data"
  "code": {
    "coding": [
        "system": "",
        "code": "[lcode]",
        "display": "[...]"
        "system": "",
        "code": "[scode]",
        "display": "[...]"
  "subject": {
    "reference": "Patient/[xxx]"
  "effectiveDateTime" : "[when]",
  "valueQuantity": {
    "value": [value],
    "unit": "[hunits]",
    "system": "",
    "code": "[units]"

Some notes about this:

  • A couple of the measurements need an effectivePeriod instead of an effectiveDateTime
  • it might not be necessary SNOMED CT and LOINC codes, but it’s probably useful to have both (where they’re defined)
  • [name], [scode], [lcode] and [units] come from a row in the table below. other values [value], [hunits], [when] come from the data source
  • the category code is new. I’ll create a task to add it to the specification
Description SNOMED CT Code LOINC Code UCUM Units
Ambient temperature 250825003 60832-3 Cel; [degF]
Blood Glucose 365812005 77145-1 / 74774-1 mmol/L or mg/dL
Blood Pressure 75367002 55417-0
   Systolic 271649006 8480-6

standing: 8460-8

   Diastolic 271650006 8462-4

standing: 8454-1
sitting: 8453-3
lying downlying down: 8455-8

Body Fat % 248300009? 41982-0 %
Body Height 50373000 8302-2 m; cm; [in_i]
BMI 60621009 39156-5 kg/m2
Body Temperature 386725007 8310-5 Cel; [degF]
Body Weight 363808001 29463-7 kg; [lb]
Breath CO 251900003 (none) [ppm]
Calories Burned (none) 41981-2 kcal; J
Expiratory Time 250820008 65819-5 s
Heart Rate 78564009 8867-4

standing: 69001-6
sitting: 69000-8
lying down: 68999-2

{beats}/min; /min
Inspiratory Time 250819002 60740-8 s
Minutes of Moderate Activity (none) (none)
Minute Volume 250811004 20142-6 (use duration) L
O2 Saturation 431314004 20564-1 %
Respiratory Rate 86290005 9279-1 {breaths}/min; /min
Sleep Duration 248263006 n/a h
Step Count n/a 55423-8

If you’re looking for additional rows not in the table, send me a data element name and a definition, and I’ll add it to the table. I’ll also propose adding this table to the FHIR specification

Question: #FHIR conformance requirements


  • status has a cardinality of 0..1 , but it is mentioned as required under Description.
  • Similarly, rest/resource/searchParam/modifier  has cardinality of 0..* which means optional, but it is mentioned as required under Description.

Should I go by the cardinality of these elements?


Conformance Status does have a cardinality of 0..1. None of us know why it’s 0..1 not 1..1 like all the other conformance resources. See gForge task 9581.

But the ‘required’ under description for all of these elements refers to the value set binding – if you have one of these elements, it is required to come from one of the specified codes in the valueset. So, yes, you should go by the stated cardinality.

Question: #FHIR Common Search Parameters


I am working on fhir based rest server. I have already implemented create, delete, read, update, and history services. I am working on search service and i have some difficulties to understand what exactly do parameters mean especially common parameters. For example _text,_content,_list,_query. Can you give me more specified examples please?



GET [base]/Condition?_text=(bone OR liver) and metastases

This example from the specification shows how you could search the xhtml content of the narrative for the word ‘metastases’ and either ‘bone’ or ‘liver’. The expectation is that your server will pass the narrative to an indexing engine (typically, either Lucene, Solr, or Microsoft SQL Text Indexer) and that when a search specifies the _text parameter, the parameter value will be passed to the search engine as is. The trick is integrating the search engine with the other search parameters, but solving that is out of scope for my blog.


This is nearly the same as the _text resource, except instead of the narrative, it searches the entire text of the resource – that is, the xhtml and all the primitive values. You have to assemble this yourself somehow and pass it to the search engine. I don’t think many implementers have done this one.


This is a short cut to allow you to search for resources that are in some list. There’s 2 main use cases for this – when a list is being used to track an ad-hoc selection of resources, such as a clinically interesting patient list, the _list parameter lets you search through only the items in that list. The other use is for EHRs or other clinical systems that maintain ‘current lists’, such as ‘current medication list’ or ‘current problem list’ – a way to search those current lists only.


This is for when the server wants to define it’s own search that works differently to the normal search. If the server sees a _query parameter, it cannot ignore it, since the parameters may not have the normal meaning. When a server defines it’s own kind of query, it can use the rest of the parameters however it wants. The FHIR specification defines one of these, for MPI Search