Guidelines for developing PROM archetypes

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 clinicians. 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 across a distributed 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 in a public folder of CKM that has active copyright 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.

Concept description

Provide a short, objective 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.

EXAMPLE:
While openEHR archetypes are all freely available under an open license, the specific content of this <XYZ> archetype is copyright protected. Any use of this archetype within implementations must be in compliance with the terms established by the copyright owners.

Copyright statement: © Copyright Smith & Jones (1995). All rights reserved, do not use without the written permission of the copyright holders.​
Copyright informationhttps://www.sandj.com/license

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.

Copyright -

  • PROM instrument IP: see the Use section

  • Archetype copyright: © openEHR Foundation

  • Archetype license: CC BY-SA 4.0

4. Content modelling

Model each PROM instrument as a standalone OBSERVATION archetype unless it requires a configurable score representation using composable CLUSTER components. For example, in the PROMIS family of archetypes, an OBSERVATION should describe the universal framework and nested CLUSTERs should be used to represent each domain item bank.

Data

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

  • 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.

  • DO NOT include cluster headings as general groupers in the archetype.

    • However, 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 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.

  • DO NOT include any contextual statement that may precede some PROM items. For example, “Please answer the following questions based on your experience over the past 7 days: ”.

  • 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.

  • 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.

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.

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 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 they 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 by the authors or copyright holders may be included where there is alignment with the English version held in CKM. In this situation, a references to the authoritative source of the translation must be included within the Use section 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 publication.

  • must comply with openEHR archetype versioning rules.