Hi,
I needed to clean up archetypes from SNOMED bindings because of license-reasons, I "grepped" the local directory from CKM.
To my surprise I found there SNOMED bindings in over 50 archetypes.
This can, I think, be a problem for countries which have no SNOMED license.
Or is the opinion that SNOMED is allowed in archetypes even in non-member-countries.
Bert
I must mitigate that, a part of the 50 are archetypes which have the word "SNOMED" somewhere in the descriptions. But still there are a few dozen which have SNOMED bindings
Bert
Hi Bert,
This is a good and timely post. We are just finalising an Affiliate License agreement with SNOMED. It has not been formally signed off but the broad approach is that we are allowed to put SNOMED bindings in archetypes as long as it is made clear to users of those archetypes that they must be appropriately SNOMED-licensed if they want to use those bindings in run-time systems. This is roughly consistent with the approach reached with FHIR.
As far as I am aware none of the current bindings in archetypes force the use of SNOMED at run-time.
So practically, no-one should be concerned about using archetypes with SNOMED bindings, unless they intend to use SNOMED within their systems, in which case they should make sure they are covered by a national or individual licence.
Regards,
Ian
Thanks Ian. This explains very well what we (in the Netherlands) need to do when "running" archetypes in Germany (which is non-member-country)
I think it is also good for others which use CKM, to realize that, if appropriate.
Bert
The challenge there will be if you decide as an organisation that e.g. SNOMED mappings should be recorded as a default. That would breach the licence agreement we will have with SNOMED, where e.g Germany does not have a national affiliate licence.
Having said that, my understanding is that SNOMED are very willing to be generous in terms of vendor/org level licensing in such a situation.
Ian
I know that they have a license for organizations in a country which is a non-member.
And for one organization, this is mostly not very expensive.
I am not sure about the exact price, but I remember that it was something around 1000 Euro a year, and there are special arrangements for organizations which are in poor countries, or academical purposes.
But if the organization uses their software in/together with other organizations, like hospitals (f.e. a laboratory-organization), then the hospitals also profit from SNOMED, and also need a license, when they are in non-member-country.
And then the total costs can become too high.
A political solution for SNOMED would make it more useful, like being governed by the WHO, or something like that. I think and hope this won't take long to happen.
Bert
Currently the use of specific SNOMED CT codes in archetypes is for further definition / specification of the clinical concepts.
To use SNOMED CT at runtime, external constraints are used in the form of URIs, that might point to a SNOMED domain or specific subset. If the subset is local, the archetype might not be the place of setting the constraints since archetypes should be general purpose & globally valid. A template might be the right place of setting those constraints (specific, locally valid).
Regards,
Pablo.
Pablo, I have a slightly different opinion on your statement. But first I want to emphasize that it is generally a good guide line what you express. But I disagree with your way of expressing strongly. In the case of local subset you are right. But in cases of non-local subsets, all SNOMED information can be used globally, depending on licensing. But even in case of local subsets, ADL offers the freedom the create archetypes for a very special small local domain. There is nothing wrong with that, if you need it, then you need it. Although, it is better to look for a wider usability or of there is already something similar. People can have good reasons to add SNOMED in archetypes, in term-bindings, or, for example, in restricting hierarchies in SNOMED. But AOM is not that far right now that it can fully extensively use SNOMED. And ADL does not yet allow expressions in termbinding So there is some way to go, but denying the need by stating that it is not right to do so does not seem right to me. It is on people to decide what is right. OpenEHR should facilitate, not dictate. That has always been a part of base thinking. I think the next generation HealthICT will use the full extend of SNOMED, including post-coordinated expressions, hierarchies, subsets, etc. I hope OpenEHR will step on board of that train very soon. This will surely change thinking about archetypes, CKM, and so on. But good scotch needs time to grow up. 
But be careful not to throw away scotch which will be very good in a few years. I disagree with this one also. There can be disadvantages against using specific constraints in templates instead of archetypes. It must be reconsidered from case to case. It has to do with code-reuse and code-maintenance, so called: the DRY-rule (Don’t Repeat Yourself). If a specific extra constraint on an archetype reoccurs inside a organization in more templates, then it is in my opinion better to specialize that archetype, because then there is one single point of maintenance. The alternative to do it in a template every time, gives you more points of maintenance on the same specific part. The DRY rule is very well-known and for good reason: An important part of the power of OpenEHR is in the flexibility which offers solutions for exceptional situations. Best regards Bert Verhees
Hi Bert,
Maybe my wording is the issue here since I don’t disagree with what you said.
Take into account that I use the word “might” on every sentence, as the indication of an ability. Never said that 1. applies to all contexts, or 2. that those are hard rules. In those cases I would use “must” instead of “might”.
With that being said, when a SNOMED CT code is referenced directly as a bind to an archetype node, the purpose is to add definition to the archetype, not to use the code as part of the record. That can be done, but is not the purpose of having term bindings on the archetype. That is explained on the specs somewhere, is not my idea 
Cheers,
Pablo.
I agree completely with you, Pablo
Best regards
Bert
But I think that it is not allowed to use SNOMED-CT in bindings when you’re not explicitly permitted to do so.
Bert
In terms of license, I don’t think using archetypes that reference snomed is a problem. The thing is when you want to support snomed in your system, having or not archetypes doesn’t makes the difference IMO.
I thought so too, I even asked someone at ihtsdo but when you read the license coming with the SNOMED-CT browser, it made me doubt. Take a look at it yourself, I believe it is point 4 ( I am on my mobile right now and it is inconvenient to look now)
Bert
Hi Bert,
The official name that SNOMED/IHTSDO use is ‘SNOMED CT’.
The technical terminology descriptor that we use inside terminology_id is ‘SNOMED-CT’
Ian
Hi Ian, not to be troublesome, but wouldn’t it be better, for interoperability, to use the name IHTSDO uses.
I think Pablo has a point here.
Bert
Pablo, you are allowed to use the SNOMED browser, even if you do not have a license, you get a temporary license to use SNOMED, here are some conditions (the important point)
When you use SNOMED in terminology binding in an archetype, how did you find that SNOMED code?
I think point 4b is important:
4. End Users, that do not hold an SNOMED International Affiliate License, may access SNOMED CT® using SNOMED International SNOMED CT Browser subject to acceptance of and adherence to the following sub-license limitations:
a) The sub-licensee is only permitted to access SNOMED CT® using this software (or service) for the purpose of exploring and evaluating the terminology.
b) The sub-licensee is not permitted the use of this software as part of a system that constitutes a SNOMED CT "Data Creation System" or "Data Analysis System", as defined in the SNOMED International Affiliate License. This means that the sub-licensee must not use SNOMED International SNOMED CT Browser to add or copy SNOMED CT identifiers into any type of record system, database or document.
Hi Bert,
SNOMED CT Licensing re openEHR is under active discussion with SNOMED.
The principle will be that archetypes or templates containing SNOMED CT codes can be freely used within systems, unless the system actually uses SNOMED CT codes in the patient data i.e as part of a defining_code or mapping, in which case a SNOMED license will be required.
Ian
For interoperability, we need to tell more things from a terminology that are nowadays still not possible: terminology version, date, license, probably oid, etc.
Is more important to know the exact version (which would solve the ‘name’ problem)
Regards
Pablo,
I agree.
Attaching codes to nodes in the archetype is in order to disambiguate that archetype node concept/name.
In addition.
I think that we should NOT use SNOMED-CT codes for that purpose.
As far as I know this is the realm of LOINC. So we need LOINC codes to disambiguate nodes in an archetype.
In general LOINC is used to disambiguate the ‘Question’.
And SNOMED is used to disambiguate the ‘Answer’; the ‘Result’
This implicates that LOINC must be used in all Archetype nodes that are NO leaf-nodes.
SNOMED must be used in Leaf-nodes and stored as results and queried for as results.
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
Ok, I misunderstood that, I thought you were in discussion about using SNOMED in CKM term-bindings, and that users without affiliate license should manually remove them.
But as I understand it now, you are in discussion about permission for using SNOMED in term-bindings, also when you have no affiliate license.
That would make life simpler for many (not for me, but our German friends)
Bert