HL7 Fresh Look Task Force

The HL7 board has authorized a new “Fresh Look” Task Force to examine the best ways we can create interoperability solutions, with no pre-conditions on what those solutions might be.   The idea is that, knowing what we now know from what has already been created within HL7 and by other groups outside of HL7, what would be our best approach to interoperability solutions?

I have accepted an invitation to be a member of this task force. It’s my belief that this is a real fresh look; none of the sacred cows are off the table for re-examination.

What’s the task force going to focus on?

I worry that the fresh look will get distracted into arguing about information modeling methodology. HL7 folks are real good at that (I am too). We do need to do that, but to my way of thinking, that’s not our problem, and we can’t get distracted by that.

Instead, I believe that we should devote time to considering how we assess “success” in a fresh look. What do we are we trying to do? What do our customers want? What exchanges are we trying to serve? Are we doing syntax or semantics? Does the market even want semantics? HL7 has two quite different stakeholders in vendors and large programs – can they agree on what they want?

Side Note:Vendors want “Drive by Interoperability”, large programs want something rather different. I think I’ll write a whole post about that (see here).

Note that this is a outgrowth of the v2/v3/cda taskforce – so it’s not about choosing between them. Which is why I don’t want it to be (just) about information modeling.

So who is going to be consulted?

Well, I don’t currently know who else is on the task force (Stan Huff is lead). But I know who’s being consulted. You are. Please think about what I have above. What do you want from HL7? What does your company / government / provider want from HL7? How would we (HL7) know whether we have succeeded?

Either comment here on this post, or write a blog post somewhere else, and let me know about it, and I’ll add a link below. If there’s enough interest, I’ll host a wiki for comments. Stan says, “Please ask for input from everyone,”  so pass this link on – we want as many people to comment as possible. Even Barry Smith and Thomas Beale ;-). (Actually, seriously, I had a long chat to Tom about this last night, and I’ll be adding another post that tries to capture some of what we talked about.)

I’m all ears…


  1. Ian Cheong says:

    I think “interoperability solutions” is off beam from a marketing perspective. If you want to sell something to clinicians and hospital management, you need to be able to save time/money to justify them spending time/money.

    Over the past decade or two, the navel-gazing informatics community has been playing intellectual games, while life in the real world goes on and not a whole lot has changed from where I sit as a GP/informatician. So yes we are communicating electronically but not saving much time compared with the old paper systems.

    Things which should be standards-based and automated aren’t because nobody with authority has created a legal or otherwise compelling environment making this necessary.

    So if you want a real fresh look, examine the real information problems that exist in the real world and plot a pathway to fix them in a cost/time-efficient manner so there is a no-brainer payoff in 12 months. Then the world will pay attention and move forward.

  2. Grahame says:

    Hi Ian. Long time no see.

    Some of this is what I though we were doing. What particular problems do you think we could focus on? Are you tracking the direct program in USA?

  3. Andrew Hudspeth says:

    I concur with Ian that a major disincentive to building integrated systems exists in the lack of current legislation to effectively pull together the good but esoteric works of NeHTA into a more constrained framework, something that providers and vendors can then move forward with in confidence. The field of possibilities is far too wide, so nobody has sufficient confidence to commit themselves to a given path when there’s every possibility the Federal Government may ultimately legislate for a different model.

    Contrast this with New Zealand, where legislation effectively constraining the available choices was introduced early on in the piece, providing parameters that all concerned could move forward with. Yes, I know New Zealand had some advantages … no state feifdoms, etc., but they’ve had an integrated and effective eHealth landscape for a decade or more now, while Australia continues to wallow in a limitless sea of possible approaches.

    As I understand it, simple practical decisions such as going to tender for a single messaging-backbone provider, charged with adopting national standards (such as they were), delivered a plug-and-play approach to N.Z. providers and vendors that facilitated both development & uptake.

    I think we’ve become too bogged down in standards, with far too little in the way of implementable initiatives to complement them. Standards are important, but we’re not going to get far if there isn’t also simultaneous progress in legislating to constrain the parameters around deliverables.

  4. […] Grieve’s recent blog entry on the HL7 Fresh Look Task Force seems a good excuse for me to have another big picture look at e-health. The fact that HL7 is doing […]

  5. Larry Singer says:

    Hi Grahame,
    One issue that I think needs to be looked at is message vs document. Part of this is about ownership of and access to that information. It is also about duplication of data and provenance.

  6. John Davidson says:

    For me (us) standards have never been a real problem, except getting vendors to look at the Australian standards, rather than the nebulous, generic HL7 “Standards” that seem to float around.
    Out problems have been mainly around the semantic area. In fact, I would not be exaggerating to say that 99% of problems are semantic in nature.

    I think that a (huge) gap has developed between various standards, and the messages’ semantic content. NMDS and NHDD seem to be divorced from messaging, with the result that every time we engage with a vendor, they look blank-faced at me when I talk about messages from the semantic viewpoint. In fact, we find ourselves going over the same ground with every vendor/project, repeating the same work over an over.

    I would like to see messaging standards and things like NHDD tied tightly together, so that everyone has a clear base to start from. This would solve many of the semantic problems. Then we would have time to do the interesting things.

  7. Grahame says:

    #All – this question is about HL7, not Australian e-Health development. Having said that, I share the frustrations deeply. I so wish that AIHW etc would come to the table with the standards community.

    #Larry – would you like to expand? messages are just documents in transit – but we think about them differently.

  8. Steve Korossy says:

    Good luck with the fresh look. Many years ago we tried to invigorate the Australian HL7 interest by producing cook books as well as AS4700.x versions. I found this work valuable and always refer our business partners to this work. However we are still a long way distant from achieving plug and play connectivity. More work needs to be done on standardising the data sets used (the data values, codes, meanings of codes).

  9. Pat Gallagher says:

    Tend to agree with Ian Cheong but with a twist. Health informatics is very top down and ‘complicated’ – translates to elite and expensively indulgent in time and resources. Whereas, in fact, ‘interoperability’ is not a technology problem, it is a people problem. We need a bottom up evolution between people in healthcare to drive change that removes paper, task duplications, bureaucracy, manual legacy habits and all the other perceived self important ‘complications’. Exchanging information that is intuitively easier and better for the people will create change and subsequent interoperability solutions will ‘come’ naturally. As many other industry sectors have tackled and implemented years ago. This awareness raising is of course not a HL7 responsibility – but until there is critical mass enthusiasm and demand for change, from over 500,000 Australian care-giving stakeholders, the whole situation is navel gazing. Global supply and financial data exchange networks were built one-step-at-a-time, inclusively from and for the coal face. Why? Because the source of originating and reticulated DATA is with the people working at the coal face – not in the IT Department, not in the policy gabfest communities, not in academia and certainly not in the standards community. These latter groups are there to serve the coal face user, not the other way round. Getting people to act interoperably is slow, boring, unsexy, simplistic and yet demonstrably compelling work for change leaders to undertake.

  10. Michael Bottos says:

    Hopefully HL7 will have implementers on the Task Force as well as HL7 members who tried to implement but failed.
    In order to fix something you have to find out what’s broken.
    Hopefully there really are no sacred cows,
    like the RIM, or
    the definition of semantic interoperability, or
    what really is the machine processable standard .

  11. Grahame says:

    #Michael : What are implementers? I do not know anyone in HL7 who does not implement one way or another. And what is failing to implement? I think that nearly everyone agrees that you can make any specification work if you work hard enough. It’s a question of whether the hard enough is justified.

    • Michael Bottos says:

      I am a member of HL7 who hasn’t implemented, that being version 3. Most who fail to implement just walk away from HL7.
      Here’s an analogy that I think will help.
      Let’s say that you are a program manager (HL7) in charge of a specific fighter jet program (the standard). Your task (HL7 Fresh look Task) is to improve survivability of the fighter aircraft. You start by examining all of the fighters that return to base after a mission (implementers). You make good progress, but the percentage of returning aircraft is the same. What have you forgotten? Well, you have to go out into the field and examine the aircraft that got shot down and never made back to base (non-implementers, people who quit HL7). If you don’t do this, the performance & survivability of your aircraft will never improve.

      • Grahame says:

        please contact me privately to further that discussion then

        • Michael Bottos says:

          I posted here b/c i wanted the discussion to be public. The current email discussions on the HL7 listserv are not viewable outside HL7. I also am not posting there b/c i didn’t want to be adversarial. I just wanted to know this effort by HL7 is mainly internal or if some sort of outreach is planned.

  12. Larry Singer says:

    Traditionally documents are not messages in transit.
    In V2 there is no document. The message is all there is.
    In V3 the model has been separated into services, messages and documents.

    Maybe rather than using document and message I should talk about datasets that need to be added to the clinical record and datasets that need to be sent to someone. For instance a referral is something that the referee needs to be told about. The referral can (should) be treated as a document but there is also the communication component of this.

  13. Thank you for calling for my opinion.
    Congratulations! I think this is a bold and positive look at moving forward a powerful standard that has, in recent years, been bogged down by unnecessary complexity. Please note that my focus is on the HL7 standards only from a real world requirement perspective.

    A fresh look IMO, should start with a relook at the fundamental needs of the user (and not goals of the organisation).
    So what does a user want? In my opinion the following:
    1. Interoperability
    2. Simplicity
    3. Un-ambiguity
    4. Ease of implementation
    5. Cost effectiveness
    6. Accessibility
    7. Stability
    Some of the points will of course clash. For example if you need un-ambiguity, simplicity could be a problem. Stability and accessibility requires a lot of cost components, therefore cost-effectiveness could take a hit. Never-the-less we need to find a practical middle ground. We should remember that there is nothing like a ‘perfect standard’ and it is better to have a working standard that works *now*, rather than a perfect standard that is never ready.
    Next, we all come with some kind of past and baggage – something that cannot just be thrown out of the window, to start afresh (that would be a horrible waste of time, money and effort).
    So what do I see here as baggage?
    1. HL7 V2.x – A decent working standard with some crimps – not perfect, but a highly workable, real world standard that 95% of the world uses.
    2. HL7 V3 – A good concept (towards the perfect standard) that has somehow become so complex and convoluted that it is practically unworkable for the ‘John Doe’ implementer (especially if you need to design a single message from scratch).
    So what is the way forward?
    Can we do away with V2.x? Impossible, it is the work house of the HL7 world.
    Can we do away with V3? Difficult, as too much of effort and money has gone into it (not forgetting egos)
    IMO this is how I see a possible way forward.
    1. De-clutter V3. Let the V3 committees do the entire RIM > MIM > etc > message magic, internally.
    2. Formalize specific message templates (similar to V2.x ADT, ORM, ORU, etc messages) based on healthcare usecases (this is already happening informally).
    3. Create a document (with chapters similar to V2.x) containing the templates in xml format with detailed explanation for each field. This document should also contain a V2V3 data mapper for each message.
    4. Create a simple freeware tool that would link to an online updatable Db and map each *constrained* V2.6 message to each of these V3 message templates and vice versa
    5. Release this document and freeware on the HL7 AU site for download by all HL7 members.
    6. Celebrate!
    I shall be happy to contribute my time and effort to support this process.

  14. Tony Shannon says:

    Dear Graham,

    Many thanks for the open invite to comment..

    We haven’t met and I should declare I’m involved with the openEHR Foundation but I hope the comments I make are useful to any eHealth standards bodies….

    You have asked “What do you want from HL7?”
    Let me answer more broadly “what do I want from eHealth standards bodies”

    1)Firstly an acknowledgement that healthcare is a complex adaptive system, where change can not be imposed from the top down, but understood as an ecosystem where change needs to be fostered top down and bottom up.

    2) Secondly an understanding that Healthcare needs to change and improve.. which involves people, process, information, technology, some standards and the pursuit of greater value for money (regardless of what system you are in)

    3) An acknowledgement that healthcare processes remain poorly supported by health IT in many fields ( I’m an Emergency Physician where needs are great but current solutions are not), eHealth standards bodies must take some responsibility for the current state.

    4) Commitment to disrupt/shift the healthcare IT market towards delivering better value for money via better interoperability, greater ease of scalability, greater ease of maintenance..

    4)Standards should help with this.. therefore I believe I need a healthcare process related service oriented architectural standard, with related messaging standards and terminology standard etc.. which would be currently served by a mix of openEHR/ISO/CEN , HL7, SNOMED CT, IHE etc etc., so all players need to admit they don’t hold all the solution.

    5) The disconnection between standards bodies doesn’t serve us well at the frontline.. so greater collaboration between them is needed.. my own current belief is that the lies in greater collaboration on open source tooling, that primarily meets the needs of those at the frontline, using standards where they iteratively and pragmatically add value, not just to be debated for debates sake..

    6) As you may be aware the US VA are moving to a redevelopment of their EHR via an open source ecosystem..I would encourage all eHealth standard bodies to be looking at how this may provide a natural means for us all to partake in greater collaboration towards the “openly architected, modular, and standards-based platform” they outline in their proposal..

    Hope these personal comments are helpful..
    More details on some of these perspective are here for those with an interest..

    Thanks again,


    Dr. Tony Shannon
    Consultant in Emergency Medicine, Leeds Teaching Hospitals
    Clinical Lead for Informatics, Leeds Teaching Hospitals
    Chair, Clinical Review Board, openEHR Foundation
    +44.789.988 5068 tony.shannon@nhs.ne

  15. Dan O'Brien says:

    To put it simply, something is very wrong with HL7 3.0. Here are my comments:
    1. It’s overly complex. I have a PhD in Computer Science and have been working as a computer scientist for many years. This is the most complex standard I have yet encountered. I keep trying to find a way to understand it, but I cannot seem to plug the holes. Which gets me to my next point:
    2. The documentation is terrible and incomprehensible. This is probably an indication of a poorly formulated framework rather then just bad writing.
    3. The documentation is not available unless you pay for it and it’s not cheap! How can we base a national standard on documentation that is not freely available! That is inexcusable and to me an indication of the closed nature of this endeavor by the HL7 committee.
    4. The documentation is poorly organized. At the very least there should be some kind of roadmap like: Start with this document, then this one. How many does one need to read before understanding the Clinical Document Architecture?
    5. How about a tutorial on the Clinical Document Architecture or the RIM with concrete examples of it’s use.

    Whatever process has been used to create this fiasco needs to be changed.


  16. Grahame says:


    There are CDA tutorials available for free or cheap. Otherwise I agree with your comments about documentation and complexity. As for paying for it – it’s a hotly contentious issue in the community. I very much wish it would be free, but it’s a mexican stand-off between revenue and adoption.

    #All thanks for all the comments. I’m trying to figure out how to report back from the fresh look taskforce

    • Kevin says:

      You were missed at the last meeting. You need to show up if you don’t want to keep getting volunteered for things…

  17. Dan O'Brien says:

    I’d appreciate a pointer to some CDA tutorials
    Regarding the lack of free documentation I think that bears on how the HL7 committee is out of touch with what creating standards is about and reflects on the poor process by which they are making decisions. A national standard should be free! If the committee is unable to do that then best not to do it at all.

  18. Dan O'Brien says:

    Thanks for the info. However, regarding the tutorial link, there is an e-learning course listed there, but it is sold out and the next one doesn’t start until mid August. So again, where are the free tutorials or even one that I can pay for an not have to wait until August?

  19. Grahame says:

    #Dan – oh man, I don’t know. I’ll ask around

  20. Jozef Aerts says:

    One of my main problems with the XML implementation of HL7-v3 (besides the enormous complexity) is the refusal to use native XML (schema) datatypes such as xsd:date, xsd:datetime, xsd:time, xsd:boolean etc..
    Instead the wheel is constantly reinvented. This gives enormous problems for validating instance files (one needs to write complex software for that instead of doing simple schema-validation). For example, a date of 20110229 is not recognized by the schema nor schematron as being a non-existing date. If instead the schema type xsd:date would have been used (i.e. the date would be expressed as 2011-02-29) then a simple schema validation would immediately report it as being a non-valid date.
    This denial of the usage of basic XML datatypes also leads to enormous problems with interoperability with other standards, such as those of CDISC (and many others).
    This is just one example of many where one refuses to use the virtues of XML itself. So I strongly believe that XML specialists should be involved in the development of the standard and the schemas, instead of automatically generating the schemas from UML diagrams, which is well known to always lead to disaster.
    I also agree with the other authors that the standard and documentation should be completely free, i.e. without any charge (also see the “ten commandments for effective standards – http://www.assero.co.uk/2011/ten-commandments-for-effective-standards/). It is totally inacceptable that one has to pay for something that is intended to become a national standard. Unfortunately ISO(-21090) made the same BIG mistake.

    • Grahame says:


      We do use native schema data types such as xsd:boolean, xsd:string in all cases except for one: dates and times. The decision not to use the dates and times provided by schema wasn’t taken lightly – in fact, with considerable reluctance. But what else can we do? I do not understand why schema doesn’t provide a date time with flexible precision. If they’d fixed decimal to 4 decimal points, no one would use it – same with date. I do think we should’ve worked harder to use the schema data types on system timestamps.

      As for payment, it’s not HL7 that makes itself a national standard; it’s just a volunteer standards body that writes standards. If national governments want to choose HL7 standards and make them national standards, then it’s their responsibility to organize how distribution works. While I wish that the standard was free, I also wish that people would stop blaming HL7 for decisions made by other parties.

  21. Jozef Aerts says:

    date/time with flexible precision: xsd:gYear, xsd:gYearMonth, xsd:gMonth, xsd:gMonthDay, xsd:gDay.
    In CDISC we defined following types (exactly what you are asking for) based on the above types (through unions): partialDate, partialTime, partialDateTime, incompleteDate, incompleteTime, incompleteDateTime.
    Is HL7 datatype “BL” really based on xsd:boolean?
    Something I am also always surprised by is that BL has a nullflavour. I don’t like nullflavors at all anyway: one can imagine a million reasons why a value is null … Another major design error in my opinion.
    So if HL7 specs (similarly ISO-21090) are not free of charge, who will want to use them then? Shall the German government pay HL7 for 80,000,000 copies?
    Should we blame governments for wanting to use HL7 standards? Your answer suggests governments make a big error by wanting to use HL7 standards !!! In my opinion, a standard is not worth the name if it is not free (i.e. completely open).
    But let us keep this discussion positive: I sincerly hope that the next version of HL7 (v4?) does take all these into account, so that we can finally get to a good set of standards for healthcare that are also implementable and interoperable with other standards.

  22. Grahame says:

    Well, I’m not sure what the deal is with those dates. Agree we could have defined unions. I’ll investigate. Yes, the BL type has an attribute value : xsd:boolean. As for nullFlavors, see here: http://www.healthintersections.com.au/?p=262

    With regard to cost. Standards cost $$ to produce. It doesn’t come for free. Just like any other standard the government could chose: it costs money. ISO-21090, you buy from http://www.iso.org for the same cost as any other standard. I agree it should be free for use.

    I too hope that the next version of HL7 will take all these things into account

  23. Jozef Aerts says:

    Short remark: all CDISC standards are for free for everyone. They are produced by volunteers that do not get any money at all for this. The CDISC organization has only about 10 employees, and lives from member contributions and grants. Even non-members do get free access to all the standards, and even to the implementation guides. With all the money that is currently available for EHRs in the US, I do not understand why HL7 can’t make the specs and other materials available for free.
    Thanks for the Nullflavor link. I will read it.

  24. Jozef Aerts says:

    Fortunately, in reality this is not the case.
    I agree that there have some discussions within CDISC in the past to give only members access to the standards, but these discussions have now been finalized, and the decision has been taken that all standards come completely for free for everyone. The advantages members currently have are mostly in the area of serious discounts for conference attendences and for training courses.
    I sincerely hope that that this policy also remains so in the future, and recent discussions with CDISC staff seem to indicate so.

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: