===============================================================================
Maturity Level: 2 | Standards Status: Trial Use |
Workflow is an essential part of healthcare - orders, care protocols, referrals are the drivers of most activity within in-patient settings and a great deal of activity in community care as well. FHIR is concerned with workflow when there's a need to share information about workflow state or relationships, when there's a need to coordinate or drive the execution of workflow across systems and when there's a need to define allowed actions, dependencies and conditions on behavior.
Workflow state & relationships
FHIR does not need to be used for the execution of workflow. Orders, care plans, lab results, hospital admissions, claim payments and other records can all be shared using FHIR resources without the process to solicit fulfillment of those orders or requesting payment of those claims being driven by a FHIR transaction. Interoperable support for workflow execution is a more advanced FHIR activity because it requires a higher degree of standardization. Rather than merely standardizing the data to exchange, interoperable workflow execution requires standardization of the processes, roles and activities across the different systems. However, even without using FHIR for workflow execution, there's still a need to standardize the data elements related to workflow: how does an event or a result point to the order that authorized it? How do parent steps and child steps get linked together? How does a care plan identify what protocol it's adhering to?
FHIR defines three categories of resources that are involved in activities - requests, events and definitions. Each of these categories has a "pattern" associated with it. Resources that fall into that category are encouraged to adhere to their respective pattern. These patterns provide standard elements that are typical for most resources of each category. Strict adherence is not required as work groups are expected to align with typical domain behavior and requirements as more authoritative than "desired" architectural patterns. In some cases, capabilities might be supported with extensions rather than core elements where a pattern capability is deemed to be "not common, but still relevant" for a given resource.
A full description of the patterns and their interrelationships can be found in the Workflow Resource Patterns section of this page.
Workflow execution
In addition to defining patterns for resources used in workflow processes, FHIR supports the execution of those processes as well. However, FHIR does not define a "one size fits all" solution for workflow architecture. FHIR supports a variety of interoperability paradigms and most of them (REST, Messaging and Services) provide support for driving workflow execution. (The Document paradigm does not directly support driving behavior, though it can be combined with one of the other patterns to do so.) In addition, several of these paradigms allow multiple approaches to supporting workflow, depending on the context and needs of the workflow process.
The Workflow Execution and Communication Patterns section describes many options for workflow execution, summarizes their respective pros and cons and makes recommendations for the circumstances in which they might best be used.
Workflow definition
The definition of protocols, order sets, guidelines and other structures that define what sorts of activities should occur, what order they should occur on, what dependencies they have, in what circumstances they should start or end, etc. is handled by a pair of resources:
The use of these two artifacts is discussed here.
Not all resources in FHIR are related to workflow - many are used to describe entities and roles (patients, medications, etc.) or infrastructure (structure definitions, value sets, etc.). However, a large proportion of the FHIR resources are devoted to the description of activities in one fashion or another and almost all of these fall into the realm of workflow - they describe things that can be done (definitions), are desired to be done (requests) or that have been done (events). The table below summarizes the list of workflow-relevant resources:
Definitions | Resources that define something that can potentially happen in a patient and time-independent manner | ||
---|---|---|---|
Requests | Resources that ask for or express a desire/intention for something to be done | ||
Events | Resources that express that something has been done and which can potentially be done because of a request | ||
* | The Appointment and AppointmentResponse resources do not follow the same sort of request/response pattern as the other resources. Their design is based on iCal conventions, so their model won't align with the pattern as strictly as most other resources. They are included here for completeness. |
‡ | The Task resource takes on characteristics of both "requests" and "events" and thus shares characteristics from both patterns |
Note that requests, events and definitions don't exist in a 1:1:1 relationship. Some requests and events have obvious pairings. For example, a SupplyRequest will generally always pair with a SupplyDelivery. The same goes for EnrollmentRequest/EnrollmentResponse, etc. On the other hand, for other resources there isn't a strict pairing. A ServiceRequest might be responded to by an Encounter, DiagnosticReport, Procedure, RiskAssessment, etc. Similarly, a Procedure might be triggered by a ServiceRequest. The set of common linkages should be asserted in their respective resources. The specific types of responses for a given request will be governed by the Request.code, any workflow definitions/protocols referenced and local convention.
These three patterns of resources have a standard set of relationships, both with themselves, as well as with each other.
Specifically:
This list of relationships is not exhaustive, but covers those that are "standardized" as part of the patterns. Further description and guidance on these relationships can be found in the Request, Event and Definition logical patterns.
Requests are resources that represent the proposal, plan or order for an activity to occur. A Request pattern defines the common elements typically present on all request resources.
The amount of information needed for a Request to be actionable can vary by circumstance. Some request instances might not be "fully specified" - additional information from protocol, patient preference and/or professional decision-making may be necessary before the authorized action can occur. For example, a MedicationRequest might be specified without indicating a strength or route in situations where the pharmacy (or even nursing station) has the authority to determine those parameters. A VisionPrescription might not be actionable until frames have been chosen and the necessary measurements of the patient's face have been taken to allow the lenses to be positioned appropriately within the frames.
All requests with an intent of "order" authorize something. Whether what is authorized is sufficient to be immediately actionable depends on who is fulfilling the order and the context in which the fulfillment request is made. The determination of whether a given "request" is actionable may be made by the systems involved or the humans being asked to act.
As well, the existence of a "Request" instance doesn't necessarily imply that fulfillment will be requested immediately - or even ever. The decision to request fulfillment may be delegated to the patient or to down-stream practitioners. Such fulfilling practitioners may need to capture additional information prior to executing the fulfillment.
Events are resources that represent the ongoing or completed execution of some activity or observation. For example, a clinical procedure, a financial transaction, the recording of a diagnosis, etc. An Event pattern defines the common elements typically present on all event resources.
Definitions are resources that represent activities that could be performed in a time and subject-independent manner such as a protocol, order set, clinical guideline, etc. A Definition pattern defines the common elements typically present on all definition resources.
STU Notes:
- It is possible to replace some portions of the MessageHeader with a reference to the Task resource. Doing so would mean consistency in how asynchronous requests are represented using REST and messaging. However, it introduces an additional layer of complexity and formality into the messaging paradigm that may be unwelcome, particularly for those systems that do not currently foresee a need to support both RESTful and messaging invocations of workflow
- The OperationDefinition resource could be used to define types of tasks and the sets of parameters that can go with them. Is this an appropriate use of the OperationDefinition resource?
- The SupplyRequest, DeviceRequest and VisionPrescription resources have a significant degree of overlap. Should they remain distinct resources?
Feedback is welcome here.
Maturity Level: Normative | Standards Status:Normative |
The XML representation for a resource is described using this format:
<name xmlns="http://hl7.org/fhir" (attrA="value")><!-- from Resource: id, meta, implicitRules, and language --> <nameA><!--
1..1 type description of content --><nameA> <nameB[x]><!-- 0..1 type1|type1 description --></nameB[x]> <nameC> <!-- 1..* --> <nameD><!-- 1..1 type>Relevant elements --></nameD> </nameC> <name>
Using this format:
value
attribute, extension URLs in the url
attribute on an extension, and the id
property on elements (but not on resources, where the resource id is an element)<?xml encoding="UTF-8" ?>
) is optional but recommendedapplication/fhir+xml
.This specification provides schema definitions for all the resource and data type content models it describes.
The base schema is called "fhir-base.xsd" and defines all the datatypes and base infrastructure types. In addition, there is a schema for each resource and a common schema fhir-all.xsd that includes all the resource schemas. For schema processors that do not like circular includes, there is a single schema that contains everything.
In addition to the w3c schema files, this specification also provides Schematron files that enforce most of the constraints defined for the datatypes and resources, though some are only expressible and validatable using FHIRPath. These are packaged as files for each resource.
XML that is exchanged SHALL be valid against the w3c schema and Schematron, though being valid against the schema and Schematron is not sufficient to be a conformant instance: this specification makes several rules that cannot be checked by either mechanism. Operational systems may choose to use schema tools to check validation, but are not required to do so. Exchanged content SHALL NOT specify the schema or even contain the schema instance namespace in the resource itself.
Given the way extensions work, applications reading XML resources will never encounter unknown elements. However, once an application starts trading with other applications that conform to later versions of this specification, unknown XML elements may be encountered. Applications MAY choose to ignore unknown elements to foster forwards compatibility in this regard, but may also choose not to - which would be the normal behavior for schema generated applications.
In addition to the validation schema, this specification provides a set of schemas suitable for code generation. These schemas describe the same XML syntax, but apply less validation to create schemas that work better with code generation tooling.
Specifically, these schemas are generated without any xsd:choice
elements,
for code generators that don't deal with choices well. Implementers that
use these schemas will need to enforce the correct usage of the
choice elements without schema
support.
Implementers making use of schema-driven code generation tooling need
to consider how to handle the decimal
data type. The decimal data type is defined to be precision aware - that
is, that implementers need to preserve the difference between "2.0" and
"2.00" - this is ubiquitously considered important in handling observed
data in healthcare. Both schemas map this data type to a union of xsd:decimal
and xsd:double
, but
the base W3C schema decimal type is specified not to be precision aware. Schema
driven implementations vary as to how precision is handled. Implementers
will need to determine how their generated code handles decimals/doubles and
consider changing the type for decimal in their schema from xsd:decimal/double
to xsd:string
. Specifically, implementers may wish to change:
<xs:simpleType name="decimal-primitive"> <xs:union memberTypes="xs:decimal xs:double"/> </xs:simpleType>
to this:
<xs:simpleType name="decimal-primitive"> <xs:restriction base="xs:string"> <xs:pattern value="-?(0|[1-9][0-9]*)(\.[0-9]+)?([eE][+-]?[0-9]+)?"/> </xs:restriction> </xs:simpleType>
Alternatively, if supported, implementers may wish to use the precisionDecimal from the XSD 1.1 framework.
Note that most code generation frameworks ignore the pattern restriction.
Resources and/or Bundles may be digitally signed (see Bundle and Provenance).
This specification defines the following method for canonicalizing FHIR resources, when represented as XML:
'
instead of "
)<?xml version="1.0" encoding="UTF-8"?>
http://www.w3.org/2006/12/xml-c14n11
)
This canonicalization method is identified by the URI http://hl7.org/fhir/canonicalization/xml
. The
following additional canonicalization URIs are also defined:
http://hl7.org/fhir/canonicalization/xml#data | The narrative (Resource.text ) is omitted prior to signing (note the deletion is at Resource.text , not Resource.text.div ) |
http://hl7.org/fhir/canonicalization/xml#static | In addition to narrative (Resource.text), the Resource.meta element is removed. This makes the signature robust as the content is moved from server to server, or workflow and access tags are added or removed. Note that workflow and security tags may contain information important to the handling of the resource, so meta elements should be protected from tampering by other means if unsigned. |
http://hl7.org/fhir/canonicalization/xml#narrative | The method only retains the Resource.id and Narrative (Resource.text |
http://hl7.org/fhir/canonicalization/xml#document | The signs everything in a Bundle, except for the Bundle.id and Bundle.metadata on the root Bundle (allows for a document to be copied from server to server) |
These canonicalization methods allow systems the flexibility to sign the various portions of the resource that matter for the workflow the signature serves. These canonicalization algorithms do not work for enveloped signatures. This will be researched and addressed in a future release. This specification may define additional canonicalizations in the future, and other specifications might also define additional canonicalization methods.
One consequence of signing the document is that URLs, identifiers and internal references are frozen and cannot be changed. This might be a desired feature, but it may also cripple interoperability between closed ecosystems where re-identification frequently occurs. For this reason, it is recommended that systems consider carefully the impact of any signature processes. The impact of signatures on Document bundles and their related processes is the most well understood use of digital signatures.