design description of lab archetypes
Karsten.Hilbert at gmx.net
Sat Jul 15 14:36:44 EDT 2017
On Thu, Jul 13, 2017 at 09:42:13AM -0300, Thomas Beale wrote:
> 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.
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
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
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
More information about the openEHR-clinical