Proposal to amendment SEC change process, introducing an intermediate Specification Lifecycle State between "Stable" and "Retired"

Submitted by: @Sebastian Iancu

Date: Feb 8, 2025

Acceptance:

Introduction

The openEHR Specification Program (SEC) Change Process currently defines "Stable" and "Retired" as the primary states for specifications that are actively maintained or formally deprecated, respectively. There is an implicit workflow (assumption) on transition between between states, but the “Retired” state is not extensively described. However, there is no designated state to capture specifications that are no longer actively developed or maintained but are still available for reference or limited use.

To address this gap, this proposal recommends the introduction of an intermediate state between "Stable" and "Retired" to reflect the stalled or inactive nature of certain specifications while preserving their accessibility.

Proposed new state

The following terms are proposed as potential names for the new state, with "Paused" as the preferred options:

• Paused (Preferred): Denotes that the specification will not undergo further changes unless exceptional circumstances arise.

• Archived or Frozen: Denotes that the specification is locked in its current state, is no longer actively maintained or updated, but remains accessible for reference or historical purposes.

• Dormant, Suspended or Inactive: Implies that development on the specification has suspended indefinitely, with the chance that in the future will become replaced or retired, but it could also resume in the future if needed.

• Legacy: Suggests that the specification remains in use but is outdated and will not receive further updates, with an expectation that it will eventually be replaced or retired.

The change process will highlight in a notice-section that specifications with this state are not recommended for new implementations, but may still be in use. Some openEHR implementers or vendors might provide tools or software based on the specification, but there might be an outage planned. As they are not actively maintained anymore, such specification might also become incompatible in time with other specifications or components of openEHR, and eventually might be transited to “Retired” state.

The new state should describe also necessary transitions, as in the diagram below:

Open

Justification and alignment with industry practice

There is a need to label certain openEHR specifications or components that are not maintained anymore in a way that they become “less visible”, hinting the reader that the respective specification might not be widely adopted. Transiting the specification state to “Retired” was initially considered, but later the critique stated that in some situation the maintenance of the respective specification is merely paused, and it might be restarted in the future - a state that contradicts the “Retired” state, which seems to be a final state.

Similar standards organizations recognize the intermediate status to reflect specifications that are inactive but not yet deprecated. The following explores and demonstrate analogous lifecycle management practices:

• ISO/IEC: In lifecycle management standards (e.g., ISO/IEC 15288:2023), several stages exists, such as “Publication“, “Review” or "Support" indicating maintenance, and “Withdrawal“ or "Retirement" indicating withdrawal, but there is no explicit state for inactive yet usable specifications. (ref. The Standard life cycle)

• HL7: While HL7 manages the complete lifecycle of its standards, encompassing development, adoption, market recognition, utilization, and adherence, it does not explicitly define an intermediate state between active and retired statuses. The organization's comprehensive lifecycle approach implicitly acknowledges stages where specifications may not be actively developed but are still in use. (ref. Standards Process and Projects, Ballots)

• The Open Group: The Open Group applies phases such as "Published" and "Maintenance," where some specifications enter a state of limited updates. (ref. The Standards Development Lifecycle :: Standards Guide )

• The OpenAPI Specification (OAS): While the OpenAPI Initiative does not formally define lifecycle states for its widely adopted specifications for describing RESTful APIs, the community acknowledges versions that are no longer under active development but remain in use.

• Lifecycle Modeling Language (LML): LML is an open-standard modeling language designed to support the full lifecycle of systems, including conceptualization, utilization, support, and retirement stages. It integrates various lifecycle disciplines into a unified framework, facilitating comprehensive management of specifications throughout their lifecycle. The systems development life cycle (SDLC) as well as the project life cycle (PLC) makes distinction between maintained and closed (outage) states, but it does not considers unmaintained and yet active state, most likely as their scope are living systems.

• European Telecommunications Standards Institute (ETSI): ETSI's lifecycle management for network functions includes stages such as development, deployment, and decommissioning. Although ETSI does not explicitly define an intermediate state for stalled specifications, their lifecycle processes recognize phases where specifications may not be actively developed but are still operational.

• Object Management Group (OMG): Specifications in OMG undergo adoption and maintenance but lack an explicit state for stalled specifications.

Specification maintenance as an overlapping dimension

It is important to recognize that the adoption and implementation of a specification represent another dimension that overlaps with and justifies the change process. The level of adoption can influence decisions regarding the maintenance, updating, or retirement of a specification. Specifications may become inactive not because of an explicit decision to retire them, but due to a lack of active implementation, technological relevance or industry engagement.

The following correspondence of lifecycle state to maintenance state is proposed:

By introducing an "Paused" state, openEHR can account for specifications that remain theoretically valid, but they lack of active development. This approach provides users and implementers with clear guidance on whether a specification is viable for future projects or if alternative, actively maintained specifications should be prioritized.

Conclusion and Recommendation

To improve clarity of the needed change process on openEHR specifications, this proposal recommends the adoption of a new state between "Stable" and "Retired," with "Paused" as the preferred terminology. This change will improve transparency for stakeholders, and help distinguish between actively maintained and inactive specifications.