This
page
is
part
of
the
FHIR
Specification
v6.0.0-ballot3:
Release
6
Ballot
(3rd
Draft)
(see
Ballot
Notes
).
The
current
version
is
5.0.0
.
For
a
full
list
Continuous
Integration
Build
of
available
versions,
see
FHIR
(will
be
incorrect/inconsistent
at
times).
See
the
Directory
of
published
versions
Responsible
Owner:
FHIR
Infrastructure
Work
Group
|
Standards
Status
:
|
This page describes several issues around lifecycle management for the resources and the content they contain. Specifically, this page describes:
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:
For additional information about managing resource life cycles, see:
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:
Examples of the clinical workflow 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:
Examples of the request/order 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:
Examples of the entity availability 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:
Many
clinical
systems
maintain
The
section
regarding
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
has
been
removed
due
to
represent
a
problem
for
investigation
provided
by
a
diagnostic
system
as
part
of
a
ServiceRequest
/
DiagnosticReport
pair
the
resources
were
received
from
another
system
as
part
lack
of
a
referral
package,
implementation
experience
and
were
current
for
that
system
when
they
were
received
There
is
no
element
on
the
Condition
resource
that
can
convey
the
difference
between
these
usages.
In
particular,
feedback.
If
there
can
be
no
way
to
differentiate
between
current
and
past
resources
without
having
to
retrospectively
alter
resources,
which
is
problematic
with
regard
to
integrity
and
digital
signatures.
One
consequence
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
continued
interest
in
the
patient
42's
"Current
Allergy
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
this
topic,
it
may
be
reintroduced
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.
API
Incubator
FHIR
defines
the
following
names
for
functional
lists:
.
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.
Handling of erroneous data is tightly tied to business processes and thus there are no generic rules for what to do when data is flagged as erroneous. Implementation Guides may define additional guidance about what actions should be taken, such as data redaction, sending of notifications, etc.
This table summarizes what is expected to happen for each resource in the case that the data it contains is subsequently found to be an erroneous entry.
| Resource | Status |
| Account | .status = entered-in-error |
| ActivityDefinition | .status = retired |
| ActorDefinition | .status = retired |
| AdministrableProductDefinition | .status=entered-in-error |
| AdverseEvent | .status = entered-in-error |
| AllergyIntolerance | .verificationStatus = entered-in-error |
| Appointment | .status=entered-in-error |
| AppointmentResponse | .participantStatus=entered-in-error |
| ArtifactAssessment | .workflowStatus = 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) |
| BiologicallyDerivedProduct | .verificationStatus = entered-in-error |
|
|
.active = false |
| 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 |
| CapabilityStatement | .status = retired |
| CarePlan | .status = entered-in-error |
| CareTeam | .status = entered-in-error |
|
|
.status = entered-in-error |
| ClaimResponse | .status = entered-in-error |
| ClinicalAssessment | .status = entered-in-error |
| ClinicalUseDefinition | .status=entered-in-error |
| CodeSystem | .status = retired |
| Communication | .status = entered-in-error |
| CommunicationRequest | .status = entered-in-error |
| CompartmentDefinition | .status = retired |
| Composition | .status = entered-in-error |
| ConceptMap | .status = retired |
| Condition | .verificationStatus = entered-in-error |
| ConditionDefinition | .status = retired |
| Consent | .status = entered-in-error |
| Contract | .status = entered-in-error |
| Coverage | .status = entered-in-error |
| CoverageEligibilityRequest | .status = entered-in-error |
| CoverageEligibilityResponse | .status = entered-in-error |
| DetectedIssue | .status = entered-in-error |
| Device | .status = entered-in-error |
| DeviceAlert | .status = entered-in-error |
| DeviceAssociation | .status = entered-in-error |
| DeviceDefinition | .operationalStatus = entered-in-error |
|
|
.status = entered-in-error |
| DeviceRequest | .status = entered-in-error |
|
|
.status = entered-in-error |
| DocumentReference | .status = entered-in-error |
| Encounter | .status=entered-in-error |
|
|
.status=entered-in-error |
| EnrollmentRequest | .status = entered-in-error |
| EnrollmentResponse | .status = entered-in-error |
| EpisodeOfCare | .status=entered-in-error |
| EventDefinition | .status = retired |
| Evidence | .status = retired |
| EvidenceVariable | Delete the instance if it is in error |
| ExampleScenario | .status = retired |
| ExplanationOfBenefit | .status = entered-in-error |
| FamilyMemberHistory | .status = entered-in-error |
| Flag | .status = entered-in-error |
| FormularyItem | .status = entered-in-error |
| GenomicStudy | .status = entered-in-error |
| Goal | .status = entered-in-error |
|
|
.active = false |
| GuidanceResponse | .status = entered-in-error |
| HealthcareService | .active = false |
| ImagingSelection | .status = entered-in-error |
| ImagingStudy | .status = entered-in-error |
| Immunization | .status = entered-in-error |
|
|
.status = retired |
| Ingredient | .status=entered-in-error |
| InsurancePlan | .status = retired |
| InsuranceProduct | .status = retired |
|
|
.status = entered-in-error |
| Library | .status = retired |
| Linkage | .active = false |
| List | .status = entered-in-error |
| Location | .status = inactive |
| ManufacturedItemDefinition | .status=entered-in-error |
| Measure | Delete the instance if it is in error |
| MeasureReport | Delete the instance if it is in error |
| Medication | .status = entered-in-error |
| MedicationAdministration | .status = entered-in-error |
| MedicationDispense | .status = entered-in-error |
| MedicationKnowledge | .status = entered-in-error |
| MedicationRequest | .status = entered-in-error |
| MedicationStatement | .status = entered-in-error |
| MedicinalProductDefinition | .status=entered-in-error |
| MessageDefinition | mostly n/a, but in the cases where messages are stored in error, they would simply be deleted |
| MessageHeader | mostly n/a, but in the cases where messages are stored in error, they would simply be deleted |
| MolecularDefinition | .status = entered-in-error |
|
|
.status = retired |
| NutritionIntake | .status = entered-in-error |
| NutritionOrder | .status = entered-in-error |
| NutritionProduct | .status = entered-in-error |
| Observation | .status = entered-in-error |
| ObservationDefinition | .status = retired |
| OperationDefinition | .status = retired |
| OperationOutcome | n/a - this resource is not expected to be stored |
| Organization | .active = false |
| OrganizationAffiliation | .active = false |
| PackagedProductDefinition | .status=entered-in-error |
| Patient | .active = false |
| PaymentNotice | .status = entered-in-error |
| PaymentReconciliation | .status = entered-in-error |
| Permission | .status = entered-in-error |
| Person | .active = false |
|
|
.status = retired |
| Practitioner | .active = false |
| PractitionerRole | .active = false |
| Procedure | .status = entered-in-error |
| Provenance | Provenance are recorded, there is no update or delete. |
| Questionnaire | .status = retired |
| QuestionnaireResponse | .status = entered-in-error |
| RegulatedAuthorization | .status=entered-in-error |
| RelatedPerson | .active = false |
| RequestOrchestration | .status = entered-in-error |
| Requirements | .status = retired |
| ResearchStudy | .status = entered-in-error |
| ResearchSubject | .status = entered-in-error |
| RiskAssessment | .status = entered-in-error |
| Schedule | .active = false |
| SearchParameter | .status = retired |
| ServiceRequest | .status = entered-in-error |
| Slot | .status = entered-in-error |
| Specimen | .status = entered-in-error |
| SpecimenDefinition | .status = retired |
| StructureDefinition | .status = retired |
| StructureMap | .status = retired |
| Subscription | .status = entered-in-error |
| SubscriptionStatus | .status = entered-in-error |
| SubscriptionTopic | .status = off (just turn it off, maybe update the error message) |
| Substance | .status = entered-in-error |
| SubstanceDefinition | .status=entered-in-error |
|
|
.status = entered-in-error |
| TerminologyCapabilities | .status = retired |
|
|
.status = retired |
|
|
.status = entered-in-error |
Note: Resources that are not listed in this table do not have any explicit documentation with regard to being entered in error.