More generic reference model

Grahame Grieve grahame at healthintersections.com.au
Sun Sep 4 06:13:16 EDT 2016


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.verhees at 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: ian at freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnicoll at 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.verhees at 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 at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_
>> lists.openehr.org
>>
>
>
>
> _______________________________________________
> openEHR-clinical mailing listopenEHR-clinical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>



-- 
-----
http://www.healthintersections.com.au / grahame at healthintersections.com.au
/ +61 411 867 065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20160904/be292b94/attachment-0002.html>


More information about the openEHR-clinical mailing list