Availability of external terms for LINK class
Description
Activity
David Moner February 14, 2024 at 4:32 PM
I agree with you about the IP, but it is worth to be sure.
The ISO 13606 link codes are in fact not very original: LINK-A1, LINK-A2…
For reference, the most similar terminology is the HL7 CDA ActRelationship:
https://vico.org/CDAR22005_HL7SP/infrastructure/vocabulary/ActRelationshipType.htm
It then derived to a ValueSet in HL7 FHIR:
http://terminology.hl7.org/ValueSet/v3-ActRelationshipType
HL7 it includes relations such as “has cost” or “has charge”
Ian McNicoll February 14, 2024 at 1:26 PM
And in all honesty , I don’t think you can claim IP on the underlying ideas/ concepts. You can say, don't use my codes but you can't claim IP on the human concepts or even the groupings.
So SNOMED-CT used to saydon't use my code for Diabetes Type 1 , but they cannot say you can't use ‘Diabetes Type 1’, with a different code
They currently say you can use the ‘Diabetes Type 1’ code license-free but not the SCT relationship tables but they don't own those relationships e.g. type 1 Diabetes is_a metabolic disorder
Ian McNicoll February 14, 2024 at 1:21 PM
This is an interesting one - both technical and political!!
1. Are the current terms actually used in practice?
2. Can we see them ?
3. Are there any equivalents being proposed by the FHIR community (likely to have wider adoption)
4. If they are indeed useful, when do we start a conversation for them to be open-sourced, license free.
Details
Details
Reporter
David MonerComponents
Priority
Lowest
The current description of the LINK.meaning attribute reads: "[...] Values for meaning include those described in Annex C, ENV 13606 pt 2 under the categories of generic , documenting and reporting , organisational , clinical , circumstancial , and view management ." That reference is outdated. ENV 13606 was the pre-norm or experimental norm back in the early 2000s. Then we had EN 13606:2007 and finally now we have ISO 13606:2019. So, at the very least, that mention in the specifications should be updated. But to increase the access to the complete list of codes, it would be interesting to study the possibility of adding all of them directly into the openEHR terminology, becoming part of the specifications. Some additional considerations: - The codes themselves are of interest and should be maintained. The are more than 70 different codes organized in six categories. - Although it could be tempting to analyze in detail that long list, it has been curated for over 20 years and it is a very stable specification. - Intellectual property should be examined. Can all those codes and their descriptions be copied from an ISO standard into an open specification?