Continuing our discussion re: modelling the available lab tests when adding Lab Ordering to the new Order Entry OWA module.
Currently, we have some requirements from our end users at one of our facilities:
A half dozen or so top-level categories to group the tests in, ie Hematology, Biochemistry, etc
Within each of those categories there are Panels and “standalone” Tests; users must be able to order any combination of panels and standalone tests… and importantly users must be able to order a subset of tests wihtin a panel. For instance, within the Hematology category we have the following tests:
Hemogram (panel)
Red Blood
White Blood
Hemoglobin/Hematocrit
MCV
MCH
MCHC
Platelets
Neutrophil
Lymphocytes
Eosinophils
Basophils
Monocytes
Coagulation (panel)
PTT
PTT/INR
Blood Group (individual test)
So, a clinician should be able to place an order for:
Hemogram panel & Blood Group
But should also be able to order “a la carte”, ie:
Hemoglobin/Hematocrit, Platelets, & Coagulation panel
Potential modelling:
“Lab Orderables” convenience set with the the top-level categories as members, ie:
“Hemotology” convenience set
“Biochemistry” convenience set,
etc…
Then each category convenience set would have the following concepts:
0 to N concepts of type “LabSet”
0 to N concepts of type “Test”
Nested in that, each “LabSet” would have:
1 to N concepts of type “Test”
I’m not in love with this model, and I suspect others won’t be either, but I don’t have a better solution yet…
Questions:
Is there any existing modelling in CIEL we can look to for examples? @akanter
A limitation of this model is that there’s no way to determine which sub-tests can be ordered “a la carte” and which can’t. Is this a problem? (I suspect it is… I’d love to avoid the “a la carte” use case for now, but it’s a requirement in our situation)
Are tests always 1 to 1 with obs? ie, if a “test” has two results, does that mean it should be broken up into two tests? (I’m guessing the answer is no, but taking a quick look in our dictionary the “Tests” I find are datatypes numeric or text, so I want to confirm
How does Bahmni handle this modelling, and should we try to be consistent with that? @angshuonline@darius
In the interest of getting something ‘out-the-door’ are there simplifications we can make in the short-term and potentially improve in the long-term. What needs to be there from “day 1”?
There has been a fair amount of work on lab modeling, although it has been some time since I re-examined it for OpenMRS. It makes a difference whether you are ordering a single lab test or a panel and it is not always possible to order a component of a panel on its own. There are different codes for resultable labs and orderable labs. A single LOINC code can be used to do both, if the component is orderable on its own. We have created lab sets for panels which are assigned LOINC codes for orders. The individual components (like the CBC components mentioned above) are created separately and generally have observation type codes (for results) and occasionally a code that is both order and observation. SGOT is an example of one with both.
Right now, we have at times differentiated concepts that are used for ordering separately from concepts that are used for results. This has not been consistent however. In the distant past we typically used the concept ID of the test to be the order test ID and the answer to that concept to hold the result. That caused some issues for CDC and that’s when we started to differentiate. I would love to participate more in this discussion.
Specifically:
Questions:
Is there any existing modelling in CIEL we can look to for examples? See above description
A limitation of this model is that there’s no way to determine which sub-tests can be ordered “a la carte” and which can’t. Is this a problem? (I suspect it is… I’d love to avoid the “a la carte” use case for now, but it’s a requirement in our situation)
Are tests always 1 to 1 with obs? ie, if a “test” has two results, does that mean it should be broken up into two tests? (I’m guessing the answer is no, but taking a quick look in our dictionary the “Tests” I find are datatypes numeric or text, so I want to confirm See above, you do need separate result concepts when a single test produces multiple results.
How does Bahmni handle this modelling, and should we try to be consistent with that? Leave this to others.
In the interest of getting something ‘out-the-door’ are there simplifications we can make in the short-term and potentially improve in the long-term. What needs to be there from “day 1”? Too bad @r_friedman isn’t still working on this!
My advice would be to explicitly control which concepts are orderable – i.e., don’t assume that all lab tests or all lab test sets are orderable. Whether we add a flag to concepts or you use concept sets to manage them is less important. A flag would be easier to manage on the individual concept level, but concept sets would probably be easier for users to understand & manage and would have the advantage of optionally controlling the arrangement via sort_weight (e.g., showing hemoglobin before hematocrit or starting a basic metabolic panel with sodium as clinicians expect).
When building the Order Service API, we created an order_type_class_map that would specify orderables by class, but I would consider that to define what concept classes could be made orderable and not necessarily responsible for defining what is orderable (since “orderability” for an implementation will often be determined on a concept-by-concept basis).
The advantage of explicitly defining which concepts are orderable rather than trying to infer it will be important, because not everyone is going to want to allow clinicians to order individual components of a battery. Ultimately, in an enterprise system, the lab determines what lab tests are available, not the clinicians. If they want to offer a full hemogram as well as individual hemoglobin and hematocrit as lab tests, that’s fine; however, another lab may think that’s ridiculous, since they have a machine that derives all components of a full hemogram on a single specimen. By explicitly controlling what’s orderable, an implementation can decide whether or not they include only full hemogram or also include hemoglobin and hematocrit in the concept set(s) that define available orders. An important point from this: I would avoid building an application that assumes components of any battery will be individually orderable. Regardless, anytime you display a orderable battery, it wouldn’t be bad to include its list of components for informational purposes (e.g., we typically display all the components in the header of a battery order form).
We are also going to need an API methods to support things like:
“get me all orderables that match the phrase ‘card’” – eventually could return a list of orderables containing the medication diltiazem (Cardizem), labs like cardiolipin antibody tests, referrals like cardiology referrral, procedures like an echocardiogram, etc.
“get me all test orderables that match the phrase ‘hemo’” – would match to full hemogram and would only include hemoglobin if it was also included itself in the list of orderables.
Thanks @burke… I’ve changed the specifications in the ticket so that a component is only individually orderable if it is listed independently as a “test”:
