So long story, but..
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.
With this context, the last year especially, I’ve really been trying to focus on the developer experience of implementing openEHR (see pain points at openEHR in Real Systems: Where Does It Break Down in Practice? - #5 by Cozy_Beard) with a simplified approach using SQL as a foundation for implementing openEHR archetypes - openEHR archetypes as SQL Tables - #53 by Sidharth_Ramesh.
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:
create adverse_reaction_screening.v1 (
presence 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
)
which is not the worst, but adds complexity.