Is SNOMED licensing actually holding back its own adoption and the development of good interfaces?

General
1

This might not be a super popular opinion and I’m posting it here to get feedback from an audience which is presumably quite invested in SNOMED as it is, and probably already has licenses.

For background I’m a clinician, clinical informatician, and software developer based in the UK. I’m well aware the UK has a ‘blanket’ NHS license for SNOMED use. However, this doesn’t cover me as an independent open source developer, and I still think that even with this relative availability of SNOMED here, actual development of SNOMED would be faster if there was a more permissive license around its use.

We’re always told that “clinicians should never really be exposed to ‘raw’ SNOMED, it should always be presented to them via a smart, intuitive user interface” - that guides them to the correct term for their needs. Well, I’ve yet to see a single example of a useful, intuitive SNOMED UI in clinical practice. If they do exist, they are mostly proprietary and not shared, no screenshots on the web, nothing. (Yes, I’ve seen the SNOMED UI examples, they are 7 years old, ng and not clinically that great) My theory is that a contributing factor to the relative lack of good SNOMED UI is the difficulty of obtaining a license.

I firmly believe that how we will eventually get these intelligent, clinically-helpful user interfaces is by the development and sharing of open source UI components, particularly web interfaces. This is how we got UI conventions via Bootstrap and Foundation and DaisyUI and hundreds of others. Open source (for the rest of the tech world) has a disproportionately large role in spreading good UI designs, good tooling, frameworks, best practice, education etc.

And the difficulty of obtaining SNOMED licenses creates friction in open source development - either cost or logistical friction. Code libraries (incl. utilities, UI, tools etc) that operate with SNOMED cannot include a copy of SNOMED, due to the licensing requirement. This makes it hard to provide a ‘batteries included’ toolset, and even though it doesn’t stop development (clearly some devs will get a license), I think it applies enough friction to affect adoption.

FHIR, from its very inception, took the bold (at the time) but very forward-thinking step of releasing the FHIR spec under the CC0 1.0 license, and in their licensing page there is this great explanatory paragraph:

“We dedicate the FHIR specification to the public domain using CC0 1.0 in order to encourage adoption of FHIR as a foundation for better healthcare around the world; to increase patient empowerment; and to promote the availability of interoperable health data for everyone who needs it.”

FHIR’s adoption has been spectacular, for any comparable health data standard. And consequently there is a lot more open source work for FHIR than SNOMED.
GitHub: fhir=1274 snomed-ct=76

Why can’t SNOMED do what FHIR did?

I realise by posting this on the actual SNOMED forums I’m risking antagonising a whole community - I’m not trolling, I’m genuinely posting this because I would like to see SNOMED proliferate and be universal, and have better clinical UI.

2

Hi,

In Member countries all it takes to get a SNOMED licence is registering with your NRC. In Belgium this is about 4 clicks and anyone can do it to use SNOMED in any product commercialised in Belgium and using the terminology. If you work at a hospital, you ask one licence for the whole hospital. If you have a private practice, your EHR provider has asked it for his product and you actually subcontract it as part as your EHR contract. Maybe in UK it’s not that simple but here I hardly see where SNOMED licencing limits implementation and use.

Aside form this SNOMED has now allowed all the content of SNOMED concepts and descriptions to be used freely in the global patient set. So that means all of SNOMED in now kind of open source for use except the relationships.

FHIR adoption is not yet spectacular. Everybody wants to do things in FHIR but almost nobody really uses it yet in live systems. And FHIR lacks what SNOMED has, what indeed Member countries fees pay for: a strict governance process, incredible high quality eLearning, a dedicated team maintaining the terminology and creating tooling. FHIR is a community. Everything gets decided on Zulip by however shouts most, is most respected and was there longest. Thought I a great fan of communities of practice myself and love the FHIR world too, this is still a geek tribe model not yet a formal governance of a standard. And the result is that there are as many FHIR implementations as there is FHIR geeks with often no consensus, no best practice, nothing normative (yes R6 is supposed to be that but it’s not yet out there), no place to get official advice from (Zulip is NOT offical endorsed advice, it depends on who answers you that day).

IMO FHIR needs to become more like SNOMED, get more rigorous in its development, get a solid minimal base of income beyond bootcamps and what EU gives for HL7EU, to move from the loose community into something structurally sustainable with a dedicated tech team, clear best practices, online education. Indeed there is actually a fee for FHIR too if you want to be HL7 member and vote in the ballots.

SNOMED has a community working voluntarily. I’m one of those. But it also has that base of service covered by staff that will remain there even if all of the people like me walk away. And this is why there is a need of money, at least a little bit of it, somewhere. SNOMED is also something incredibly dangerous. It’s a clinical language. It’s for primary use. Any ambiguous content could kill. So it has to be carefully curated by experts. It cannot be anything else than 99% good, advice cannot be offered by volunteers who don’t have any true responsability.

FHIR is nothing but an enveloppe. If you map your data model poorly to FHIR in or out and get meaning issues, it’s on your head, you did the mapping. It’s different with SNOMED which is a terminology thus the only representation of the medical truth once the clinician has selected a concept and walks away for his computer. That’s why SNOMED international also doesn’t allow anyone but countries to translate SNOMED CT.

Knowing the Belgian yearly fee for SNOMED, and running myself a community of practice that now has to become more like an institute, I can tell you one that SNOMED national fees are really more than correct for all they give in return and two that you need a baseline funding once you need to go pro on something, no way around it. WHO also has a fee for ICD and the rest. It’s invisible in the global WHO countries funding but it’s there nevertheless. Nothing of quality can totally be for free, someone is always paying for it somewhere.

3 Likes
3

I’m not saying that anything can be done completely for free. I just think the license needs to shift to open source, in order to fix the distribution problem which I don’t think many in SNOMED actually know that they have.

Modern software (which SNOMED is, as a computable knowledge artefact) needs package manager tooling that automatically and deterministically manage versions of the artefacts. As long as SNOMED licensing is in the way of this, you will never be able to have a package manager that installs SNOMED in the way you can npm install, pip install or cargo install software. With an open license, you can then build these tools that install SNOMED at a particular version, with specific extensions, ‘pin’ to specific versions, and manage upgrades safely and deterministically.

That doesn’t stop SNOMED International requesting paid memberships from countries, companies, and even individuals. The fees would be paid for a seat at the table in decision-making, direction-setting, and editorial process.

Failing to address the licensing problem, and the downstream package management problem, will just slow SNOMED’s adoption and massively increase costs of any adoption that happens, because the tooling is not commoditised, it is still a ‘bespoke service’.

4

You could add Docker to the list. The licence terms are getting more permissive overall and between the Global Patient Set, Free Sets and IPS Terminology, developers of ‘everywhere solutions’ have a bit of a selection. In a perfect world the SNOMED International Edition and its national extensions would be released as free global public goods under a Creative Commons licence. The IPS Terminology (which includes relationships) is released under the CC 4.0 International Licence and that may be a good enough option for a base product, with international and national editions as licensable extras.

1 Like
5

Yep, this is exactly what I would hope for. The work that’s been done to release IPS under CC4.0 is excellent and I think bodes well for the future.

Obtaining these free sets though still requires registering via the website and because of this step it’s not completely clear if it’s OK to ‘redistribute’ them (eg in my sct package on GitHub). I have asked the question and am awaiting the response.

It is not allowed to “remix, transform, or build upon” without approval from SNOMED Int’l, but it doesn’t say how one gets this approval. In the CC license detail it is clear: “Merely changing the format never creates a derivative” - but I still don’t feel quite confident that it would be OK.