FHIR Artifacts > Structure Definition: ServiceRequest Profile

Structure Definition: ServiceRequest Profile

Canonical URL:http://ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-ServiceRequest

Simplifier project page:

Derived from: ServiceRequest (R4)

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work

Usage

The ServiceRequest resource is the primary resource used to represent a referral request in this IG. References to other resources are used to convey the details of the request including the Patient (ServiceRequest.subject), Referrer (ServiceRequest.requester) and supporting information (ServiceRequest.supportingInfo).

Notes

.id

• used to uniquely identify the resource
• if a persistent identity for the resource is not available to use when constructing a message Bundle for transmission via Direct Messaging, a UUID SHOULD be used in this element (with a corresponding value in Bundle.entry.fullUrl)

.meta.profile

• used to declare conformance to this profile
• populate with a fixed value: http://ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-ServiceRequest|1.0.0

.extension:PatientPresentLocation

• used to communicate the present location of the patient if it is different than the patient's home address
• see business rules for more information

.extension:RoutingOptions

• used to communicate referral source type information to support referral processes with automated referral processing rules
• see business rules for more information

.identifier

• business identifers associate the information exchanged between systems with the real world entity
• any number of business identifiers MAY be included in the resource (e.g., Ontario HCN, Band #, CHRIS #, Caredove #, Hubly ID, etc...).
• when a resource is send back to the sender in a message, all business identifiers received SHOULD be included with the resource to help the sending system to associate the information received with the resource sent
• for Health Information System assigned and similar Identifier values record the organization that issued the identifier in identifier.assigner.display.

.basedOn

• used when the recipient of a ServiceRequest, creates ServiceRequests for other service providers (e.g.: a coordinator in a central intake or assessment centre may create requests for other service providers basedOn the ServiceRequest being peformed)
• basedOn SHALL NOT be populated when a new ServiceRequest is created to initiate a referral
• when a service provider performing a ServiceRequest creates another, basedOn SHALL be populated on the new ServiceRequest with a reference to the ServiceRequest being performed
• if the ServiceRequest is being transmitted via messaging, the referenced ServiceRequest resource SHALL be included in the message as a Bundle.entry

.requisition

• used in cases where multiple connected referrals are made simultaneously (i.e. a requisition)

• in these cases:

  • multiple ServiceRequests SHALL be referenced in MessageHeader.focus
  • each of the ServiceRequests in MessageHeader.focus SHALL have the same identifier in ServiceRequest.requisition
  • the identifier used in ServiceRequest.requisition SHALL also be used in MessageHeader.extension:ReferralIdentifier

• Note that additional business rules apply to requisitions

• FOR EREFERRAL USAGE: It is highly recommended that the common elements should match between multiple ServiceRequests (e.g., patient, requester, etc...) 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

• used to communicate the current status of the ServiceRequest on the requester's system
• see Direct Messaging for a discussion of ServiceRequest.status and the state machine

.intent

• populate with the fixed value: "proposal"

.category

• see note on terminology binding in profile

.code

• eREFERRAL USAGE:
  • the meaning of this field is to be used in conjunction with ServiceRequest.performer which points to a HealthCareservice,
  • .code further specifies the service, for example code could be a specific procedure under the specificed HealthcareService (e.g., HealthcareService = Orthopaedic Surgeon, code=Knee Surgery).
  • 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.

.subject

• identifies the patient being referred to the service provider
• SHALL be populated with a reference to a Patient resource
• if the ServiceRequest is being transmitted via messaging, the referenced Patient resource SHALL be included in the message as a Bundle.entry

.authoredOn

• FOR EREFERRAL USAGE: .authoredOn is the submission time of the sending system
• note: if this element corresponds to the dateTime the author "signed" the request, it could be populated with a time before the message was actually submitted
• recommentation: to track the time that a ServiceRequest message was submitted to the performer, Task.authoredOn will contain the time the ServiceRequest was received and the Task (perform-request) was created

.requester

• identifies the person who requested the service
• SHALL be populated with a reference to a PractitionerRole resource or, for self-referrals, a Patient resource
• if the ServiceRequest is being transmitted via messaging, the referenced resource SHALL be included in the message as a Bundle.entry

.performer

• identifies the requested service or service provider
• populate with a reference to a HealthcareService for services, or a PractitionerRole for clinicians
• IMPORTANT if the ServiceRequest is being transmitted via messaging, this element SHALL always reference a resource known to the recipient of the message, therefore this resource is not expected to be included as a Bundle.entry when transmitting a ServiceRequest to a service provider
• see business rules for more information

.supportingInfo

• used to associate supporting information in the patient's record with a ServiceRequest
• MAY be populated with references to AllergyIntolerance, Condition, Consent, QuestionnaireResponse, or other FHIR resources in the future to associate structured information with a ServiceRequest
• MAY be populated with references to DocumentReference to associate binary attachments with a ServiceRequest
• if the ServiceRequest is being transmitted via messaging, any resource referenced here SHALL be included in messages from the requester to the performer as a Bundle.entry

.note

• used to communicate information that cannot be referenced in supportingInfo with a ServiceRequest

• MAY be used when the referral source system has a custom data capture form with fields are not mapped to a resource (e.g., Food preference, home visit risk factors, etc...).

• if note.author and note.time are not populated, these SHOULD be assumed to be the requester and authoredOn respectively (this is expected to be the normal use case)

• an Organization MAY be referenced as the note.author when there's no need for specific attribution as to who made the comment.

• FOR EREFERRAL USAGE:

• note is used to include additional information in the referral that is not captured by an existing resource or in a DocumentReference. This is often used when the sending application has a custom data capture form with fields are not mapped to a resource (e.g., Food preference, home visit risk factors, etc...).

• For systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information.

• Annotations SHOULD NOT be used to communicate "modifying" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible).