# Q: design description of lab archetypes **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2017-07-12 15:22 UTC **Views:** 1 **Replies:** 15 **URL:** https://discourse.openehr.org/t/q-design-description-of-lab-archetypes/15501 --- ## Post #1 by @system Clinical modellers, I'm trying to work out the latest design of Lab archetypes. A Lab result seems to now be a structure like the following: - openEHR-EHR-**OBSERVATION**.**laboratory_test_result** - + at0097|Test findings|: openEHR-EHR-**CLUSTER**.**laboratory_test_panel** [*] - +at0002 |Laboratory Result|: **CLUSTER** [*] - +at0004 |Reference range guidance| - +at0005 |Result status| - +at0014 |Result Detail|: [open slot] - ? openEHR-EHR-**CLUSTER**.**laboratory_test_analyte** [*] - +at0001 |Analyte Result|: **DATA_VALUE** - +at0003 |Comment|: **DV_TEXT** - etc Questions - is this a correct understanding of the current design? - where would the LOINC code for each analyte go? - we could build some common test panels by specialising the test analyte archetype into things like TSH, TS4, etc and lab test panel into 'thyroid test' - is anyone doing this? - how does AQL querying work if LOINC is not in use / not available? It would be good if there was a design page on this e.g. in the openEHR wiki. thanks - thomas --- ## Post #2 by @heather.leslie Hi Thomas, This might help you: [https://openehr.atlassian.net/wiki/spaces/healthmod/pages/91139266/Implementing+Laboratory+Tests+in+openEHR](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/91139266/Implementing+Laboratory+Tests+in+openEHR) Heather --- ## Post #3 by @system 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) 1. The doc orders just a specific analyte, e.g. TSH 1. 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 1. one or more separate analytes, e.g. TSH, iron, ... 1. 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] - order meta-data - etc - __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 - requestor: Dr Silva, Hospital Clinicas Porto Alegre, ... - order id: 1234 - etc - 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 - requestor: Dr Silva, Hospital Clinicas Porto Alegre, ... - order id: 1234 - etc - 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 --- ## Post #4 by @system i just realised it can be simpler still: > - Lab report > > - requestor: Dr Silva, Hospital Clinicas Porto Alegre, ... > > - order id: 1234 > > - etc > > - Lab Test: **Thyroid test ?? or maybe just TSH?** > > - conclusions > - method > - other details... > - Lab Panel - **Panel** > > - **TSH** > - value > - method [0..1] > - comment [0..1] > - other detail [0..1] there is no need for any special name on the 'panel' group; it is always just 'panel'. - thomas --- ## Post #5 by @system Going a bit further in my analysis, it seems to me that the archetypes needed are not exactly what are in CKM right now... I would expect: - **COMPOSITION**: **Lab report** - order meta-data - etc - __OBSERVATION: Lab Test [*]__ **// may be LOINC coded here, or via archetype binding only** - protocol - method - other details... - sample- data/events/data: ITEM_TREE: results [1] - ELEMENT: test status - ELEMENT: diagnostic service category - ELEMENT: conclusion - ELEMENT: test findings - ELEMENT: pathological diagnosis - __CLUSTER: Lab Analyte Result [*] // may be LOINC coded here, or via archetype binding only__ - value - method [0..1] - comment [0..1] - other detail [0..*] Only the bolded items need be archetypes. So I don't think 'lab panel' (understanding 'panel' as just a list of analyte results) needs an archetype. Maybe I am missing something.... - thomas --- ## Post #6 by @system Hi, Panels have a specific name And can have an associated result describing the panel as a whole. Plus context data pertaining to the panel and all its items. E.g. *Haematology panel: normal.* Both the *Panelresult* and the results of the individual items can to be queried. Remarks: - The individual *Itemresults* are the result of a process and therefor Observations (ENTRIES) - The *Panelresult* is the result of an EVALUATION Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #7 by @system Stan tells me that LOINC can code most/all standard panels. there is a linguistic thing going on here where we use the word 'panel' to mean two things: It has not been modelled like this, but scientifically it's a reasonable view. It's a bit heavy in terms of information structures though. I'm inclined to still allow grouping of analytes in a single Observation for practical reasons - e.g. at least for groups of analytes that are obtained by the same method, etc. But the more I learn about path lab results, maybe it is worth revisiting this question. I'm not sure I agree on this, unless you are talking about the a data point like 'pathological interpretation' but I think this has to be understood not as a Dx on the patient but a standard Dx that should be inferred from the path value e.g. high Potassium => possible kidney compromise. I have no expertise in this, so could be wrong, but from a common sense point of view, I don't see how a lab can provide a Dx on the actual patient without examining the patient history / EHR. I don't think 'normal' should be understood as an evaluation on the patient - it's just the lab saying: all the analytes are within normal ranges for the patient type (adult male or whatever). Interested to know if others disagree violently...! - thomas --- ## Post #8 by @heather.leslie 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](http://www.openehr.org/ckm/#showArchetype_1013.1.2191). Regards Heather --- ## Post #9 by @Karsten_Hilbert > 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? Yes\. > I believe this is possible and normal in some places\. Indeed\. > 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\. I think the realisation is that a lab \*order\* is something orthogonal from a lab \*result\* and seems likely to benefit from being modelled in distinct archetypes\. IOW, no matter which way a specific analyte ended up being \*ordered\* it always "comes back" as a singular\-analyte result\. Receiving systems may decide \(or not\) to group single\-analyte results one way or another \(typically the way they were ordered \.\.\.\) but that is an implementation detail\. A result may carry with it a reference to the order to facilitate such grouping\. Regards, Karsten --- ## Post #10 by @system but in some cases at least, you would presumably agree that the panel analytes taken together provide a useful picture\. E\.g\. docs tend to read a lipids panel as a panel, not just \(say\) the total cholesterol, but the HDL / LDL / ratio \(or whatever the current science says matters\!\); same for a blood panel\.\.\. So, having that panel which was performed from the same sample, taken at a certain time is what ties them together, not just the order\. \- thomas --- ## Post #11 by @Colin_Sutton Can I suggest that 'Sample date' (aka 'Collection date') and 'Analysis date' should be explicit in 'etc' and 'other details' respectively? --- ## Post #12 by @system Hi Colin, this is already taken care of in [standard openEHR](http://openehr.org/releases/BASE/latest/docs/architecture_overview/architecture_overview.html#_time_in_the_ehr), Observation class. - thomas --- ## Post #13 by @Karsten_Hilbert Sure\. the order would contain a reference to the sample\. Which allows for a back\-reference from the result\. Or, in case an order contains several samples, the result would carry a reference to the sample\. My main point is that results should be groupable in other ways than via the panel they are ordered under\. Maybe I am barking up the wrong tree \- is panel only meant to reference the "probe" or "sample" ? Typically, "panel" is a tool for \(lazy ;\-\) doctors, providing relief from the need to really think about which answers are needed, and hence which questions \(tests\) need to be asked\. Of course, results can be re\-grouped dynamically even if the order panel is stored in the returned result but storing more than one result in a result archetype smells like denormalization\. However, Normal Form need not be the goal, which I am not competent enough to say\. Karsten --- ## Post #14 by @system that was partly my original point.. 'panel' has more than one meaning, and is used differently in the ordering phase (I can't think right now if I really want TSH or T4... just give my a 'thyroid panel') to the analysis phase and the review / use phase. It could mean: - thomas --- ## Post #15 by @Koray_Atalag 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 --- ## Post #16 by @system Hi, In my SIAMM thinking: - I use the ENTRY to model using a fixed pattern the process of documentation of anything (the context of documentation) and that what is documented - What can be documented is done using a panel (compound statement) as CLUSTER - The compound statement CLUSTER documents all about the context of the panel - The compound statement CLUSTER can hold one or more single statement CLUSTERS In this way the path always is the same for one single statement of a panel of single statements. In CIMI they use the ENTRY in a peculiar way to achieve the same, but I am not in favor of this solution. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- **Canonical:** https://discourse.openehr.org/t/q-design-description-of-lab-archetypes/15501 **Original content:** https://discourse.openehr.org/t/q-design-description-of-lab-archetypes/15501