Preparing for the Australia #FHIR Connectathon

It’s 10 days or sp until the Australian FHIR Connectathon, which is Friday. This post is to help people who are preparing for that connectathon. There’s 3 tracks at the Australian Connectathon:

Track 1: Patient resource (Introductory)

This track serves as the simple introductory task for anyone who hasn’t been to a connectathon before, though previous attendees will find it useful for extending their experience and knowledge. The patient scenario is to write a client that can follow this simple sequence:

  • Search for a patient
  • Get a selected patient’s full details
  • Edit and Update the patient details
  • Create a new patient record

Or, alternatively, to write a server that is able to support some or all of these functions.

This is useful because the same patterns and problems apply to all the other resources, and very nearly everyone has to implement the patient resource.

If you’re writing a client, our experience is that your minimum preparation is to start the day with a functioning development environment of your choice – to be able to develop and execute. If you don’t have that set up, you can lose most of the day just getting that done. If you’re writing a server, then the minimum functionality is to have a working web server that you know how to extend

Beyond the ability to develop and execute, any additional work you do before hand to work non these scenarios means that on the day you’ll get further into the scenario, and you’ll get that much more out of it.

Track technical lead: Grahame Grieve

Track 2: Smart on FHIR

This track is more advanced; it uses more functionality and makes deeper use of the functionality that FHIR provides, and adds to this additional context and security related content. For further information about this track, see the Chicago Connectathon Details

Track technical lead: Josh Mandel

Track 3: Clinical Connectathon

The first 2 tracks are distinctively developer tracks – to participate, you really need to be able to develop product (which is not the same as “being a developer”). Still, there are many users of interoperability specifications who are interested in how FHIR works, and these participants have as much to gain from a hands on experience learning FHIR as developers do – and the FHIR specification and community have just as much to learn from them too. With this in mind, the FHIR core team is working towards a connectathon experience that is focused on the end-user experience with FHIR. We held our first “Clinical Connectathon” in Chicago – you can read the summary report from it.

The 3rd track will be a follow up to the Chicago connectathon. Participants in this track will use tools provided by the core team to match the capabilities of the FHIR specification against the requirements and tasks of routine clinical workflow. There’s no preparation needed, except to turn up with a working laptop (or even tablet) that has the latest version of your favourite web browser installed (no support for old versions of IE).

Participants should not that this whole clinical track is a work in progress – it needs mature tooling from the core team, and we are still working towards that goal. This connectathon will be exercising the tooling that supports it as much as it’s going to be exercising clinical scenarios against the FHIR specification.

String clinical lead: Stephen Chu. Stream technical lead: David Hay

#FHIR Updates

Several FHIR related updates:

Just a note in response to a question from an implementer: we are going through a period of making many substantial changes to the specification in response to user feedback. Right now, the test server (http://fhir-dev.healthintersections.com.au) is far behind – that’s work for next month. This doesn’t affect the DSTU test server (http://fhir.healthintersections.com.au)

p.s. someone asked why I put the Hash tag (#FHIR) in my blog post headings – that’s because I can’t see how to get my blog post auto-tweeter to add the # all by itself (and I don’t want to write my own)

Health Interoperability Webinar

David Booth, who’s working with the FHIR team on RDF format, asked me to post this to alert my readers to this:

I want to be sure you’re all aware of a free webinar series we are

producing at SemanticWeb.com about the “Yosemite Project.” You can read
more about that project here:

http://semanticweb.com/semantic-interoperability-electronic-healthcare-info-agenda-u-s-veterans-health-administration_b44360

The webinar details are below and you can sign up to attend the live
event here:

http://content.dataversity.net/101714YosemitePART1_SWWeinarRegistrationPage.html

*WEBINAR DETAILS
DATE: October 17, 2014*
*TIME: 2 PM Eastern / 11 AM Pacific*
*PRICE: Free to all attendees*
*Registration link:
*http://content.dataversity.net/101714YosemitePART1_SWWeinarRegistrationPage.html

*About the Webinar***

Interoperability of electronic healthcare information remains an
enormous challenge in spite of 100+ available healthcare information
standards. This webinar explains the Yosemite Project, whose mission is
to achieve semantic interoperability of all structured healthcare
information through RDF as a common semantic foundation. It explains the
rationale and technical strategy of the Yosemite Project, and describes
how RDF and related standards address a two-pronged strategy for
semantic interoperability: facilitating collaborative standards
convergence whenever possible, and crowd-sourced data translations when
necessary.

*About the Speaker***

David Booth is a senior software architect at Hawaii Resource Group,
LLC, using Semantic Web technology to make clinical healthcare data
interoperable between diverse systems. He previously worked at KnowMED,
using Semantic Web technology for healthcare quality-of-care and
clinical outcomes measurement, and at PanGenX, applying Semantic Web
technology to genomics in support of personalized medicine. Before that
he worked on Cleveland Clinic’s SemanticDB project, which uses RDF and
other semantic technologies to perform cardiovascular research. Prior to
that was a software architect at HP Software, where his primary focus
was emerging technologies. He was a W3C Fellow from 2002 to 2005, where
he worked on Web Services standards before becoming involved in Semantic
Web technology. He has been programming for many years using a variety
of programming languages and operating systems. He holds a Ph.D. in
Computer Science from UCLA.

 

Integration and translation will remain part of what we do for many decades, at least. I know that a lot of what we have to do involves implicit knowledge, and special rules, but it will be interesting to see how a stable knowledge foundation might be able to be leveraged to make it easier to get  there.

If Hospitals ran like Restaurants

Yesterday, I gave a lecture about Healthcare Interoperability – and the lessons learned from FHIR – to a group of master’s students at Melbourne University HaBIC. In passing, I mentioned the danger of using bad metaphors to describe healthcare interoperability, and compared this to the danger of the whole “healthcare should be like the airlines”… and then today, I saw this (h/t HISTalk)

These things are basically pretty stupid – one day, I really want to see someone do this backwards, and do “what if a hospital worked like a restaurant?” – limited menus, shallow service, variable quality… healthcare is not like a restaurant.

On the other hand, the way the financials work in the USA.. that is pretty stupid; they sure have a point about that.

p.s, for a much more serious comparison, see Atul Guwunde’s Big Med

Question: Using #FHIR Medication Resources

Question:

To what extent should FHIR Medication resources be reused? Should they be reused across multiple patients’ records?

Answer:

The general answer is that they should re-used as much as possible. The general expectation is that either a system has a formulary or drug dictionary, in which case there would be one medication resource per entry, and these commonly re-usable medications would be used across many patients, or that you are prescribing by some external code. In the second case, you wouldn’t re-use the medication resource at all.

Note- the resource design will change in the near future to make the second case easier – just put the code on the prescription directly, with no need for the medication resource.

New #FHIR Open License

Today, HL7 released an updated version of the FHIR™ Draft Standard, which is now covered under a Creative Commons License: No Rights Reserved. This marks the formal adoption of a recognized open license for the FHIR specification, and one that is truly open: this is an unencumbered license. Under the terms of the Creative Commons license, HL7:

… has dedicated the work to the public domain by waiving all of it’s rights to the work worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law. You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.

This is a truly open license – even more open than most open source projects, which usually require some form of attribution. However since FHIR is a standard, and many implementations will be required to implement it, it would be inappropriate to require acknowledgement of the specification. Note, though, that the reference implementations may require attribution – and most of them use a mix of BSD or Apache licenses that do.

It should be clear, though, that HL7 has not chosen the public domain license because we don’t care about FHIR – on the contrary, HL7 cares greatly about FHIR and is investing heavily in it. HL7 wants all health care systems, whether commercial or open source, to use the FHIR specification – hence the unencumbered license terms. Because HL7 cares about the specification, it means that HL7 needs to protect the Trademark carefully, since control of the FHIR specification is how HL7 derives value from it’s investment. So the specification itself makes this clear:

HL7 protects the “FHIR” trademark carefully. This means that:

  • You cannot publish an altered version of the FHIR specification unless it clearly identifies that it is a derivative specification, not FHIR itself
  • Derivative Specifications cannot redefine what conformance to FHIR means
  • The letter sequence “FHIR” can only appear as part of a product name with specific written agreement from HL7
  • You can only use the FHIR logo as part of a commercial product with specific written agreement from HL7
  • When used in other contexts, the word “FHIR” and the “FHIR” logo should bear the ™ symbol

The point isn’t to restrict the use of the name FHIR, but to prevent it from falling into ‘common use‘. Where FHIR is used as part of an existing product name – whether a commercial product, or an open source server or library, please contact fmgcontact@hl7.org to ask for this permission (I need to do this myself). Note: As a point of reference, you can compare these rules to the Mozilla Foundation’s equivalent policy.

History

In the past, FHIR was published under a different license, adapted from OMG (thanks for Richard Soley for allowing this), but using a custom license increased implementation costs, and caused perceptions that the FHIR license wasn’t a proper open license. This new license doesn’t change the effective license terms that apply to FHIR at all – it’s just an expression of the same intent in a form that is more aligned with the open software and standards communities. Changing the license was a process that involved agreement from a very large number of people with HL7, and the fact that this has happened shows the importance that HL7 places in FHIR’s openness. I’d like also to thank two people outside HL7 who particularly contributed to the process – Paul Biondich (from Regenstrief / OpenMRS) and Larry Rosen.

Specification Technical Correction

The update to the license was accompanied by a technical correction to the specification itself. Quoting from the version history entry:

Fix major bug in reading/writing JSON instances: the json equivalent for xml:id is specified as “id” but the java reference implementation had been using “_id”. This is a breaking changed for users of the JSON representation using the Java reference implementation. Note also that this means that all the example JSON instances in the specification were wrong; these have also been fixed in this update

Because of this, the reference implementations and the test servers accept either “id” or “_id”, but “id” is correct.

So the spec used to have, for JSON examples such as this one:

  "contained": [
    {
      "resourceType": "Observation",
      "_id": "obx1-4",

and now it has

  "contained": [
    {
      "resourceType": "Observation",
      "id": "obx1-4",

This only affected contained resources. Thanks for Doug Martin from Regenstrief for pointing this error out.

Reference Implementations

This updated version of the FHIR specification includes updated reference implementations, and an updated maven package has also been posted.

#FHIR DSTU2: Changing the Composition Resource

While in Chicago, one of the decisions that we made was to refactor the Composition resource. Here’s the design in DSTU #1:

composition_dstu_1

The design can be summarised in prose:

  • A section has a title and a code that describe it, and it may have a section if the subject is different to the overall composition (documents that span multiple subjects are not that unusual)
  • A section can contain other sections, or a resource that contains the content for the section
  • The resource is allowed to be any kind of resource, but the most common kind is a List resource.

Observationally, almost all CDA sections are a list – medications, problems, diagnostic reports. There’s a few exceptions: a synopsis section, a care plan. But these are the minority.

There’s a major problem with this design, which revolves around the narrative/text dynamic in a document – what happens if there’s no entries, and only some narrative? Do you have to use a different resource type (other?) if you don’t have structured content (and actually, the way resources are defined pushes you in this direction, because many of them have required data elements, and you can’t use them if all you have is text (that’s a different issue for potential resolution elsewhere).

After a fairly long discussion about this problem, and consideration of a number of alternatives, the structured document working group decided to try this design:composition_dstu_2

This design can be summarised in prose:

  • A section has a title, a code, and an identifier that describe it. Note: the identifier should only be populated if it is persistent across different compositions (unlike CDA, where slippery ids are a source of confusion)
  • A section can have narrative, and an empty reason, or sub-sections or entries (can’t have sub sections and entries, and must have a narrative unless it has sub-sections
  • The narrative is the ‘attested content’ for the section (see CDA definition)
  • Entries provide supporting data for the section narrative
  • If there are no entries and no sub-sections, there can be an empty reason. This is for things like “No medications prescribed” or “None known”
  • A code can be provided indicating what order the entries are in (the narrative order should match the order of the entries, but what is that order – chronological?)

Essentially, the relevant capabilities of the list resource have been conflated into the section.

This has the following advantages:

  • All the attested narrative is inside a single resource
  • The structure much more closely matches CDA (this will help with CCDA/FHIR implementation efforts that are ramping up)
  • There is no ambiguity about what kind of resource to use
  • There’s no confusion about the list snapshot mode – some of the list capabilities don’t make sense in a composition

There’s some potential downsides to this structure – particularly around conformance, and these are the subject of active development and testing, so implementers shouldn’t assume that this is the last word on the matter.

#FHIR Report from the Chicago meeting

Here’s a FHIR progress report from the HL7 working meeting in Chicago held the week before last.

General Progress

Overall, the hype about FHIR is astonishing, and I don’t see any evidence that it’s starting to slow. While we were in Chicago, Wes Rischel made some interesting comments about where FHIR is (though following his logic, our current task is to bring on the trough of disillusionment as soon as possible) . The FHIR project team is aware that there is a duality here: expectations and excitement about FHIR are high, but what we have published is still an early beta, and FHIR is not yet ready to meet the expectations that people have about it. We intend and expect to get there, but it is important that stakeholders and implementers understand that there’s still a lot of work to be done.

Connectathons

At the Chicago meeting, we held two connectathons: our normal implementer connectathon, and a clinical connectathon.

The normal connectathon was a largest yet (close to capacity). Each connectathon, we grow in 3 respects: the number of attendees, the scope of the specification that we test, and the sophistication of the outcomes. What really pleases me is that it’s not just old hands that produce sophisticated outcomes, but first time attendees who are able to use FHIR to extend their existing applications and platforms to create interesting new solutions. Sadly, the things that are seen and/or shown at the connectathon are not packaged in a way suitable for publication – maybe this is something we can change next time? (There’s an opportunity for a volunteer there). This connectathon included a focus on Smart on FHIR, and this created something new for us: a strong focus on servers rather than clients.

The clinical connectathon was something new. We held the clinical connectathon because we recognise that the connectathon process is fundamental to the strength of the specification – we’ve tested the technical interoperability aspects repeatedly, and improved the specification in response to what we’ve learnt. We know that the strength of FHIR isn’t because we’re clever, but because we keep testing it. However our existing connectathons are limited in that they require users with development tools – they are focused on system implementers. Users with clinical knowledge are generally excluded from participating, and we’ve not tested the suitability of FHIR for clinical interoperability. In fact, this is the gap between hype and reality that is our most pressing concern. The clinical connectathon intended to begin addressing this gap.

The clinical connectathon focused on clinical exchange – that is, clinical users connecting with each other. For this, the patient care group co-chairs prepared a set of clinical scenarios, and the FHIR project team provided a single tool that all the users would use to enter a set of data for an exchange associated with the scenario. Users would then review what they received and compare it to the scenario. Because all the users have the same tool, and the tool is focused on the specification, rather than being a normal EHR, this is about testing the specification, not some other software.

Technical note, for those interested: the tool has 2 parts, client and server. The client was written primarily by Peter Bernhardt (a huge effort, thanks) with assistance from David Hay and Viet Nguyen, and the server is http://fhir-dev.healthintersections.com.au. For the data entry, the server converts a profile to a questionnaire, the client presents the questionnaire, creates a set of answers, and then the server converts these answers into a resource that conforms to the profile.

On the day, the clinical connectathon reminded me of the first normal connectathon we had – the potential of both FHIR and the connectathon was evident, but we didn’t get that much achieved on the day. For the clinical connectathon, we identified plenty of opportunities to improve the tool, and identified a number of questions about how the common clinical scenarios should be represented in the resources. Most importantly, for me, my success criteria for the first connectathon were met: all participants agreed that it was a worthwhile exercise, and that it’s worth continuing, and that we now have a better way to drive clinical engagement with the specification.

Status of the FHIR community

Up to now, FHIR has primarily been a standards project: a group of people with a core task of producing a standard. In order to do produce a good standard, we’ve had a strong implementation focus. That is, we worked with implementers in order to produce a better standard. But we recognize that the focus now needs to change: we produce a standard in order to enable implementations to solve important problems. The FHIR project and management teams will place increasing focus on implementation and engagement with a wider community. One tangible result of this is that we’ll create a home for the FHIR community at http://fhir.org, which presently simply redirects to the specification. I’ll post more about this later.

Implementation Guides

This meeting also represented the first ballot of a FHIR implementation guide – a draft for comment ballot of the U.S. Realm ONC Structured Data Capture project). It received over 200 comments from 20 voters.  We still have work to go on how implementation guides will be produced, but this is a start.  In the December-January ballot cycle, the entire IG will go back to ballot, this time with the entire FHIR specification as part of a second “draft for comment” in preparation for the DSTU ballot cycle in May.

Generally, the infrastructure to produce implementation guides will be a major focus for the core team in the next couple of months – we’re now working a number of implementation guides in addition to this one.

Administrative Details

  • We published an initial set of “FHIR principles” for consideration. These are important because they define the scope of what FHIR is and is not, and the principles that we keep in mind when evaluating change proposals
  • We initiated a process to QA review all the codes that are defined as part of FHIR, and to see whether we can get them from somewhere else. Also, we will be working on a social-media driven process for design review of FHIR value sets, since these codes often have a different life cycle than simple ballot (e.g. once published, they can be pre-adopted by users without going through ballot first)
  • We are getting closer to publishing a registry for FHIR profiles, value sets, etc. An RFP calling for the provision of the services to support this will be released soon (if you are interested, subscribe to the FHIR email list)
  • Exactly what the letters “FHIR” stand for is a little difficult to pin down. The specification itself offers 2 different meanings, and educational material offers more. The correct name is “Fast Healthcare Interoperability Resources”, and the specification will be updated soon

DSTU 2

We have now started on the work of preparing the next version of FHIR in earnest. It’s going to be big task; as of today there are 316 open tasks relating to the next specification. While in Chicago, we made a number of decisions that are breaking changes for the next version of the FHIR specification:

  • We will change two data type names:  “Schedule” to “Timing” (We want to use Schedule as the name a resource), and “Contact” to “ContactPoint” (to resolve implementer confusion about double use of the name “Contact”
  • We will change the way that extensions are represented in JSON (I’ll post about this more later)
  • We will change the way a Composition is stitched with it’s content (next blog post)
  • We will change the way that version specific updates are performed to align with other web specifications
  • We will add multi-lingual support to the value set resource (and will extend the specification infrastructure to make use of it)

Note there are other changes already made, see http://hl7-fhir.github.io/history.html

In addition, we’ll be working on adding a bunch of new resources:

  • Nutrition Orders
  • Financial transactions
  • Information sharing consent
  • Device management

Finally, we decided that future connectathons at HL7 working meetings will be based on the future DSTU version

Other Details

  • We were pleased to welcome the OpenMRS team to the connectathon for the first time. We expect to have an ongoing and increasingly fruitful collaboration between the FHIR and OpenMRS communities. One aspect of this that we will be looking at is what we can do to make FHIR more suitable for use in communities other than the developed world – this has both technical and requirements based implications.
  • We are hoping to add sections to the specification dealing with the complicated issues around handling identification and record keeping associated with the birth process, and how to code genetic mutations for oncology.

 

 

 

HL7 Australia #FHIR Forum and Connectathon

On Thursday & Friday 6-7 November 2014 Hl7 Australia is holding a FHIR Forum and Connectathon in Melbourne.

Day 1 is focused on education:

Keynote: FHIR in context … a step forward for patients Andrew Yap, Alfred Hospital Melbourne
FHIR – A US perspective David McCallie, CMIO, Cerner
Implementing FHIR for Australian GP Systems Brett Esler, Oridashi
FHIR / openEHR collaboration Heather Leslie, Ocean
FHIR & the Telstra eHAAS design Terry Roach, Capsicum / Telstra
Introduction to SMART on FHIR Josh Mandel, Smart / Boston Childrens
Using Terminologies with FHIR Michael Lawley, CSIRO
Using FHIR in new and unexpected ways – actually including the Patient in the system Brian Postlethwaite, Telstra (DCA)
Clinical records using FHIR David Hay, Orion Healthcare
Panel: What are the prospects for FHIR Adoption in Australia?

  • Grahame Grieve, Health Intersections (FHIR Project)
  • Richard Dixon Hughes, DH4 (Standards)
  • Tim Blake, Semantic Consulting / DOH (Government)
  • Peter Young, Telstra  – DCA (Industry)
  • Malcom Pradhan – Alcidion (Clinical)

 

Im really pleased about this program: it’s a great line up of speakers from Australia and New Zealand talking about what they’re actually doing with FHIR. Also, I’m really pleased to welcome David McCallie, the CMIO for Cerner, who’ll be joining us from USA by video to discuss Cerner’s plans for FHIR and discuss the broader prospects for the adoption of FHIR in the USA. Finally, we’re really lucky and extremely pleased to have Josh Mandel from Boston Children’s Hospital Informatics Program present. Josh will be talking about SMART on FHIR, and describing how that works as an EHR extensibility framework.

On Day 2, we’ll be holding a connectathon. We’ll have 3 streams of activity:

  • Basic Patient Stream – this is suitable for any developer with no prior experience of FHIR necessary – all you need is a working development environment of your choice
  • Smart on FHIR – this is for EHR vendors who want to experiment with using Smart n FHIR as a plug-in framework for their system, or for anyone who’s interested in writing an EHR plug-in – as many clinical departments will be
  • Clinical Connectathon – this is for non-developers who still want hands on experience with FHIR – use the clinical connectathon tools to learn how real world clinical cases are represented in FHIR resources

I hope to see all of you there. To register, go to www.hl7.org.au, or you can see the formal program announcement.

p.s. it doesn’t say so on the program, but there’ll be a conference dinner on the Thursday night.

Question: FHIR release schedule

Question:

I’m using the Java version of FHIR release 0.81. A bug fix that I needed required a later version of the code. I downloaded the code (rev. 2833) from SVN and, following the directions on the FHIR build page, had no trouble recompiling all of FHIR. Since rebuilding and replacing FHIR in our application is time consuming, I have some questions concerning release management:

  1. Is there a published release plan and schedule for FHIR?
  2. Is there a mechanism for patching or updating FHIR code between releases?

Note: this question was originally asked on StackOverflow where it was (a little unfairly) ruled out of scope.

Answer:

The FHIR project is a combination of a specification, and a set of source that supports it. The project life cycle is driven by the considerations that flow from this.

The trunk version of FHIR is the current development version of FHIR, what the team works on from day to day. As a matter of ongoing work, it is not stable, and there is no guarantee that it is coherent and/or correct. The trunk version of FHIR is published here: http://latest.fhir.me/

Periodically, the core editorial team that works on the specification and the code will determine that there have been enough changes and there is enough stability to publish a development release. These are published here: http://hl7.org/fhir-develop. We typically keep upcoming connectathons that intend to use a more recent version than the formal DSTU in mind when we do this. This effectively corresponds to a beta release. Change notes and release notes are prepared when this is done.

Finally, HL7 ballots FHIR through the formal standards processes. The ballot process is based on the trunk version, and is the principle driver of the project development work. Once the ballot is passed and finalised, then a branch will be created for that formal publication – so far, there has only been one, the first DSTU (draft standard for trial use), published Feb 3 2014. This is published here: http://hl7.org/fhir.

A little further information can be found in our version numbering/change tracking policy.

Future plans:

  • We have no formal plans around when new development releases are made – this will happen periodically
  • We plan to close the next ballot cycle around May/June next year (e.g. 2015), and publish the 2nd DSTU then
  • Then we will start working on the full normative release, perhaps end of 2016. note that there can be no formal timeline for this, because it depends on the ballot process

A note about DSTU: from a software perspective, the 1st DSTU was a full release of working software. From a standards perspective, this is a beta release. Once a full normative standard is released, different change control policies kick in.

With regard to patching the FHIR code between releases, the reference implementations are actively maintained. The major ones (Java, C#, and pascal) are maintained in (or for) both the trunk and the DSTU branch (tagged DSTU1). We do periodic releases to them as major bugs are identified and fixed.

The DSTU branch has a history.

Specifically, with regard to the Java Reference Implementation, as of 12-Sept 2014:

  • We will maintain Maven releases for both the DSTU and development releases. The dev/trunk is not published to Maven
  • The original DSTU release was numbered 0.80. After a large argument about version numbering, we changed that version number to 0.0.81, and both of these are published on Maven. 0.0.81 supercedes 0.81
  • The specification will change to reference the correct Maven package directly next time it is published
  • A new release for the DSTU version is required now., because of a significant issue in the json represented, but there is considerable due process to releases in the DSTU branch, and the process isn’t quite finished yet.
  • I will be updating the development version immediately after the Sept 2014 connectathon, including releasing a new dev version