Release 4 5 Preview #2
This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU ). This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

12.3 Pattern request - Content

FHIR Infrastructure Maturity Level : 1 Informative

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

This is NOT a resource. It is not part of the FHIR schema and cannot appear directly in FHIR instances. It is a logical model that defines a pattern adhered to by other resources. This pattern serves two purposes:

  • It offers guidance to work groups designing resources and helps ensure consistency of content created by different work groups
  • It provides a standard "view" that might be useful for implementers in processing and manipulating all resources that adhere to the same pattern. (Tooling that supports this may become available in a future release.)

The notion of "request" encompasses all types of orders (original orders, filler representations of orders, reflex orders, etc.) as well as proposals/recommendations for action to occur, plans, scheduling, etc. Any sort of description of an activity that is "desired" where the description is specific as to the subject of the activity and the approximate timing of the activity would be considered a "Request".

This logical model is one of three common workflow patterns . The other two patterns are Event and Definition . This pattern is followed by (or is intended to be followed by a number of other FHIR resources /

Requests are distinct from events in that an event is primarily focused on what has occurred or is occurring while requests deal with what is "desired" to occur. While creating a request or definition can be seen as a type of event, the focus of those other resources is not the "creation" but the desire/intention. Both requests and definitions deal with activities that "can" occur, but requests represent a specific intention for something to occur and are bound to a specific context of subject (e.g. patient) and time, while definitions represent mere "possibility" rather than intention and are independent of a specific subject or timeframe.

Requests are related to Task in that tasks can both request and track the fulfillment of a request. In some cases, fulfillment may also result in the creation of sub-tasks. Requests do not track their own fulfillment - i.e. requested/accepted/in-progress. This is managed through Task. The status of a request only reflects the status of the "authorization/intention", not how the request is being executed or not. It is possible for multiple tasks to be associated with the fulfillment of a single Request.

This model represents a pattern. It provides a standard list of data elements with cardinalities, data types, definitions, rationale and usage notes that will ideally be adhered to by resources that fall into the "request" workflow category. However, adherence to this pattern is not mandatory. Not all healthcare domains are the same. Concepts that may be generally applicable (and thus are included in this standard pattern) might still not be relevant everywhere or may be sufficiently uncommon that they are more appropriate to include as extensions than as core properties of the resource. Work groups are encouraged to adjust descriptions, usage notes and rationale to be specific to their resource (e.g. use the term "diagnostic test" or "prescription" rather than "request"). As well, design notes in the comments column marked with [square brackets] identifies areas where domain variation is expected and encouraged. Other variation, including differences in names, cardinalities, data types and the decision to omit an element outright are also possible, but should be discussed with the FHIR Infrastructure work group's Workflow project to ensure the rationale for non-alignment is understood, to confirm that the deviation is necessary and to identify whether any adjustments to the pattern are appropriate.

This pattern provides a linkage to the W5 list of standard data elements. Resources that adhere to this pattern should ensure their w5 mappings are consistent, as is their data element ordering.

This pattern is implemented by Appointment , AppointmentResponse , CarePlan , Claim , CommunicationRequest , Contract , CoverageEligibilityRequest , DeviceRequest , EnrollmentRequest , ImmunizationRecommendation , MedicationRequest , NutritionOrder , RequestGroup , ServiceRequest , SupplyRequest and VisionPrescription .

Structure

Name Flags Card. Type Description & Constraints doco
. . Request I Logical Request Pattern
. . . identifier Σ 0..* Identifier Business Identifier for {{title}}
. . . instantiatesCanonical Σ 0..* canonical ( Definition ) Instantiates FHIR protocol or definition
. . . instantiatesUri Σ 0..* uri Instantiates external protocol or definition
. . . replaces Σ 0..* Reference ( Request ) Request(s) replaced by this {{title}}
. . . groupIdentifier Σ 0..1 Identifier Composite request this is part of
. . . status ?! Σ 1..1 code draft | active | suspended | cancelled | completed | entered-in-error | unknown
RequestStatus ( Required )
. . . statusReason 0..1 CodeableConcept Reason for current status
. . . intent ?! Σ 1..1 code proposal | plan | order (immutable)
RequestIntent ( Required )
. . . priority Σ 0..1 code routine | urgent | asap | stat
RequestPriority ( Required )
. . . doNotPerform ?! Σ 0..1 boolean true if request is prohibiting action
. . . code Σ 0..1 CodeableConcept What's being requested/ordered
. . . subject Σ 1..1 Reference ( Patient | Group ) Individual the service is ordered/prohibited for
. . . encounter Σ 0..1 Reference ( Encounter ) Encounter created as part of
. . . occurrence[x] Σ 0..1 When service should (not) occur
. . . . occurrenceDateTime dateTime
. . . . occurrencePeriod Period
. . . . occurrenceTiming Timing
. . . authoredOn Σ 0..1 dateTime When request was created/transitioned to active
. . . requester Σ 0..1 Reference ( Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device ) Who/what is requesting service
. . . reported[x] Σ 0..1 Reported rather than primary record
. . . . reportedBoolean boolean
. . . . reportedReference Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization )
. . . performerType Σ 0..1 CodeableConcept Desired kind of service performer
. . . performer Σ 0..1 Reference ( Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson ) Specific desired (non)performer
. . reasonCode . reason Σ 0..* CodeableConcept Why is service (not) needed? reasonReference Σ 0..* Reference CodeableReference ( Condition | Observation | DiagnosticReport | DocumentReference ) Why is service (not) needed?
. . . insurance 0..* Reference ( Coverage | ClaimResponse ) Associated insurance coverage
. . . supportingInfo 0..* Reference ( Any ) Extra information to use in performing request
. . . note 0..* Annotation Comments made about {{title}}
. . . relevantHistory 0..* Reference ( Provenance ) Key events in history of {{title}}

doco Documentation for this format

UML Diagram ( Legend )

Request ( Logical Base ) «Pattern» 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 identifier : Identifier [0..*] 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}} instantiatesCanonical : canonical [0..*] « 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}} instantiatesUri : uri [0..*] A plan, proposal or order that is fulfilled in whole or in part by this {{title}} basedOn : Reference [0..*] « Request » Completed or terminated request(s) whose function is taken by this new {{title}} replaces : Reference [0..*] « Request » 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 groupIdentifier : Identifier [0..1] The current state of the {{title}} (this element modifies the meaning of other elements) status : code [1..1] « Codes identifying the lifecycle stage of a request. (Strength=Required) RequestStatus ! » Captures the reason for the current state of the {{title}} statusReason : CodeableConcept [0..1] Indicates the level of authority/intentionality associated with the {{title}} and where the request fits into the workflow chain (this element modifies the meaning of other elements) intent : code [1..1] « Codes indicating the degree of authority/intentionality associated with a request. (Strength=Required) RequestIntent ! » Indicates how quickly the {{title}} should be addressed with respect to other requests priority : code [0..1] « Identifies the level of importance to be assigned to actioning the request. (Strength=Required) RequestPriority ! » If true indicates that the {{title}} is asking for the specified action to *not* occur (this element modifies the meaning of other elements) doNotPerform : boolean [0..1] A code that identifies the specific service or action being asked to be done (or not done) code : CodeableConcept [0..1] The individual or set of individuals the action is to be performed/not performed on or for subject : Reference [1..1] « Patient | Group » The Encounter during which this {{title}} was created or to which the creation of this record is tightly associated encounter : Reference [0..1] « Encounter » The date or time(s) at which the activity or service is desired to occur or not occur occurrence[x] : Type DataType [0..1] « dateTime | Period | Timing » For draft {{title}}s, indicates the date of initial creation. For requests with other statuses, indicates the date of activation authoredOn : dateTime [0..1] Who initiated the {{request}} and has responsibility for its activation requester : Reference [0..1] « Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device » 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 reported[x] : Type DataType [0..1] « boolean | Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization ) » The type of individual that is desired to act upon/ not act upon the {{request}} performerType : CodeableConcept [0..1] Indicates who or what is being asked to perform (or not perform) the {{request}} performer : Reference [0..1] « Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson » Describes why the request is being made in coded or textual form reasonCode : CodeableConcept [0..*] form, or Indicates another resource whose existence justifies this request reasonReference reason : Reference DataType [0..*] « Condition | Observation | DiagnosticReport | DocumentReference » Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant in delivering the requested service insurance : Reference [0..*] « Coverage | ClaimResponse » Information that may be needed by/relevant to the performer in their execution of this {{title}} supportingInfo : Reference [0..*] « Any » Comments made about the {{title}} by the requester, performer, subject or other participants note : Annotation [0..*] 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 relevantHistory : Reference [0..*] « Provenance »

Structure

Name Flags Card. Type Description & Constraints doco
. . Request I Logical Request Pattern
. . . identifier Σ 0..* Identifier Business Identifier for {{title}}
. . . instantiatesCanonical Σ 0..* canonical ( Definition ) Instantiates FHIR protocol or definition
. . . instantiatesUri Σ 0..* uri Instantiates external protocol or definition
. . . replaces Σ 0..* Reference ( Request ) Request(s) replaced by this {{title}}
. . . groupIdentifier Σ 0..1 Identifier Composite request this is part of
. . . status ?! Σ 1..1 code draft | active | suspended | cancelled | completed | entered-in-error | unknown
RequestStatus ( Required )
. . . statusReason 0..1 CodeableConcept Reason for current status
. . . intent ?! Σ 1..1 code proposal | plan | order (immutable)
RequestIntent ( Required )
. . . priority Σ 0..1 code routine | urgent | asap | stat
RequestPriority ( Required )
. . . doNotPerform ?! Σ 0..1 boolean true if request is prohibiting action
. . . code Σ 0..1 CodeableConcept What's being requested/ordered
. . . subject Σ 1..1 Reference ( Patient | Group ) Individual the service is ordered/prohibited for
. . . encounter Σ 0..1 Reference ( Encounter ) Encounter created as part of
. . . occurrence[x] Σ 0..1 When service should (not) occur
. . . . occurrenceDateTime dateTime
. . . . occurrencePeriod Period
. . . . occurrenceTiming Timing
. . . authoredOn Σ 0..1 dateTime When request was created/transitioned to active
. . . requester Σ 0..1 Reference ( Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device ) Who/what is requesting service
. . . reported[x] Σ 0..1 Reported rather than primary record
. . . . reportedBoolean boolean
. . . . reportedReference Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization )
. . . performerType Σ 0..1 CodeableConcept Desired kind of service performer
. . . performer Σ 0..1 Reference ( Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson ) Specific desired (non)performer
. . reasonCode . reason Σ 0..* CodeableConcept Why is service (not) needed? reasonReference Σ 0..* Reference CodeableReference ( Condition | Observation | DiagnosticReport | DocumentReference ) Why is service (not) needed?
. . . insurance 0..* Reference ( Coverage | ClaimResponse ) Associated insurance coverage
. . . supportingInfo 0..* Reference ( Any ) Extra information to use in performing request
. . . note 0..* Annotation Comments made about {{title}}
. . . relevantHistory 0..* Reference ( Provenance ) Key events in history of {{title}}

doco Documentation for this format

UML Diagram ( Legend )

Request ( Logical Base ) «Pattern» 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 identifier : Identifier [0..*] 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}} instantiatesCanonical : canonical [0..*] « 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}} instantiatesUri : uri [0..*] A plan, proposal or order that is fulfilled in whole or in part by this {{title}} basedOn : Reference [0..*] « Request » Completed or terminated request(s) whose function is taken by this new {{title}} replaces : Reference [0..*] « Request » 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 groupIdentifier : Identifier [0..1] The current state of the {{title}} (this element modifies the meaning of other elements) status : code [1..1] « Codes identifying the lifecycle stage of a request. (Strength=Required) RequestStatus ! » Captures the reason for the current state of the {{title}} statusReason : CodeableConcept [0..1] Indicates the level of authority/intentionality associated with the {{title}} and where the request fits into the workflow chain (this element modifies the meaning of other elements) intent : code [1..1] « Codes indicating the degree of authority/intentionality associated with a request. (Strength=Required) RequestIntent ! » Indicates how quickly the {{title}} should be addressed with respect to other requests priority : code [0..1] « Identifies the level of importance to be assigned to actioning the request. (Strength=Required) RequestPriority ! » If true indicates that the {{title}} is asking for the specified action to *not* occur (this element modifies the meaning of other elements) doNotPerform : boolean [0..1] A code that identifies the specific service or action being asked to be done (or not done) code : CodeableConcept [0..1] The individual or set of individuals the action is to be performed/not performed on or for subject : Reference [1..1] « Patient | Group » The Encounter during which this {{title}} was created or to which the creation of this record is tightly associated encounter : Reference [0..1] « Encounter » The date or time(s) at which the activity or service is desired to occur or not occur occurrence[x] : Type DataType [0..1] « dateTime | Period | Timing » For draft {{title}}s, indicates the date of initial creation. For requests with other statuses, indicates the date of activation authoredOn : dateTime [0..1] Who initiated the {{request}} and has responsibility for its activation requester : Reference [0..1] « Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device » 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 reported[x] : Type DataType [0..1] « boolean | Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization ) » The type of individual that is desired to act upon/ not act upon the {{request}} performerType : CodeableConcept [0..1] Indicates who or what is being asked to perform (or not perform) the {{request}} performer : Reference [0..1] « Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson » Describes why the request is being made in coded or textual form reasonCode : CodeableConcept [0..*] form, or Indicates another resource whose existence justifies this request reasonReference reason : Reference DataType [0..*] « Condition | Observation | DiagnosticReport | DocumentReference » Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant in delivering the requested service insurance : Reference [0..*] « Coverage | ClaimResponse » Information that may be needed by/relevant to the performer in their execution of this {{title}} supportingInfo : Reference [0..*] « Any » Comments made about the {{title}} by the requester, performer, subject or other participants note : Annotation [0..*] 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 relevantHistory : Reference [0..*] « Provenance »

 

alternate definitions: Master Definition XML + JSON .

Path Definition Type Reference
Request.status Codes identifying the lifecycle stage of a request. Required RequestStatus
Request.statusReason Codes identifying the reason for the current state of a request. Unknown No details provided yet
Request.intent Codes indicating the degree of authority/intentionality associated with a request. Required RequestIntent
Request.priority Identifies the level of importance to be assigned to actioning the request. Required RequestPriority
Request.code Codes indicating the details of what is being requested. These will vary significantly based on the type of request resource and will often be example/preferred rather than extensible/required. Unknown No details provided yet
Request.performerType Identifies types of practitioners, devices or other agents that should fulfill a request. While the detailed constraints of relevant agents will vary by resource, some degree of consistency around recommended codes across request and definition resources would be desirable. Unknown No details provided yet
Request.reasonCode Request.reason Codes identifying why this request was necessary. These may be clinical reasons (e.g. diagnoses, symptoms) and/or administrative reasons. While the detailed constraints of relevant reasons will vary by resource, some degree of consistency across resources around recommended codes would be desirable. Unknown No details provided yet

Not all resources that follow the 'Request' pattern will necessarily include all of the above elements. A set of standard extensions have been defined for use with resources where an element might be "applicable" but is not commonly supported. A list of these can be found on the Request Extensions (request-specific) and Workflow Extensions (shared by events and requests).

The following diagram shows the "typical" state machine diagram for resources following the Request pattern. Note that not all resources will support all states, some resources may choose different names for certain states and some resources may introduce sub-states to the listed states. As well, additional transitions may be supported, including from terminal nodes (e.g. from "completed" back to "active"). That said, most resources should align with this state machine fairly well.

Typical state machine diagram for resources following the Request pattern

Note that this state machine does not reflect the execution of the request. That state is managed either through the Event resources that are based on the request or via the Task resource.

Request resources describe what activity is desired/authorized. Requests do not track the execution/fulfillment of the plan, proposal or order. I.e. the request resource will not indicate actual performer, actual performance time, actual action performed, etc. Information about what action (if any) has occurred against the request is tracked using the corresponding Event resource(s). Events that are associated with the request should have a basedOn link referencing the request. In addition, a linkage can be established (and information about progress of execution) may be found in Task resources that have a focus of this request.

FHIR does not impose any business rules on what sorts of changes may be made to a request. A generic FHIR server could support updating a completed request to change the subject, requester, authorized action, quantity, timing and any other such information. However, most business processes will impose significant constraints on what changes, if any, are allowed to request resources, particularly after they have transitioned to "active" or "completed". Servers are free to enforce whatever rules they deem appropriate - and to provide appropriate OperationOutcome responses detailing constraints if those rules are violated.

There are three different ways to define "compound" requests in FHIR:

  • Shared requisition id
  • "Based on" chain
  • RequestGroup

The Request.requisitionId element allows multiple requests to be linked as having been created as part of the same "event" - generally by the same practitioner at the same time for the same subject. The "requisitionId" represents the identifier of the prescription, lab requisition or other form that was shared by all items. The common information ( patient / practitioner / authoredOn ) can be seen by examining any of the Request instances that share that requisitionId If there are common comments or notes that span the entire requisition, they should be captured as Observation or Communication instances linked to relevant Request instances using Request.supportingInfo .

Each "component" behaves as an independent request and has its own status that changes independently. In general the requisitionId, practitioner, authoredOn and subject for each will be immutable, but there may be situations where some workflows allow them to change. The shared requisitionId allows business processes dependent on "simultaneous/requisition-based ordering" such as payment rules to know that the requests were ordered at the same time.

In this case "components" of a parent request are not treated as components, but rather as separate orders that are executed as part of the fulfillment process for the parent order. For example, a lab order might spawn child orders to draw the specimen, treat the specimen, run several tests and to create the report. Each "child" Request would use Request.basedOn to reference the original Request. In this case, there's a relationship between the statuses of the base Request and the fulfilling Requests, but they transition separately and might not transition in the same manner. For example, if the original lab order were updated to "suspended", the initial blood draw request might be complete. The other requests might change to either "suspended" or even "aborted" and a subsequent update of the lab order back to active might require spawning additional fulfilling orders, perhaps to draw a new specimen.

basedOn is distinct from the notion of replaces . In a "based on" relationship both resources are "active" and in force and the authority cascades from the initial request to the request that is based on that original request. In a "replaces" relationship, the target resource is no longer in force and should have a status of "completed" or "cancelled" or some other terminal state.

This approach makes use of the RequestGroup resource which allows the assertion of complex timing and other dependencies between a collection of requests. These effectively become one overall Request instance with a single status. All resources referenced by the RequestGroup must have an intent of "option", meaning that they cannot be interpretted independently - and that changes to them must take into account the impact on referencing resources. Typically these will either be contained resources or tightly controlled or immutable instances based on ActivityDefinitions that can safely be referenced without concern of them changing independent of referencing Requests.

The status of the parent request automatically cascades to the component "options". If there is a need for divergent statuses, these must be handled by creating "child" using the "basedOn" approach above. They should have a basedOn relationship with both the "parent" Request as well as the specific "option" Request they are tied to.

Appointment.reasonReference : Reference [0..*]"> 1 Claim.diagnosis : BackboneElement [0..*] The type 'BackboneElement' is not legal according to the pattern (BackboneElement vs Reference(Condition|Observation|DiagnosticReport|DocumentReference)) "> 1 NT CommunicationRequest.reasonCode : CodeableConcept [0..*]"> 1 CommunicationRequest.reasonReference : Reference [0..*]"> 1 DeviceRequest.code[x] DeviceRequest.reasonCode : CodeableConcept [0..*]"> 1 DeviceRequest.reasonReference : Reference [0..*]"> 1 MedicationRequest.medication[x] MedicationRequest.reasonCode : CodeableConcept [0..*]"> 1 MedicationRequest.reasonReference : Reference [0..*]"> 1 RequestGroup.reasonCode : CodeableConcept [0..*]"> 1 RequestGroup.reasonReference ServiceRequest.reasonCode : CodeableConcept [0..*]"> 1 ServiceRequest.reasonReference SupplyRequest.item[x] SupplyRequest.reasonCode : CodeableConcept [0..*]"> 1 SupplyRequest.reasonReference Task.location : Reference [0..1] The type 'Reference' is not legal according to the pattern (Reference vs CodeableConcept) "> 1 NT Task.reasonReference : Reference [0..1]"> 1
identifier instantiatesCanonical instantiatesUri basedOn replaces groupIdentifier status statusReason intent priority doNotPerform code subject encounter occurrence[x] authoredOn requester reported[x] performerType performer reasonCode reasonReference reason insurance supportingInfo note relevantHistory
Appointment 1 1 1 1 T 1 NC 4 NTC NC 1 N 1 NTC Appointment.reasonCode : CodeableConcept [0..*]"> 1 NC 1 N 1 NT N
AppointmentResponse 1 1 N 1 N 2 NT N 1 NC 1 N 1 NT N
CarePlan 1 2 2 1 1 CarePlan.status : code [1..1]; Request.status : code [1..1] => CarePlan.activity.detail.status : code [1..1]"> 1 2 1 1 1 1 1 2 NT N 1 N 1 N CarePlan.activity.detail.reported[x] : boolean, Reference [0..1]"> 1 CarePlan.activity.detail.performer CarePlan.careTeam : Reference [0..*] Maximum Cardinality Violation (pattern = 1, resource = *)"> 1 C CarePlan.activity.detail.reasonCode : CodeableConcept [0..*]"> 1 CarePlan.addresses : Reference [0..*]; Request.reasonReference *); Request.performer : Reference(Condition|Observation|DiagnosticReport|DocumentReference) [0..*] Reference(Practitioner|PractitionerRole|Organization|CareTeam|HealthcareService|Patient|Device|RelatedPerson) [0..1] => CarePlan.activity.detail.reasonReference CarePlan.activity.detail.performer : Reference [0..*]"> [0..*] Maximum Cardinality Violation (pattern = 1, resource = *)"> 2 N NC 1 1
Claim 2 1 N 1 1 T 1 N 1 N 1 N 1 N 1 T
CommunicationRequest 1 1 1 1 1 1 1 1 1 C 1 1 1 CommunicationRequest.sender CommunicationRequest.informationProvider : Reference [0..1]"> [0..*] Maximum Cardinality Violation (pattern = 1, resource = *)"> 2 NC 1 N string, Attachment, Reference Reference, CodeableConcept [1..1] The type 'string' 'Attachment' is not legal according to the pattern (string, Attachment, Reference (Attachment, Reference, CodeableConcept vs Annotation) , The type 'Attachment' 'Reference' is not legal according to the pattern (string, Attachment, Reference (Attachment, Reference, CodeableConcept vs Annotation) , The type 'Reference' 'CodeableConcept' is not legal according to the pattern (string, Attachment, Reference (Attachment, Reference, CodeableConcept vs Annotation) ; Request.note : Annotation [0..*] => CommunicationRequest.note : Annotation [0..*]"> 2 NT N
Contract 2 1 C 2 N 1 C 2 N 2 N 1 N 1 NT Contract.term.action.intent : CodeableConcept [1..1]"> 1 N
CoverageEligibilityRequest 1 1 1 T 1 N 1 N 2 N 1 N
DeviceRequest 1 1 1 1 1 N 1 1 C 1 1 DeviceRequest.code : Reference, CodeableConcept CodeableReference [1..1] The type 'Reference' 'CodeableReference' is not legal according to the pattern (Reference, CodeableConcept (CodeableReference vs CodeableConcept) "> 1 NT 1 1 1 1 1 1 1 1 1 1 1
EnrollmentRequest 1 1 C 1 NC 1 N 1 N 1 N 1 N
ImmunizationRecommendation 1 1 NC 1 N 1 NTC NC 1 N 1 N
MedicationRequest 1 1 1 N 1 1 1 1 1 MedicationRequest.medication : CodeableConcept, Reference CodeableReference [1..1] The type 'Reference' 'CodeableReference' is not legal according to the pattern (CodeableConcept, Reference (CodeableReference vs CodeableConcept) "> 1 NT N 1 1 NTC NC 1 1 1 1 1 1 N 1 1 N
NutritionOrder 1 1 1 1 1 8 NC 1 N 1 3 NC 1 N 1 N 3 NT N 1
RequestGroup 1 1 1 1 1 1 1 1 2 2 C 1 C 1 1 NT N 1 1 N 1 NC RequestGroup.reason : Reference CodeableReference [0..*]"> 1 1 NT N 1
ServiceRequest 1 1 1 1 1 1 N 1 1 1 1 1 1 1 1 1 1 1 1 C ServiceRequest.reason : Reference CodeableReference [0..*]"> 1 1 1 1 1
SupplyRequest 1 1 C 1 SupplyRequest.item : CodeableConcept, Reference CodeableReference [1..1] The type 'Reference' 'CodeableReference' is not legal according to the pattern (CodeableConcept, Reference (CodeableReference vs CodeableConcept) "> 1 NT N 1 1 1 1 NC SupplyRequest.reason : Reference CodeableReference [0..*]"> 1
Task 1 1 1 [0..*]; Request.replaces : Reference(Request) [0..*] => Extension task-replaces : Reference [0..*]"> E 1 1 1 1 1 1 NC 1 1 1 1 1
VisionPrescription 1 1 1 N 1 N 1 N