Monthly Archives: November 2015

FHIR Notepad++ Plug-in: Tools for #FHIR developers

I’m pleased to announce that the FHIR Plug-in for Notepad++ that was distributed and tested at the DevDays in Amsterdam last week is now ready for general release.

Notepad++ is a powerful text editor that’s pretty popular with developers – it seems most of us who use windows use it. And it has a flexible and powerful plug-in framework with an active community around that. So it was the logical choice for a set of FHIR tools. The FHIR tools themselves offer useful functionality for FHIR developers (programmers, analysts), based on the kinds of things that we need to do at connectathons or for authoring content for the specification.

ToolBox

toolbar

The FHIR Toolbox makes the following functionality available:

  • XML / JSON interconversion
  • Interactive and background resource validation
  • FHIR Path execution and debugging (more on that in a subsequent post)
  • Create a new populated resource from its definition (or a profile on it)
  • Connect to a server (including Smart-on-FHIR servers)
  • Create a new populated resource from its definition (or a profile on it)
  • Open a resource from a server
  • PUT/POST a resource to a server
  • Narrative generation

Visualizer

visualizer

In addition, there’s a visualizer provided. This shows the following kind of information:

  • Narrative for the resource
  • Validation and Path execution results
  • Information about the current element (e.g. viewer for attachments, codes, references)

Note that the FHIR Plug-in doesn’t provide syntax highlighting for XML or JSON – there’s other plug-ins for them.

Additional Notes:

  • The FHIR tools are based on DSTU2
  • There is ongoing active development of the plug-in, so expect glitches and bugs (report bugs using my FHIRServer Github project)
  • To get notified of updates, subscribe to the RSS link from the downloads page. Or the plug-in itself will notify when a new version is released
  • yes, Notepad++ is only available for windows. For OSX developers, well, you can get a windows VM. It’s unlikely that it will be feasible to port the tools to OSX
  • For further documentation, see the Wiki page

 

Language Localization in #FHIR

Several people have asked about the degree of language localization in FHIR, and what language customizations are available.

Specification

The specification itself is published and balloted in English (US). All of our focus is on getting that one language correct.

There are a couple of projects to translate this to other languages: Russian  and  Japanese, but neither of these have gone very far, and to do it properly would be a massive task. We would consider tooling in the core build to make this easier (well, possible) but it’s not a focus for us.

One consequence of the way the specification works is that the element names (in either JSON or XML) are in english. We think that’s ok because they are only references into the specification; they’re never meant to be meaningful to any one other than a user of the specification itself.

Codes & Elements

What is interesting to us is publishing alternate language phrases to describe the codes defined in FHIR code systems, and the elements defined in FHIR resources. These are text phrases that do appear to the end-user, so it’s meaningful to provide these.

A Code System defined in a value set has a set of designations for each code, and these designations have a language on them:

code system

Not only have we defined this structure, we’ve managed to provide Dutch and German translations for the HL7 v2 tables. However, at present, these are all we have. We have the tooling to add more, it’s just a question of the HL7 Affiliates deciding to contribute the content.

For the elements (fields) defined as part of the resources, we’d happily add translations of these too, though there’s no native support for this in the StructureDefinition, so it would need an extension. However no one has contributed content like this yet.

It’s not necessary to do this as part of the specification (though doing it there provides the most visibility and distribution), though we haven’t defined any formal structure for a language pack. If there’s interest, this is something we could do in the future.

Useful Phrases

There’s also a source file that has a set of common phrases – particularly error phrases (which do get displayed to the user) – in multiple languages. This is available as part of the specification. Some of the public test servers use these messages when responding to requests.

Note that we’ve been asked to allow this to be authored through a web site that does translations – we’d be happy to do support this, if we found one that had an acceptable license, could be used for free, and had an API so we could download the latest translations as part of the build (I haven’t seen any service that has those features)

Multi-language support in resources

There’s no explicit support for multi-language representation in resources other than for value set. Our experience is that while mixed language content occurs occasionally, it’s usually done informally, in the narrative, and rarely formally tracked. So far, we’ve been happy to leave that as an extension, though there is ongoing discussion about that.

The one place that we know of language being commonly tracked as part of a resource is in document references, with a set of form letters (e.g. procedure preparation notes) in multiple languages. For this reason, the DocumentReference resource as a language for the document it refers to (content.language).

#FHIR DevDays Amsterdam 2015

In two weeks time – Nov 18 2015 – I will be joining Ewout Kramer from Furore in Amsterdam – along with other core team members James Agnew, Josh Mandel, Lloyd Mckenzie – for the Furore #FHIR DevDays 2015. I’m really looking forward to this – it’s the peak European FHIR event, and we’ve got a great program lined up:

  • Patient Track: Create, update and search patients with FHIR.
  • Terminology Services Track: See if you can work with FHIR’s terminology operations: expand valuesets, validate your codes and get human readable labels for your codes.
  • Profile & Validation Track: Create a profile and an instance, and ask a server to validate the instance according to your profile.
  • SMART on FHIR track: Extend your server or build a client to add OAuth2 to the FHIR REST interface, and see whether they can authenticate and talk.
  • Imaging Track: Imaging, DICOM and FHIR.
  • API Beginners Track: Get your very first FHIR client application up and running.
  • Community Track: Presentations of real life experiences with FHIR.

The full schedule is here: http://goo.gl/gHGmCB, along with the the presenters (Keith Boone, Brad Genereaux, Michel Rutten, Dunmail Hodkinson, Mirjam Baltus, Kevin Mayfield, Marten Smits, René Spronk, Simone Heckmann – what a stellar line up!)

In addition to this, the FHIR Core Team will be announcing a couple of new and exciting implementation features for the community at DevDays – hopefully I’ll see you there!