Resources For Health: A Fresh Look Proposal

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:


  1. Grahame Grieve says:

    Actually, many people have helped me prepare this idea. Rene most of all – thanks. Also Tom, Russ, Ewout, Andy, Lloyd, Michael, Dale. Note that me thanking them for their input doesn’t mean that they endorse any part or all of the idea.

  2. Rene Spronk says:

    To me, RFH contains a lot of elements that turn it into an implementable standard. My main concern is not a technical one, but one of governance. If we assume RFH is adopted by HL7 as a next step in the development of HL7 version 3 – will we really be able to define a process whereby we can get agreement on the boundaries of the individual Resources? Sure, we can aggregate resources into other resources, but there is some lower boundary of granularity that all will have to agree upon. Especially on the clinical side of things that won’t be easy to accomplish.

    For those who’ll be attending the HL7 WGM in San Diego, As a co-chair of the HL7 RIMBAA Working group (the HL7 v3 software developers) I’ve requested Grahame to address RFH during a ➡ RIMBAA session (Tuesday September 13, from around 20:00 onwards). I’m sure it will be discussed at other venues during the WGM as well. RFH is strongly motivated by implementation concerns, which resonate some of the best practices we as RIMBAA have seen, so it’s certainly worthy of our time.

    ❗ To me, RFH certainly has the potential to blow some “fresh air” into the future development of HL7 version 3.

    Note: also see my full blogpost available at

  3. Ian McNicoll says:

    Rene’s point about governance of the boundary of each resource, and by definition, therefore, its granularity, is I agree a major issue. The start point, I believe, has to be that the resource/archetype is regarded as the single source of truth, even if this forces us to include some competing ideas, particularly differing granulaity of expression. Of course this is messy but it at least makes the messiness visible in a single, reasonably small space and therefore amenable to future resolution and alignment. By all means disagree about tge representation of ‘x’ but do so within Resource_x.

    Current minimum dataset methods, whilst operationally necessary, simply hide the natural messiness, and force people to work independently. Of course, this inclusive approach, does absolutely depend on the ability to further constrain the resource/archetype for operational use agreed by local stakeholders. Is this kind of layered constraint a part of the RfH idea? It brings its own governance challenges!

  4. Jim McCusker says:

    Get feedback from non-members. W3C working groups go out of their way to get feedback from people who will be using the standard, but aren’t active members of W3C. They even have a special category for people participating in working groups but don’t belong to member organizations: Invited Experts. Surveys, reviews of existing work, etc. are critical.

    Yes, this means taking criticisms from certain philosophy professors seriously and working within the group to address them to the degree appropriate.

    This is, of course, because W3C tries to make open standards that are available to everyone. If an organization lays claim to something that solves all things X, remember that plenty of folks might want to solve that too, and if it means paying dues to use your solution, they may very well go elsewhere, and organizations that produce closed standards can’t complain when not everyone is using their standard, because hey, market forces and all.

    Finally, make the right thing to do the easy thing to do. Yes, healthcare is complex, hard, etc., but so was global computer networking before IP. Discovering what to leave out can be more important than figuring out what should be put in.

    Getting this to happen is hard, but hey, that’s what they pay us the big bucks for.

  5. Ken Rubin says:

    While I applaud the inclusion of services among the nuggets that “survive” in this re-conceived model, what is represented in the early draft is what I would consider to be a very myopic, narrow-cast view of services.

    While “web services” can be considered in the context of a new technology platform alternative to traditional messaging, this is missing the true promise of achieving an abstraction of business processes with responsibility and authority for providing some outwardly-facing function and managing the associated data.

    Whether realized in “the cloud”, an ESB, or a proprietary SOA architecture, this view of application enablement differs greatly from the “pass the data” model, regardless of what transport is doing the passing.

    My specific point issues aside, I applaud you in raising the level of the dialogue to the types of issues that need to be discussed in a broad forum. Kudos.

  6. Grahame Grieve says:

    #Ken – REST is not (really) services, and are not intended as SOA. You would use RFH for SOA by aggregating the resources and doing SOA in the normal way

    #Jim – you’re right about consulting non-members. As for certain philosophy professors, they get listened to. And even addressed to some degree. Who’s to say that it’s the degree appropriate – or that any amount of listening would be recognised? And I really wish the standard was free for use.

    #Rene – thanks. and agree.

    #Ian. Governance and consensus around compromise are core issues that must be addressed. The conformance layer can be “layered”, though I think that this is a very costly practice, and should be used sparingly

  7. Diego Bosca (@yampeku) says:

    Having listen to Rene presentation, I have a couple of doubts
    first about ‘cond’: How is ‘cond’ condition expressed? is human or machine interpretable? How is ‘opt’ different from ‘cond’ with an specific condition?

    second, if data types come from ISO21090 (which already has nullFlavour), do we have two nullFlavour? (this and dataAbsentReason)

  8. Grahame Grieve says:

    #Diego – cond is only text. It differs from opt in that under some conditions, the content must be there. Rene and others have queried it too.

    nullFlavor has been renamed to dataAbsentReason. The data types are based on ISO 21090, but not actually 21090. “nullFlavor” is not actually “null”, which is endlessly confusing, even to long time HL7 insiders, so I have renamed it for clarity.

  9. Eliot Muir says:

    Hats off – I think it’s an excellent piece of work and definitely a step in right direction.

    It’s good to see promotion of the RESTful paradigm.

    I noticed the references to the Highrise APIs – they are beautiful to work with. We just completed a 3 day implementation with them – compared to the agony we went through with our previous CRM integration efforts it was an absolute pleasure. There is huge power in having the flexibility to insert arbitrary data where you want it in an application.

    I didn’t know other people in the HL7 world other than me were talking about them. Who are they?

    I think the approach you have here is a good start and it makes good sense to reuse some of the thought process from the RIM and V3. Things I like about what I see here are:
    1) Restful APIs
    2) GUIDs to uniquely and globally identify all the objects
    3) Ability to tie comments to any object allowing human descriptions of fuzzy concepts.
    4) A better data model than V2.
    5) Build it up by hand with a wiki – it is more scalable really since you can get more people involved without soaking up their time learning tools or fiddling around with Access 2007 vs. Access 2010 – see the commentary on the Truffola tool in the HL7 mailing lists recently.

    I see a some over lap of ideas I was hashing out here:

    I haven’t really had the full amount of time to fully read and understand the implications of everything in your proposal. Some feedback though:

    1) I think it would be better not to use inheritance to define a patient as a sub type of a person. The trouble with that approach is that people can do many things – I could be a doctor, and yet be a next of kin or get ill myself and become a patient. We wear many hats in life and data models need to be flexible enough to reflect that. Many software packages (like our old CRM) fail to allow for that flexibility.

    A simpler approach is associate additional data with a person if and when they become a patient. The other advantage of this is that it makes for a much less brittle data model that can be extended for new requirements as needs change. This is sometimes called “Aggregation vs. Inheritance”.

    2) I’d avoid language that speaks down to ‘implementers’. It’s enterprise IT speak and speaks to the totem pole that when you are the top dog when you no longer have to be a lowly coder. It’s going to reduce the number of people willing to take an interest in your material – if your goal is to reach people and influence how the industry is moving then try to positively address all your audience – if someone reads your document and thinks they are being targeted as a “dumb implementer” they are unlikely to become a proponent in the organization for your ideas – they might not be the decision makers but they can certainly be decision influencers.

    3) If you want to reach a broader audience, then simplify the language. I generally try to get my language down to about the level of 12 year old in technical documentation. I do it because I want to people to be focused on reading and understand my content. If you express ideas with less jargon it’s going to broaden their appeal.

    Anyway – go ahead at set up a wiki but make sure you use a WYSIWYG one – don’t pick one that requires arcane wiki markup to get started with it.

    (ah dear probably too much jargon in the above 🙂 )

  10. Grahame Grieve says:

    > Hats off – I think it’s an excellent piece of work and definitely a step in right direction.


    > I didn’t know other people in the HL7 world other than me were talking about
    > (highrise). Who are they?

    not in Hl7. you were one. it came up in some other purely IT places that I play

    > 5) Build it up by hand with a wiki – it is more scalable really since you

    wiki’s have their problems, though I’m not against them.

    > 1) I think it would be better not to use inheritance to define a patient as
    > a sub type of a person. The trouble with that approach is that people can

    On the wire, a patient is not a sub type of person. The relationship
    between the two is defined in the definitions.

    > A simpler approach is associate additional data with a person if and when
    > they become a patient.

    in one way, this is exactly what RFH does. On the other hand, it creates a
    new identity for the notion of patient (for integrity). We can discuss
    whether that’s good or bad.

    > 2) I’d avoid language that speaks down to ‘implementers’. It’s enterprise

    really? Because I’m one. down the bottom of your enterprise pole. And
    I’m happy to be one of those stinking implementers down in the mud.
    I wrote it first for me. But obviously we wouldn’t want to cause offense.
    I’m sure I haven’t caused any of that this week 😉

    > 3) If you want to reach a broader audience, then simplify the language.

    argh, and I thought I had. how can we not use the right terms? But I
    agree that the introduction is not yet direct enough – and that’s after
    4 rewrites to try and make it so….

  11. Brad Head says:

    And, I believe the new HL7 should not only be more XML centric, simplified, but also should allow for extensions.. and allow embedding of foreign namespaces to share information not yet dreamed of by the modelers. Extensibility should be factored in. All mature specifications allow extensibility. HL7v3 should too. This is not the same as the dreaded v2 Z-segment. It’s declarative, deterministic and controllable.

    • Grahame Grieve says:

      Actually, I think that foreign namespaces are far less declarative, deterministic and controllable than z segments.

  12. Ann Wrightson says:

    I like the way the discussion is shaping up, & recognize echoes of many HL7-WGM foyer-discussions (& HL7 UK TC discussions, come to that) from the last few years. In particular, it’s good to see so many of those threads being caught up into a constructive proposal.

    It would be good to see more about the relationship across to hData – maybe RFH provides a neat method to design hData payloads? The ability to build interaction profiles from atomic information services (see Ken Rubin’s comment) is an intrinsic aspect of hData, & I would be interested to see what you (i.e. GG) & Gerald Beuchelt’s team could put together in this space.

  13. […] of new irons in the fire this week.  Like Grahame’s Resources for Healthcare proposal, the HTML5 + Microdata proposal is gaining traction.  Not overwhelming support like […]

  14. Hi everybody,

    I am totally new to HL7/Healthcare systems. I have read several posts of Grahame – they are very educating, interestingly written and eye opening for me – to get an initial understanding of issues of healthcare interoperability for a novice.

    I have a couple of naïve questions. On the first glance the resources in RFH resemble the resources of RDF – you have URLs and you have relations between the resources. The data dictionary resembles OWL. An example of using Semantic Web technologies (Linked Data) + REST for interoperability can be seen in the field of software tools – Open Services for Lifecycle Data (OSLC) and the Jazz platform. Here is a nice video about interoperability between software tools . The description of Linked Lifecycle Data (Linked Data of software lifecycle management tools) is given here – and here – .

    My questions are:
    1. if you use resources and links between resources, why don’t you just call it RDF and leverage the existing software and tools for RDF and W3C standards related to RDF ?
    2. the same for data dictionary and OWL ?
    3. if using Linked Data principles + REST for creating interoperability between software tools is considered beneficial by the OSLC community – can the same principles be applied to creating interoperability between healthcare systems ?

    Here are two nice videos about Linked Health Data:

    I am sorry if my questions are too naïve or out of context. I would be glad to receive some explanations or links that could clarify the issues/problems with using the Semantic Web/Linked Data technologies for the healthcare systems interoperability. I am sure you have already discussed these issues and probably dismissed the Semantic Web technologies for some reason.

  15. Gokul B S says:

    Hi Grahame Grieve,
    Need few clarifications. I have just started on FHIR. Really it is modeled well. But could you please explain, if I have a very well working system in HL7 V2.x why should I need to migrate to FHIR? What are the benefits I will get upon migration? Expecting your reply…..

    Thanks in advance 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen


%d bloggers like this: