HL7 September Ballots: The Good, the Bad, and the Ugly

I should probably do this in reverse order, so that I end it on a positive note.  Yesterday was the close of the September ballot cycle.  I reviewed several ballots, but three stood out for me.  Here they are from the worst to the best.

The Ugly: Provenance

In the we need a template for every possible combination of ways to specify author and document, section or entry, this one takes the cake.  What you really need are three to five templates to represent authorship or assembly, and some policies about how they must be used in documents which conform to requirements about provenance.  This specification tries to make templates to enforce what is necessary for every possibility, instead of telling people what needs to be done in different circumstances, and expecting them to be able to follow some very general and simply policies.  Most of the requirements it tries to enforce through templates are already mechanisms by which CDA interprets authorship.  This one could use a rewrite to dramatically simplify it.

The Bad: QUICK

This one did itself in by providing evidence that it had the worst reason to develop a separate standard.  The image captured below is from section 4.7 of the overview:

The point being that if there really is that much similarity, then why not improve FHIR to meet the needs, or develop extensions.  We don't need yet another information model.  Yeah, I know, "it's ... and you have different requirements than ...," but I'm really over that argument.  

To their credit, they did ask: "Can (and should) QUICK and FHIR be harmonized into one model? If so, how could this be achieved and still meet the intent of both models? If not, how should the two models relate?"  

I'd get this one under FHIR Governance as quickly as possible and stop messing around with yet another UML model.

The Good: CQL

This isn't just good, it's actually astonishingly good.  In my early college years for my Microcomputer class, I once wrote a mini-operating system instead something simpler suggested by the instructor to solve the problem.  He presumed I had submitted something else I'd written for another purpose and didn't give me full credit until I complained to him about it.  I pointed out that it quite elegantly solved the problem he asked it to, and that when assembled (yes it was in assembly), it did exactly what he wanted (which was to support ANSI terminal emulation).

CQL looks like a similar kind of component.  It hardly looks like something that was prepared for an HL7 ballot, but frankly, it really solves the problem that it was asked to solve, which was to develop a language that would support Clinical quality and clinical decision support.  It reads well, and it has a certain elegance that things developed based on a simple model do.  I really liked this one, and it got a very rare affirmative from me on it's first ballot.  I suppose if I had been following it more closely I could have found some fault with it, but it actually looks pretty good.