One of the things that people say about HL7 is that it is no longer producing specifications that are useful for implementers, that give implementers what they want.
This message was certainly given a thorough airing at the RIMBAA Q6 Wednesday meeting in Orlando recently. The Wed Q6 meeting is a odd meeting – it starts during the cocktail party; people have to give up a drink and go sit listen to presentations. Attendance is a bit variable. This time there was maybe 40 people there – an attendance record by a long shot (I don’t think I’ve missed any)
RIMBAA itself is an odd duck – a group of people who share an interest in using the RIM as the object model at the heart of their application. I for one have a hard time getting my head around using a denormalised half ontological model designed for interoperability as the basis for a logical persistence store – these are very different goals and compromises, but I can’t argue with their enthusiasm, nor the fact that they are building real world, useful clinical applications. So they’re certainly a bunch of fans of the RIM (a category of people who sometimes seem to be in short supply).
I was asked to be in attendance, along with Lloyd Mckenzie, to talk about PIIMs, an idea that I came up with in the first place, with Lloyd (though Lloyd named them!) and that was raised during the spirited discussion on the Fresh Look Taskforce on the RIMBAA email list. But the RIMBAA Q6 meeting was advertised as a meeting about the Fresh Look Task Force, and many people came along to talk about that, not to listen to Lloyd and I drone on about yet another weird modeling acronym.
PIIM, btw, stands for Platform Independent Information Model. It’s not unrelated to the point of this post, so I’m going to explain it. There are two main ways that HL7 implementable models (i.e. models that are ready to be be part of messages, documents, or services) are described: as “RMIM” diagrams, and as an XML schema. The problem with this is that RMIM diagrams are not standard UML (a claim that I will define and defend in another post), and the schema, as well as not having any formal standing (another subject I’ll take up in separate post), they’re, well, schema. They might describe XML but they’re not any way to develop software (though they make some people happy).
A PIIM is a proper UML model, that describes the same instance as the XML schema, only at a computable level, not a technology level (i.e. PIM not PSM). It’s not that RMIM diagrams aren’t useful, but that they’re several transforms away from being concrete. PIIMS are standard UML (no fancy stereotypes, no hidden properties, no abstract data types) and therefore concrete. We could produce PIIMs for all of our v3 models – it’s just a question of resourcing it, and from my point of view, the discussion was to find out whether people thought that was worth doing, whether it would fill a hole in what HL7 delivers to people.
The answer appeared to be, “just a little” – some people are excited by them, but for most people, not having a UML definition of the exchange specifications is not the problem, and HL7 making and publishing PIIMs wouldn’t make any difference to whether v3 would meet any goals or not. That makes sense to me, btw. UML is good for conceptual descriptions of object systems, and not so good but widely (ab)used for formal definitions of object systems (a la MDA) but there’s no accepted standard canonical format for exchanging object instances between any systems defined by a common UML model (not that there is even such a thing as a common UML model across the UML tooling stacks).
After we talked about PIIMs, the discussion turned to the wider issues of the Fresh Look Task Force. People were pretty interested in that, because the Fresh Look Task Force is somewhat opaque (as of June 14 2011, there has been some notes released to the participants, but no formal public report yet, which a lot of people are disappointed by).
The outcome of the discussion was that we set up a wiki page (http://wiki.hl7.org/index.php?title=Fresh_Look) where everyone in the community can make comment about what they’d like the fresh look task force to achieve, to document problems, and propose courses of action. I think everyone should go and take a look and contribute. HL7 is first and foremost a community, and so we’d like to know what the community thinks.
This post is the first of a series where I’m going to pick an issue I see in (or from) that page, and seek further focused contributions.
What Implementers Want.
The qestion I’m going to pick is, what do implementers want? What specification could we publish that the implementors – the people who choose and use specifications – really want. That would make them go, “yeah, that’s the thing I want”.
What, then? It seems pretty obvious to me that what v3 is isn’t rocking people’s boat. That message was given a thorough airing at the RIMBAA Q6 meeting.
But what do they want?
One stakeholder spoke of the challenge of working with implementers that don’t know the meaning of the word “serialisation”. It’s hard for me to know what to make of that. Should we not use the correct terms because some implementers don’t know them? If we didn’t, other implementers would not be happy at all (me!).
I have some pretty solid ideas that I’m working on for the fresh look taskforce. But before I start rolling these out for debate, what are the criteria by which a good specification can be measured? Comments welcome here or particularly in my Desiderata for a good specification on the HL7 wiki.
p.s. Implementer or Implementor? (beats me)