Hi Bert, I talked about specializations because one of the basis of it is that constraints in specialized archetypes must be included in the parent constraints. e.g. parent archetype contains the "any allergy" subset and the children archetype contains "all allergies caused by a drug", and for that specialization to be correct, the second should be a subset of the first one. If you refer to label binding then I completely agree with you, bindings to snomed labels are difficult or almost impossible to define (I think that probably the only safe way of doing this is that the country asks for an extension to snomed based on their national archetypes and then binds the labels to the new codes)
Regards 2016-12-04 18:25 GMT+01:00 Bert Verhees <[email protected]>: > Hi Diego, your link does not work. > > But I am replying for another reason. > > I think that subsumption testing in archetypes is not feasible when the > archetypes are not covered by SNOMED. > This is because SNOMED subsumption testing is only valid inside the SNOMED > definitions. > > The system of specialized archetypes and parent archetypes (without the use > of SNOMED) is a parallel system in its own semantic world, which cannot be > mixed with the SNOMED semantics, so there will be no automatic subsumption > testing. > > OpenEHR will need to implement SNOMED if you want to do what Ian proposed as > an example: > "e.g Give me any patients with a problem/diagnosis of diabetes mellitus type > 2 or children. i.e is_a relationships" > > When you want to use advantages of SNOMED, you must not mix up a parallel > world to SNOMED with SNOMED. > This could lead to dangerous situations. > > Bert > > > > On 04-12-16 18:00, Diego Boscá wrote: > > Hi Daniel, > > We have been working on this from several perspectives. We have been > mostly focused in providing terminology binding support for > archetypes, and first efforts were focused in providing term and > subset bindings via external terminology services (such as ITServer) > > Lately we have implemented a Snomed expression syntax engine (for both > parsing and executing) called SNQuery (http://snquery.veratech.es) and > we are using it instead, as provides more flexibility. > > Having Snomed expression syntax queries as value bindings in > archetypes allows to easily create queries for data validation ("this > code should be an allergy" or "the text of this coded text should be > one of the synonyms of the code") and data transformation (to have > conditional data transformation functions such as "if the diagnosis is > a cancer diagnosis then A else B"). We mostly use subset membership > queries, but I assume that subsumption testing will be handy in > archetype specialization definition (subsets in the specialized > archetypes must be a subset of the ones in the parent archetype). > > Regards > > 2016-12-02 9:50 GMT+01:00 Daniel Karlsson <[email protected]>: > > Dear All, > > while thinking about terminology server requirements for openEHR systems > I would like to ask all openEHR implementers about experiences of > different solutions. Are there any experiences of using openEHR systems > with e.g. the FHIR terminology services, CTS2, Ocean TQL, homebrew, etc? > What are the use cases when the terminology servers are used (e.g. > design time, data entry, querying, etc.)? What are the "terminological > queries" that are used/needed (e.g. subsumption testing, subset > membership, subset expansion, etc.)? > > Thanks, > Daniel > > -- > > Daniel Karlsson, PhD, sr lecturer > Department of Biomedical Engineering/Health informatics > Linköping university > SE-58185 Linköping > Sweden > Ph. +46 708350109, Skype: imt_danka, Hangout: [email protected] > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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
