DSTU2 STU 3 Ballot
This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is

This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). The current version which supercedes this version is 5.0.0 . For a full list of available versions, see the Directory of published versions . For a full list of available versions, see the Directory of published versions . Page versions: . Page versions: R5 R4B R4 R3 R2

1.13 2.16 FHIR Life Cycle Page FHIR Life Cycle Page

This page describes several issues around lifecycle management for the resources and the content they contain. Specifically, this page describes:
FHIR Infrastructure FHIR Infrastructure Work Group Work Group Maturity Level : 3 Maturity Level : 3 Ballot Status : DSTU 2 Ballot Status : STU 3

This page describes several issues around lifecycle management for the resources and the content they contain. Specifically, this page describes:

1.13.1 Resource Status 2.16.1 Resource Status 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 life cycles: Clinical workflow process life cycle Request/Order life cycle Entity status life cycle Clinical status life cycle

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 life cycles:

  • Clinical workflow process life cycle
  • Request/Order life cycle
  • Entity status life cycle
  • Clinical status life cycle

1.13.2 Clinical Workflow Process Life Cycle 2.16.2 Clinical Workflow Process Life Cycle Describes the lifecycle states of complex activities common in healthcare. Typically, these states follow a chronological life cycle that leads from initiation to the conclusion of the action. A characteristic (but non-exhaustive) set of states for the clinical workflow process life cycle include: planned - resources for the activity are being allocated but the activity has not begun cancelled - the planned activity did not start and 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 life cycle: Communication.status:

Describes the lifecycle states of complex activities common in healthcare. Typically, these states follow a chronological life cycle that leads from initiation to the conclusion of the action. A characteristic (but non-exhaustive) set of states for the clinical workflow process life cycle include:

  • planned - resources for the activity are being allocated but the activity has not begun
  • cancelled - the planned activity did not start and 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 life cycle:

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

1.13.3 Request/Order Life Cycle 2.16.3 Request/Order Life Cycle Some resources in FHIR 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 (but non-exhaustive) set of states for the request/order 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 life cycle: CommunicationRequest.status:

Some resources in FHIR 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 (but non-exhaustive) set of states for the request/order 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 life cycle:

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

1.13.4 Entity Availability Life Cycle 2.16.4 Entity Availability Life Cycle The entity availability life cycle 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 (but non-exhaustive) set of states for the entity availability life cycle 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 life cycle: DiagnosticReport.status:

The entity availability life cycle 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 (but non-exhaustive) set of states for the entity availability life cycle 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 life cycle:

  • DiagnosticReport.status: registered | | partial | | final | | corrected | | appended | | cancelled | | entered-in-error MedicationStatement.status:
  • MedicationStatement.status: active | | completed | | entered-in-error | | intended . (note: in-progress and completed are states reflecting the administration of the medication) DocumentManifest.status: | stopped | on-hold . (note: in-progress and completed are states reflecting the administration of the medication)
  • DocumentManifest.status: current | | superseded | | entered-in-error Conformance.status:
  • Conformance.status: draft | | active | | retired StructureDefinition.status:
  • StructureDefinition.status: draft | | active | | retired DataElement:
  • DataElement: draft | | active | | retired Questionnaire.status:
  • Questionnaire.status: draft | | published | | retired DocumentReference.status:
  • DocumentReference.status: current | | superseded | | entered-in-error QuestionnaireResponse.status:
  • QuestionnaireResponse.status: in-progress | | completed | | amended Flag.status:
  • Flag.status: active | | inactive | | entered-in-error Location.status:
  • Location.status: active | | suspended | | inactive Organization.active: true | false Patient.active: true | false
  • Organization.active: true | false
  • Patient.active: true | false

1.13.5 Clinical Status Life Cycle 2.16.5 Clinical Status Life Cycle Clinical status is somewhat different than 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:

Clinical status is somewhat different than 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: active | | inactive Condition.clinicalStatus:
  • Condition.clinicalStatus: active | | relapse | | remission | | resolved

1.13.6 Current Resource Lists 2.16.6 Current Resource Lists Many clinical systems maintain current lists of some kind of resources for a patient. Some of the commonly maintained lists include: Current Problem List: a list of the problems that are of concern for care of the patient Current Medication List: a list of the medications that a patient is known to be on at the current time Because of the way that resources are used, there is no simple way to determine, from examination of a resource, whether it is 'current' or not. Take, as an example, the

Many clinical systems maintain current lists of some kind of resources for a patient. Some of the commonly maintained lists include:

  • Current Problem List: a list of the problems that are of concern for care of the patient
  • Current Medication List: a list of the medications that a patient is known to be on at the current time

Because of the way that resources are used, there is no simple way to determine, from examination of a resource, whether it is 'current' or not. Take, as an example, the Condition resource. In a typical EHR, condition resources might be published on the RESTful interface for the following reasons: to represent an item in a patient's curated problem list to represent a complaint or a diagnosis from an encounter record to represent a problem for investigation provided by a diagnostic system as part of a DiagnosticOrder resource. In a typical EHR, condition resources might be published on the RESTful interface for the following reasons:

There is no element on the Condition resource than can convey the difference between these usages. In particular, there can be no way to differentiate between current and past current resources without having to retrospectively alter resources, which is problematic with regard to intergrity and digital signatures.

One consequnce of this is that searching the condition resource for a given patient will return more than just the patient's current problems. Though this is somewhat counter-intuitive to some implementers, restricting searches on Condition to only include the patient's current curated problem list excludes all the other - important - uses of the Condition resource.

Determining whether a Condition is an entry on a patient's current problem list is done by checking with the Condition resource is referenced from the correct list.

On the RESTful API, this is done using the list search mechanism : 

 GET [base]/AllergyIntolerance?patient=42&_list=$current-allergies
This
is
a
request
to
fetch
all
the
allergies
in
the
patient
42's
"Currrent
Problem
List".
Note
that
the
server
is
not
required
to
actually
make
a
resource
representation
of
the
current
allergy
list
available,
though
doing
so
assists
clients
in
their
audit/integrity
tasks.
See
List
Operation
"Find"
for
further
information.
In
a
document,
current
lists
are
determined
by
the
code
on
a
Composition
section.
FHIR
defines
the
following
names
for
functional
lists:

This is a request to fetch all the allergies in the patient 42's "Currrent Problem List". Note that the server is not required to actually make a resource representation of the current allergy list available, though doing so assists clients in their audit/integrity tasks. See List Operation "Find" for further information.

In a document, current lists are determined by the code on a Composition section.

FHIR defines the following names for functional lists:

List ResourceType Description Possible LOINC codes in documents / sections Possible LOINC codes in documents / sections
$current-problems Condition The "Currrent Problem List" - A list of current and active diagnoses as well as past diagnoses relevant to the current care of the patient 46105-3 (Problem conditions Set) The "Currrent Problem List" - A list of current and active diagnoses as well as past diagnoses relevant to the current care of the patient 46105-3 (Problem conditions Set)
$current-medications MedicationStatement / / MedicationOrder A list of all medications that the patient is taking. The 'current medications list' sometimes may in clude a mix of prescribed and over-the-counter medications - or only some of them. The list may contain a mix of A list of all medications that the patient is taking. The 'current medications list' sometimes may in clude a mix of prescribed and over-the-counter medications - or only some of them. The list may contain a mix of prescriptions and more general and more general statements , or only one of the two. The list may also correspond to a formal reconciled medication administration schedule, but more often does not 57828-6 (Prescription list), 10160-0 (History of medication) , or only one of the two. The list may also correspond to a formal reconciled medication administration schedule, but more often does not 57828-6 (Prescription list), 10160-0 (History of medication)
$current-allergies AllergyIntolerance A list of known or suspected propensities to medications, foods, or environmental agents that is provided to help prevent reactions while care is occurring 18716-1 (Allergy studies (set)), 52472-8 (Allergies and Adverse Drug Reactions), and 48765-2 (Allergies and adverse reactions Document) A list of known or suspected propensities to medications, foods, or environmental agents that is provided to help prevent reactions while care is occurring 18716-1 (Allergy studies (set)), 52472-8 (Allergies and Adverse Drug Reactions), and 48765-2 (Allergies and adverse reactions Document)
$current-drug-allergies AllergyIntolerance A list of known or suspected propensities to medications that is provided to help prevent reactions while care is occurring. This list is a subset of the full allergies list (same as above?) A list of known or suspected propensities to medications that is provided to help prevent reactions while care is occurring. This list is a subset of the full allergies list (same as above?)

1.13.7 Entered In Error Summary 2.16.7 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 life cycle, but can be associated with the Request/Order and the Entity Availability life cycles. 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.

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 life cycle, but can be associated with the Request/Order and the Entity Availability life cycles.

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.

.status = entered-in-error .status = entered-in-error .status = retired .status = retired .status = retired .status = entered-in-error .status = entered-in-error .status = entered-in-error .status = entered-in-error .status = entered-in-error .status = entered-in-error .status = entered-in-error .status = retired .status = entered-in-error .status = inactive .status = entered-in-error .status = entered-in-error .status = entered-in-error .status = entered-in-error .status = retired .status = entered-in-error .status = retired .active = false .active = false .active = false .active = false .status = entered-in-error .status = retired .status = retired .status = entered-in-error .status = retired .status = off (just turn it off, maybe update the error message) .status = retired .status = retired Note: Resources that are not listed in this table do not have any explicit documentation with regard to being entered in error. © HL7.org 2011+. FHIR DSTU2 (v1.0.2-7202) generated on Sat, Oct 24, 2015 07:44+1100. Links: Search | Version History | Table of Contents | Compare to DSTU1
Resource Status
Account .status = entered-in-error
ActivityDefinition
AllergyIntolerance .status = entered-in-error
Appointment .status=entered-in-error
AppointmentResponse .participantStatus=entered-in-error
AuditEvent Audit Events are recorded, there is no update or delete.
Basic There are no fixed arrangements for Basic - profiles should describe how this works as arrangements will depend on the 'type' of Basic resource
Binary n/a (This would be handled where the binary is linked from) n/a (This would be handled where the binary is linked from)
BodySite
Bundle Depends on the type: document - see for Composition; message - see for MessageHeader; transaction / transaction-response / history / searchset - not expected to be stored; collection: just delete it if it's stored, and in error Depends on the type: document - see for Composition; message - see for MessageHeader; transaction / transaction-response / history / searchset - not expected to be stored; collection: just delete it if it's stored, and in error
CarePlan
CareTeam
Claim .status = entered-in-error
ClaimResponse .status = entered-in-error
ClinicalImpression .status = entered-in-error
CodeSystem .status = retired
Communication
CommunicationRequest
CompartmentDefinition .status = retired
Composition .status = entered-in-error
ConceptMap .status = retired
Condition
Conformance .status = retired
Consent .status = entered-in-error
Contract
Coverage .status = entered-in-error
DataElement .status = retired
DecisionSupportServiceModule
DetectedIssue
Device .status = entered-in-error
DeviceComponent
DeviceMetric
DeviceUseRequest .status = entered-in-error
DeviceUseStatement
DiagnosticOrder DiagnosticReport .status = entered-in-error
DiagnosticReport DiagnosticRequest .status = entered-in-error
DocumentManifest .status = entered-in-error
DocumentReference .status = entered-in-error
EligibilityRequest .status = entered-in-error
EligibilityResponse .status = entered-in-error
Encounter .status=entered-in-error
Endpoint .status=entered-in-error
EnrollmentRequest .status = entered-in-error
EnrollmentResponse .status = entered-in-error
EpisodeOfCare .status=entered-in-error
ExpansionProfile .status=retired
ExplanationOfBenefit .status = entered-in-error
FamilyMemberHistory .status = entered-in-error
Flag .status = entered-in-error
Goal
Group .active = false
GuidanceResponse
HealthcareService .active = false
ImagingObjectSelection ImagingManifest Imaging Object Selection state is managed in PACS.
ImagingStudy Imaging Study state is managed in PACS.
Immunization .status = entered-in-error
ImmunizationRecommendation
ImplementationGuide .status = retired
Library
Linkage
List .status = entered-in-error
Location .status = inactive
Measure
MeasureReport
Media n/a - this would be handled whereever the media is linked from n/a - this would be handled whereever the media is linked from
Medication Medication does not have a status
MedicationAdministration .status = entered-in-error
MedicationDispense .status = entered-in-error
MedicationOrder .status = entered-in-error
MedicationStatement .status = entered-in-error
MessageHeader mostly n/a, but in the cases where messages are stored in error, they would simply be deleted mostly n/a, but in the cases where messages are stored in error, they would simply be deleted
NamingSystem .status = retired
NutritionOrder NutritionRequest .status = entered-in-error
Observation .status = entered-in-error
OperationDefinition .status = retired
OperationOutcome n/a - this resource is not expected to be stored n/a - this resource is not expected to be stored
Order Organization .active = false
OrderResponse Patient .active = false
Organization PaymentNotice .status = entered-in-error
Patient PaymentReconciliation .status = entered-in-error
PaymentNotice Person .active = false
PaymentReconciliation PlanDefinition
Person Practitioner .active = false
Practitioner PractitionerRole .active = false
Procedure .status = entered-in-error
ProcedureRequest
ProcessRequest .status = entered-in-error
ProcessResponse .status = entered-in-error
Provenance Provenance are recorded, there is no update or delete.
Questionnaire .status = retired
QuestionnaireResponse
ReferralRequest .status = entered-in-error
RelatedPerson .active = false
RiskAssessment .status = entered-in-error
Schedule .active = false
SearchParameter .status = retired
Sequence
Slot .status = entered-in-error
Specimen .status = entered-in-error
StructureDefinition .status = retired
StructureMap .status = retired
Subscription .status = off (just turn it off, maybe update the error message)
Substance
SupplyDelivery
SupplyRequest
Task
TestScript .status = retired
ValueSet .status = retired
VisionPrescription

Note: Resources that are not listed in this table do not have any explicit documentation with regard to being entered in error.