Monthly Archives: March 2016

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.