Continuing on from the basis established in the previous post, here I will say what I think HL7 could do to help here. My suggestions are as follows:

• For practical reasons, it should keep going with HL7V2
• HL7 should continue to exist as a meeting place for great minds, and possibly evolve into some sort of conference.
• It should concentrate on obtaining, recording, organising e-health requirements. This probably needs its own framework and/or ontology. This is serious work and requires serious resources.
• And from requirements, conformance criteria & models could be developed. Not the narrow ones of today.
• if it has any pretensions of being the ‘one sole heaven’ in the intellectual design space, it will have to be far more ecumenical in how it does this. I am actually not convinced that this is HL7’s business at all, but if it were, the following would be needed:
• it has to engage experts from software engineering, ontology, UI, and other IT domains;
• it has to abandon the RIM. There, I’ve said it. It has useful lessons, but it is not the way of the future. Getting rid of it would also simplify CDA for the future; (actually, bits could be retained for use in downstream HL7 message generation tools);
• it has to abandon the RIM-based refinement methodology. This, to be fair, was a real attempt at solving a very difficult problem (and it certainly helped me work out how to make archetype specialisation work), but it mixes up classes, instances and constraints in a way too tangled to be usable;
• it should forget about doing  any real modelling directly in XML schema. This means converting CDA templates to openEHR style archetypes and templates or maybe just UML. XML schema can only be used as an output format; it simply fails to properly express many basic characteristics of object models, constraints, propositional logic….(I will make a separate post on this topic).
• it would need to agree to a new architectural paradigm; obviously from my point of view, I would say reference model > archetype > template > generated components + query language as we do in openEHR; regardless, it needs to understand the need for a clearly articulated meta-architecture rather than an implicit one;
• it should adopt the openEHR archetype & template formalisms as a starting point for expressing standardised content models (it should be sceptical at the start, so I would expect the need to demonstrate why these formalisms actually work). It’s not poisonous, it just has a few {} and <>, and is perfectly expressible in XML;
• it would need to adopt a practical reference information model. There are useful resources from CDA (minus the RIM stuff), openEHR, CCR, 13606, and probably DICOM SR and maybe some bits of IHE;
• it would simply have to resolve the problem of clinical data types. The ISO 21090 standard is not the answer, because it is infected with the HL7 upside down inheritance + ‘profile for your own use’ approach;
• it would need to stop trying to re-invent the known basics of software engineering (HDF), SOA (SAIF) and object modelling. This is wasting a lot of time and achieving nothing useful in my view;
• it might get into the business of developing and managing ‘detailed content models’ (DCMs), or archetypes as we call them. This would require a quite different type of constituency – mainly physicians, and in our experience in openEHR, it has to be done mostly online, as for most of those clinicians, spending days in meetings is not an option. On the other hand, areas that HL7 knows a lot about including lab, Admission/Discharge/Transfer, and re-imbursement are content areas that need such models, so it seems sensible for HL7 to be properly involved, even if not running the activity. My recommendation here would obviously hinge on the adoption of the openEHR archetype/template formalism, a jointly developed meta-data and resource model, and an online model manager such as openEHR’s CKM. Redeveloping all of that de novo is 10 years’ work.
• it would need to get rid of committee-based design and balloting for nearly everything and instead help set up a small number of groups of professional designers who can create properly engineered artefacts. The only things that should be ‘balloted’ (and I would prefer the IHTSDO 3-phase approach) would be specific releases of specific downstream generated artefacts;
• in fact it just needs far fewer committees – maybe 5, with some interest groups that discuss specific topics;
• clearly, adjusted relationships with IHTSDO and IHE would be needed. Any relationship with OMG might be of a more fundamental nature, but OMG would need to get its own house in order to make things work. Some relationship with openEHR could be established. A clear division between requirements shops and solution shops could inform all of this.

The great strength of HL7 is its people, and their deep knowledge of the domain. Most of the current technical architecture (excluding HL7v2) could be obsoleted in favour of better things.

I personally do not believe in ‘committee-developed standards’, nor ‘volunteer standards work’. Any future world in which these strongly feature will be a revision of the past. Therefore we need ways of making heaven 2.0 sustainable and relevant enough so that it can attract funding. Committees are really only useful for defining priorities and deadlines.

Whatever happens, I can’t see it being an HL7 -only effort. It will need to involve other key players in the e-health standards and systems business. If so, then there would be steps that might need to be taken by those organisations to inch toward heaven 2.0.

I believe I have now said a sufficient number of shocking things for one post, and will now retire to a safe place, to await the inevitable…