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 😉

Mapping between CCDA and FHIR

Across the board, many FHIR implementers have the same challenge: mapping between some other format, and a set of FHIR resources. Right now, the pressing issue is mapping between CCDA and FHIR (in both directions). At the HL7 Orlando meeting in January 2016, we held a Birds of a Feather session about mapping. At this meeting, there was general consensus that we – the FHIR community – would like to have a mapping framework that

  • allows us to exchange maps that express detailed transforms from one format to another (in terms of a previous post, executional maps)
  • means that the transforms are portable e.g. the same transform can be run on multiple different system
  • can be shared through a FHIR repository
  • allows to move data into and out of FHIR resources (or between them)

While we were at it, we noted that it would be pretty cool if the language could be used for transforms that didn’t involve FHIR either. And we decided that we’d focus on CCDA <-> FHIR as a primary use case, since that’s an operational issue for so many people. Also, we noted that there’s no existing standard that meets these requirements, or that can easily meet them. MDMI was brought forward as a candidate, but it’s not clear that MDMI solves the problems we usually encounter.

After the meeting, I sat down with Keith Duddy, one of the editors of the other leading candidate specification, which is QVT. After a long discussion about what we were trying to do, and a review of the possible candidates, Keith and I designed a mapping language for FHIR that is very much based on QVT, but leverages a number of design features and philosophies from the existing FHIR work. The work includes an abstract syntax (which is a resource, the StructureMap resource), and a concrete syntax, and a transform host API that delegates implementation specific transformation actions to the host engine. In addition, we’ve prototyped it in the context of CCDA –> FHIR Mapping. Btw, this arrangement means that Keith can take all the credit for the good parts, and I can get the blame for all the other parts.

So this mapping language is published, and open for community review. I expect that there will be robust discussion: is it rich enough? too complex? why do we need to do this? can’t we just use [insert name here]. And maybe there’s some candidate out there we haven’t found… so to help with the evaluation, we’re working on the transform from CCDA to FHIR for the Montreal connectathon.

So here’s an initial contribution to get discussion going:

Download all these, and then you can execute the validator jar with the following parameters:

 ccd.xml -transform -defn 
   -folder [cda structure definitions=] -folder [map files folder] 
   -output bundle.xml

The transform will produce bundle.xml from the CCDA input files. Alternatively, if you want the java source, see org.hl7.fhir.dstu3.utils.Transformer in the FHIR svn

Transform Pseudo Code

To help other implementations along, here’s a bunch of pseudo code for the transform engine (it’s actually pretty simple!). Note that to use this, you need to two things:

Object model – both the source object model, and a target object model express the same meta-level API, which has the following features:

  • – list children (name) returns list of Value : given a name, return all the children that have the given name
  • – make child (name) returns Value: create the appropriate object, and return it (can’t be used if the object is polymorphic)
  • – create (typename) returns Value: create an object of the specified type name (type name comes from the mapping language)
  • – set property(name, Value): set the property name to value. if name is cardinality 0..*, add to the list

And then you need a FluentPath engine that compiles and evaluates fluent path expressions:

  • – parse(string) returns expression: parse the string expression
  • – evalute(expression, Value) returns boolen: apply the expression to a value, and see whether it is true or not

Here’s the logic for the structure map transform

 transform(Value src, StructureMap map, Value tgt)
   create new variables 
   add src as new variable "src" in mode source to variables 
   add tgt as new variable "tgt" in mode target to variables 
   run transform by group (first group in map)
 transform by group(group, variables)
   transform for each rule in the group
 transform by rule(rule, variables)
   clone the variables (make us a new copy so changes don't propagate backwards)
   check there's only one source (we don't handle multiple sources yet)
   for each matching source element (see logic below - a list of variables)
     - for each target, apply the targets
     - for each nested rule, transform by rule using the variables
     - for each dependent rule, apply the dependent rule
 processing dependent rules
   look through the current map for a matching rule (by name)
   look through all the other known maps (in the library) for a matching group (by name)
   if match count != 0, it's an error
   check the variable cont provided matches the variable count expected by the group (and check whether they are source or target)
   make a new variables
   for each parameter, get the variable given the name, and add it to the new variables (in order)
   transform by the group using the new variables
 Finding Match Source Elements(source, variables)
   get the source variable with the name "source.context"
     - check it's not null (error if it is)
   if there's a condition, get the fluent path engine to check it against the source variable
     - if it fails, return an empty list
   if there's a check, get the fluent path engine to check it against the source variable
     - if it fails, blow up with some error message

   if there's a source.element
     get a list of the children with the name source.element from the source variable
     turn the source variable into a list
   for each element in the list from the previous step, 
     clone source variables
     if there's a source.variable, add the element as to the cloned variable list using the source.element name
     add the closed variable list to the results
   return the results
 Apply a target(target, variables)
   get the target variable with the name "target.context"
     - check it's not null (error if it is)
   check there's an element (todo: support this)
   if there's a transform 
     value = run the tranform
     set the given name on the target variable to the value
     value = make the given name on the target variable
 Run the transform(parameters, vars)
   depends on the transform:
   create: ask the object API to create an object of the type in parameter 1
   copy: return the value of parameter 1 (see below)
   evaluate: use the fluent path engine to execute aginst the p value of 
     parameter 1 using the string value of parameter 2 as the expression
   pointer: return the correct URL to reference the object that is the value of parameter 1 
     - which is right is a deployment decision

 The value of a parameter
   if it's an id (e.g. not a constant, just a word)
     then it's a reference to the named variable
     it's some kind of constant 

New #FHIR Vital Signs Profile

Over on the official FHR product blog, I just announced a new release. I wanted to expand on one of the features in the new version here

A new profile to describe vital signs (note: this is proposed as mandatory to enable better data sharing)

One of the emerging themes in many countries is sharing data with patients. And one of the broad set of things called ‘health data’ that is easiest to share is what is loosely called ‘vital signs’. It’s simple data, it’s easy to share with the patients, and we’re starting to see monitoring devices available in mainstream consumer technology. But it’s more than just patients that care – vital signs data is widely shared through the healthcare provision system, and there’s lots of interesting decision support and surveillance that can usefully be done with them.

But if every different part of the healthcare system, or different jurisdictions, represent basic vital signs differently, there’ll be no way to easily share decision support and survelliance systems, nor will patients be able to share their healthcare data with common data management tools – which are cross-jurisdictional (e.g. things like healthkit/carekit).  With this in mind, we’ve defined a vital signs profile in the new draft of FHIR, and said that all vital signs must conform to it. It doesn’t say much:

  • The common vital signs must be marked with a common generic LOINC code, in addition to whatever other codes you want to give them
  • There must be a value or a data absent reason
  • There must be a subject for the observations
  • Systolic/Diastolic must be represented using components
  • The units must be a particular UCUM unit

This is as minimal a floor as we can get: defining a common way to recognize a vital sign measurement, and a common unit for them. None of this restricts what else can be done, so this is really very minimal.

For FHIR, this is a very gentle step towards being proscriptive about how healthcare data is represented. But even this looks likely to generate fierce debate within the implementer community, some of whom don’t see the data sharing need as particularly important or near in the future. I’m writing this post to draw everyone’s attention to this, to ensure we get a good wide debate about this idea.

Note: it’s a proposal, in a candidate standard. It has to get through ballot before it’s actually mandatory.


(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

Announcement: #FHIR Code-a-thon Washington DC April 1/2

An announcement from CMS/HHS Entrepreneur-in-Residence and FHIR community member Mark Scrimshire:
I wanted to let you know that we are preparing a FHIR Code-a-thon in Washington DC on Friday April 1st and Saturday April 2nd. We have Susannah Fox opening the event and the Code-a-thon will see the first public access to a prototype CMS Blue Button on FHIR data API. We are busy readying a synthetic data set to make available through the API.
It would be great if you could let fellow Argonauts, and other interested parties, know about our event. Advanced registration is required. People can sign up at
The winners of the FHIR Code-a-thon will receive tickets to the Health Data Palooza where they will have the opportunity to demonstrate their winning solution.


I’d say that I’d see you there, but I’m afraid I’ll be surfing in Samoa on those days  – sorry.

Question: Locating the #FHIR end-point


I have been trying to develop FHIR app using your API. The url “” doesnt return me list of patients. Am i hitting the right URL?


No. and in fact, this trips lots of people over for lots of servers. Very often, the link provided to the server is a reference to a web page that describes the various end-points the server offers, and the security details for them. For instance, my server offers 2 end points –, which anyone can use, and, which requires authorization via Smart on FHIR.

So the url you’re looking for is


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.

IEEE Event: Health Informatics on #FHIR

Health Informatics on FHIR: Opportunities in the New Age of Interoperability

A half day, pre-HIMSS Workshop on Saturday February 27th from 9:30 – 12:30 Westin Las Vegas Hotel, Casino & Spa

Organizers: Professors May Wang, PhD Professor ( and Mark Braunstein, MD Professor of the Practice ( – Georgia Tech

Keynote: Charles Jaffe, MD, PhD, CEO of HL7: Toward a Global Health Interoperability Standard (30 minutes)

Panel 1: The FHIR Standard (90 minutes – Moderator: Mark Braunstein) + Panel Discussion / Q&A

  • Grahame Grieve, HL7 FHIR Project Leader: Toward Global Interoperability through the FHIR Standard
  • Josh Mandel, MD Lead Architect for the SMART on FHIR project, Harvard Boston Childrens Hospital: FHIR as a Universal App Platform
  • Charles Jaffe: The Argonaut Project

Panel 2: Healthcare in the Age of Interoperability (90 minutes – Moderator: May Wang) + Panel Discussion / Q&A

  • Robert A Greenes, MD, PhD, Professor, Biomedical Informatics, Arizona State University (co-author Aziz Boxwala, MD, PhD, Meliorix Inc, and mWorksHealth, Inc, La Jolla, CA): Enabling Patient-Centered Care by Liberating Data.
  • Jimeng Sun, PhD, Associate Professor, School of Computational Science and Engineering, Georgia Tech: FHIR-based Clinical Decision Support: An Epilepsy Case Study.
  • Paula Braun, MS Data Science Entrepreneur, CDC: FHIR and Public Health: Death Reporting Case Study
  • Gil Alterovitz, PhD, Harvard/MIT Health Sciences and Technology Division Children’s Hospital Informatics Program: SMART on FHIR Genomics

In addition, there will be up to five poster presentations available to the audience.

See IEEE page for  registration


Patient Matching on #FHIR Event at HIMSS

In a couple of weeks I’m off to HIMSS at Los Vegas. I’m certainly going to be busy while I’m there (If you’re hoping to talk to me, it would be best to email me to set up a time). Before HIMSS, there’s several satellite events:

  • Saturday: Health Informatics on FHIR: Opportunities in the New Age of Interoperability (IEEE)
  • Sunday: Patient Matching on FHIR event (HIMSS)
  • Monday: First joint meeting between HEART/UMA & FHIR/SMART teams – if you want to attend this meeting, let me know by email (there’s a couple of places still open)

About the Sunday meeting, quoting from the announcement:

Previous work included a Patient Testing Matching Event on this idea was developed at an event in Cleveland, OH on August 14th, 2015 at the HIMSS Innovation Center.  The event covered a tutorial on FHIR along with sessions on patient matching.  A key takeaway from the event was that the healthcare community can advance interoperability by working on a standard Application Programming Interface (API) for master patient index software, commonly used to facilitate patient data matching.

In fulfillment of this vision, we are hosting this second Patient Matching on FHIR Workshop in conjunction with the HIMSS 16 Annual Conference in Las Vegas.  We invite:

─         Algorithm vendors
─         EMR vendors,
─         Developers and standards experts
─         All interested parties

So, here’s passing on the invitation – see you there!

ps. I’ll pass on information about the IEEE event when I get a link.