Guidelines for developing PROM archetypes

1. Scope and intent

• This guideline provides high-level rules for developing openEHR archetypes that represent validated Patient-Reported Outcome Measures (PROMs), including those that may be administered or recorded by carers or other proxies. It should be read in conjunction with the openEHR Editorial Guidelines.

• The objective is to ensure that PROM archetypes are clinically appropriate, faithful to their source instruments, and safely reusable across implementations.

• These guidelines have been developed with an emphasis on clarity and simplicity, in order to maximise the likelihood of producing consistent, high quality PROMs that can be distributed across a global environment.

2. Principles

• Appropriate permission or licence to use a copyrighted PROM must be secured before it is incorporated into a governed and public CKM project.

  • DO NOT include an archetype that has active copyright in a public project or incubator of CKM without permission. Discussions with active copyright holders has resulted in a variety of responses, some encouraging and supportive, others explicitly refusing due to strict commercial licensing conditions. If in doubt, consult the International Editorial Committee for guidance.

• Maintain fidelity to the scope of the original instrument by not altering the wording of items and responses or the sequence of items. This approach will:

  • ensure openEHR does not break copyright or breach the intellectual property of the original authors or current rights holders.

  • facilitate a simpler review process by allowing reviewers to focus on correct digital representation rather than interpretation or re-expression of content.
    Note: If the instrument cannot be represented exactly as originally documented, and a specific adaptation or interpretation is required for appropriate digital representation, then the adaptation or interpretation must be documented in the Use section. For example, a VAS score typically rendered as a line on a paper form may need to be represented using a DV_COUNT data type in an archetype.

• Review and publication of an archetype representing a copyrighted PROM should include the authors or copyright holders in the process wherever possible, and potentially should consider their approval prior to publication in CKM.

3. Metadata

Metadata must comply with the Editorial style guide, as well as additional conventions for Scores and Scales. If in doubt, consult the International Editorial Committee for guidance.

Concept name

Select a concept name that clearly identifies the original PROM instrument, including the published version of the instrument where necessary.

For example: “Measure of activity performance of the hand (MAP-Hand)”

Concept description

Provide a short description of the PROM content being recorded.

For example: “A patient-reported outcome measure used to…

Keywords

Include terms that support CKM search and classification.

Purpose

Describe the reason for using this archetype to record data, not the purpose of the PROM itself. Follow the Editorial style guide conventions and begin with “To record…”. For example: “To record the results for each component parameter and their total sum for the <XYZ> score.”

Use

• Follow the Editorial style guide conventions and begin with “Use to record…”.

• Explain how the archetype has been designed for use within digital systems, such as recording or exchanging PROM response data.

  • DO NOT describe the structure, content, or administration of the PROM instrument. This text is not a substitute for the PROM’s official user manual.

• Include an appropriately adapted version of the italicised text in the information panel, below, together with the required copyright or licensing information, as explicitly directed by the IP holder. The italicised text should be translated into the language of each translation, while the copyright statement should be kept in its original language.

Misuse

Preface with “Not to be used…” and clearly describe scenarios where this archetype is not appropriate. Follow with one of the following:

• a sentence directing users to the appropriate archetype(s) for the specified use case, or

• if no suitable archetype exists, use: “A separate archetype is intended for this use case but was not available at the time of authoring or publication.”

References

As per the References section of the Editorial style guide.

• The main reference should be the original publication of the PROM, or a publication which defines the specific version of the PROM represented in the archetype.

• If the PROM requires a specific (audio-)visual representation when it is being answered, include a reference to relevant resources.

Copyright -

• PROM instrument IP: see the Use section

• Archetype copyright: © openEHR Foundation

• Archetype license: CC BY-SA 4.0

4. Content modelling

Choosing an archetype class

Most PROM instruments should be modelled as standalone OBSERVATION archetypes.

However, if the original instrument is part of a framework other patterns should be used:

• where questionnaires are created using questions drawn from discrete item banks, an OBSERVATION should describe the universal framework, nested CLUSTERs should be used to represent each item bank, and the specific questionnaires should be represented using templates.

• where one or more questionnaires are subsets of the questions contained within a single, larger questionnaire, the larger questionnaire should be modelled as a maximal OBSERVATION archetype, and the subset questionnaires as templates constraining out irrelevant elements. For example: EPIC

Data

• The order of data elements should mirror the sequence of items in the validated questionnaire wherever possible.

  • Where the instrument has question numbers, subscale IDs, or other annotations associated with specific questions or sections, these can be added using archetype annotations. See https://openehr.atlassian.net/wiki/x/BICt1w for guidance on adding and naming annotations.

• Each item (question) should be represented explicitly as a data element with its associated responses (answers).

• Each item name and all responses should preserve the original wording verbatim, even if long.

  • DO NOT change an item name or response in any way, including inventing shortened names, using alternative terms or creating substitute categories or domains.

  • If the original item names include numbering, the numbers should be included in the archetype element names.

• DO NOT include cluster headings as general groupers in the archetype. There are a few identified exceptions to this rule:

  • if the instrument includes multiple identically named items that must be semantically separated in the archetype to provide correct context, an inline cluster ‘heading’ representing a domain name or a time frame may be necessary. For example:

    • ‘Mobility’ domain - “How much difficulty do you have climbing a flight of stairs?” with a focus on muscle strength, balance, endurance.

    • 'Pain' domain - “How much difficulty do you have climbing a flight of stairs?” with a focus on measuring how pain limits the same activity.

    • ‘Last week’ time frame - “How much difficulty have you had climbing a flight of stairs?”

    • ‘Last month’ time frame - “How much difficulty have you had climbing a flight of stairs?”

  • if the instrument includes “header questions” followed by several sub-questions which don’t make sense without the header question, an inline cluster “header question” may be necessary. For example:

    • header question: “How big a problem, if any, had each of the following been for you during the last 4 weeks?”

      • sub-questions: “Dripping or leaking urine”, “Pain or burning on urination”, etc

• DO NOT include any contextual statement or instruction that may precede some PROM items. For example, “For the following questions please circle the number between 1 and 7 that best applies to you”.

• DO NOT include bolding, emphasis, or any other formatting attributes intended to control user interface display within the archetype. Any presentation or formatting requirements specified in the original PROM are the responsibility of the system implementer and will typically be governed by the licensing terms agreed between the implementer and the copyright holder.

• DO NOT include commentary or annotation about conditional item. Conditionality is currently not supported in tooling and therefore remains an implementation issue that will typically be governed by the licensing terms agreed between the implementer and the copyright holder.

• DO NOT include data elements that are routinely found in other clinical archetypes. For example, “Clinical description” or “Comment” should only be included if they are explicitly part of the PROM.

Data types

• Use DV_CODED_TEXT for unscored response options. Represent the original response wording as the text. No additional description should be included.

• Use DV_ORDINAL for responses scored with integers.

  • Represent the score for each response as the ordinal ‘value’ attribute, and use the original response wording as the ordinal ‘text’ attribute. No additional ‘description’ should be included.

  • Value sets wholly or partly consisting of numbers without corresponding descriptions should be represented by the ‘value’ only, do not invent descriptions where the original instrument doesn’t have them.

• Use DV_SCALE for responses scored using non-integer values. Represent the decimal score for each response as the scale ‘value’ attribute, and use the original response wording as the scale ‘text’ attribute. No additional ‘description’ should be included.

• Use DV_COUNT or DV_QUANTITY for respectively integer or decimal number result score elements, or where the patient is expected to enter a number in a simple field without a selection list.

State

• No state-related data should be included unless explicitly required in the original instrument.

• DO NOT include generic modelling patterns, such as ‘Confounding factors’, by default.

Protocol

• DO NOT include an Extension SLOT.

Events

• Most PROM archetypes should have a single “Any point-in-time event” representing the time when the measure was performed.

• In some use cases it may be relevant to include fixed interval events such as “During the last 2 weeks”, mostly when the measure can be performed for different time periods.

• In some use cases it may be relevant to include separate interval events such as “Mean” or “Maximum”, or a generic “Any interval event” to allow any math function to be applied.

5. Scoring and result representation

• Computation of PROM scores should be performed in applications, not within the archetype. This ensures separation of data model from scoring logic and prevents computational interpretation outside the control of the copyright holder. This approach may be reviewed in future if tooling matures to support governed embedded computation.

6. Terminology bindings

• A terminology binding to the clinical concept name should be applied at at0000 (ADL1.4) / id1 (ADL2) when a PROM instrument is represented by a recognised terminology concept. For example a SNOMED CT code from the assessment scale hierarchy: SCTID 273302005 | Barthel index (assessment scale) |

• Bindings to item names (questions) and responses (answers) should only be included if terms available in the international edition of a terminology/ontology are formally recognised components of the PROM, and their use has been approved or previously published by the instrument’s authors or copyright holders.

7. Language translation

• Translations that have been validated or otherwise approved by the authors or copyright holders may be included where there is alignment with the English version held in CKM. In this situation, references to the authoritative source of the translation must be included within the Use section of the relevant translation, immediately following the copyright statements.

• Ad hoc translations using usual CKM processes may be included only with the approval of the authors or copyright holders and must comply with their conditions to translate. If in doubt, consult the International Editorial Committee for guidance.

8. Governance, review, and publication

All PROM archetypes:

• are subject to the openEHR CKM content review process, and if appropriate, terminology and translation reviews.

• must meet copyright and licensing requirements prior to CKM upload.