Release 4

FHIR Infrastructure Maturity Level: 1Informative

Detailed Descriptions for the elements in the request pattern.

Request
Definition

A pattern to be followed by resources that represent a specific proposal, plan and/or order for some sort of action or service.

Cardinality0..*
TypeLogical
Request.identifier
Definition

Business identifiers assigned to this {{title}} by the author and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server.

NoteThis is a business identifier, not a resource identifier (see discussion)
Cardinality0..*
TypeIdentifier
Requirements

Allows identification of the {{title}} as it is known by various participating systems and in a way that remains consistent across servers.

Summarytrue
Comments

The identifier.type element is used to distinguish between the identifiers assigned by the requester/placer and the performer/filler.

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

Request.instantiatesCanonical
Definition

The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}.

Cardinality0..*
Typecanonical(Definition)
Summarytrue
Request.instantiatesUri
Definition

The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}.

Cardinality0..*
Typeuri
Summarytrue
Comments

This might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier.

Request.basedOn
Definition

A plan, proposal or order that is fulfilled in whole or in part by this {{title}}.

Cardinality0..*
TypeReference(Request)
Requirements

Allows tracing of authorization for the request and tracking whether proposals/recommendations were acted upon.

Alternate Namesfulfills
Summarytrue
Comments

[The allowed reference resources may be adjusted as appropriate for the request resource].

Request.replaces
Definition

Completed or terminated request(s) whose function is taken by this new {{title}}.

Cardinality0..*
TypeReference(Request)
Requirements

Allows tracing the continuation of a therapy or administrative process instantiated through multiple requests.

Alternate Namessupersedes; prior; renewed order
Summarytrue
Comments

The replacement could be because the initial request was immediately rejected (due to an issue) or because the previous request was completed, but the need for the action described by the request remains ongoing.

Request.groupIdentifier
Definition

A shared identifier common to all requests that were authorized more or less simultaneously by a single author, representing the identifier of the requisition, prescription or similar form.

Cardinality0..1
TypeIdentifier
Requirements

Some business processes need to know if multiple items were ordered as part of the same "prescription" or "requisition" for billing or other purposes.

Alternate NamesgrouperId; requisition
Summarytrue
Comments

Requests are linked either by a "basedOn" relationship (i.e. one request is fulfilling another) or by having a common requisition. Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.

Request.status
Definition

The current state of the {{title}}.

Cardinality1..1
Terminology BindingRequestStatus (Required)
Typecode
Is Modifiertrue (Reason: This element is labeled as a modifier because it is a status element that contains status entered-in-error which means that the resource should not be treated as valid)
Summarytrue
Comments

The status is generally fully in the control of the requester - they determine whether the order is draft or active and, after it has been activated, completed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding Event(s) or using the Task resource. A nominal state-transition diagram can be found in the [[request.html#statemachine | Request pattern]] documentation Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. A status of 'active' when doNotPerform is true means that the request to not perform is currently in force.

A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds.

To DoShould this be a common code system for all requests?
Request.statusReason
Definition

Captures the reason for the current state of the {{title}}.

Cardinality0..1
Terminology BindingRequestStatusReason:
TypeCodeableConcept
Alternate NamesSuspended Reason; Cancelled Reason
Comments

This is generally only used for "exception" statuses such as "suspended" or "cancelled". The reason why the {{title}} was created at all is captured in reasonCode, not here. [distinct reason codes for different statuses can be enforced using invariants if they are universal bindings].

Request.intent
Definition

Indicates the level of authority/intentionality associated with the {{title}} and where the request fits into the workflow chain.

Cardinality1..1
Terminology BindingRequestIntent (Required)
Typecode
Is Modifiertrue (Reason: This element changes the interpretation of all descriptive attributes. For example "the time the request is recommended to occur" vs. "the time the request is authorized to occur" or "who is recommended to perform the request" vs. "who is authorized to perform the request)
Requirements

Proposals/recommendations, plans and orders all use the same structure and can exist in the same fulfillment chain.

Alternate Namescategory
Summarytrue
Comments

This element is expected to be immutable. E.g. A "proposal" instance should never change to be a "plan" instance or "order" instance. Instead, a new instance 'basedOn' the prior instance should be created with the new 'intent' value.

One exception to this is that the granularity of Request.intent is allowed to change. For example, a Request identified as an "order" might later be clarified to be a "filler-order". Or, in rarer cases (to meet recipient constraints), the reverse might also occur.

When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy.

To DoShould this be a common code system for all requests?
Request.priority
Definition

Indicates how quickly the {{title}} should be addressed with respect to other requests.

Cardinality0..1
Terminology BindingRequestPriority (Required)
Typecode
Meaning if MissingIf missing, this task should be performed with normal priority
Summarytrue
Request.doNotPerform
Definition

If true indicates that the {{title}} is asking for the specified action to not occur.

Cardinality0..1
Typeboolean
Is Modifiertrue (Reason: If true this element negates the specified action. For Example, instead of a request for a procedure, it is a request for the procedure to not occur.)
Meaning if MissingIf do not perform is not specified, the request is a positive request e.g. "do perform"
Requirements

Supports things like Do Not Recussitate, Nothing by mouth, etc.

Alternate Namesprohibited
Summarytrue
Comments

The attributes provided with the request qualify what is not to be done. For example, if an effectiveTime is provided, the "do not" request only applies within the specified time. If a performerType is specified then the "do not" request only applies to performers of that type. Qualifiers include: code, subject, occurrence, perormerType and performer.

In some cases, the Request.code may pre-coordinate prohibition into the requested action. E.g. "NPO" (nothing by mouth), "DNR" (do not recussitate). If this happens, doNotPerform SHALL NOT be set to true. I.e. The resource shall not have double negation. (E.g. "Do not DNR").

Request.code
Definition

A code that identifies the specific service or action being asked to be done (or not done).

Cardinality0..1
Terminology BindingRequestCode:
TypeCodeableConcept
Alternate Namestype
Summarytrue
Request.subject
Definition

The individual or set of individuals the action is to be performed/not performed on or for.

Cardinality1..1
TypeReference(Patient | Group)
Requirements

Links the request to the Patient context.

Alternate Namespatient
Summarytrue
Comments

[For resources that aren't patient-specific, the set of allowed resources may be extended to include other things. Group should generally be retained unless there's certainty this resource won't be used for veterinary, research or public health settings where Group may be necessary (e.g. this cage of rats/crate of chickens, group of people in a 5 mile radious of the incident, etc.)].

To DoFor mapping, is it better if we make this Any and then constrain it down?
Request.encounter
Definition

The Encounter during which this {{title}} was created or to which the creation of this record is tightly associated.

Cardinality0..1
TypeReference(Encounter)
Requirements

Links the {{title}} to the Encounter context.

Alternate Namescontext
Summarytrue
Comments

This will typically be the encounter the request was created during, but some requests may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests).

Request.occurrence[x]
Definition

The date or time(s) at which the activity or service is desired to occur or not occur.

Cardinality0..1
TypedateTime|Period|Timing
[x] NoteSee Choice of Data Types for further information about how to use [x]
Alternate Namestiming
Summarytrue
Comments

[The list of types may be constrained as appropriate for the type of event].

Request.authoredOn
Definition

For draft {{title}}s, indicates the date of initial creation. For requests with other statuses, indicates the date of activation.

Cardinality0..1
TypedateTime
Alternate NamescreatedOn; signedOn
Summarytrue
To DoDo we need a "status date" too (for when the request was suspended, cancelled, etc.).
Request.requester
Definition

Who initiated the {{request}} and has responsibility for its activation.

Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device)
Alternate Namesauthor
Summarytrue
Comments

[Resources may choose to constrain potential requesters, though should consider proposals and plans as well as orders].

Request.reported[x]
Definition

Indicates if this record was captured as a secondary 'reported' record rather than as an original primary source-of-truth record. It may also indicate the source of the report.

Cardinality0..1
Typeboolean|Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization)
[x] NoteSee Choice of Data Types for further information about how to use [x]
Requirements

Reported data may have different rules on editing and may be visually distinguished from primary data.

Alternate Namesinformer
Summarytrue
Request.performerType
Definition

The type of individual that is desired to act upon/ not act upon the {{request}}.

Cardinality0..1
Terminology BindingPerformerType:
TypeCodeableConcept
Summarytrue
Comments

If specified without indicating a performer, this indicates that the performer must be (or can't be) of the specified type. If specified with a performer then it indicates the requirements of the performer if the designated performer is not available. If doNotPerform is true, then only one of performerType and performer should be present.

To DoNeed to define who.performer.
Request.performer
Definition

Indicates who or what is being asked to perform (or not perform) the {{request}}.

Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)
Summarytrue
Request.reasonCode
Definition

Describes why the request is being made in coded or textual form.

Cardinality0..*
Terminology BindingRequestReason:
TypeCodeableConcept
Summarytrue
Comments

Textual reasons can be captured using reasonCode.text. If doNoPerform is true, this will be the reason why the request is being made to not act.

Request.reasonReference
Definition

Indicates another resource whose existence justifies this request.

Cardinality0..*
TypeReference(Condition | Observation | DiagnosticReport | DocumentReference)
Summarytrue
Comments

[Additional resources may be added as appropriate].

Request.insurance
Definition

Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant in delivering the requested service.

Cardinality0..*
TypeReference(Coverage | ClaimResponse)
Request.supportingInfo
Definition

Information that may be needed by/relevant to the performer in their execution of this {{title}}.

Cardinality0..*
TypeReference(Any)
Request.note
Definition

Comments made about the {{title}} by the requester, performer, subject or other participants.

Cardinality0..*
TypeAnnotation
Request.relevantHistory
Definition

Links to Provenance records for past versions of this resource or fulfilling request or event resources that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the resource.

Cardinality0..*
TypeReference(Provenance)
Alternate NameseventHistory
Comments

This element does not point to the Provenance associated with the current version of the resource - as it would be created after this version existed. The Provenance for the current version can be retrieved with a _revinclude. Referenced provenances should adhere to the provenance-relevant-history profile.