Light My FHIR

One of the most significant claims made by FHIR is out-of-the-box interoperability (see the one page glossy summary on FHIR). This is only true for a weak definition of interoperability. Any well-formed FHIR resource can be parsed by any compliant FHIR application, but this doesn’t mean the receiver can understand and employ that information computationally. For that to happen, the exchanging parties need to agree in advance on terminology, extensions, cardinality restrictions, and more.

Continue reading →

In a prior post I proposed an alternate XML syntax for FHIR extensions that is based on the use of XML namespaces. JSON doesn’t natively support namespaces so how can this work?

Continue reading →

In an earlier post Mark reviewed some proposed requirements for the syntax of FHIR extensions and how the previously considered alternatives align with those goals. In this post I’m going to describe an additional alternative that I’d like to submit for consideration. I’m going to focus on the XML syntax in this post but a subsequent post will address the JSON representation.

Continue reading →

There has been a lot discussion on the Skype Implementers channel and other forums about FHIR Transactions, specifically the rules around HTTP POST and the use of Bundle.entry.fullUrl and Bundle.entry.resource.{resourceType}.id, and how servers should behave.

Continue reading →

In the last post, I took up Grahame’s request for feedback on possible alternative syntax for extensions. To review, the goal would be to eliminate the use of the <extension> tag and use readable names, similar to the way core elements are represented. It may or may not be possible to improve on the current representation, but it is worth investigating. In the last post, I listed the following requirements:

Continue reading →

Recently, Grahame posted a request on his blog requesting feedback on how FHIR represents extensions (http://www.healthintersections.com.au/?p=2467). Currently, all extensions appear under <extension> tags. This makes the wire format hard to read, particularly when there are nested extensions. The worst-case scenario involves using the Basic resource to create a new profile built entirely of extensions, resulting in definitions and instances with deeply nested <extension> tags and lacking of readable names, falling short of FHIR’s goal of “a human-readable wire format for ease of use by developers.”

Continue reading →

Welcome to the LightMyFHIR blog. For several years, folks at MITRE Corporation have been working with and working on FHIR. We have many experiences to share with the broader FHIR community. This blog is one of the ways the MITRE team will be sharing our ideas, suggestions, creations, and conniptions.

Continue reading →