Monthly Archives: March 2015

#FHIR DSTU ballots this year

Last week, the FHIR Management Group (FMG – the committee that has operational authority over the development of the FHIR standard) made a significant decision with regard to the future of the FHIR specification.

A little background, first. For about a year, we’ve been announcing our intent to publish an updated DSTU – DSTU 2 – for FHIR in the middle of this year. This new DSTU has many substantial improvements across the entire specification, both as a result of implementation experience from the first DSTU, and in response to market and community demand for additional new functionality. Preparing for this publication consists of a mix of activities – outreach and ongoing involvement in the communities and projects implementing FHIR, a set of standards development protocols to follow (internal HL7 processes), and ongoing consultation with an ever growing list of other standards development organizations. From a standards view point, the key steps are two-fold: a ‘Draft for comment’ ballot, and then a formal DSTU (Draft Standard for Trial Use).

  • Draft For comment: really, this is an opportunity to do formal review of the many issues that arose across the project, and a chance to focus on consistency across the specification (We held this step in Dec/Jan)
  • DSTU: This is the formal ballot – what emerges after comment reconciliation will be the final DSTU 2 posted mid-year

In our preparation for the DSTU ballot, which is due out in a couple of weeks time, what became clear is that some of the content was further along in maturity than other parts of it; Some have had extensive real world testing, and others haven’t – or worse, the real world testing that has occurred has demonstrated that our designs are inadequate.

So for some parts of the ballot, it would be better to hold of the ballot and spend more time getting them absolutely right. This was specially true since we planned to only publish a single DSTU, then wait for another 18months before starting the long haul towards a full normative standard. This meant that anything published in the DSTU would stand for at least 2 years, or if it missed out, it would be at least 2 years before making it into a stable version. For this content, there was a real reason to wait, to hold off publishing the standard.

On the other hand, most of the specification is solid and has been well tested – it’s much further along the maturity pathway. Further, there are a number of implementation communities impatient to see a new stable version around which they can focus their efforts, one that’s got the improvements from all the existing lessons learned, and further, one with a broader functionality to meet their use case. The two most prominent communities in this position are Argonaut and HSPC, both of which would be seriously impeded by a significant delay in publishing a new stable version – and neither of which use the portions of the specifications that are behind in maturity.

After discussion, what FMG decided to do is this:

  • Go ahead with the ballot as planned – this meets the interests of the community focused on PHR/Clinical record exchange
  • Hold a scope limited update to the DSTU (planned to be called 2.1) later this year for a those portions of the DSTU that are identified as being less mature

The scope limited update to the DSTU will not change the API, the infrastructure resources, or the core resources such as Patient, Observation etc. During the ballot reconciliation we’ll be honing the exact scope of the DSTU update project. Right now, these are the likely candidates:

  • the workflow/process framework (Order, OrderRequest, and the *Request/*Order resources)
  • The financial management resources

For these, we’ll do further analysis and consultation – both during the DSTU process and after it, and then we’ll we’ll hold a connectathon (probably October in Atlanta) in order to test this.

Canadian FHIR Connectathon

unnamedFHIR® North

Canada’s FHIR Connectathon


Event Details

Date: April 29th

Time: 9:00AM – 6:00PM

Location: Mohawk College, 135 Fennel Ave W, Hamilton, ON L9C 1E9

Room: Collaboratory (2nd Floor – Library)

Registration Cost: $45.00 (Entry, lunch, coffee break, pizza dinner)

Registration Site: http://www.mohawkcollegeenterprise.ca/en/event_list.aspx?groupId=3

Event Description

A FHIR connectathon is an opportunity for developers to come together to test their applications to determine if they can successfully interoperate using the HL7 FHIR specification. Participants will have a chance to meet and ask questions with some of the world’s leading FHIR experts, a chance to see whether FHIR really lives up to the hype and a chance to shape the specification.

Don’t miss out on this opportunity. Register now at http://www.mohawkcollegeenterprise.ca/en/event_list.aspx?groupId=3. For further details regarding this event, please review the pdf attached.

FHIR is attracting significant interest world-wide. Although the standard is still evolving, it’s being used in production in multiple countries. Numerous connectathons have been held in the U.S., Europe, South America and Australasia. It seems time to give Canadian developers a chance to take it out on the road.

FHIR North v1.0 (PDF)

Note: “HL7” and “FHIR” are registered trademarks of Health Level Seven International

Establishing Interoperability by Legislative Fiat

h/t to Roger Maduro for the notification about the Rep Burgess Bill:

The office of Rep. Michael C. Burgess, MD (R-Texas) released a draft of the interoperability bill that they have been working for the past several months on Friday. Rep. Burgess, one of the few physicians in Congress, has been working very hard with his staff to come up with legislation that can fix the current Health IT “lock-in” crisis.

Well, I’m not sure that it’s a crisis. Perhaps it’s one politically, but maybe legislation can help. With that in mind, the centerpiece of the legislation, as far as I can see, is these 3 clauses:

‘‘(a) INTEROPERABILITY.—In order for a qualified electronic health record to be considered interoperable, such record must satisfy the following criteria:

‘‘(1) OPEN ACCESS.—The record allows authorized users access to the entirety of a patient’s data from any and all qualified electronic health records without restriction.

‘‘(2) COMPLETE ACCESS TO HEALTH DATA.— The record allows authorized users access to the en- tirety of a patient’s data in one location, without the need for multiple interfaces (such as sign on systems).

‘‘(3) DOES NOT BLOCK ACCESS TO OTHER QUALIFIED ELECTRONIC HEALTH RECORDS.—The record does not prevent end users from interfacing with other qualified electronic health records.

Well, there’s some serious issues around wording here.

Firstly, with regard to #1:

  • What’s the scope of this? a natural reading of this is that “the record’ allows access to all patient data from any institution or anywhere else. I’m pretty sure that’s what not they mean to say, but what are they saying? What ‘any and all’?
  • Presumably they do want to allow the authorizing user – the patient – to be able restrict access to their record from other authorised users. But that’s not what it says
  • The proposed bill doesn’t clarify what’s the ‘patient record’ as opposed to the institution’s record about the patient. Perhaps other legislation qualifies that, but it’s a tricky issue. Where does, for instance, a hospital record a note that clinicians should be alert for parental abuse? In the child’s record where the parent sees it?
  • Further to this, just what are health records? e.g. Are the internal process records from a diagnostic lab part of ‘any and all qualified health records’? Just how far does this go?

With regard to #2:

  • What’s an ‘interface’? As a technologist, this has so many possible meanings… so many ways that this could be interpreted.
  • I think it’s probably not a very good idea for legislation to decide on system architecture choices. In particular, this sentence is not going to mesh well with OAuth based schemes for matching patient control to institutional liability, and that’s going to be a big problem.
  • I’m also not particularly clear what ‘one location’ means. Hopefully this would not be interpreted to mean that the various servers must be co-located, but if it doesn’t, what does it mean exactly?

With regard to #3:

  • I can’t imagine how one system could block access to other qualified health records. Except by some policy exclusivity, I suppose, but I don’t know what that would be. Probably, if this was written more clearly, I’d be in agreement. But I don’t really know what it’s saying

There’s some serious omissions from this as well:

  •  There’s nothing to say that the information must be understandable – a system could put up an end-point that returned an encrypted zip file of random assorted stuff and still meet the legislation
  • There’s no mention of standards or consistency at all
  • There’s no mention of any clinical criteria as goals or assessment criteria

The last is actually significant; one of the real obstacles to interoperability is the lack of agreement between clinicians (especially across disciplines) about clinical interoperability. There’s this belief that IT is some magic bullet that will create meaningful outcomes, but that won’t happen without clinical change.

As usual, legislation is a blunt instrument, and this bill as worded would do way more damage than benefit. So is there better wording? I don’t have any off the top of my head – anything we could try to say is embedded in today’s solutions, and would prevent tomorrow’s (better) solutions.

It would be good if the legislation at least mentioned standards, though. But we’re decades away from having agreed standards that cover even 10% of the scope of “any and all qualified electronic health records”

Guest Post: Breaking a lance for #FHIR

A guest post about FHIR adoption from Andreas Billig, Fraunhofer FOKUS. I asked Andreas to write about his experience using FHIR to implement a terminology service.

Although it seems not necessary to break a lance for FHIR, there might be some skeptics that need to be motivated to use FHIR for electronic health artifacts in future. The upcoming success of FHIR is directly related to past efforts for establishing a common modeling language and method for electronic health artifacts. One of the most prominent ambitions was HL7-v3 in the mid 2000s. So why trying to introduce a new language?

Past issues & consolidated goals

HL7-v3 was backboned with excellent concepts and techniques for developing models to ensure well-defined interpretation of the instances exchanged between various actors in electronic healthcare. It relies on model-driven approaches (MDA) well known in the software development community and on a sound architecture enabling re-use and refinement of model elements.

Starting from RIM (Reference Information Model) elements as a general vocabulary for the health care domain you can first define your DMIM (Domain Message Information Model) for specialized artifacts of a particular sub-domain. These models are not intended to be serializable and will be refined/constrained to so-called RMIMs (Refined Message Information Models). (Serializable) RMIMs have their direct equivalent in XML schemata which in turn are used as grammars for electronic artifacts exchanged between healthcare actors. A prominent instance of the RIM-DMIM-RMIM-XML chain is CDA (Clinical Document Architecture).

So far so good. But what were the issues? From our point of view there were at least five points where the development of FHIR went very good and learned from past issues:

  • dissemination by documentation
  • handling modeling complexity
  • extensibility
  • domain model diversity
  • integration with the method of profiling

The first point concerns the excellent documentation of the standard utilizing the hypertext paradigm. It can be seen as a domain-specific WIKI with concentrating on the essential elements with a consistent structure following the KISS-principle.

The Modeling complexity of FHIR is of low degree thanks to the profile- centric approach. Of course, HL7-v3 made very good efforts to handle complexity by introducing elements like class- and mood-code, shrinking the number of explicit classes (by the way, this was the reverse application of the principle of attribute discrimination). FHIR does not introduce them explicitly but due to the fact that most of the coding attributes are discriminating per se FHIR does not abandon this facility in general.

The extensibility approach of FHIR is at prominent place. Explicit language constructs to represent extensions of information items allows for managing and tracking extensions with direct machine support. It is expected that some extensions are gathered for reflow to standard resource profiles.

As said before, with HL7-v3 one can define arbitrary models to reach the goal of high domain model diversity by instantiating the RIM-DMIM-RMIM-XML chain as done in the CDA definition. From my point of view it was the HL7 intention that followers massively will define custom models for their projects. For reasons unknown to me (may be due to the understandable absence of modeling experts in projects) most of the users stuck with the CDA model to avoid the above chain and to profit from various resources developed around CDA. Unfortunately, this practice did not led to sound model diversity. Instead, many users tried to press everything in CDA – so the diversity was formulated within CDA and not sufficiently covered by tailored modeling language elements. FHIR minimizes this risks by its profile-oriented approach where strong model chaining cannot discourage users. Instead FHIR is initially equipped with a high diversity that can be refined or extended as needed for the project.

The present point is directly related to the last point. People and organizations, e.g. IHE, customized the chain end CDA/XML by defining various profiles – with the problems sketched above. FHIR is based consequently on profiling from the beginning to the end. This uniform way ensures low complexity and the absence of language breakings.

Ready for the web

Since many years easy-to-use web technologies are increasingly utilized. The most prominent examples are REST and JSON. I remember a telco two years ago where I asked “Will FHIR be the successor of V3?”. After a small pause the moderator analogously said “mmh, FHIR is merely intended for use on smartphones and tablets but we will see …”. Now we see that it makes no sense to artificially split the modeling techniques in dependence of distribution channel.

The lightweight profile-centric modeling approach of FHIR is directly targeted to main formats XML and JSON and therefore a perfect fit to the technological base of the web. Moreover, semantic web applications coming out of age and FHIR will easily be integrated by using RDF bindings. Of course we do not want to break up with MDA. Instead, many MDA results will flow in the FHIR development in future.

How we use fhir

Our institute have applied FHIR in several projects. First of all, the project DEMIS (German Electronic Notification System for Infection Protection) utilized FHIR resources to represent and exchange information of infectious diseases and pathogens, a project together with the Robert Koch Institute, the central federal institution responsible for disease control and prevention. Here we profited from the quick and easy definability of profiles for resources concerning infectious diseases. Moreover, the facility of handling FHIR profiles as first class citizens enabled us to generate input forms to be filled by healthcare actors.

Secondly, our terminology server CTS2-LE is able to import code systems and value sets represented by FHIR Value Set Resources. These artifacts are then mapped to the CTS2 standard. Here we benefit from their concise definition. As an side product, we were able to load all HL7-v3 code systems and the FHIR systems itself via this interface.

It has to be noted that of course we will continue with HL7-v3 as long as some market segments will base on this standard. HL7-v3 was a groundbreaking project that influences the FHIR development – or – one can say, made FHIR possible.

Thanks Grahame, for the opportunity to break a lance for FHIR in your blog