Category Archives: Uncategorized

I want to be a student at Heilbronn

Last week, at the end of the FHIR DevDays, we offered participants a podium to demo their prototypes built or tested during the hackathon part of the DevDays. While there were surprisingly many interesting entries, one in particular struck me: a demo by Simone Heckmann, which showed a message broker turning HL7 v2 messages into FHIR and posting them to a server.

Now, Simone teaches at Hochschule Heilbronn, and she told us that building this message broker is actually part of a student project at the Hochschule. That’s right: Simone uses FHIR to teach her students about interoperability and show them the caveats and real-life problems involved in building connected systems. And that’s only part of her teaching curriculum; in addition to have them map one type of messages to another standard, she also asks her students to select any of the available open-source FHIR clients and servers, play with them for about a month and extend them. And this is just the prelude to the final part of the teaching program: she then organizes a hackathon at the Hochschule where the students bring their pet projects they have been working on and test them against each other.

By the time she reached this point in her story is was almost sure I had misheard. A teaching facility where students not only learn the background on actual interchange standards and terminologies, but where current standards and software are used to get hands-on experience with them and be confronted with the reality of having your software speaking to someone else’s!  Where was she when I was a student?  Okay, “interchange” back then meant calling servers using CORBA and writing IDL, but still!  I know quite some about current teaching methods and I frequently talk to people coming straight out of (medical) IT universities, this is the first time I have heard about a teaching program that takes practical teaching to this level.

As you can understand from my perspective as a FHIR co-designer, I love the idea of combining teaching with bringing practical skills to future interface developers and I am delighted that one of the central tenets of FHIR – focus on implementability and practical use – has found such good use in teaching about interoperability. In fact, I love the idea so much that I’d like to see how we can bring some of the student projects to the Developer Days next year.

See this as a warning to the other participants of next year’s edition of the DevDays: you will have to face the projects from these fresh minds from Heilbronn, showing what you can do with FHIR in just a single semester of teaching. Good luck!

Oh, how I would have loved to be a student at Heilbronn!

Update: I would have become a co-student with Grahame, see Grahame’s blog


Metrics in FHIR, part 1

(This is a guest post by my colleague Martijn, who is implementing FHIR Profile validation for the .NET reference implementation)

As reference implementers of FHIR, we try to fully understand the possible difficulties that future FHIR implementers would encounter. When we can, we try to build the full implementation, including the optionals. We did full monty with the implementation of storing and searching for quantities. Which was not an easy but very interesting path, which I will try to tell you all about in this and the next to blog posts.

To get you up-to-speed, let’s start with a small recap: Quantity is one of the core data types in FHIR. It is used to communicate and store physical measurements. Doctors do it. Nurses do it. And especially laboratories do. A quantity basically consists of a value and the unit that the value expresses. For example [3 liter]. So far so good. Doesn’t look too difficult. The truth is both the value and the unit have a their share of serious challenges.

A unit is not simply a unit, but actually a compound of units with prefixes that have multiplications and  divisions. For example pressure: Kilo Pascal per square meter (kPa/m^2). It gets more complicated: in the US this measurement would be expressed in pounds of force per square inch. The measurement is the same, but value is completely different. Yet in the end we do want to compare them.

As well, a conversion of 1 kilo to 1,000 gram is not a mere multiplication by 1,000. Because a measurement has precision, 1 Kilo Pascal is not the same as 1,000 Pascal. It’s the same as 1e3 Pascal (or 1 times 10 to the power of 3), and the value is 1000 times more precise than 1e3.

In the next two separate posts I will tell you how we dealt with the units and the value issue. If you can’t wait to check it out, take a look at the Metric library, right here

Questionnaires and the Connectathon

At the upcoming May HL7 Workgroup Meeting in Phoenix, we will organize the 6th FHIR Connectathon. Track 2 will focus on Questionnaires, so both client and server developers can test their skills at creating and supporting the Questionnaire resource. As well, David Hay has written additional information about it in his blog.

Basically, the Questionnaire can be used both as a medium to communicate filled-out Questionnaires, but it is conceivable -supported even- to exchange “empty” Questionnaires that don’t contain answers. In that case the Questionnaire contains just the questions, including their text, section headings etcetera. It matches the usual “paper” workflow where you send out an empty form, and get the same form back, but than filled with data. 

Of course, electronic forms can do much more than their paper counterparts, so you can stuff additional design information about a form into an empty form. Examples are graphic make-up, rules about hiding/showing questions depending on answers given and all kinds of validations. In DSTU1 we went for a general approach where Questionnaire’s basic “core” elements focused on supporting the exchange of answers (adding a few extra elements to include headers and prompt texts), but most other “form design” matter was to go into extensions.

One such extension is “answerFormat“. You can use it on a Question component to indicate the kind of answer you’re expecting (string, number, multiplce choice, etc.), and it mirrors the list of “types” people make up when they build eForms systems like SurveyMonkey or Excelsheets with minimal datasets. This data can be used for basic validation and UI building. No doubt you can go more fancy than this, but it should serve as a start.

Another extension is “mayRepeat”, which is only allowed on Groups of questions. The suggestion was that if you look at forms, you’ll often see repeating groups of questions, often layed in tabular form (with the question text in the column header). On the implementers Skype however, the question rose about how you would go about if you’d like a user to give multiple answers to the same question. Are these repeating questions with a single answer? Or one question with multiple answers? 

We concluded that, to stay aligned with the physical counterpart of a Questionnaire, it makes most sense to have multiple answers to a single question. You’re not repeating the question text, nor the header, instead you’re allowing multiple inputs to a question. Multiple answers, however, is not currently supported by Questionnaire’s Question component. To make this work, we are proposing to add an extension “additionalAnswer[x]” of type “decimal | integer | boolean | date | string | dateTime | instant to the “answer[x]” element. This extension works in the same manner as the current  “answer[x]” element which, mostly for technical reasons, was limited to 0..1. This extension may repeat, so you can give multiple answers:

<!-- stuff left out -->
     <system value=""/>
     <code value="228488005"/>
 <text value="What are your favorite colors?"/>
 <answerString value="red">
  <extension url="">
     <valueString value="yellow" />
  <extension url="">
     <valueString value="blue" />

For multiple-choices, you won’t need to use this construction, this is simply done by using the choice element, which may repeat and which represents the coded choices the user made (e.g. one or more codes from LOINC).

Because you’d probably want to limit the number of answers (“name your top three pastimes”), we’ll also add two extension “minCardinality” and “maxCardinality” to Question, both [0..1] of type Integer.

We’ll use these extensions during the connectathon and DSTU1, and any feedback will be fed into the community process leading up to DSTU2.

Authoring FHIR profiles

(and here’s part 2: )

Granted, FHIR Profiles are some of the more complex parts of the HL7 FHIR standard, but also one of the most important ones to learn about if you want to adapt FHIR to your needs and usecases. With profiles you can:

  • Extend the FHIR Resources with your own data elements
  • Provide your own lists of codes to amend or replace the ones given in the standard
  • Limit cardinality on existing data elements
  • Define your own messages and documents

Find out more about Profiles in this presentation I gave at the last HL7 Workgroup Meeting in San Antonio. Thanks to Rene Spronk of Ringholm for taping and publishing this! You can find the slides to this presentation on Slideshare

At the UK hackathon

Today’s HL7 UK connectathon was a first for many of the participants. It was certainly the first European hackathon and for most the first time working with FHIR. For many it was also a renewed acquintance with HL7, especially in the mobile and REST space. “Where were you when we needed you” pretty much sums up the general sentiment, as quite a few participants had resorted to build a home-brewn solution in the past years when requirements asked for a web-ready architecture. I am grateful that the participants took the effort to come to London today to ponder and try replacing their bespoke solutions for a FHIR based one.


Some things I wish to share:

  • Robert Worden built a cross-server search client, that took your query, posted it to the available public servers, and then showed the combined result. Ofcourse, since the query format has changed from FHIR 0.11 (“Boston”) to FHIR 0.12 (“San Antonio”) this didn’t always work out yet, but nice to be able to do in just a day!
  • Two colleagues from the NHS Wales split the work: one built a FHIR adapter on top of v2 PDQ, while the other tried to invoke that service from a set of collaborating Android apps. It showed again that turning a v2 message into a REST resource requires careful thought about how you go about managing REST identities in relation to the available business keys.
  • Robert and his colleague Mark have been working on putting a FHIR wrapper on top of an existing database. Robert, as would be expected, built a mapping tool for this! Practical problem here is that they had a database without primary keys and no timestamping whatsoever. In addition the schema was fixed and the database read-only. Under these circumstances it’s hard to come up with a method to have a reliable version id to use as a FHIR version id, even when you’re allowed to only keep the most recent version.
  • Richard and Prashant of the NHS are all set to start using the full Profile and Conformance infrastructure (REST based validation, Profile editor, automated conformance testing). On their wishlist: a Profile to XSD converter. And documentation of how to create your own Resource (which, of course, is an unsupported practice anyway ;-))
  • There were many Json users, yet no one used Json schema. Which is a good thing, since our latest Json serialization format does not really lend itself to such validation.
  • Vendors working with the NHS are comfortable with the fact they might have to use FHIR for some of the upcoming exchanges. For some, however, the fact that FHIR is an HL7 product seems to take away some of that cautious enhousiasm. Clearly, we’ll have to work on our reputation here!

As usual the hours passed by in the blink of an eye, accompanied by the comforting sound of a humming airco and the hammering of keys. That’s how I like my hackathons!








European FHIR training courses

Rene Spronk and I had fun last week recording videos at Furore headquarters in Amsterdam to promote the 1-day FHIR training courses that I will be giving in various cities around Europe.

So far, we are scheduled to go to Oslo, Amsterdam and London, and other locations are likely to follow. See for a detailed agenda, dates and locations.

It also reminded me of one of the basic rules of video recording: don’t wear a checquered shirt 😉