Charlie Mead sent me this, from the NCI CBIIT Enterprise Service Specification Team, since it’s quite relevant to several of my posts.
This diagram is a different way to look at my comments about both the Context of Interoperability, and whether we need Semantic Interoperability. I wrote:
HL7, Interoperability in the worst case
But the fact is, interoperability projects don’t always exist in the worst case. On the y-axis, the degree to which you need semantic interoperability. On the x-axis, the scale of the interoperability exposure. Concerning the graph, Charlie says:
The overarching motivation of the graphic and trajectory line: trying to figure out how to communicate a commitment to “making easy things easy” aka “linear value proposition” aka “just enough semantics, just enough security, just enough specification, etc. etc., etc.” Note that “making easy things easy” does <<not>> mean that “hard things become easy.” They’re still hard..
I want to know how this applies to HL7. There’s certainly a widespread view that we’ve made the easy things hard. Where do we need explicit semantic interoperability in the instance, where do need it implicit in the instance (i.e. it’s in the definitions), and where is it just completely spurious?
I’m not going to propose an answer right here and now, other than to note that in a single exchange, different parts of the content probably have different answers. But I think this is a very pertinent with regard to the issues in front of the HL7 Fresh Look Taskforce.
Interesting graph, I note the top right hand corner looks to be the place to be. Do they have some demo code available that shows how full ECCF Compliance yields cross enterprise computable semantic interoperability. I’m a download and tinker with it kind of guy. I think the concrete implementations that they have done to prove its applicability will help me understand the full advantages of this approach. Sort of a picture is worth a thousand words thing. An sometimes hard things do become easy just because tools have been built to make them that way. Consider this blog, in 1998 creating it would have been really hard, but because the tools are readily available it is really easy. Tools to make hard things easy are very important, and should not be overlooked.
> the top right hand corner looks the place to be
Does it? When do you actually need computable semantics? And I think it’s better not to be in a community if you don’t need to be. The message of this diagram is to you pick where you should be, and then choose the specifications to get you there.
I thought that was the way HL7 was headed with SAIF or a least a lot I have read about SAIF. If you truly are looking at just enough interoperability to get the job done then CDISC is a good example. Inter-operating your CDR with CRO’s via ODM is very straightforward, likewise creating STDM for transmission to the FDA, not a problem. They are much more focused on the use case. Like CDASH, they focus on a glaring need and give just enough to make the rest of your work pretty easy.
As SAIF was, yes, it was totally focused on the top right hand corner. But this generated some ballot comments, and I would like it to cater for more of this diagram.
No … SAIF was always focused on letting the community define its own terms. The point was in the definition, not a pre-determined destination. As it exists now, few communities need rigorous semantics.
Having said that, some do, and some do and don’t realize it (like some implementations of clinical research). The SAIF was only ever about having that conversation and making the terms explicit.