Situation: In the 3.x RefApp, the Test Results feature pulls data in if there is any data for that patient where the concept Type = “Test”.
Currently in CIEL, SpO2 is a Test. This resulted in https://issues.openmrs.org/browse/MF-659 where SpO2 was showing up in Test results unexpectedly, instead of Vital Signs. This was easily fixed by changing the type in the EMR dictionary to not be “Test”; however, ideally CIEL would have a consistent way of capturing Vital Sign types.
E.g. right now, BP (which is also captured with a device) is listed as a “finding”.
Discussing with @akanter, it turns out that in SNOMED SpO2 is now an observable entry - so it doesn’t have to be a test. It would actually be a question not a finding. Same should be true of SBP.
The purpose of this thread is to discuss next steps, let people know, and i.d. any issues with changing the concept class.
Although traditionally I am very cautious about changing a concept class, in this case, it does align with SNOMED CT and this would only break workflows where people were searching for the class test to record SpO2.
What’s our definition of question, test, and finding? My rough mental working definitions are:
Question: something asked of the user or patient
Test: a procedure that provides a result
Finding: something you can observe by looking, listening, or touching the patient
I would’ve expected vitals signs, including BP and oximetry, to be tests, since they’re obtained through a procedure (you don’t ask the patient for their blood pressure or derive their SpO2 by simply looking at them). To separate these from other tests, I could imagine a class for vital signs. But, if these are a question or finding, what prevents hemoglobin or creatinine from being a question or finding?
I am not sure there is any consistency here. Usually observable entity (question) is used when the result is being requested, versus the result is part of the concept. For example. Respiratory Rate is a question, but Respiratory rate low would be a finding. SNOMED has Chief complaint as a finding (since I think they are using it as a flag rather than capturing a coded complaint. The original issue was that tests have results and we put the two together… when actually the procedure is the test but the result is an observation. I don’t want to create a vital sign class until we have have multiple classes per concept. I am OK with making these questions but do worry about what this will mean for all those findings in PIH.
This was an unfortunate short-cut introduced by FHIR2. I’d really love there to be some consistent mechanism for determining what is a “Vital Sign” vs something else, even if that consistent mechanism is everyone must have a ConceptSet named “Vital Signs”.
This seems like a red flag that we need a concept class for “Vital Signs”, since concept classes serve two purposes: (1) classifications that include large numbers of concepts and (2) concept sets (aka classifications) that are widely useful and/or programmed against.
I’m OK with this as a concept tag (class as a 1 to many from concept). I don’t think we can have only one class be vitals as there are all sorts of observations which can be considered a vital sign including LMP.
I think the point of classifying some concepts as vitals would be for those data that one would expect to be shown within the “vital signs” section of physical exam for a patient instead of mixed within test results (e.g., temperature, blood pressure, heart rate, respiratory rate, oximetry, etc.).
But what I think I’m hearing is we should use concept class to classify things by what they are instead of how we might use them.
I don’t know where the previous conversation is, but we wanted to removed the 1:1 relationship between concept and class so that we can add different classes for different use cases. For now, I don’t think using a new class to constrain vital signs is the right approach. If we need to create a conv. set to do this, than I would not be opposed to that.
I created TRUNK-4540 for this in 2014. We even contemplated a GSoC project for it, but eventually closed the ticket for lack of any pressing use cases or mandate by implementers.
So, it sounds like the near-term solution for this is a vital signs convenience set.
