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:

Command 'link' could not render: Object reference not set to an instance of an object.

Derived from: ServiceRequest (R4)

Formal Views of Profile Content

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

Differential View

Command 'tree' could not render: File was not found for ca-on-eReferral-profile-ServiceRequestv10-1

Hybrid View

Command 'tree' could not render: File was not found for ca-on-eReferral-profile-ServiceRequestv10-1

Snapshot View

Command 'tree' could not render: File was not found for ca-on-eReferral-profile-ServiceRequestv10-1

Table View

Command 'table' could not render: File was not found for ca-on-eReferral-profile-ServiceRequestv10-1

JSON View

Command 'json' could not render: File was not found for ca-on-eReferral-profile-ServiceRequestv10-1

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).