it's possible to use SCT more infrastructurally in FHIR, but this is something we are only now exploring with IHTSDO staff + other interested parties
Grahame On Sun, Sep 4, 2016 at 7:58 PM, Bert Verhees <bert.verh...@rosa.nl> wrote: > Hi Ian, thanks for attaching that presentation, I saved it. > > But I also read it, but I must admit, that is a bit hard, presentations > are always a bit hard to read, the person who gives the information adds > value. > But still, very informative. > > And at the same time, the difference between FHIR and OpenEHR came to > mind, and also the difference purpose of SNOMED in both. FHIR is a message > format, while OpenEHR defines a storage environment complete with > possibilities for a query engine, facilities for datamining, templates for > screens, generating FHIR messages, etc. > > In FHIR SNOMED is mainly be used, as I understand, to refer to SNOMED, > conceptID's, Refsets, Compositional Grammar, Constraint Language. It are > references to explain data, or the environment of the message producer. > While in OpenEHR, it can be used to facilitate the other features which > can come out of a full featured OpenEHR environment. It are these > facilities where I refer to when I talk about SNOMED in OpenEHR integration. > > So I think it is another subject. But still, I am very grateful for the > presentation. I almost never have chance to visit those occasions where > these presentations are given. > > Bert > > > > On 03-09-16 20:43, Ian McNicoll wrote: > > I found this excellent document from GEHCO gehco.org. It refers mostly to > FHIR but has some examples from openEHR, and I think the challenges and > principals are pretty well identical. > > http://www.gehco.org/wp1508/wp-content/uploads/2016/06/ > Powerpoint-FHIR-and-SNOMED-V0-92.pdf > > I know CIMI has a key aim of trying to create the kind of iso-semantic > models that Bert is advocating, and while this is a laudable objective, the > challenge should not be under-estimated. > > Ian > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > On 3 September 2016 at 17:34, Bert Verhees <bert.verh...@rosa.nl> wrote: > >> On 03-09-16 18:17, Thomas Beale wrote: >> >> Bert, >> >> doing most of what you want should come in AQL, e.g. the following in a >> WHERE clause is already possible. >> SELECT >> e/ehr_status/subject/external_ref/id/value, >> diagnosis/data/items[at0002.1]/value >> FROM >> EHR e >> CONTAINS Composition c[openEHR-EHR-COMPOSITION.problem_list.v1] >> CONTAINS Evaluation diagnosis[openEHR-EHR-EVALUATI >> ON.problem-diagnosis.v1] >> WHERE >> c/name/value='Current Problems' >> AND diagnosis/data/items[at0002.1]/value/defining_code *matches* { >> http://snomed.info/id/42570301000090487|cancer Dx refset|} >> >> >> That is a very OpenEHRish way to do it, is comparing the code. >> >> But what if you also want to find the subtypes, lungcancer (30 >> sub-types), etc, if you want to know about SNOMED attributes. >> For that purpose is the Expression Constraint language, and you need to >> query the terminology to know what you need to compare your data with. >> >> The best way to do it is not invent another way to do it, but embed that >> language. >> http://doc.ihtsdo.org/download/doc_ExpressionConstraintLangu >> ageSpecificationAndGuide_Current-en-US_INT_20150820.pdf >> When that is done well, you have the full power in one move. >> >> One interesting question is whether 'inline' refset definitions would be >> allowed, e.g. using the SNOMED constraint grammar. We probably should add >> this to AQL as a plug-in syntax, since IHTSDO standardised it >> <http://doc.ihtsdo.org/download/doc_ExpressionConstraintLanguageSpecificationAndGuide_Current-en-US_INT_20150820.pdf>. >> What the solution is for ICDx I don't know. >> >> >> I don know either. >> >> There is more then just a plugin which does some separate work. Because >> the ECL also works on subtypes and attributes, and the attributes are not >> available. AQL must deliver them to the SNOMED engine, because they are on >> another path. There is code infrastructure needed. >> >> For example: Find systolics higher then 165, in the archetype the type of >> the measurement can be in another element then the value of the measurement. >> This mapping between SNOEMD attributes and where they are in the >> archetypes must be done in some elegant way. >> >> The main thing to understand is that if a SNOMED or ICD code for say >> leukaemia is found in EHR data, the code alone doesn't tell you the >> epistemic status, i.e. the kind of statement being made - i.e. current >> diagnosis, no risk of, risk of, fear of ... etc. Querying properly means >> understanding where in the data you are looking, and the archetypes help >> with that. >> >> >> That will be one of the added values of archetypes. >> >> Bert >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_ >> lists.openehr.org >> > > > > _______________________________________________ > openEHR-clinical mailing > listopenEHR-clinical@lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org > -- ----- http://www.healthintersections.com.au / grah...@healthintersections.com.au / +61 411 867 065
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
