Hi all,
First off, I’m new to the team so for those I haven’t met yet, I’m excited to work with all of you!
I’ll list out my approach from the platform meeting this morning to hopefully make my thoughts more clear.
I agree with Daniel that the least disruptive approach is to leave the concept_numeric table alone. We could treat it as a default fallback option for the case where a more specific numeric isn’t found for a given set of factors. While we could add additional columns to the concept_numeric table to support age and gender, it’s an incredibly rigid solution and the moment we need to add another factor (like ethnicity, weight, or any of the other factors Burke mentioned) we’ll have the same problem all over again. I get that it’s potentially the less costly option but I think it hilights the fact that we need a more generic solution here.
As Ian mentioned, pairing the ranges with observation data would put us on par with the FHIR approach but it seems that data is better configured outside of an individual observation context since its meant more as the expected range of a population at large.
Given all that, I’ve thought through a potential solution with the following table structure:
And a very rough UI for what editing these numeric groups could look like:
Essentially, instead of a concept being mapped to a single numeric, it’s mapped to a group of them, each defined by a group of factors. You can see I’ve also split out the range types (normal, critical and absolute) to their own table or enum. I feel this is more flexible than having them defined as columns since it lets us add new ones as needed without altering tables.
The big plus of this approach, aside from it more easily being able to be implemented as a module, is that it can grow dynamically as our needs change. If we want to support a new factor (such as pregnancy status) we simply need to add a row to the numeric_factor table.
Still to be sorted out is how we’d handle fallbacks in the case of where a patient only matches some of the factors, but that’s a problem to be solved no matter what approach we take.
Also of note, it seems that a concept can have multiple numeric values. For example, blood pressure has both an upper (systolic) and lower (diastolic) number. If we ever want to be able to perform automatic validation on a patient’s data to visually signify that either of these values are outside of the normal range, we’d likely want to store these two values seperately, right? If so, we could achieve this by creating a sub_concept type table to represent each individual numeric of a concept. But maybe that’s a problem for another time.