License Restrictions on Terminologies
Jul 17, 2014One of the things that we can do in FHIR that can make a significant contribution to interoperability in FHIR is to describe how to use common terminologies in a common fashion. Interoperability is a waste of time if the way one organization uses a code system is different to way another one does. And I’ve learnt, through my implementation experience, that it’s not just enough to say “use this code system”, or “this is the namespace for the code system”. There’s a lot more to say, about what valid codes are, how versions should be identified consistently, how to exchange information about subsets - which relates heavily to agreeing how to use the code system, etc. But the terminologies themselves seem hell-bent on making this impossible by their licenses. The problem is that the licenses divide the world into three categories: the provider of the terminology, the creators of implementation systems, and the rest: unlicensed entities who have no rights to the code system.
HL7 and it’s specifications don’t fit into the first two, so end up in the 3rd category. Consider these two license statements:
Licensee is prohibited from distributing the [tx] or subsets of it, except (a) as an integral part of computer applications developed by Licensee for a purpose other than redistribution of vocabulary sources contained in the [tx] and (b) as also subject to (additional rules)…
and this one:
The Licensed Materials may be used only internally at a single entity within your facilities in the United States or its territories, only by you, your employees, or agentsYou may not sell, sublicense, assign or transfer the Agreement or the Licensed Materials or any copy, modification or merged portion or version of the Licensed Materials to any party
With licenses like these, it’s not possible for HL7 to say some really important things about how code systems are used, or to provide examplar information. Or sometimes, to even mention their existence.
And also, btw, there is no way to seek assistance from some external provider of specialist advice. I know that goes on all the time anyway, despite the license, but when you’re writing an open public specification, that’s not really an option.
So for the meantime, the FHIR specification will not be able to describe to it’s user’s how to interoperably use a set of useful and important code systems. Because remember, corporate control over licensed materials (even if they are free) is more important than making things work well in the real world.