design description of lab archetypes

Koray Atalag k.atalag at auckland.ac.nz
Sun Dec 3 19:14:09 EST 2017


Hi,

I couldn’t see any further discussions on the points Thomas raised – especially around being able for AQL to be able to fetch a lab result whether inside the single analyte or part of a panel. Right now they’d be two different paths and it is not ideal. I’ve also read the documentation Ian has put and found it confusing as well.

Can I ask to provide further guidance to the community using the specific use cases Tom gave below? I reckon going with the panel option by default is probably a practical good solution

Cheers,

-koray

From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Heather Leslie
Sent: Saturday, 15 July 2017 4:11 p.m.
To: For openEHR clinical discussions
Subject: [FORGED] RE: design description of lab archetypes

Hi Thomas,

Yes, the analyte is a newborn, developed in response to review feedback.

Ian has been leading this work, including the documentation, so I’ll leave this to him to respond to when he’s back from leave.

This archetype is currently just completing its first review – we had 25 responses from 404 invitations - the opportunity for adding comments is now closed for this review round and the comments have been resolved, so that immediately after the holidays it will be sent out for its second review round.

If you want to get involved in the next review round, please adopt the archetype – http://www.openehr.org/ckm/#showArchetype_1013.1.2191.

Regards

Heather

From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Thomas Beale
Sent: Thursday, 13 July 2017 10:42 PM
To: openehr-clinical at lists.openehr.org<mailto:openehr-clinical at lists.openehr.org>
Subject: Re: design description of lab archetypes


Heather,

thanks that's a page I was looking for. I assume the laboratory analyte archetype is newer than this? It is not mentioned.

I think we need more explanation about the basic intended structure. There are at least the following scenarios to cope with for the 'simple tabular' types like biochemistry.
1.      The doc orders (taking thyroid as an example) a standard thyroid test, without nominating things like TSH, TS4, etc (because they know what they will get back)
2.      The doc orders just a specific analyte, e.g. TSH
3.      any combination of the above in a single order? I believe this is possible and normal in some places. This could mean
1.      one or more 'panels', e.g. a GP orders thyroid test, lipids and liver function
2.      one or more separate analytes, e.g. TSH, iron, ...
3.      a mixture of 'panels' and single analytes.

There are two things we want to achieve in representing the data (apart from the obvious one that we don't lose information from the original data provided by the lab when converting to openEHR):
•        no matter if just a single analyte, or panel is ordered, the specific analyte results are represented in the same way. In the thryoid example, TSH must be queryable in exactly the same way no matter whether received as part of a thyroid test panel, or just on its own.
•        coding of panels and analyte results with LOINC should be optional (but probably encouraged). I.e. there must be a way of querying that works even if LOINC is not used.

To achieve this, I would propose that we always consider that there is a panel in the openEHR representation, regardless of whether a single analyte was ordered. This means a structure like the following:
•        Lab report [corresponds to one order]
o   order meta-data
o   etc
o   Lab Test [*] (= container for all content for a single test)
•  conclusions
•  method
•  other details...
•  sample
•  Lab Panel [*]
•  Analyte [*]
•  value
•  method [0..1]
•  comment [0..1]
•  other detail [0..1]

So for the TSH example, ordered in a Thyroid panel, we have something like:
•        Lab report
o   requestor: Dr Silva, Hospital Clinicas Porto Alegre, ...
o   order id: 1234
o   etc
o   Lab Test: Thyroid test
•  conclusions
•  method
•  other details...
•  Lab Panel - Thyroid
•  TSH
•  value
•  method [0..1]
•  comment [0..1]
•  other detail [0..1]
•  TS4
•  value
•  method [0..1]
•  comment [0..1]
•  other detail [0..1]

If TSH is ordered on its own, we get:
•        Lab report
o   requestor: Dr Silva, Hospital Clinicas Porto Alegre, ...
o   order id: 1234
o   etc
o   Lab Test: Thyroid test ?? or maybe just TSH?
•  conclusions
•  method
•  other details...
•  Lab Panel - TSH (synthesised, or maybe 'thyroid' can be inferred)
•  TSH
•  value
•  method [0..1]
•  comment [0..1]
•  other detail [0..1]

In these structures, the TSH result is always in the same place from the point of view of AQL querying.

The bold items could be (shoud be?) coded. By LOINC or by SNOMED? If no coding is available the generic archetypes used to represent the above could be specialised to build typical lab result structures e.g. thyroid panel etc. In such archetypes there will be direct archetype paths to TSH, TS4 etc, and a TDS will contain tags of these names. The LOINC or SNOMED codes can still be included in bindings.

how does this sound?

- thomas



On 13/07/2017 03:46, Heather Leslie wrote:
Hi Thomas,

This might help you: https://openehr.atlassian.net/wiki/spaces/healthmod/pages/91139266/Implementing+Laboratory+Tests+in+openEHR

Heather

From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Thomas Beale
Sent: Thursday, 13 July 2017 1:22 AM
To: For openEHR clinical discussions <openehr-clinical at lists.openehr.org><mailto:openehr-clinical at lists.openehr.org>
Subject: Q: design description of lab archetypes




--
Thomas Beale
Principal, Ars Semantica<http://www.arssemantica.com>
Consultant, ABD Team, Intermountain Healthcare<https://intermountainhealthcare.org/>
Management Board, Specifications Program Lead, openEHR Foundation<http://www.openehr.org>
Chartered IT Professional Fellow, BCS, British Computer Society<http://www.bcs.org/category/6044>
Health IT blog<http://wolandscat.net/> | Culture blog<http://wolandsothercat.net/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20171204/5384aced/attachment-0002.html>


More information about the openEHR-clinical mailing list