2024-11-4 Workshop
Clinical Program Board Workshop – EHRCON24
Notes of topics and discussions
Modelling Patient-Reported Outcome Measure (PROM) archetypes
PROM style guide proposal https://openehr.atlassian.net/wiki/x/AwBWkw
PROM Patient related outcome measure. Created for research and clinical trials. Organisations can be very strict about copyright.
PREM Patient reported experience measure- views about health care service received. More wholistic than care survey. In patient’s language.
PROMS Discussion summary:
· We need to look into the process of performing PROMS, such as ordering and tracking the process.
· Otherwise, we are largely in agreement about proposed style guide
· Item banks, example PROMIS was discussed
· OBSERVATION Class discussion
· Licensing issues briefly mentioned
· PROMs Lifecycle and ePRO Administration Proposal (by Koray Atalag) - openEHR Clinical - Confluence
Terminologies and value sets in archetypes and template modelling
Multilingual template value sets: Currently a limitation in tooling. See AD support for multilingual editing of templated value sets - Tool Support / Archetype Designer - openEHR
Terminology services: Will probably need to be managed on a national (or more local) level.
Important that this is agreed at National level, but work needs to be done to improve consistency internationally. Future goal - to work toward this together with SNOMED and terminology services. This inevitably leads to a multilayered approach.
Terminologies change more rapidly than clinical models so terminology services help to keep these up to date and regularly checked. Problem in maintaining SNOMED value sets because there is no external governance. Tooling implementation issues when value set code
Terminology Discussion summary:
· Terminologies change, more often than the archetypes
· Experience with terminology/ontology servers. Not much around, but wanted.
· Scotland has a ontoserver.
· We want SNOMED and openEHR to work together, which could simplify the SCT to become much easier, by using the information modelse of openEHR instead of SNOMED to add all the layers just representing the same. Example the qualifiers of diagnoses
Screening Questionnaire and family of archetypes
“Screening questionnaire” family of archetypes
How are these archetypes applied today and what insights can we gain to inform best practice?
Connection between archetypes at point of care and archetypes at secondary level.
Symptom/sign screening questionnaire
Ask Me Anything!
Is it possible to have some fields that do not change in the future?
Technically this is possible but extremely difficult to give a guarantee and will affect quality of archetypes long term. It may be possible to say an element is extremely unlikely to change. For example, systolic and diastolic readings in BP. However, with a new version of the archetype the implementers have to change the queries.
Developers would like a ‘Safe to use for a long period of time’ for some elements. Unfortunately, vendors will need to manage this so that archetypes can be maintained to give the best quality archetypes. Medical knowledge grows, and the models grow too.
Better documentation about implementation would be very useful. Currently, implementation guides and tools to support implementations are missing to help the vendors.
In the end it is really important for people to work together to ensure interoperability. Governance tooling at cluster and individual implementation level would help to manage this.
Diagnosis problem
In Netherlands they are finding problems between differential diagnosis and symptoms. They are missing a concept. Problem/diagnosis archetype. Discussion to be set up on Discourse.
User interface instructions, part of the archetype, template or something else?
· Cramming too many dimensions into the models will make them overly complicated.