{ "resourceType": "StructureDefinition", "url": "http://telus.com/fhir/patientChart/StructureDefinition/profile-service-request", "name": "ServiceRequest", "status": "draft", "date": "2022-08-12T20:30:19.0036288+00:00", "description": "This profile service requisitions for diagnostic tests and imaging, lab requisitions, as well as referrals,", "fhirVersion": "4.0.1", "kind": "resource", "abstract": false, "type": "ServiceRequest", "baseDefinition": "http://hl7.org/fhir/StructureDefinition/ServiceRequest", "derivation": "constraint", "differential": { "element": [ { "id": "ServiceRequest", "path": "ServiceRequest", "comment": "Usage Note: There are two referral use cases: Sending referral in real time to a specialist; and Sending a referral record as recorded in the database for a past event. Referrals can be either internally within a clinic or to an external provider. \r\nUsage Note: This single profile will cover all service requisitions including such items as lab requests, diagnostic imagining, amd referrals. Generally speaking the category and code will be used to distinguish the type of service request." }, { "id": "ServiceRequest.id", "path": "ServiceRequest.id", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.meta", "path": "ServiceRequest.meta", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.meta.lastUpdated", "path": "ServiceRequest.meta.lastUpdated", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.meta.source", "path": "ServiceRequest.meta.source", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.meta.profile", "path": "ServiceRequest.meta.profile", "mustSupport": true }, { "id": "ServiceRequest.text", "path": "ServiceRequest.text", "mustSupport": true }, { "id": "ServiceRequest.text.status", "path": "ServiceRequest.text.status", "mustSupport": true }, { "id": "ServiceRequest.text.div", "path": "ServiceRequest.text.div", "mustSupport": true }, { "id": "ServiceRequest.identifier", "path": "ServiceRequest.identifier", "comment": "Usage Note: This is a stable identifier that is recognized by both sending and receiving applicaitons. This is mandatory for use cases that may be updating a record as this is the key identifier. If it is not present in the EMR this must be generated, and must be unique (eg PSS: combination of the application instance + patient identifier + patient piece transaction id)\r\n\r\nThe 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.", "mustSupport": true }, { "id": "ServiceRequest.identifier.type", "path": "ServiceRequest.identifier.type", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.identifier.type.coding", "path": "ServiceRequest.identifier.type.coding", "min": 1, "max": "1", "mustSupport": true }, { "id": "ServiceRequest.identifier.type.coding.system", "path": "ServiceRequest.identifier.type.coding.system", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.identifier.type.coding.code", "path": "ServiceRequest.identifier.type.coding.code", "min": 1, "fixedCode": "PLAC", "mustSupport": true }, { "id": "ServiceRequest.identifier.system", "path": "ServiceRequest.identifier.system", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.identifier.value", "path": "ServiceRequest.identifier.value", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.basedOn", "path": "ServiceRequest.basedOn", "comment": "Usage Note: Must provide if this is supported and available in the sending EMR\r\nUsage note: MA - If there is a Care plan resource created for a detailed care plan include the reference to the careplan during which this service request was created\r\n\r\nPSS - N/A\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.", "mustSupport": true }, { "id": "ServiceRequest.basedOn.reference", "path": "ServiceRequest.basedOn.reference", "mustSupport": true }, { "id": "ServiceRequest.basedOn.display", "path": "ServiceRequest.basedOn.display", "mustSupport": true }, { "id": "ServiceRequest.requisition", "path": "ServiceRequest.requisition", "comment": "Usage Note: This is used for grouping service requests that are part of the same grouping/service request in the EMR. This may not be supported by all implementation projects but should be considered. This type of identifier likely doesn't exist in the EMR, but can created by the EMR for linking purposes. For referrals there is typically only one service request. \r\n\r\nUsage Note: Not supported by DW; EMRs do not have this identifier. \r\n\r\neReferral Ontario Notes: 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.", "mustSupport": true }, { "id": "ServiceRequest.requisition.system", "path": "ServiceRequest.requisition.system", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.requisition.value", "path": "ServiceRequest.requisition.value", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.status", "path": "ServiceRequest.status", "comment": "Usage note: draft, active, completed or unknown are likely status relevant\r\n\r\nPSS --> FHIR\r\nActive --> active\r\nMore Information Requested --> Active \r\nCompleted --> Completed\r\nCancelled --> revoked\r\nRequest Refused--> revoked\r\nPatient Never Went/Missed Appointment --> on-hold\r\n\r\n\r\nMA --FHIR\r\nActive -- >Active\r\nCompeleted -->completed\r\nDeleted --> entered-in-error\r\n\r\nThe 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 (see [Event Pattern](event.html) for general discussion) or using the [Task](task.html) resource.", "mustSupport": true }, { "id": "ServiceRequest.intent", "path": "ServiceRequest.intent", "comment": "Usage note: Value of \"order\" as the EMRs treat this as an order if it has completed. If it is a request, this should be a \"proposal\", when there is no intent to ensure that this has occurred. ***** confirm this\r\n\r\nDW Usage Note: Will always set a value of \"order\" as it is treated as such in the EMR.\r\nOntario eReferral: Has a fixed value of \"proposal\". \r\n\r\nThis element is labeled as a modifier because the intent alters when and how the resource is actually applicable.", "mustSupport": true }, { "id": "ServiceRequest.category", "path": "ServiceRequest.category", "comment": "Usage Note: The following codes will be supported:\r\n108252007 Laboratory procedure \r\n363679005 Imaging\r\n44383000 Patient referral for consultation\r\n386053000 investigation \r\n\r\nUsage Note: Investigation will cover diagnostic testing, reports. eg EEG, PFT\r\n\r\nOntario eReferral Binding to Infoway code set: https://fhir.infoway-inforoute.ca/ValueSet/interventioncodesubsetcare; over 3000 codes and doesn't make much sense to ues this value set which doe snot include the above codes. We do not need to align with this\r\n\r\nThere 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.", "mustSupport": true }, { "id": "ServiceRequest.category.coding", "path": "ServiceRequest.category.coding", "mustSupport": true }, { "id": "ServiceRequest.category.coding.system", "path": "ServiceRequest.category.coding.system", "mustSupport": true }, { "id": "ServiceRequest.category.coding.code", "path": "ServiceRequest.category.coding.code", "mustSupport": true }, { "id": "ServiceRequest.category.text", "path": "ServiceRequest.category.text", "mustSupport": true }, { "id": "ServiceRequest.priority", "path": "ServiceRequest.priority", "comment": "Usage Note: This will be supported when the EMR can determine this (eg MA can specify a code of urgent). Most EMRs do not support this discretely.\r\n\r\neReferral Ontario - this is a supported data element\r\n\r\nNote that FHIR strings SHALL NOT exceed 1MB in size", "mustSupport": true }, { "id": "ServiceRequest.code", "path": "ServiceRequest.code", "comment": "Usage Note: Coding is not always possible and in these cases text may be used.\r\n\r\nOntario eReferral Note: The meaning of this field is to be used in conjunction with ServiceRequest.performing pointing to a HealthCareservice, and .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).\r\n\r\n\r\nMany 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.", "min": 1, "mustSupport": true }, { "id": "ServiceRequest.code.coding", "path": "ServiceRequest.code.coding", "comment": "Usage Note: Where possible a code must be provided, though it is recognized that this is not always possible .\r\n\r\nCodes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.", "mustSupport": true }, { "id": "ServiceRequest.code.coding.system", "path": "ServiceRequest.code.coding.system", "mustSupport": true }, { "id": "ServiceRequest.code.coding.code", "path": "ServiceRequest.code.coding.code", "mustSupport": true }, { "id": "ServiceRequest.code.text", "path": "ServiceRequest.code.text", "mustSupport": true }, { "id": "ServiceRequest.orderDetail", "path": "ServiceRequest.orderDetail", "comment": "Usage Note: Any further information will be in a referral letter and not discretely tracked in the EMR for exporting. Therefore this need not be supported by sending systems at this point in time.\r\n\r\nAlignment: Ontario eReferral: Supported; code not text\r\n\r\nFor information from the medical record intended to support the delivery of the requested services, use the `supportingInformation` element.", "mustSupport": true }, { "id": "ServiceRequest.subject", "path": "ServiceRequest.subject", "comment": "Usage Note: Only patient will be supported at this time.\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.", "type": [ { "code": "Reference", "targetProfile": [ "http://hl7.org/fhir/StructureDefinition/Patient", "http://hl7.org/fhir/StructureDefinition/Group" ], "aggregation": [ "bundled" ] } ], "mustSupport": true }, { "id": "ServiceRequest.subject.reference", "path": "ServiceRequest.subject.reference", "mustSupport": true }, { "id": "ServiceRequest.subject.display", "path": "ServiceRequest.subject.display", "mustSupport": true }, { "id": "ServiceRequest.encounter", "path": "ServiceRequest.encounter", "mustSupport": true }, { "id": "ServiceRequest.encounter.reference", "path": "ServiceRequest.encounter.reference", "mustSupport": true }, { "id": "ServiceRequest.encounter.display", "path": "ServiceRequest.encounter.display", "mustSupport": true }, { "id": "ServiceRequest.occurrence[x]", "path": "ServiceRequest.occurrence[x]", "comment": "Usage note: When the service is scheduled to take place when available, provided there is a date in the EMR\r\n\r\nAlignment: Ontario eReferral does not support this data element", "mustSupport": true }, { "id": "ServiceRequest.authoredOn", "path": "ServiceRequest.authoredOn", "comment": "Ontario eReferral Note: : authoredOn is the submission time of the sending system", "mustSupport": true }, { "id": "ServiceRequest.requester", "path": "ServiceRequest.requester", "comment": "Usage Note: Populate with the practitioner who requested this service\r\nThis 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.", "type": [ { "code": "Reference", "targetProfile": [ "http://hl7.org/fhir/StructureDefinition/Practitioner", "http://hl7.org/fhir/StructureDefinition/PractitionerRole", "http://hl7.org/fhir/StructureDefinition/Organization" ], "aggregation": [ "bundled" ] } ], "mustSupport": true }, { "id": "ServiceRequest.requester.reference", "path": "ServiceRequest.requester.reference", "mustSupport": true }, { "id": "ServiceRequest.requester.display", "path": "ServiceRequest.requester.display", "mustSupport": true }, { "id": "ServiceRequest.performer", "path": "ServiceRequest.performer", "comment": "Usage: If this is an external request, there is often only a name and will be conveyed as display. For internal requests, it will often be possible to reference a practitioner resource in addition to the display. HealthcareService is not supported at this point in time.\r\n\r\nIf 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](extension-request-performerorder.html). Use CareTeam to represent a group of performers (for example, Practitioner A *and* Practitioner B).", "mustSupport": true }, { "id": "ServiceRequest.performer.reference", "path": "ServiceRequest.performer.reference", "mustSupport": true }, { "id": "ServiceRequest.performer.display", "path": "ServiceRequest.performer.display", "mustSupport": true }, { "id": "ServiceRequest.reasonCode", "path": "ServiceRequest.reasonCode", "comment": "Usage Note: Support when available in the sending EMR. This may be a local code or ICD-9, ICD-10, PIN (MA), SNOMED, ENCODE. As this may not be understood by the receiving application, either text and display is strongly recommended\r\n\r\nMA - may have reason as a code or text\r\n\r\nThis 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 `CodeableConcept.text` element if the data is free (uncoded) text as shown in the [CT Scan example](servicerequest-example-di.html).", "mustSupport": true }, { "id": "ServiceRequest.reasonCode.coding", "path": "ServiceRequest.reasonCode.coding", "mustSupport": true }, { "id": "ServiceRequest.reasonCode.coding.system", "path": "ServiceRequest.reasonCode.coding.system", "mustSupport": true }, { "id": "ServiceRequest.reasonCode.coding.code", "path": "ServiceRequest.reasonCode.coding.code", "mustSupport": true }, { "id": "ServiceRequest.reasonCode.coding.display", "path": "ServiceRequest.reasonCode.coding.display", "mustSupport": true }, { "id": "ServiceRequest.reasonCode.text", "path": "ServiceRequest.reasonCode.text", "mustSupport": true }, { "id": "ServiceRequest.supportingInfo", "path": "ServiceRequest.supportingInfo", "comment": "Use Case: Sending referral record from the DB: In PSS: where there is a pending test, additional data may be available, eg a composition of the Patient Chart data that accompanyed the referral letter if the data is linked to the referral in the EMR. \r\nUse Case - Sending Referral record from DB: A note that a graph of hemoglobin was sent as part of the referral may be included\r\nUse Case: Sending Referral record from DB: This may be a document reference for the attached PDF/letter. This could also be used to attach lab results, observations, previous consult letters, etc. Generally speaking, the allergies, conditions, medications are in the letter and are not discretely linked in the EMR and are therefore not available to include as resources.\r\n\r\nUse Case - Sending Referral to Specialist: This could also be a reference to an image (eg graph of hemoglobin) that is generated at the time of the referral. \r\n\r\nTo represent information about how the services are to be delivered use the `instructions` element.", "mustSupport": true }, { "id": "ServiceRequest.supportingInfo.reference", "path": "ServiceRequest.supportingInfo.reference", "mustSupport": true }, { "id": "ServiceRequest.supportingInfo.display", "path": "ServiceRequest.supportingInfo.display", "mustSupport": true }, { "id": "ServiceRequest.note", "path": "ServiceRequest.note", "comment": "Usage note: Any notes related to the service Request or the updates to the service request as additional note. \r\n\r\nUsage Notes: The EMRs have a detailed section which could be included here.\r\n\r\nFor 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).", "mustSupport": true }, { "id": "ServiceRequest.note.author[x]", "path": "ServiceRequest.note.author[x]", "mustSupport": true }, { "id": "ServiceRequest.note.time", "path": "ServiceRequest.note.time", "mustSupport": true }, { "id": "ServiceRequest.note.text", "path": "ServiceRequest.note.text", "mustSupport": true } ] } }