This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

?.? FHIR Life Cycle Page

?.?.1 Introduction

Many FHIR resources have a status element that represents the lifecycle state of the resource or the clinical process represented by the resource. Work groups can specify status values appropriate to the individual resource. Although consistency between resources is not the primary objective, it is helpful to users and developers to have well-crafted value sets that cover all possible states (since the value sets are typically required and non-extensible).

To understand existing status elements, and to help create extensions and resources involving resource states, we note that status value sets follow one of the following patterns:

• Clinical workflow process pattern
• Request/Order pattern
• Entity status pattern
• Clinical status pattern

?.?.2 Clinical Workflow Process Pattern

Describes the lifecycle states of complex activities common in healthcare. Typically, these states follow a chronological pattern that leads from initiation to the conclusion of the action. A characteristic set of states for the clinical workflow process pattern include:

• planned – resources for the activity are being allocated but the activity has not begun
• cancelled – the planned activity will not take place
• in-progress – the activity has begun
• on-hold (suspended) – the activity has been temporarily interrupted
• stopped (aborted, failed) – the activity has not been completed but no future action is planned
• completed (finished) – the activity has been completed

Examples of the clinical workflow pattern:

• Communication.status: in-progress | completed | suspended | rejected | failed
• Encounter.status: planned | arrived | in-progress | onleave | finished | cancelled
• Goal.status: proposed | planned | in-progress | achieved | sustaining | cancelled | accepted | rejected
• MedicationAdministration.status: in-progress | on-hold | completed | entered-in-error | stopped
• MedicationDispense.status: in-progress | on-hold | completed | entered-in-error | stopped
• Procedure.status: in-progress | aborted | completed | entered-in-error

?.?.3 Request/Order Pattern

Some resources in FHIR that represent orders or requests. The request lifecycle can be generalized in terms of four stages: creating the request, sending the request, receiving acceptance or refusal of the request, and fulfillment of the request. A characteristic set of states for the clinical workflow process pattern include:

• proposed: An actor (e.g. a clinical decision support system) has proposed an action to be requested
• draft: The request is in preliminary form, prior to being requested
• requested: The request has been been made
• rejected: The request receiver has declined the request
• accepted: The request receiver has accepted the request
• in-progress: Work to fulfill the request has begun
• on-hold (suspended): Work on the request has been interrupted
• stopped (aborted): The activity has not been completed but no future action is planned
• completed: Work on the requested task has been completed, and no further action is required
• cancelled: The request has been withdrawn

Examples of the request/order pattern:

• CommunicationRequest.status: proposed | planned | requested | received | accepted | in-progress | completed | suspended | rejected | failed
• DeviceUseRequest: proposed | planned | requested | received | accepted | in-progress | completed | suspended | rejected | aborted
• DiagnosticOrder.status: proposed | draft | planned | requested | received | accepted | in-progress | review | completed | cancelled | suspended | rejected | failed
• MedicationPrescription.status: active | on-hold | completed | entered-in-error | stopped | superceded | draft
• ProcedureRequest.status: proposed | draft | requested | received | accepted | in-progress | completed | suspended | rejected | aborted
• ReferralRequest.status: draft | sent | active | cancelled | rejected | completed

?.?.4 Entity Availability Pattern

The entity availability pattern indicates if the resource, or the entity described by the resource, is ready for use, not yet ready for use, or has been retired from use. A characteristic set of states for the clinical workflow process pattern include:

• draft: The entity is being prepared but is not yet in use
• active: The entity is in use
• suspended: The entity is not in use at the moment, but may return to active status
• amended: The entity has undergone a revision but is still active
• retired (superseded): The entity is no longer in use.

Examples of the entity availability pattern:

• DiagnosticReport.status: registered | partial | final | corrected | appended | cancelled | entered-in-error
• MedicationStatement.status: in-progress* | completed* | entered-in-error
• DocumentManifest.status: current | superceded | entered-in-error
• Conformance.status: draft | active | retired
• StructureDefinition.status: draft | active | retired
• DataElement: draft | active | retired
• Questionnaire.status: draft | published | retired
• DocumentReference.status: preliminary | final | appended | amended | entered-in-error
• QuestionnaireResponse.status: in-progress | completed | amended
• Alert.status: active | inactive | entered-in-error
• Location.status: active | suspended | inactive
• Organization.active: true/false
• Patient.active: true/false

*states reflecting the administration of the medication

?.?.5 Clinical Status Pattern

Clinical status is somewhat different that the previous status values, since it does not deal with workflow or lifecycle. Instead, it indicates how evidence is affecting a clinical interpretation. Here are two examples:

• AllergyIntolerance.status: unconfirmed | confirmed | resolved | refuted
• Condition.clinicalStatus: provisional | working | confirmed | refuted

?.?.6 Entered In Error Summary

The entered-in-error state indicates the resource was created accidentally, and should be ignored. This state can apply to resources created by manual entry. It is usually not associated with the Clinical Workflow Process pattern, but can be associated with the Request/Order and the Entity Availability patterns.

This table summarises what is expected to happen for each resource in the case that the data it contains is subsequently found to be an erroneous entry.