Ian, I need to correct you.
1- CIMI and SNOMED. The nodes are NOT labeled using SNOMED, but LOINC is used. SNOMED is reserved for the data fields. 2- SNOMED is a Reference Terminology and should in the ideal world be orthogonal to structures as used in HL7v2, v3, and 13606. The natural role of SNOMED is to define ‘atomic’ concepts like any dictionary. These concepts are universal. In the ideal world the structures equate the syntax of a sentence and the Reference Terminology provides the ‘atomic’ concepts, the words. The dictionary defines for instance the concept: 'story’. And defines the concepts; ’tell’, ' by’, ‘as’, ‘patient’ and ‘mother’. The dictionary never describes as one single concept: ‘Story as told by mother’. This complex, pre-co-ordinated, concept is no longer universal, but specific. In language we use the syntax and the ‘atomic’ words to create statements. In the world of archetypes we use structure and ‘atomic’ codes to create Archetypes. 3- Helas SNOMED started to incorporate things from the world of structures in their coding system. They were no longer orthogonal. For example: The dictionary defines for instance the concept: 'story’. And defines the concepts; ’tell’, ' by’, ‘as’, ‘patient’ and ‘mother’. The dictionary never describes as one single concept: ‘Story as told by mother’. This complex, pre-co-ordinated, concept is no longer universal, but it is specific, it is particular. In language we use the syntax and the ‘atomic’ words to create statements. In the world of archetypes we use structure and ‘atomic’ codes to create Archetypes. 4- CIMI decided to use the ‘atomic’ codes, as much as possible in their structures in order to express results in data fields and use LOINC to label nodes. This is the CIMI preferred way. And yes, as a service, iso-sematic expressions are provided, but these are NOT the CIMI preferred way. Gerard Gerard Freriks +31 620347088 [email protected] <mailto:[email protected]> > On 29 apr. 2016, at 16:01, Ian McNicoll <[email protected]> wrote: > > Hi Bert, > > This is going to sound controversial but ... > > I am a big fan of SNOMED-CT and at some pint in the far distant future, what > you are proposing (or something like it) will happen. However, I have seen > endless similar proposals/projects in the UK and beyond, entranced by the > potential of post-coordination, repeatedly falling over, wasting huge amounts > of resource and energy and achieving nothing. That includes CIMI, which has, > IMO, been largely stalled by setting itself the goal of labelling all CIMI > nodes as SNOMED terms, and for archetypes being 'iso-semantic' with > post-coordinated SNOMED expressions. > > Whilst this is a laudable goal, it is hugely complex and it is, I think > significant that where progress has been made (openEHR and FHIR) both have > largely taken a prgamatic and limited approach to use of SNOMED-CT. > > SNOMED is a primarily an ontology of biomedical fact, not of clinical > practice/documentation. Used > > @Erik - we have only just been asked to resume discussion with IHTSDO. The > view of the MB is that it is not our place to police the use of SNOMED-CT by > end-user systems. All SNOMED-CT bindings in openEHR artefacts are optional > mappings. We are happy to add a boilerplate license to each archetype (as for > any third-party IP) that implementers must ensure that any use of SNOMED-CT > is allowed. There is no intention to otherwise adapt or strip-out content for > unlicensed consumers, as I think you were suggesting. If IHTSDO feel the need > to enforce more onerous terms than a simple boilerplate "Please respect IP" > statement, I think we might find that very problematic. > > Regards, > > Ian > > > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: [email protected] <mailto:[email protected]> > twitter: @ianmcnicoll > > > Co-Chair, openEHR Foundation [email protected] > <mailto:[email protected]> > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > On 29 April 2016 at 15:45, Bert Verhees <[email protected] > <mailto:[email protected]>> wrote: > Thanks Erik, for your reply. I did some more thinking in the meantime. > > In SNOMED you have disorders, and they have attributes, and we all know there > are thousands of them. Writing so many archetypes is impossible, and probably > not necessary, but when you take in account to limit the number of used > paths, (this helps also limiting the length key-index for a key value store), > and you really think smart how to do it, so it can be generated. > > Because SNOMED is in fact a description of many clinical meanings with > post-coordinate expressions and allowable attributes, just like archetypes > are a way to describe the same, it seems quite a potential, especially > because it can be used to generate archetypes, I had never thought of the > idea until yesterday. So I haven't worked it out. > > I don't know which part is of high quality and how you define high quality, > (or do "they" define it?), and also to consider, are archetypes always of > high quality? > > Archetypes are version-able, so, they could follow SNOMED versions. You > cannot build the world in one day. It has to grow, but a lot of work can be > done in one major blow. > > In the Netherlands we can use SNOMED for free, so that is a good thing. > > By the way, the semantics which are baked in the OpenEHR RM make it a bit > more difficult. I think that a data-storage, modeled like CEN13606 would make > it easier to do this. But it may also be possible in OpenEHR, we must work it > out, to find it out. > > Bert > > > > On 29-04-16 14:15, Erik Sundvall wrote: >> You can do some very clever things with Snomed CT especially if using >> "post-coordination" in a good way. Sadly many current EHR-systems can't >> utilize that power of Snomed CT fully. Clever archetyping with e.g. some >> built in post-coordination-generating logic combined with some extended >> (AQL?)querying-capabilities in openEHR storage systems could help >> openEHR-based systems jump ahead of a lot of the EHR competitors regarding >> efficient Snomed CT use... >> >> It is often good to look at Snomed CT when designing archetypes. Especially >> the high quality parts of Snomed CT (there is constant maintenance and >> cleanup going on). I believe this is happening more already when designing >> archetypes today. >> >> Regarding licensing I believe there has been a discussion going on between >> IHTSDO and the openEHR foundation for a long time, perhaps the management >> board has an update? >> >> I believe we might need to add a function to repositories/CKMs that removes >> Snomed bindings/codes from archetypes if downloaded by non-licensed users. >> (A lot of the structure/content itself is based on (non protected) general >> medical knowledge and I believe IHTSDO concludes it can be partly reused >> without license, thus not stopping global use of Snomed-inspired archetypes.) >> >> Others will surely add more to the discussion. >> >> //Erik Sundvall >> >> Sent from mobile... >> >> fredag 29 april 2016 skrev Bert Verhees < >> <mailto:[email protected]>[email protected] >> <mailto:[email protected]>>: >> Part two is of course, generating templates, and we almost have the GUI's in >> place. >> >> It is the enormous collection of medical datastructures which can be the >> source of many generated EPD-software. >> >> Bert >> >> On 29-04-16 08:50, Bert Verhees wrote: >> Hi, >> >> I got an idea when reading the nice story from Heather on LinkedIn. In fact >> it is hers idea, but in a opposing way. >> https://www.linkedin.com/pulse/journey-interoperability-part-i-heather-leslie >> >> <https://www.linkedin.com/pulse/journey-interoperability-part-i-heather-leslie> >> >> https://www.linkedin.com/pulse/journey-interoperability-part-ii-heather-leslie >> >> <https://www.linkedin.com/pulse/journey-interoperability-part-ii-heather-leslie> >> >> >> I wonder in how far it is feasible and useful to create archetypes from >> SNOMED concepts, it would be possible to generate them, with attributes and >> so on. >> In a few hours time, one would have a complete forest with archetypes, >> including ontology in more languages. >> Maybe some smart handling, filtering, combining can create a better >> collection, also looking at the paths, so that there are similar paths for >> similar situations, to keep the number of different datapoints low, which >> can help creating a faster key-value storage. >> >> I don't know how it is about copyright, with members, and licensing, that >> should be looked at. >> >> The argument that SNOMED is fragmented should not count, I think (however >> without having an expertise on this), because, when working with handwritten >> archetypes will always be incomplete and fragmented. >> >> Bert >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] <> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> >> >> >> -- >> Sent from mobile. >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> <mailto:[email protected]> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > > _______________________________________________ > openEHR-technical mailing list > [email protected] > <mailto:[email protected]> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > <http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
