A Student at the 2015 FHIR DevDays Student Track

First of all, I should introduce myself: I’m Ben de Haan, a Medical Informatics student at the University of Amsterdam and the Academic Medical Center.

Sometime in September, I received an invitation for the FHIR Developer Days Student Track in Amsterdam. Being a home game, I decided that at least one team from my university should be present! Joost teamed up with me and we started reading: in preparation for the student track, the folks at Firely asked us to play the ‘Game of APIs’.

More specifically, we should:

  • Pick a smart device
  • Get the device data through its API
  • Map the data to FHIR resources
  • Transform the data into FHIR resources
  • Send the data to a FHIR server

Joost and I decided to use my fitness tracker, a Jawbone UP24. My fitness tracker had died earlier that year, though. Luckily (?), my data was saved online – so we decided to make an API for it.

Sample JSON output from my API
Sample JSON output from our API

The next most important thing was to make our own logo, of course. Being students from the Academic Medical Center, we dubbed our team the ‘Arsonist Medical Center’.

Arsonist Medical Center
Our logo!

Now that we fixed the two most important things, we thought we should try and figure out what this ‘FHIR’ thing actually was. We received a lecture on it previously, but we never found the opportunity to really get acquainted with it. We figured the first thing we should do was to create our first FHIR client. We created and retrieved our first FHIR Patient. Nice!

So, our application had to create a patient and device, and then link the device and patient to an observation. In turn, the observation would contain the measurement. Coffee at the ready, we sat down for some .NET programming.

We didn’t get it working on time though: the FHIR DevDay started November 19th… Turns out, we weren’t the only student team that hadn’t finished everything. Luckily, we all had some time to experiment and talk to the Gurus!

Connectathon time!
Connectathon time!

So our application was able to select and create a patient and a device, and retrieve a measurement in similar fashion. A quick snippet:

// When select button is clicked, select patient
private void selectPatientButton_Click_1(object sender, EventArgs e)
    // Edit status text
    patientSelectStatus.Text = "Selecting...";

    // Search patient based on ID from user input
    var query = new string[] { "_id=" + selectPatientSearchText.Text.Trim() };
    Bundle result = client.Search<Patient>(query);

    // Set the current patient
    currentPatient = ((Patient)result.Entry.FirstOrDefault().Resource);

    // Update selected patient text
    patID.Text = currentPatient.Id;
    patBirthday.Text = currentPatient.BirthDate;
    // Update status text
    patientSelectStatus.Text = "Done!";

Creating, finding and selecting our patient
Creating, finding and selecting our patient

The next task was to convert it all into an observation resource. Doubting whether we should use the ‘Quantity’ or ‘SampledData’ for our measurement value, we chose SampledData – which, as it turns out, was not the way it was intended! This basically was the decisive factor in whether our application was able to handle other people’s data – which it wasn’t :(. Another factor was the decision whether to use ‘effective[x]’  or ‘issued’ as measurement date  in the Observation resource. Some chose to interpret ‘issued’  as the measurement date, but we used the ‘effectiveDateTime’ value because the date a measurement was taken is not per se the date a measurement was made available. We got it working for our own device and we were able to search for the observations from a patient – including other team’s patients!

Finding our observations
Finding our observations

In the end, our application could connect with Firely’s Spark server and James Agnew’s server, but our resources failed validation on Grahame Grieve’s server. We successfully created a patient and device, and linked it with our measurement to form an observation.

In my experience, the server choice does matter. The Firely Spark server and James Agnew’s server do not validate the resources as thoroughly as Grahame Grieve’s server does. The other teams experienced the same issue.

Our application had some other shortcomings as well:

  • We did not validate our resources
  • We did not use a FHIR profile
  • We did not prevent the creation of duplicate patients and devices

At the end of the connectathon, we presented our solution and got to see what the end results from other universities were: a live heartrate monitoring app, a glucose meter interface, an online personal health record… The apps everyone built really demonstrated the versatility of FHIR. However, it also demonstrated how everyone built their applications without paying attention to the exchange of data to other teams’ applications. The lesson here is that if different teams do not communicate with each other, connectivity will be hard to realise – a very illuminating experience!

Time to present!
Time to present!

At the end of the day we went on a cruise through the canals of Amsterdam, and had a taste of the local food and drinks at Hanneke’s Boom and the Bierfabriek!

The canals of Amsterdam!
The 7 bridges canal of Amsterdam

All in all, we enjoyed our experience that day and we will certainly participate again if we have the opportunity!

Some tips for getting started with FHIR:

  1. Use the cheat sheet
  2. Use the HL7 FHIR wiki
  3. Use a FHIR profile. If necessary: create one yourself. This will get you working in a more structured way
  4. If ever you get stuck, StackOverflow has a HL7-FHIR question tag! Most of the time, it suffices to RTFM (pardon my French)
  5. Learn about HTTP headers, and use a tool like fiddler to analyse your requests and responses
  6. Test your application with several servers – they behave differently!
  7. Read The Fhirplace blog! There are two posts by Rob Mulders which helped me a great deal in making my first client and profile 🙂
  8. If you want to send a resource to the server that can actually be used by others, work in a structured way (see #3 🙂 ) and make sure you use the same things for the same purposes (this does not only apply to the ‘Quantity’ and ‘effective[x]’ situations) – communicate!

Post a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.