More generic reference model

Ian McNicoll ian at freshehr.com
Sat Sep 3 14:43:20 EDT 2016


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-
> EVALUATION.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_ExpressionConstraintLanguageSp
> ecificationAndGuide_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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20160903/0a55168e/attachment-0002.html>


More information about the openEHR-clinical mailing list