Resources For Health: A Fresh Look Proposal

Aug 18, 2011

The remit of the HL7 Fresh Look Taskforce is:

If HL7 started again from scratch with a new specification, what would a good specification look like?

Even if you’re going to be critical of the v3 Process, you still need to recognise that there’s much value there too. But as I said, what are we going to do?

At Orlando, I spoke with several people about a new way of looking at v3 - taking all the existing ideas, but moving them all around. A big part of that proposal was to move all the complexity of the RIM derivation away from the wire format (i.e. the implementers) into the definitions, and to leverage ontology tools (i.e. OWL) instead of custom tools and class designs. But I could see that it was too hard to explain what I had in mind. So when I got back from Orlando, I cast around for ideas. If you started writing a standard now, it would certainly be focused entirely on the web. Many people pointed me at the highrise specfication as state of the art - simple and easy to implement and manage. So I started there. I took that and wrote “Resources For Health”. It’s not complete, of course (including all the broken links and todos) - but it’s enough to actually exchange lab reports with.

It’s enough to show what a different kind of standard that HL7 could produce. It’s no less sophisticated than the HL7 version 3 specification, but it seems really simple - life doesn’t need to be more complicated than it already is. This specification is altogether different from other HL7 specifications, yet in many ways, it has real continuity with much of where we are. While the patterns have been deeply re-organised, most of the ideas here are already present:

  •   This specification uses the vocabulary model as described by the core principles (though we’d love to simply it even more for implementers)
  •   The modeling is still based on the RIM - all the implementable models are mapped to the RIM (though it’s a little further away than before)
  •   The resources are based on the CMETs and RMIMS defined in v3, with input from v2 and openEHR models
  •   The conformance model is based on the HL7 one, but it’s been reorganised to focus on XML, not abstract attributes
  •   HL7 has a strong interest in simplifying the XML - this specification takes that to the next step
  •   The data types are very closely aligned to v3 data types, but simplified (sometimes by moving things out of the datatypes)
  •   CDA has introduced the notion of text as a fallback for human interpretation. this specification generalises that

Anyway, enough of that. Here’s the links:

Main Introduction

Also, make sure to read the letter to readers at

RFH Covering Letter

A key part of this specification is that there needs to a constrained number of resources that are useful to everyone. I don’t know whether appropriate governance can be put in place to build a specification which has just the right number of resources, at the right point between useable and reusable, and whether we can get meaningful compromise around the, - but if we can’t, what value are we bringing to the process? (note though, an important part of this specification is that the agreement and compromise happens on the implementer side of the transform to the RIM, not the RIM side, which is the key difference between this and greenCDA as a methodology).

This specification was written by hand - all of it. That’s not a process that scales. I haven’t put a lot of thought into the question of how to produce this specification, or what tools would be needed. The point was to produce an examplar of what the output should be - and then to worry about the input. If this specification achieves it’s goal, end implementers - from programmers to CIOs - can look at it for a few minutes, and then say, “right, I understand this. Let’s go build something.”

Maybe this proposal would be v4. Maybe it’s just v3A. Certainly several people who’ve looked at it said it was just a better way to implement v3 (or the only possible way). But there’s some real change too. Perhaps the biggest is that in the existing v3 process, the RIM is a jealous idol - it suffers no competition. In this world, where the design is done in an open space (ontology) rather than a closed space (classes), there’s space for other inputs, other perspectives.

What now? I’m interested in commentary on the proposal. If there’s enough interest, I’ll setup a wiki. Please read RFH, and think about whether it’s a good idea or not.

Update: Rene, who’s been working with me on this, has contributed this introductory video: