ServiceRequest | Medplum
A record of a request for service such as diagnostic investigations, treatments, or operations to be performed.
Elements
| Name | Required | Type | Description |
|---|---|---|---|
| identifier | Identifier[] | Identifiers assigned to this order. Details: Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller. 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. | |
| instantiatesCanonical | canonical[] | Instantiates FHIR protocol or definition. Details: The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this ServiceRequest. 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. | |
| instantiatesUri | uri[] | Instantiates external protocol or definition. Details: The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this ServiceRequest. This might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier. | |
| basedOn | Reference< CarePlan | ServiceRequest | MedicationRequest >[] |
What request fulfills. Details: Plan/proposal/order fulfilled by this request. | |
| replaces | Reference< ServiceRequest >[] | What request replaces. Details: The request takes the place of the referenced completed or terminated request(s). | |
| requisition | Identifier | Composite Request ID. Details: 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. 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. | |
| status | ✓ | code | draft | active | on-hold | revoked | completed | entered-in-error | unknown. Details: The status of the order. 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, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding event or using the Task resource. |
| intent | ✓ | code | proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option. Details: Whether the request is a proposal, plan, an original order or a reflex order. This element is labeled as a modifier because the intent alters when and how the resource is actually applicable. |
| category | CodeableConcept[] | Classification of service. Details: A code that classifies the service for searching, sorting and display purposes (e.g. "Surgical Procedure"). 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. | |
| priority | code | routine | urgent | asap | stat. Details: Indicates how quickly the ServiceRequest should be addressed with respect to other requests. | |
| doNotPerform | boolean | True if service/procedure should not be performed. Details: Set this to true if the record is saying that the service/procedure should NOT be performed. 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. | |
| code | CodeableConcept | What is being requested/ordered. Details: A code that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that have been requested. 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. | |
| orderDetail | CodeableConcept[] | Additional order information. Details: Additional details and instructions about the 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. For information from the medical record intended to support the delivery of the requested services, use the supportingInformation element. |
|
| quantity[x] | Quantity, Ratio, Range | Service amount. Details: An amount of service being requested which can be a quantity (for example $1,500 home modification), a ratio (for example, 20 half day visits per month), or a range (2.0 to 1.8 Gy per fraction). | |
| subject | ✓ | Reference< Patient | Group | Location | Device > |
Individual or Entity the service is ordered for. Details: 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). |
| encounter | Reference< Encounter > | Encounter in which the request was created. Details: An encounter that provides additional information about the healthcare context in which this request is made. | |
| occurrence[x] | dateTime, Period, Timing | When service should occur. Details: The date/time at which the requested service should occur. | |
| asNeeded[x] | boolean, CodeableConcept | Preconditions for service. Details: If a CodeableConcept is present, it indicates the pre-condition for performing the service. For example "pain", "on flare-up", etc. | |
| authoredOn | dateTime | Date request signed. Details: When the request transitioned to being actionable. | |
| requester | Reference< Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device > |
Who/what is requesting service. Details: The individual who initiated the request and has responsibility for its activation. 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. | |
| performerType | CodeableConcept | Performer role. Details: Desired type of performer for doing the requested service. 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”. | |
| performer | Reference< Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson >[] |
Requested performer. Details: The desired performer for doing the requested service. For example, the surgeon, dermatopathologist, endoscopist, etc. 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 request-performerOrder extension. Use CareTeam to represent a group of performers (for example, Practitioner A and Practitioner B). | |
| locationCode | CodeableConcept[] | Requested location. Details: 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. | |
| locationReference | Reference< Location >[] | Requested location. Details: A reference to the the preferred location(s) where the procedure should actually happen. E.g. at home or nursing day care center. | |
| reasonCode | CodeableConcept[] | Explanation/Justification for procedure or service. Details: An explanation or justification for why this service is being requested in coded or textual form. This is often for billing purposes. May relate to the resources referred to in supportingInfo. This element represents why the referral is being made and may be used to decide how the service will be performed, or even if it will be performed at all. Use the CodeableConcept text element if the data is free (uncoded) text as shown in the CT Scan example. |
|
| reasonReference | Reference< Condition | Observation | DiagnosticReport | DocumentReference >[] |
Explanation/Justification for service or service. Details: Indicates another resource that provides a justification for why this service is being requested. May relate to the resources referred to in supportingInfo. This element represents why the referral 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. Otherwise when referencing DiagnosticReport it should contain a finding in DiagnosticReport.conclusion and/or DiagnosticReport.conclusionCode. When using a reference to DocumentReference, the target document should contain clear findings language providing the relevant reason for this service request. Use the CodeableConcept text element in ServiceRequest.reasonCode if the data is free (uncoded) text as shown in the CT Scan example. |
|
| insurance | Reference< Coverage | ClaimResponse >[] | Associated insurance coverage. Details: Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be needed for delivering the requested service. | |
| supportingInfo | Reference |
Additional clinical information. Details: 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. To represent information about how the services are to be delivered use the instructions element. |
|
| specimen | Reference< Specimen >[] | Procedure Samples. Details: One or more specimens that the laboratory procedure will use. Many diagnostic procedures need a specimen, but the request itself is not actually about the specimen. This element is for when the diagnostic is requested on already existing specimens and the request points to the specimen it applies to. Conversely, if the request is entered first with an unknown specimen, then the Specimen resource points to the ServiceRequest. | |
| bodySite | CodeableConcept[] | Location on Body. Details: Anatomic location where the procedure should be performed. This is the target site. Only used if not implicit in the code found in ServiceRequest.code. If the use case requires BodySite to be handled as a separate resource instead of an inline coded element then use the standard extension procedure-targetBodyStructure. | |
| note | Annotation[] | Comments. Details: Any other notes and comments made about the service request. For example, internal billing notes. | |
| patientInstruction | string | Patient or consumer-oriented instructions. Details: Instructions in terms that are understood by the patient or consumer. | |
| relevantHistory | Reference< Provenance >[] | Request provenance. Details: Key events in the history of the request. 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. |
Search Parameters
| Name | Type | Description | Expression |
|---|---|---|---|
| code | token | What is being requested/ordered | ServiceRequest.code |
| identifier | token | Identifiers assigned to this order | ServiceRequest.identifier |
| patient | reference | Search by subject - a patient | ServiceRequest.subject.where((resolve() is Patient)) |
| encounter | reference | An encounter in which this request is made | ServiceRequest.encounter |
| authored | date | Date request signed | ServiceRequest.authoredOn |
| based-on | reference | What request fulfills | ServiceRequest.basedOn |
| body-site | token | Where procedure is going to be done | ServiceRequest.bodySite |
| category | token | Classification of service | ServiceRequest.category |
| instantiates-canonical | reference | Instantiates FHIR protocol or definition | ServiceRequest.instantiatesCanonical |
| instantiates-uri | uri | Instantiates external protocol or definition | ServiceRequest.instantiatesUri |
| intent | token | proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option | ServiceRequest.intent |
| occurrence | date | When service should occur | ServiceRequest.occurrence |
| order-details | token | Order detail | ServiceRequest.orderDetail.text |
| performer | reference | Requested performer | ServiceRequest.performer |
| performer-type | token | Performer role | ServiceRequest.performerType |
| priority | token | routine | urgent | asap | stat | ServiceRequest.priority |
| replaces | reference | What request replaces | ServiceRequest.replaces |
| requester | reference | Who/what is requesting service | ServiceRequest.requester |
| requisition | token | Composite Request ID | ServiceRequest.requisition |
| specimen | reference | Specimen to be tested | ServiceRequest.specimen |
| status | token | draft | active | on-hold | revoked | completed | entered-in-error | unknown | ServiceRequest.status |
| subject | reference | Search by subject | ServiceRequest.subject |
| priority-order | number | Numeric priority order for resource types... | iif(priority = 'stat', 50, ... |
| reason-code | token | Coded value representing the reason | ServiceRequest.reasonCode |
Inherited Elements
| Name | Required | Type | Description |
|---|---|---|---|
| id | string | Logical id of this artifact. Details: The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes. The only time that a resource does not have an id is when it is being submitted to the server using a create operation. | |
| meta | Meta | Metadata about the resource. Details: The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource. | |
| implicitRules | uri | A set of rules under which this content was created. Details: A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc. | |
| language | code | Language of the resource content. Details: The base language in which the resource is written. Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). | |
| text | Narrative | Text summary of the resource, for human interpretation. Details: A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. | |
| contained | Resource[] | Contained, inline Resources. Details: These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently. | |
| extension | Extension[] | Additional content defined by implementations. Details: May be used to represent additional information that is not part of the basic definition of the resource. | |
| modifierExtension | Extension[] | Extensions that cannot be ignored. Details: May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. |