The Best Standards are Invisible

At 10:54 today I declared success at the FHIR Connectathon.  I had been able to create a SecurityEvent on one of the FHIR Servers, and was certain that I'd be able to use it with at least two others soon enough.  From my perspective, that was the result of starting from code I'd written eight months back, updating it to the current FHIR specifications, and working through how I'd implement generating a Security Event logging a disclosure while accessing data using FHIR.  All in all I added about 200 lines of code to my 400 line application (HTML and JavaScript).

For me, success was less about creating the FHIR resource, or querying a FHIR server for a particular piece of data, and much more about solving a particular workflow problem. It really wasn't about FHIR at all. I spent so much more time thinking about how I wanted to address this problem, and designing the service to work the way I wanted it to than I ever did worrying about the details of FHIR. And that to me is the biggest sign that FHIR will be successful.  It gets our of your (or my) way, and lets you (or me) focus on the real (or externally imposed) problems.

The servers and clients running now in FHIR are crafted in multiple programming languages and platforms, including: Java, TCL, C#, Python, JavaScript, Objective C, Ruby and Grails.  Rarely have I seen an IT standard, let alone a healthcare IT standard, with that much implementation done across that many different languages.  There are at least three different reference servers, one of which is an Open Source effort (via Josh Mandel).

Grahame Grieve, Ewout Kramer, Lloyd McKennzie, Josh Mandel, John Moehrke and many others have done a tremendous amount of work on the FHIR specification.  I look forward to resolving the ballot comments on this specification [something that I rarely say].  I'm getting quite impatient to use it, and thrilled that it has become the basis for the Blue Button Plus REST API Pilot efforts.