type: resource-definitionsresource: ServiceRequest

ServiceRequest Definitions

ServiceRequest

A request for a service to be performed

Definition: A record of a request for service such as diagnostic investigations, treatments, or operations to be performed. When the ServiceRequest is active, it represents an authorization to perform the service.

Aliases: diagnostic request, referral, referral request, transfer of care request, order, test ordered

Cardinality: 0..*

Mappings: workflow=Request; v2=ORC; rim=Act[moodCode<=INT]; w5=clinical.general

ServiceRequest.identifier

Identifiers assigned to this order

Definition: Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller.

Comments: The identifier.type element is used to distinguish between the identifiers assigned by the orderer (known as the 'Placer' in HL7 V2) and the producer of the observations in response to the order (known as the 'Filler' in HL7 V2). For further discussion and examples see the resource notes section below.

Cardinality: 0..*

Type: Identifier

Summary: true

Mappings: workflow=Request.identifier; w5=FiveWs.identifier; v2=ORC-2, ORC-3, RF1-6 / RF1-11,; rim=.identifier; quick=ClinicalStatement.identifier

ServiceRequest.basedOn

What request fulfills

Definition: Plan/proposal/order fulfilled by this request.

Aliases: fulfills

Cardinality: 0..*

Type: Reference(CarePlan, DocumentReference, ServiceRequest, MedicationRequest, RequestOrchestration, NutritionOrder, DocumentReference)

Summary: true

Mappings: workflow=Request.basedOn; v2=ORC-8 (plus others); rim=.outboundRelationship[typeCode=FLFS].target

ServiceRequest.replaces

What request replaces

Definition: The request takes the place of the referenced completed or terminated request(s).

Aliases: supersedes, prior, renewed order

Cardinality: 0..*

Type: Reference(ServiceRequest, MedicationRequest, RequestOrchestration, CarePlan, DeviceRequest, CommunicationRequest, NutritionOrder, VisionPrescription)

Summary: true

Mappings: workflow=Request.replaces; v2=Handled by message location of ORC (ORC-1=RO or RU); rim=.outboundRelationship[typeCode=RPLC].target

ServiceRequest.requisition

Composite Request ID

Definition: A shared identifier common to all service requests that were authorized more or less simultaneously by a single author, representing the composite or group identifier.

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.

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

Cardinality: 0..1

Type: Identifier

Summary: true

Mappings: workflow=Request.groupIdentifier; v2=ORC-4; rim=.inboundRelationship(typeCode=COMP].source[moodCode=INT].identifier

ServiceRequest.status

Definition: The status of the order.

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, competed, revoked or placed on-hold. States relating to the activities of the performer are reflected on either the corresponding event (see Event Pattern for general discussion) or using the Task resource.

Cardinality: 1..1

Type: code

Binding: required:request-status

Summary: true

Is Modifier: true (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)

Mappings: workflow=Request.status; w5=FiveWs.status; v2=ORC-5,RF1-1; rim=.status; quick=Action.currentStatus

ServiceRequest.statusReason

Reason for current status

Definition: Provides reason why the service request status is what it is. The statusReason can be used to explain why a service request is suspended, cancelled, or on hold, including administrative and clinical reasons.

Comments: This is generally not present when the service request has a status of 'active' or 'completed'. There is potential overlap between ServiceRequest.reason (why the service is being requested) and ServiceRequest.statusReason (why the request is in its current status) early in the performance of the request when the reason for the service request might influence the initial status.

Cardinality: 0..*

Type: CodeableConcept

Binding: example:servicerequest-status-reason

Mappings: workflow=Request.statusReason

ServiceRequest.intent

Definition: Whether the request is a proposal, plan, an original order or a reflex order.

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 ServiceRequest.intent is allowed to change. For example, a ServiceRequest 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.

Cardinality: 1..1

Type: code

Binding: required:request-intent

Summary: true

Is Modifier: true (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)

Mappings: workflow=Request.intent; w5=FiveWs.class; v2=N/A; rim=.moodCode (nuances beyond PRP/PLAN/RQO would need to be elsewhere)

ServiceRequest.category

Classification of service

Definition: A code that classifies the service for searching, sorting and display purposes (e.g. "Surgical Procedure").

Comments: There may be multiple axis of categorization depending on the context or use case for retrieving or displaying the resource. The level of granularity is defined by the category concepts in the value set.

Requirements: Used for filtering what service request are retrieved and displayed.

Cardinality: 0..*

Type: CodeableConcept

Binding: example:servicerequest-category

Summary: true

Mappings: w5=FiveWs.class; v2=RF1-5; rim=.outboundRelationship[typeCode="COMP].target[classCode="LIST", moodCode="INT"].code; workflow=Request.category

ServiceRequest.priority

routine | urgent | asap | stat

Definition: Indicates how quickly the ServiceRequest should be addressed with respect to other requests.

Meaning if Missing: If missing, this task should be performed with normal priority

Cardinality: 0..1

Type: code

Binding: required:request-priority

Summary: true

Mappings: workflow=Request.priority; w5=FiveWs.grade; v2=TQ1.9, RF1-2; rim=.priorityCode

ServiceRequest.doNotPerform

True if service/procedure should not be performed

Definition: Set this to true if the record is saying that the service/procedure should NOT be performed.

Comments: In general, only the code and timeframe will be present, though occasional additional qualifiers such as body site or even performer could be included to narrow the scope of the prohibition. If the ServiceRequest.code and ServiceRequest.doNotPerform both contain negation, that will reinforce prohibition and should not have a double negative interpretation.

Requirements: Used for do not ambulate, do not elevate head of bed, do not flush NG tube, do not take blood pressure on a certain arm, etc.

Meaning if Missing: If missing, the request is a positive request e.g. "do perform"

Cardinality: 0..1

Type: boolean

Summary: true

Is Modifier: true (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.)

Mappings: workflow=Request.doNotPerform; rim=.actionNegationInd

ServiceRequest.code

What is being requested/ordered

Definition: A code or reference that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that has been requested.

Comments: Many laboratory and radiology procedure codes embed the specimen/organ system in the test order name, for example, serum or serum/plasma glucose, or a chest x-ray. The specimen might not be recorded separately from the test code. The PlanDefinition may be used when you want to group multiple activities together (e.g., order set that are part of a plan).

Aliases: service requested

Conditions: prr-1

Cardinality: 0..1

Type: CodeableReference

Binding: example:procedure-code

Summary: true

Mappings: workflow=Request.code; w5=FiveWs.what[x]; v2=PR1-3 / OBR-4 (varies by domain); rim=.code; quick=Procedure.procedureCode

ServiceRequest.orderDetail

Additional information about the request

Definition: Additional details and instructions about how the services are to be delivered. For example, an order for a urinary catheter may have an order detail for an external or indwelling catheter, or an order for a bandage may require additional instructions specifying how the bandage should be applied. Questions or additional information to be gathered from a patient may be included here.

Comments: For existing information to support the delivery of the requested services, use the supportingInformnation.element - e.g. to share information with the lab about a patient's age, gender, or current medications.

Aliases: detailed instructions

Conditions: prr-1

Cardinality: 0..*

Type: BackboneElement

Summary: true

Mappings: v2=NTE

ServiceRequest.orderDetail.parameterFocus[x]

The context of the order details by reference

Definition: Indicates the context of the order details by reference.

Cardinality: 0..1

Type: CodeableConcept, Reference(Device, DeviceRequest, Medication, MedicationRequest, BiologicallyDerivedProduct, Substance, SubstanceDefinition, MedicinalProductDefinition), canonical

Mappings: workflow=Request.product

ServiceRequest.orderDetail.parameter

The parameter details for the service being requested

Definition: The parameter details for the service being requested.

Cardinality: 1..*

Type: BackboneElement

Summary: true

ServiceRequest.orderDetail.parameter.code

The detail of the order being requested

Definition: A value representing the additional detail or instructions for the order (e.g., catheter insertion, body elevation, descriptive device configuration and/or setting instructions).

Cardinality: 1..1

Type: CodeableConcept

Binding: example:request-orderdetail-parameter-code

Summary: true

ServiceRequest.orderDetail.parameter.value[x]

The value for the order detail

Definition: Indicates a value for the order detail.

Comments: CodeableConcept values are indented to express concepts that would normally be coded - when a code is not available for a concept, CodeableConcept.text can be used. When the data is a text or not a single identifiable concept, string should be used.

Cardinality: 1..1

Type: Quantity, Ratio, Range, boolean, CodeableConcept, string, Period

Summary: true

ServiceRequest.quantity[x]

Service amount

Definition: An amount of service being requested.

Comments: The amount of service being requested can be a quantity (e.g., $1,500 for home modification request), a ratio (e.g., 20 for a request of home visits to occur each month), or a range (e.g., 8-10 for physiotherapy sessions).

Requirements: When ordering a service the number of service items may need to be specified separately from the the service item.

Cardinality: 0..1

Type: Quantity, Ratio, Range

Summary: true

Mappings: v2=NTE; rim=.quantity

ServiceRequest.subject

Individual or Entity the service is ordered for

Definition: On whom or what the service is to be performed. This is usually a human patient, but can also be requested on animals, groups of humans or animals, devices such as dialysis machines, or even locations (typically for environmental scans).

Cardinality: 1..1

Type: Reference(Patient, Group, Location, Device)

Summary: true

Mappings: workflow=Request.subject; w5=FiveWs.subject; v2=PID; rim=.participation[typeCode=SBJ].role; quick=ClinicalStatement.subject

ServiceRequest.focus

What the service request is about, when it is not about the subject of record

Definition: The actual focus of a service request when it is not the subject of record representing something or someone associated with the subject such as a spouse, parent, fetus, or donor. The focus of a service request could also be an existing condition, an intervention, the subject's diet, another service request on the subject, or a body structure such as tumor or implanted device.

Cardinality: 0..*

Type: Reference(Resource)

Summary: true

Mappings: w5=FiveWs.subject; rim=participation[typeCode=SBJ]

ServiceRequest.encounter

Encounter in which the request was created

Definition: An encounter that provides additional information about the healthcare context in which this request is made.

Aliases: context

Cardinality: 0..1

Type: Reference(Encounter)

Summary: true

Mappings: workflow=Request.encounter; w5=FiveWs.context; v2=PV1; rim=.inboundRelationship(typeCode=COMP].source[classCode<=PCPR, moodCode=EVN]; quick=ClinicalStatement.encounter

ServiceRequest.occurrence[x]

When service should occur

Definition: The date/time at which the requested service should occur.

Aliases: schedule

Cardinality: 0..1

Type: dateTime, Period, Timing

Summary: true

Mappings: workflow=Request.occurrence[x]; w5=FiveWs.planned; v2=TQ1/TQ2, OBR-7/OBR-8; rim=.effectiveTime; quick=Procedure.procedureSchedule

ServiceRequest.asNeeded

Perform the service "as needed"

Definition: Indicates that the service (e.g., procedure, lab test) should be performed when needed (Boolean option).

Cardinality: 0..1

Type: boolean

Summary: true

Mappings: rim=boolean: precondition.negationInd (inversed - so negationInd = true means asNeeded=false CodeableConcept: precondition.observationEventCriterion[code="Assertion"].value

ServiceRequest.asNeededFor

Specified criteria for the service

Definition: Indicates specific criteria that need to be met to perform the service (e.g., lab results or symptoms).

Conditions: asn-1

Cardinality: 0..*

Type: CodeableConcept

Binding: example:medication-as-needed-reason

Summary: true

Mappings: quick=Proposal.prnReason.reason

ServiceRequest.authoredOn

Date request signed

Definition: When the request transitioned to being actionable.

Aliases: orderedOn

Cardinality: 0..1

Type: dateTime

Summary: true

Mappings: workflow=Request.authoredOn; w5=FiveWs.recorded; v2=ORC-9, RF1-7 / RF1-9; rim=.participation[typeCode=AUT].time; quick=Proposal.proposedAtTime

ServiceRequest.requester

Who/what is requesting service

Definition: The individual who initiated the request and has responsibility for its activation.

Comments: This not the dispatcher, but rather who is the authorizer. This element is not intended to handle delegation which would generally be managed through the Provenance resource. The requestor is expected to receive the provided results (if any) of the ServiceRequest. If other additional recipients of results are required, use a CommunicationRequest resource based on the ServiceRequest and with the appropriate code in the CommunicationRequest.category element. Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners. In those instances it is preferable to use more specific resources such as Organization.

Aliases: author, orderer

Cardinality: 0..1

Type: Reference(Practitioner, PractitionerRole, Organization, Patient, RelatedPerson, Device, Group)

Summary: true

Mappings: workflow=Request.requester; w5=FiveWs.author; v2=ORC-12, PRT; rim=.participation[typeCode=AUT].role; quick=ClinicalStatement.statementAuthor

ServiceRequest.performerType

Performer role

Definition: Desired type of performer for doing the requested service.

Comments: This is a role, not a participation type. In other words, does not describe the task but describes the capacity. For example, “compounding pharmacy”, “psychiatrist” or “internal referral”.

Aliases: specialty

Cardinality: 0..1

Type: CodeableConcept

Binding: example:participant-role

Summary: true

Mappings: workflow=Request.performerType; w5=FiveWs.actor; v2=PRT, RF1-3; rim=.participation[typeCode=PRF].role[scoper.determinerCode=KIND].code

ServiceRequest.performer

Requested performer

Definition: The desired performer for doing the requested service. For example, the surgeon, dermatopathologist, endoscopist, etc.

Comments: If multiple performers are present, it is interpreted as a list of alternative performers without any preference regardless of order. If order of preference is needed use the [[[http://hl7.org/fhir/StructureDefinition/request-performerOrder]]]. Use CareTeam to represent a group of performers (for example, Practitioner A and Practitioner B). Group is only allowed in the circumstance where the group represents a family or a household, and should not represent groups of Practitioners. In those instances it is preferable to use more specific resources such as Organization, CareTeam, or HealthcareService instead.

Aliases: request recipient

Cardinality: 0..*

Type: Reference(Practitioner, PractitionerRole, Organization, CareTeam, HealthcareService, Patient, Device, RelatedPerson, Group)

Summary: true

Mappings: workflow=Request.performer; w5=FiveWs.actor; v2=PRT, Practitioner: PRD-2/PRD-7 where PRD-3 = RT; Organization: PRD-10 where PRD-3 = RT; rim=.participation[typeCode=PRF].role[scoper.determinerCode=INSTANCE]

ServiceRequest.location

Requested location

Definition: The preferred location(s) where the procedure should actually happen in coded or free text form. E.g. at home or nursing day care center.

Cardinality: 0..*

Type: CodeableReference

Binding: example:v3-ServiceDeliveryLocationRoleType

Summary: true

Mappings: w5=FiveWs.actor; rim=.participation[typeCode=LOC].role[scoper.determinerCode=KIND].code

ServiceRequest.reason

Reason or indication for requesting the service

Definition: The reason or the indication for requesting the service (e.g., procedure, lab test).

Comments: This element represents why the request is being made and may be used to decide how the service will be performed, or even if it will be performed at all. To be as specific as possible, a reference to Observation or Condition should be used if available. Use reason.concept.text element if the data is free (uncoded) text as shown in the CT Scan example.

Cardinality: 0..*

Type: CodeableReference

Binding: example:procedure-reason

Summary: true

Mappings: workflow=Request.reason; w5=FiveWs.why[x]; v2=ORC-16, RF1-10; rim=.reasonCode

ServiceRequest.insurance

Associated insurance coverage

Definition: Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be needed for delivering the requested service.

Cardinality: 0..*

Type: Reference(Coverage, ClaimResponse)

Mappings: workflow=Request.insurance; v2=IN1/IN2; rim=.outboundRelationship[typeCode=COVBY].target

ServiceRequest.supportingInfo

Additional clinical information

Definition: Additional clinical information about the patient or specimen that may influence the services or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as 'ask at order entry questions (AOEs).' This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurements.

Comments: To represent information about how the services are to be delivered, use the orderDetail element.

Aliases: Ask at order entry question, AOE

Cardinality: 0..*

Type: CodeableReference

Mappings: workflow=Request.supportingInfo; v2=Accompanying segments; rim=.outboundRelationship[typeCode=PERT].target

ServiceRequest.specimen

Procedure Samples

Definition: One or more specimens that the laboratory procedure will use.

Comments: Most commonly the association between the Specimen and ServiceRequest resources will be from the Specimen to the ServiceRequest, as usually the ServiceRequest is created first and provides the authorization for the specimen to be collected, and the reference to the ServiceRequest is recorded using the Specimen.request element. The ServiceRequest.specimen element, on the other hand, is being deprecated and is discouraged from use and is intended to be removed in a future release. In the less common cases where the specimen to be used to perform the test is already known and available and needs to be specified at the time the ServiceRequest is created, it is preferable to use the new 'specimenSuggestion' extension on the ServiceRequest resource, which enables specifying a particular specimen to be used either by a direct reference, more generally by a coded concept specifying the specimen type, or by the context of another ServiceRequest and any existing specimen(s) that may be associated with that request. When a specimen is referenced, it is expected to be used. If for some reason the specified specimen is unable to be used (doesn't exist, wrong specimen type, insufficient quantity or quality, etc.), the decision to collect another specimen or to not perform the test must be based on established policies or determined by some other means agreed to with the requester. References to specimens for purposes other than performing a test/procedure should be made using ServiceRequest.supportingInfo or the Specimen.parent, where the Specimen.parent would enable descendency and ServiceRequest.supportingInfo provides a general reference for context.

Cardinality: 0..*

Type: Reference(Specimen)

Summary: true

Mappings: v2=SPM; rim=.participation[typeCode=SPC].role

ServiceRequest.bodyStructure

BodyStructure-based location on the body

Definition: Anatomic location where the procedure should be performed. This is the target site.

Requirements: Knowing where the procedure is performed is important for tracking if multiple sites are possible.

Aliases: locationStructure

Cardinality: 0..1

Type: CodeableReference

Binding: example:body-site

Summary: true

Mappings: v2=SPM; rim=targetSiteCode; quick=Procedure.targetBodyStructure

ServiceRequest.note

Comments

Definition: Any other notes and comments made about the service request. For example, internal billing notes.

Cardinality: 0..*

Type: Annotation

Mappings: workflow=Request.note; v2=NTE; rim=.inboundRelationship(typeCode=SUBJ].source[classCode=ANNGEN, moodCode=EVN].value[xsi:type=ST]; quick=ClinicalStatement.additionalText

ServiceRequest.patientInstruction

Patient or consumer-oriented instructions

Definition: Instructions in terms that are understood by the patient or consumer.

Cardinality: 0..*

Type: BackboneElement

Mappings: v2=NTE; rim=.text

ServiceRequest.patientInstruction.instruction[x]

Patient or consumer-oriented instructions

Definition: Instructions in terms that are understood by the patient or consumer.

Cardinality: 0..1

Type: markdown, Reference(DocumentReference)

Summary: true

Mappings: v2=NTE; rim=.text

ServiceRequest.relevantHistory

Request provenance

Definition: Key events in the history of the request.

Comments: This might not include provenances for all versions of the request – only those deemed “relevant” or important. This SHALL NOT include the Provenance associated with this current version of the resource. (If that provenance is deemed to be a “relevant” change, it will need to be added as part of a later update. Until then, it can be queried directly as the Provenance that points to this version using _revinclude All Provenances should have some historical version of this Request as their subject.

Cardinality: 0..*

Type: Reference(Provenance)

Mappings: workflow=Request.relevantHistory; v2=N/A; rim=.inboundRelationship(typeCode=SUBJ].source[classCode=CACT, moodCode=EVN]