Deploying Orderables within SNOMED CT

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

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

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.