Pragmatically speaking, deployment of an observables ontology for lab medicine should include order panels since they are common organizing features encountered in the clinical realm. Struggling with the question of how to model them in SNOMED CT, it occurs to me that they represent a Situation with explicit context in that they represent proposed actions rather than reports of results. Carrying this thought forward, I would observe that we have an implicit 'soft context' for Observable entities as we have defined them, to wit:
Soft context for observable entities:
Associated procedure: Observable entity
Procedure context: Done
Temporal context: Current or past Subject relationship context: Patient
Orderables and panel codes, on the other hand, could be conceptualized as
ISA Procedure with explicit context Associated procedure: Observable entity Procedure context: To be done Temporal context: Future Subject relationship context: Patient
These orderable concepts should have 'Component' relationships to the set of observables that are actually accomplished by executing the order:
{24323-8 Comprehensive metabolic panel =
ISA Procedure with explicit context(Orderable) Associated procedure: Clinical chemistry observable entity Procedure context: To be done Temporal context: Future Subject relationship context: Patient
Component:2345-7 Glucose in serum or plasma
Component: 3094-0 Urea nitrogen in serum or plasma...etc}
Does that make sense relative to the SNOMED CT concept model?
I assume that those will not be in the international release as panels tend to vary between organisations.
The situation concept model includes Observables in the range of | Procedure context | but | Component | is only allowed for | Procedure | and | Observable entity |.
The Associated procedure: Clinical chemistry observable entity seem to add little to the definition. Why not like this (if the small issue of mixing code syntaxes can be solved):
This would provide a SNOMED CT definition of the contents of the panel.
However, there is no formal definition of the "metabolicness" of the panel and thus you would not be able to query for all panels concerning metabolism (if that is at all possible).
I agree it is an area for fruitful discussion. There are two strands: orderables/requestables in general (what the physician wants an answer to) and test panel orderables.
The panels/batteries/profiles orderable certainly needs some possible solutions although it may be that pragmatically individual countries may find their own approach. Procedure codes for panel orderables and report message headers would seem robust; Australian use noted.
My personal view on the generic orderables/requestables issue, certainly from a primary care physician reporting perspective, is to propose sending the basic Observable Entity with null value as an individual test request to the lab and getting back the same code with a value attached. The clinician just wants an answer to a question 'what is the patient's serum sodium' rather than describe the test/method to be carried out, which is a matter for the lab and lab system - precise test prescription would be confined to highly specialized domains? The replication and harmonisation of volumes of evaluation procedures and observables to complement each other for orderables looks unattractive on redundancy and scalability. Using the 'blind' Observable Entity in a request 'works' in a 'Primitive' world but I'm less clear on how the Observable Entity modelling outcomes will allow for such code use as requestables.
5 Comments
James R. Campbell
Pragmatically speaking, deployment of an observables ontology for lab medicine should include order panels since they are common organizing features encountered in the clinical realm. Struggling with the question of how to model them in SNOMED CT, it occurs to me that they represent a Situation with explicit context in that they represent proposed actions rather than reports of results. Carrying this thought forward, I would observe that we have an implicit 'soft context' for Observable entities as we have defined them, to wit:
Soft context for observable entities:
Associated procedure: Observable entity
Procedure context: Done
Temporal context: Current or past
Subject relationship context: Patient
Orderables and panel codes, on the other hand, could be conceptualized as
ISA Procedure with explicit context
Associated procedure: Observable entity
Procedure context: To be done
Temporal context: Future
Subject relationship context: Patient
These orderable concepts should have 'Component' relationships to the set of observables that are actually accomplished by executing the order:
{24323-8 Comprehensive metabolic panel =
ISA Procedure with explicit context(Orderable)
Associated procedure: Clinical chemistry observable entity
Procedure context: To be done
Temporal context: Future
Subject relationship context: Patient
Component:2345-7 Glucose in serum or plasma
Component: 3094-0 Urea nitrogen in serum or plasma...etc}
Does that make sense relative to the SNOMED CT concept model?
Jim
Sarah Harry
Could this not apply to any orderable whether panel or single item? A means of connecting orderable and result is certainly appealing.
Sarah.
Daniel Karlsson
I assume that those will not be in the international release as panels tend to vary between organisations.
The situation concept model includes Observables in the range of | Procedure context | but | Component | is only allowed for | Procedure | and | Observable entity |.
The Associated procedure: Clinical chemistry observable entity seem to add little to the definition. Why not like this (if the small issue of mixing code syntaxes can be solved):
24323-8 | Comprehensive metabolic panel |
===
| Procedure with explicit context | :
{
| Associated procedure | = 2345-7 | Glucose in serum or plasma |,
| Procedure context | = | Requested (qualifier value) |
},
{
| Associated procedure | = 3094-0 | Urea nitrogen in serum or plasma |,
| Procedure context | = | Requested (qualifier value) |
}, ... etc...
This would provide a SNOMED CT definition of the contents of the panel.
However, there is no formal definition of the "metabolicness" of the panel and thus you would not be able to query for all panels concerning metabolism (if that is at all possible).
Thus, adding a grouper-like Observable:
24323-8 | Comprehensive metabolic panel |
<<<
|Observable|:
|Characterizes|=|Metabolism|
with a GCI could provide this information.
/Daniel
Michael Osborne
In Australia, we have used Procedures (Specifically Evaluation Procedures) as a standard for ordering tests and test panels. This is similar to what the NLMC is in the UK.
http://www.rcpa.edu.au/Library/Practising-Pathology/PTIS/APUTS-Downloads
There was no effort to try to link individual tests (Observables) even at this National level as the variation is too great.
I actually think this would be a good subject for a talk at Bratislava. TBA.
Sarah Harry
I agree it is an area for fruitful discussion. There are two strands: orderables/requestables in general (what the physician wants an answer to) and test panel orderables.
The panels/batteries/profiles orderable certainly needs some possible solutions although it may be that pragmatically individual countries may find their own approach. Procedure codes for panel orderables and report message headers would seem robust; Australian use noted.
My personal view on the generic orderables/requestables issue, certainly from a primary care physician reporting perspective, is to propose sending the basic Observable Entity with null value as an individual test request to the lab and getting back the same code with a value attached. The clinician just wants an answer to a question 'what is the patient's serum sodium' rather than describe the test/method to be carried out, which is a matter for the lab and lab system - precise test prescription would be confined to highly specialized domains? The replication and harmonisation of volumes of evaluation procedures and observables to complement each other for orderables looks unattractive on redundancy and scalability. Using the 'blind' Observable Entity in a request 'works' in a 'Primitive' world but I'm less clear on how the Observable Entity modelling outcomes will allow for such code use as requestables.