I’m looking at a bunch of screening-style archetypes where a presence field (encodes boolean information) is modelled as a choice of: DV_BOOLEAN, DV_CODED_TEXT, DV_TEXT
Across these archetypes, the coded text options seem to be variants of:
Yes
No
Unknown
Not asked / not known / unable to determine, depending on archetype wording
If the field is fundamentally a yes/no clinical assertion, why is this modelled as a choice between DV_BOOLEAN, DV_CODED_TEXT, and DV_TEXT instead of just DV_BOOLEAN?
There already seem to be several ways to represent uncertainty or absence:
The field can be left empty if it is optional in a template, and just be null
openEHR null flavours can represent missing, unknown, masked, not asked, etc.
Adding DV_CODED_TEXT and DV_TEXT seems to introduce ambiguity in how this data point can be captured.
What was the modelling rationale for introducing DV_CODED_TEXT and DV_TEXT here? Are these intended to capture clinically meaningful states beyond true/false, or are they mainly a workaround for uncertainty/missingness? If they are intended to represent uncertainty, why not rely on null flavours or optionality instead?
Others will give a more complete answer. But usual pattern is as you say yes/no/unknown/other(namely).
Very few things in medicine are binary.
Unknown isn’t nescessarily uncertainty/absence of information. Eg in advance decisions it means patients doesn’t know if they want resuscitation. Which is very different from the doctor doesn’t know what the patient wants (eg because they haven’t asked).
The other is usually combined with a dv_text to explain in more detail.
What is the isssue witht this pattern for you? Is it just engineering elegance or something else?
When building EHR systems for many practices previously, I saw that most doctors fallback on unstructured text summaries as the definitive truth even if given forms / fields to capture structured data. So for a lot of these use cases, the structured data points we were building in openEHR only made sense if it captured unambiguously computable information. Something like Unknown / Not willing to answer could always be captured as free text with more context. We were also doing a bunch of text/voice → structured data conversion here as well, and needed simple schemas to auto-fill forms from the unstructured data.
And the way I’ve used archetypes in templates for these use case has almost always has been very opinionated to eliminate the fuzzy, ambiguous, unknown data elements as much as possible because it can always be represented in free text that’ll live alongside the structured record.
As a part of this, I’ve been trying to convert certain archetypes to SQL tables with a well defined simple enough schema. I think it’s possible to do if a few opinionated clinical decisions about an archetype’s usage can be made in advance. And when I was going through the above archetypes, I really just wanted to represent these choice fields as DV_BOOLEAN:
Because it seems to make the most sense given my goal to eliminate the “fuzzy, ambiguous, unknown”. But I don’t want to make this decisions without understanding the full clinical modeling logic that went behind it. Especially the presence of DV_TEXT as one of the choice options stumped me - like why allow free text in these “Presence?” fields. If it represents some actual use case I didn’t know about, then I’ll have to do something like:
create adverse_reaction_screening.v1 (
presence_boolean boolean
presence_text text
-- SQL constraint to allow either presence_dv_boolean or presence_dv_text
-- not both
)
@Sidharth_Ramesh I have been following your research into using archetypes as tables in a relational database. While storing Reference Model (RM) data relationally is challenging, I am not convinced that simplifying the RM is the best approach.
I believe it is possible to maintain the full RM when persisting compositions in a purely relational way. Ultimately, we do not have to make compromises when storing and querying RM data. You can find more details on this approach here: Querying an openEHR CDR with SQL, Cypher, and GraphQL? Yes, it’s possible.
SELECT $blood_pressure.data.events.data.items AS blood_pressure,
$pulse.data.events.data.items AS pulse
FROM `openEHR-EHR-COMPOSITION.encounter.v1`
LET $blood_pressure = out('has_openEHR-EHR-OBSERVATION.blood_pressure.v2'),
$pulse = out('has_openEHR-EHR-OBSERVATION.pulse.v2'),
WHERE $blood_pressure CONTAINS (data.events CONTAINS (data.items CONTAINS (
archetype_node_id = "at0004" AND -- Systolic
value.magnitude > 140 AND value.units = "mm[Hg]"))) AND
$pulse CONTAINS (data.events CONTAINS (data.items CONTAINS (
archetype_node_id = "at0004" AND -- Rate
value.magnitude > 80 AND value.units = "/min")))
There is a deliberate modelling strategy behind the repeating pattern evident in these archetypes.
The family of screening questionnaire archetypes is attempting to establish a standardised pattern in an area where almost no standardisation currently exists. Most questionnaires are created from scratch, with different structures, different data types, and different approaches. Our aim has been to identify and model the common, reusable patterns across them, to tame a very wild and variable set of data as best we could.
The archetype metadata deliberately explains that some aspects of the model are intentionally loose - especially with ‘Timing’, which is an issue that concerns me more than the Yes/No values. We are trying to standardise what is, in many respects, the data equivalent of jello.
The challenge goes further. We need to support not only what we would consider future best practice (which will probably be better expressed through agreed templates at some point), but also the large body of legacy questionnaires and registry data that continue to provide significant clinical and research value.
As a result, the modelling may appear untidy or less prescriptive than would be ideal. However, that reflects the need to balance the reality of existing practice with where we want the ecosystem to evolve. This flexibility is one of the reasons these archetypes have been successfully adopted across many implementations and datasets.
Hopefully, over time we will be able to become more prescriptive as questionnaire and registry designers increasingly use approaches such as openEHR from the outset rather than designing each questionnaire independently.
The different data types are intended to support this balance between current practice and the desired future state:
DV_CODED_TEXT is the preferred option because many clinical questions cannot be represented adequately by a simple Yes/No response. In practice, responses often require an intermediate option rather than a strict binary choice.
Following extensive Editorial discussion, the documented recommendation in the Editorial Style Guide) is to use a standard value set such as Yes / No / Unsure / Unknown (or a similar, relevant equivalent) across screening questionnaires. In this context, Unknown is a genuine clinical response rather than simply a technical null value, so it is modelled explicitly.
We also considered terms such as Uncertain and Indeterminate which may be considered interchangeable. However the Editorial decision was that Unsure is the preferred term in our questionnaire contexts because it reflects the respondent’s subjective doubt or hesitation. By comparison, Uncertain suggests inherent unpredictability or lack of certainty about the underlying situation, which is a different concept.
DV_TEXT allows alternative response sets to be defined at the template level where local requirements differ.
DV_BOOLEAN exists primarily to support legacy datasets and existing implementations.
Amazing! This is exactly the answer I was looking for @heather.leslie!
So in short, if you were on a boat with DV_TEXT, DV_CODED_TEXT, and DV_BOOLEAN (for this use case). And you were forced to keep only one, you’d throw DV_BOOLEAN first, DV_TEXT next and keep DV_CODED_TEXT? Would you maybe consider throwing DV_TEXT first before DV_BOOLEAN?
Well, in the interests of standardisation, the DV_CODED_TEXT is the generic and I guess the Editor’s would suggest it is their preferred value set, as explained above. But we will definitely find examples, some quite sensible, where this doesn’t work and we need DV_TEXT as our ‘get out of jail free’ card for a value set that is a little left field or unique.
I think it is fair to say that DV_BOOLEAN is our least preferred. Very few things are binary, and if so, just constraining the DV_CODED_TEXT terms would be more preferable.
