Monthly Archives: January 2014

Follow up workshops: Clinical Safety for Healthcare Applications

Back in November I ran a clinical safety workshop for the MSIA in Sydney. I had several requests for follow ups in Melbourne and Brisbane, so I will be holding follow up workshops on March 11 (Melbourne) and Mar 13 (Brisbane). I’ll do more if there’s sufficient interest.

Here’s some quotes from the announcement:

This workshop provides a set of tools and knowledge that will help healthcare application designers create safer software. Attendees will work through real, practical examples that demonstrate clinical safety issues in application design, and also cover general clinical safety thinking, coding, presentation, data management issues, and the looming regulatory process.

The workshop is for people who make decisions about software design, or manage the software design process – whether their background is clinical, programming, or otherwise.

Testimonials

“The Clinical Safety Workshop was not what I expected, but so much more. Grahame did not condescend to dictate specific software tricks to write safe software. Rather, he engaged with participants to help them understand for themselves a philosophy and approach to developing safe and effective health software using skills we already know. Suited to senior technical management, architects and code cutters alike.”  Mat Hudson, CEO RadLogix Pty Ltd

Grahame brings together his years of experience in medical software and standards development to address one of the most important issues related to using information and associated machines in the provision of health care and that issue is safety.  The workshop I attended was both academically rigorous and practical. I would not hesitate to recommend it for anyone wanting to work with information and knowledge in health and in my view there is no-one that doesn’t! Michael Legg, Conjoint Associate Professor, School of Medical Sciences, University of New South Wales

The workshop will cost $700, or $500 for employees of companies that are MSIA members (the program was prepared in association with the eHealth Industry Clinical Safety and Security Committee auspiced by the MSIA)

Hopefully, I’ll see you there.

I will not be at San Antonio

Next week is the HL7 working group meeting, in San Antonio this time. The WGM is where most of the work of developing a standard gets done.

I will not be present.

It’s the first WGM I’ve missed for about 7 years or so. I’m not going for personal reasons – family arrangements. Next week, during the FHIR connectathon and then the WGM, I will be off at Tamboon Inlet where not only is there no mobile broadband, there’s not even any mobile coverage. Or Power. Or even Water.

It’s not that I’m not interested; the original plan was that I’d be attending the meeting virtually this week – when it was originally supposed to be. But instead, for reasons beyond HL7’s control, they were forced to change the week, and I simply can’t be available. I’ve done what I can to make sure that FHIR is ready for the meeting, and I’ll just have to sit out this one.

I hope all my friends enjoy San Antonio – it’s one of my favourite places for an HL7 meeting, though increasingly I can’t get out the hotel. Well, not this time – I’m off fishing.

Guest Post: FHIR Ballot Process

GE have asked for another round of FHIR balloting. See here and here. I don’t have time to commit my thoughts to the blog in a measured way – it’s very hard to comment rationally on this matter, and I don’t have time. So instead, Lloyd McKenzie volunteered this as a guest post:

The FHIR Management Group and the FHIR Governance Board will be making the determination of whether to go back to ballot during one of their face-to-face meetings at the WGM next week.

A few things to keep in mind:

  • All balloters *have* had a two-week chance to review the dispositions of all ballot comments (not just their own) and the specification has been up to date reflecting those changes. Thus far, only one balloter  has indicated an issue with any of the resolutions, and it looks like we can resolve that.
  • In parallel with that opportunity for review by balloters, every page in the specification has undergone QA for style, formatting, etc. So most, if not all, minor readability issues resulting from the changes should now be cleaned up.
  • The DSTU specification is a draft. It will change and will continue to evolve.

Technically, the ballot has more than met the HL7 requirements to pass. The question is whether it would be in the interest of implementers to hold the specification back for another 6 months to go through another round of balloting, subsequent updates, QA and publication. I’m far from convinced that is the case.

One of the objectives of FHIR is to be “fast”. That doesn’t just mean “fast to design”, it means “fast to develop”. Thus far, we’ve managed to meet a pretty remarkable timeline, at least compared with HL7 v3. FHIR is also trialing some new processes and governance mechanisms. We’ve made significant use of QA reviews in addition to ballot cycles. We conduct distributed ballot reconciliation, etc.

It’s important to remember what DSTU is and what it is not. DSTU is not a “done specification”, though I realize it’s been treated that way in some cases. Anyone who treats the FHIR DSTU that way will likely regret it. FHIR will change as part of the DSTU process, almost certainly in a few ways that are not wire format backward compatible. While we have more implementation experience with FHIR than HL7 has ever had with a specification at this point in its development cycle, the reality is that there are significant parts of the specification that have not yet been well exercised, much less been exercised across the full diversity of the healthcare environment. The purpose of DSTU is to say “this specification is well reviewed and is solid enough to try applying it in the real world so that we may apply that real-world experience when crafting the final version of the specification”. Those who cannot tolerate risk of change should not implement based on a DSTU.

Most of the valuable feedback we’re getting now about FHIR is coming from those who are implementing it. I think we’re far better off releasing the specification for general use and implementing a responsive mechanism for dealing with implementer feedback as it’s received.

FHIR will be going to ballot again, and any interim tweaks we make in response to implementation issues will be vetted through a full ballot – as well the changes we’ve made as part of reconciliation of the first ballot. But it seems to me that we benefit implementers more by giving them our blessing to go forth and use it and then responding than we do to delay just for the sake of ensuring we dot our “I”s and cross our “T”s. (Reality is there will be plenty of undotted and uncrossed letters no matter how many cycles we go through.)

Balloting has a significant cost – it delays when many implementers can take advantage of it, it consumes HL7 and volunteer resources that could be focused on enhancing the specification and it can contribute to ballot fatigue – where reviewers get so tired of constantly reviewing content that they cease to bother anymore.

If you want to review the specification and didn’t take advantage of the two week window, go ahead and do so now (or more realistically, when you get through the WGM). If you have feedback, submit it via the gForge tracker so it can be triaged and incorporated in the next release (and if urgent, provided as “implementation guidance” to early DSTU implementers).

Question: HL7 v2 Backwards Compatibility

Question

If I code a library to HL7 2.6 standard, will it mostly work for all versions below it? Wikipedia says 2.x is backward compatible, but how backward compatible is it?

Answer

In principle, HL7 is highly backward compatible. The basic syntax and structures are unchanged between any version 2.x (as long as you use the vertical bar syntax, which is the normal way). So your code will read earlier messages just fine. In fact, very often the only difference between the message is the value of the MSH-12 field:

MSH|^~\&|ADT1|MCM|LABADT|MCM|198808181126||ADT^A17^ADT_A17|MSG00001|P|2.6

If you can parse this, and you don’t explicitly tie your logic to the value of the 12th field of MSH – and I never do – then your library is version independent.

However, as the versions have rolled on, additional fields have been added. If your logic depends on a value of an additional field that was defined in a more recent version, then your logic won’t be backward compatible.