As CCIO and a CKA of CKM, I undertook to develop a proposal that would be discussed as our working proposal for PROMs. I haven’t had a chance to do it yet. Mea culpa.
Most of the discussion in Confluence was about where/how to document the full question and hierarchies to represent the contextual information. What didn’t feature so much was the important protection of copyright where relevant and governance issues, such as ensuring that original authors were satisfied that their tools were represented correctly and that reviewers did not find any ambiguity in the archetypes.
My notes are currently a few thousand miles away, but from memory, my discussions with @siljelb (as the other CKA) and @Kanthan_Theivendran (as lead of the CPB PROMs working group) established the following principle: Data elements should accurately represent the PROM questions as authored. This means using the full original question as the data element name. Shortening or paraphrasing introduces subjective interpretation, which risks diverging from the author’s intent, triggering debate during review, and potentially breaching copyright. In short, don’t make anything up.
I will endeavour to write this up more formally later in the week. Thanks for the poke.
Thank you very much for the link, where also the current PROM guidelines for the University Hospital Basel, which Ian referred to, can also be found.
You point out that, in addition to implementation guidelines for instructions and questions, other aspects need to be taken into account. I have added an ‘Extension’ to 'Protocol” and drafted a CLUSTER openEHR-EHR-CLUSTER.questionnaire_metadata.v0.adl. This is attached. It should also take into account the FHIR questionnaire metadata as far as possible. Is this a viable option?
I look forward to the final Implementation Guidelines for PROM/PREM Questionnaires in openEHR.
With regard to your proposed metadata extension, much of this has been discussed and the view was that many of the items were already carried in the archetype metadata definition and did not have to be explicitly recorded in the patient record. FHIR Questionnaires are in essence, design-time artefacts i.e not actually part of a patient record. If we need to carry some of these items it would probably be as extra
tags in the other_details section of the archety[e and not as an actual CLUSTER which intended for data that will end up in the patient record
But definitely worth reviewing, in terms of any extra information that we should include as routine.
As you know, I have, until now been on the other side of this argument i.e. that we should use short names but carry the long named elsewhere.
This is definitely a case of ‘both sides’ having a good case but we do need to come to a conclusion, and on balance, it is probably easier to accomodate those scenarios where short names are required, as an exception, with a particular need to lower the burden on CKM authors/editors.
In that case, those of us who might want or need to surface short names in downstream tech artefacts should get together and find a way of advising tooling folks what we need. e.g we just overwrite the long name in a local template. Not quite that simple but hopefully we can find an approach that is not too burdensome for modellers but is also supported in tooling.
Hello Ian, thank you very much, good points.
I am primarily concerned with the secondary use of the composition, i.e. scientific evaluation. There are certain general conditions that may be required, e.g.
Language on then screen of the questionnaire when completed by the patient (recognition of language-related bias)
How the questionnaire was administered (e.g. patient himself, proxy, interviewer)
On which device was the questionnaire completed (desktop, tablet, smartphone/manually, speech recognition)
What would be the best practices for storing this data in the composition?
Hi @JPMesserli and all, long story short I prepared a very comprehensive guide for full-lifecycle of PROMs representation and implementation. I’m sharing this because I put a lot of previous real-world implementation experience and knowledge (we built a PROMs/PREMs solution and undertook quite large-scale (national/state-wide projects) - but our data model was proprietary and we used FHIR Questionnaire/QuestionnaireResponse resources for integation with EMR/HIEs).
Related with your query on meta-data the link will take you to relevant section in my guide.
This was at early stages of PROMs WG discussions and I dumped all my ideas without much consideration of existing work and approaches within the openEHR Community. I’m talking about pre-EHRCon2024. There, we had a good discussion with quite a few people around the table and then we mostly converged. Where the contention lies at the moment is:
Long vs short labels in PROMs Archetypes: 100% I think we should stick with author’s guide BUT when administering it. But we don’t need full path for data analysis and secondary use (e.g. as data dictionary and after response is collected). So, I think we need to consider these two options together.
I also think proper tooling should also support the latter use cases; for example reducing length of full path of elements using a discrete shortener (e.g. like URL shortener but leaving enough semantics for human readability) so the Web Template will look much better.
Mitigating copyright/IP issues: now this is really really important and I echo what @heather.leslie said. My take on this is we need to answer an existential question:
a) Is the purpose of PROMs Archetypes to faithfully represent full instrument (with instructions at the top - which can change for example for adult vs paediatric patients or when administered by a proxy). Followed by individual or groups of nodes to capture questions to the degree it will drive ePRO solutions to be able to provide GUI for administration to patient/proxy as well support linkage with other assessments in a VBHC care pathway. Plus all the analytics, trended results, dashboards and reporting for quality improvement/performance benchmarking as well VBHC payment and population health/policy making. So, I’m talking about the end-to-end use case here.
b) Is the purpose to simply persist, query and unpack PROMs data to populate proper clinical concepts (e.g. comorbidities captured in Problem/Diagnosis archetype, symptoms patient is reporting into proper openEHR models so they can be part of the EHR) - while full question labels and meta-data is managed separately and with proper licensing/permissions from authors.
I think the answer is the latter. And take how ICHOM provides full data dictionaries, including PROMs that are not in the public domain. I’m attaching the Excel data dictionary which has the gold standard PAID PROMs (copyrighted and with license fees in most cases) and you’ll see its data elements.
The way they get around this is simply the data dictionary is providing a template for storing data and not for electronic PROMs administration. It’s the vendor’s and consuming organisations responsibility to get access to the full instrument and build UIs, administration workflows, integrations - using additional data from the instrument but also others such as scoring guides, CAT-IRT item banks etc.
BOTTOMLINE: I think we should shorten the Archetype labels, optionally store full label in Description (we need to check of authors’ are comfortable - since ICHOM data dictionaries include full labels it should be doable). Proper tooling should allow for consistent shortening while keeping key semantics of the node/element/question for users who would consume this (data analysts, quality managers etc.). Clinical and other operational users who need full labels can always use text in Description. Hope it all makes sense.