Letter to RFH Readers

Grahame Grieve 13-Aug 2011

This specification arose from the remit of the HL7 Fresh Look Taskforce: if HL7 started again from scratch with a new specification, what would a good specification look like?

Well, it would certainly be focused entirely on the web. Beyond that, many people pointed me at the highrise specfication as state of the art - simple and easy to implement and manage. So I started there (http://developer.37signals.com/highrise/index). From that premise, I wanted to build a specification that showed what could really be done. To do that, I built a specification that can actually be used for "doing" lab reports.

This specification is just a proposal for 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. When you read this specification, keep in mind that it's a work in progress - broken links (there are some) represent work that isn't yet done, and there's lots of todos. Also, ask, is this simple? Could it be simpler and still be functional? What doesn't it cover, what doesn't it offer? Will it still be so simple and easy/obvious to implement if it handles all this extra stuff?

This specification took a certain path, a certain amount of alignment with the internet. But perhaps, not enough. Should it be more focused on Microdata, per Keith's blog post about CDA R3? Should it strive harder for data alignment with schema.org per John Halamka's post, in spite of it's lack of support for so many recognised requirements in health (including many non-US requirements)? The microdata question arose after much of this was written. Rather than start again, I decided to finish this and then think about that stuff.

The other question many people ask is, where's JSON? UML? ISO 11179: What about [some protocol] - and there's been a lot of those questions. For further discussion see {blog post to be done].

Note for HL7 insiders

This specification is really different - altogether different from other HL7 specifications. Yet in many ways, it has real continuity with much of where HL7 is. While the patterns have been deeply re-organised, most of them are still 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
• The resources are based on the CMETs and RMIMS defined in v3. In most cases, they were modeled directly from the CMETS etc
• The conformance model started being 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

But having said that, the presentation is very different from our existing standards; the RIM is hardly visible at all, for example. It's important to understand that this is not about geting rid of the RIM; it's a recognition that much of the value that the RIM brings - rigorous modeling etc - doesn't need to be in the face of the implementers for them to benefit from it. This implementation is written for implementors - to be something they want to implement. They benefit from the rigor without even seeing it.

One big part of the difference between our existing standards and this specification is that this is based on a fine grained RESTful specification. It's really different to what we've done in v2, in messages, services, and documents, and it needs to be thought about completely differently - it's not a drop in replacement for what we have. The fine grained restful approach has it's strengths, but it also has it's weaknesses, and they are many. So the specification is designed around the ability to aggregate both the resources and the fine grained transactions into higher bigger exchanges, scaling all the way up to a CDA equivalent general clinical document.

This specification has 5 main parts:

A key part of this specification is that design by constraint is completely absent at the implementor level. Modeling by constraint is very important - it's a fundamental principle of the data dictionary layer, where the RIM lives. But implementation by constraint is not present. Instead, there is a series of concrete resources from which interoperable systems and specifications are constructed. The central challenge of this specification - one which is not answered by this draft - is 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 (it will depend on the resource type).

This specification was written by hand - all of it. That's not a process that scales. Not much thought has been put 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."

Thanks. I hope you enjoy looking at this specification. I certainly enjoyed the process of thinking through all this stuff.

Grahame.

p.s. One last thing: a question I've had - this is all © Health Intersections - why? It's taken me a lot of work to produce this specification. If HL7 wants to have a good look at taking this forward, then I will happily gift it in it's entirety to HL7. Until then, I retain copyright.

© 2011