Monthly Archives: October 2014

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.