pub struct ServiceRequestInner {Show 74 fields
pub id: Option<String>,
pub meta: Option<Meta>,
pub implicit_rules: Option<String>,
pub language: Option<String>,
pub text: Option<Narrative>,
pub contained: Vec<Resource>,
pub extension: Vec<Extension>,
pub modifier_extension: Vec<Extension>,
pub identifier: Vec<Option<Identifier>>,
pub identifier_ext: Vec<Option<FieldExtension>>,
pub instantiates_canonical: Vec<Option<String>>,
pub instantiates_canonical_ext: Vec<Option<FieldExtension>>,
pub instantiates_uri: Vec<Option<String>>,
pub instantiates_uri_ext: Vec<Option<FieldExtension>>,
pub based_on: Vec<Option<Reference>>,
pub based_on_ext: Vec<Option<FieldExtension>>,
pub replaces: Vec<Option<Reference>>,
pub replaces_ext: Vec<Option<FieldExtension>>,
pub requisition: Option<Identifier>,
pub requisition_ext: Option<FieldExtension>,
pub status: RequestStatus,
pub status_ext: Option<FieldExtension>,
pub intent: RequestIntent,
pub intent_ext: Option<FieldExtension>,
pub category: Vec<Option<CodeableConcept>>,
pub category_ext: Vec<Option<FieldExtension>>,
pub priority: Option<RequestPriority>,
pub priority_ext: Option<FieldExtension>,
pub do_not_perform: Option<bool>,
pub do_not_perform_ext: Option<FieldExtension>,
pub code: Option<CodeableReference>,
pub code_ext: Option<FieldExtension>,
pub order_detail: Vec<Option<ServiceRequestOrderDetail>>,
pub order_detail_ext: Vec<Option<FieldExtension>>,
pub quantity: Option<ServiceRequestQuantity>,
pub quantity_ext: Option<ServiceRequestQuantityExtension>,
pub subject: Reference,
pub subject_ext: Option<FieldExtension>,
pub focus: Vec<Option<Reference>>,
pub focus_ext: Vec<Option<FieldExtension>>,
pub encounter: Option<Reference>,
pub encounter_ext: Option<FieldExtension>,
pub occurrence: Option<ServiceRequestOccurrence>,
pub occurrence_ext: Option<ServiceRequestOccurrenceExtension>,
pub as_needed: Option<ServiceRequestAsNeeded>,
pub as_needed_ext: Option<ServiceRequestAsNeededExtension>,
pub authored_on: Option<DateTime>,
pub authored_on_ext: Option<FieldExtension>,
pub requester: Option<Reference>,
pub requester_ext: Option<FieldExtension>,
pub performer_type: Option<CodeableConcept>,
pub performer_type_ext: Option<FieldExtension>,
pub performer: Vec<Option<Reference>>,
pub performer_ext: Vec<Option<FieldExtension>>,
pub location: Vec<Option<CodeableReference>>,
pub location_ext: Vec<Option<FieldExtension>>,
pub reason: Vec<Option<CodeableReference>>,
pub reason_ext: Vec<Option<FieldExtension>>,
pub insurance: Vec<Option<Reference>>,
pub insurance_ext: Vec<Option<FieldExtension>>,
pub supporting_info: Vec<Option<CodeableReference>>,
pub supporting_info_ext: Vec<Option<FieldExtension>>,
pub specimen: Vec<Option<Reference>>,
pub specimen_ext: Vec<Option<FieldExtension>>,
pub body_site: Vec<Option<CodeableConcept>>,
pub body_site_ext: Vec<Option<FieldExtension>>,
pub body_structure: Option<Reference>,
pub body_structure_ext: Option<FieldExtension>,
pub note: Vec<Option<Annotation>>,
pub note_ext: Vec<Option<FieldExtension>>,
pub patient_instruction: Vec<Option<ServiceRequestPatientInstruction>>,
pub patient_instruction_ext: Vec<Option<FieldExtension>>,
pub relevant_history: Vec<Option<Reference>>,
pub relevant_history_ext: Vec<Option<FieldExtension>>,
/* private fields */
}Expand description
A record of a request for service such as diagnostic investigations, treatments, or operations to be performed.
ServiceRequest v5.0.0
A request for a service to be performed
A record of a request for service such as diagnostic investigations, treatments, or operations to be performed.
Fields§
§id: Option<String>Logical id of this artifact
The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.
Within the context of the FHIR RESTful interactions, the resource has an id except for cases like the create and conditional update. Otherwise, the use of the resouce id depends on the given use case.
meta: Option<Meta>Metadata about the resource
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.
implicit_rules: Option<String>A set of rules under which this content was created
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.
Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of its narrative along with other profiles, value sets, etc.
language: Option<String>Language; Language of the resource content
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). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).
text: Option<Narrative>Text summary of the resource, for human interpretation
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. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.
Contained resources do not have a narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a “text blob” or where text is additionally entered raw or narrated and encoded information is added later.
contained: Vec<Resource>Contained, inline Resources
These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, nor can they have their own independent transaction scope. This is allowed to be a Parameters resource if and only if it is referenced by a resource that provides context/meaning.
This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags in their meta elements, but SHALL NOT have security labels.
extension: Vec<Extension>Additional content defined by implementations
May be used to represent additional information that is not part of the basic definition of the resource. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
modifier_extension: Vec<Extension>Extensions that cannot be ignored
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. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.
Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
identifier: Vec<Option<Identifier>>Identifiers assigned to this order
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.
identifier_ext: Vec<Option<FieldExtension>>Extension field.
instantiates_canonical: Vec<Option<String>>Instantiates FHIR protocol or 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 ServiceRequest.
The PlanDefinition resource is used to describe series, sequences, or groups of actions to be taken, while the ActivityDefinition resource is used to define each specific step or activity to be performed. More information can be found in the Boundaries and Relationships section for PlanDefinition.
instantiates_canonical_ext: Vec<Option<FieldExtension>>Extension field.
instantiates_uri: Vec<Option<String>>Instantiates external protocol or 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 ServiceRequest.
This might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier.
instantiates_uri_ext: Vec<Option<FieldExtension>>Extension field.
based_on: Vec<Option<Reference>>What request fulfills
Plan/proposal/order fulfilled by this request.
based_on_ext: Vec<Option<FieldExtension>>Extension field.
replaces: Vec<Option<Reference>>What request replaces
The request takes the place of the referenced completed or terminated request(s).
replaces_ext: Vec<Option<FieldExtension>>Extension field.
requisition: Option<Identifier>Composite Request ID
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.
requisition_ext: Option<FieldExtension>Extension field.
status: RequestStatusServiceRequestStatus; draft | active | on-hold | revoked | completed | entered-in-error | unknown
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, 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.
status_ext: Option<FieldExtension>Extension field.
intent: RequestIntentServiceRequestIntent; proposal | plan | directive | order +
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.
intent_ext: Option<FieldExtension>Extension field.
category: Vec<Option<CodeableConcept>>ServiceRequestCategory; Classification of service
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.
category_ext: Vec<Option<FieldExtension>>Extension field.
priority: Option<RequestPriority>ServiceRequestPriority; routine | urgent | asap | stat
Indicates how quickly the ServiceRequest should be addressed with respect to other requests.
priority_ext: Option<FieldExtension>Extension field.
do_not_perform: Option<bool>True if service/procedure should not be performed
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.
do_not_perform_ext: Option<FieldExtension>Extension field.
code: Option<CodeableReference>ServiceRequestCode; What is being requested/ordered
A code or reference 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.
code_ext: Option<FieldExtension>Extension field.
order_detail: Vec<Option<ServiceRequestOrderDetail>>Additional order information
Additional details and instructions about the how the services are to be delivered. For example, and 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.
order_detail_ext: Vec<Option<FieldExtension>>Extension field.
quantity: Option<ServiceRequestQuantity>Service amount
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).
quantity_ext: Option<ServiceRequestQuantityExtension>Extension field.
subject: ReferenceIndividual or Entity the service is ordered for
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).
subject_ext: Option<FieldExtension>Extension field.
focus: Vec<Option<Reference>>What the service request is about, when it is not about the subject of record
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.
focus_ext: Vec<Option<FieldExtension>>Extension field.
encounter: Option<Reference>Encounter in which the request was created
An encounter that provides additional information about the healthcare context in which this request is made.
encounter_ext: Option<FieldExtension>Extension field.
occurrence: Option<ServiceRequestOccurrence>When service should occur
The date/time at which the requested service should occur.
occurrence_ext: Option<ServiceRequestOccurrenceExtension>Extension field.
as_needed: Option<ServiceRequestAsNeeded>Preconditions for service
If a CodeableConcept is present, it indicates the pre-condition for performing the service. For example “pain”, “on flare-up”, etc.
as_needed_ext: Option<ServiceRequestAsNeededExtension>Extension field.
Date request signed
When the request transitioned to being actionable.
Extension field.
requester: Option<Reference>Who/what is requesting service
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.
requester_ext: Option<FieldExtension>Extension field.
performer_type: Option<CodeableConcept>ServiceRequestParticipantRole; Performer role
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_type_ext: Option<FieldExtension>Extension field.
performer: Vec<Option<Reference>>Requested performer
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 http://hl7.org/fhir/StructureDefinition/request-performerOrder. Use CareTeam to represent a group of performers (for example, Practitioner A and Practitioner B).
performer_ext: Vec<Option<FieldExtension>>Extension field.
location: Vec<Option<CodeableReference>>ServiceRequestLocation; Requested location
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.
location_ext: Vec<Option<FieldExtension>>Extension field.
reason: Vec<Option<CodeableReference>>ServiceRequestReason; Explanation/Justification for procedure or service
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. To be as specific as possible, a reference to Observation or Condition should be used if available. Otherwise, use concept.text element if the data is free (uncoded) text as shown in the CT Scan example.
reason_ext: Vec<Option<FieldExtension>>Extension field.
insurance: Vec<Option<Reference>>Associated insurance coverage
Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be needed for delivering the requested service.
insurance_ext: Vec<Option<FieldExtension>>Extension field.
supporting_info: Vec<Option<CodeableReference>>Additional clinical information
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.
supporting_info_ext: Vec<Option<FieldExtension>>Extension field.
specimen: Vec<Option<Reference>>Procedure Samples
One or more specimens that the laboratory procedure will use.
The purpose of the ServiceRequest.specimen is to reflect the actual specimen that the requested test/procedure is asked to be performed on, whether the lab already has it or not. References to specimens for purposes other than to perform a test/procedure on should be made using the ServiceRequest.supportingInfo or the Specimen.parent where the Specimen.parent would enable descendency and ServiceRequest.supportingInfo a general reference for context.
specimen_ext: Vec<Option<FieldExtension>>Extension field.
body_site: Vec<Option<CodeableConcept>>BodySite; Coded location on Body
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 (e.g. to identify and track separately) then use the standard extension http://hl7.org/fhir/StructureDefinition/procedure-targetBodyStructure.
body_site_ext: Vec<Option<FieldExtension>>Extension field.
body_structure: Option<Reference>BodyStructure-based location on the body
Anatomic location where the procedure should be performed. This is the target site.
body_structure_ext: Option<FieldExtension>Extension field.
note: Vec<Option<Annotation>>Comments
Any other notes and comments made about the service request. For example, internal billing notes.
note_ext: Vec<Option<FieldExtension>>Extension field.
patient_instruction: Vec<Option<ServiceRequestPatientInstruction>>Patient or consumer-oriented instructions
Instructions in terms that are understood by the patient or consumer.
patient_instruction_ext: Vec<Option<FieldExtension>>Extension field.
relevant_history: Vec<Option<Reference>>Request provenance
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. (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.
relevant_history_ext: Vec<Option<FieldExtension>>Extension field.
Trait Implementations§
Source§impl Clone for ServiceRequestInner
impl Clone for ServiceRequestInner
Source§fn clone(&self) -> ServiceRequestInner
fn clone(&self) -> ServiceRequestInner
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more