STU3 Candidate
FoundationThis page is part of the FHIR Specification (v1.8.0: STU 3 Draft). 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 Infrastructure Work Group | Maturity Level: 3 | Ballot Status: STU 3 |
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:
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 current lists of some kind of resources for a patient. Some of the commonly maintained lists include:
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:
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 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:
| List | ResourceType | Description | 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) |
| $current-medications | MedicationStatement/ MedicationRequest | A list of all medications that the patient is taking. The 'current medications list' sometimes may include 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 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) |
| $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) |
| $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?) |
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 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 |
| AllergyIntolerance | .verificationStatus = 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) |
| 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 |
| CapabilityStatement | .status = retired |
| CarePlan | .status = entered-in-error |
| 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 | .verificationStatus = entered-in-error |
| Consent | .status = entered-in-error |
| Contract | .status = entered-in-error |
| Coverage | .status = entered-in-error |
| DataElement | .status = retired |
| DetectedIssue | |
| Device | .status = entered-in-error |
| DeviceComponent | |
| DeviceMetric | |
| DeviceUseRequest | .status = entered-in-error |
| DeviceUseStatement | |
| DiagnosticReport | .status = entered-in-error |
| 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 | .status = entered-in-error |
| Group | .active = false |
| GuidanceResponse | |
| HealthcareService | .active = false |
| ImagingManifest | Imaging Object Selection state is managed in PACS. |
| ImagingStudy | Imaging Study state is managed in PACS. |
| Immunization | |
| ImmunizationRecommendation | |
| ImplementationGuide | .status = retired |
| Library | .status = retired |
| Linkage | |
| List | .status = entered-in-error |
| Location | .status = inactive |
| Measure | .status = retired |
| MeasureReport | |
| Media | 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 |
| MedicationRequest | .status = entered-in-error |
| MedicationStatement | .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 |
| NamingSystem | .status = retired |
| NutritionRequest | .status = entered-in-error |
| Observation | .status = entered-in-error |
| OperationDefinition | .status = retired |
| OperationOutcome | n/a - this resource is not expected to be stored |
| Organization | .active = false |
| Patient | .active = false |
| PaymentNotice | .status = entered-in-error |
| PaymentReconciliation | .status = entered-in-error |
| Person | .active = false |
| PlanDefinition | .status = retired |
| Practitioner | .active = false |
| 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 | .status = entered-in-error |
| ReferralRequest | .status = entered-in-error |
| RelatedPerson | .active = false |
| RequestGroup | |
| ResearchStudy | .status = entered-in-error |
| ResearchSubject | .status = entered-in-error |
| RiskAssessment | .status = entered-in-error |
| Schedule | .active = false |
| SearchParameter | .status = retired |
| Sequence | |
| ServiceDefinition | .status = retired |
| 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 | .status = entered-in-error |
| TestReport | |
| TestScript | .status = retired |
| ValueSet | .status = retired |
| VisionPrescription | .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.
© HL7.org 2011+. FHIR STU3 Candidate (v1.8.0-10521) generated on Tue, Dec 6, 2016 12:27+1100. QA Page
Links: Search |
Version History |
Table of Contents |
Compare to DSTU2 |
|
Propose a change