A Patient visits an orthopedic surgeon after suffering shoulder pain for a number of months.
The surgeon examines him and refers him for an MRI.
She does this by filling out a form in the hospital’s CRM system. As soon as it’s filled out, an order for the MRI is created.
In HL7 this might be an ORM message. In FHIR it’s usually a ServiceRequest resource.
Here are some of the key pieces of information captured in a ServiceRequest:
- code
What is being requested? A CodeableConcept containing a SNOMED or other code for a shoulder MRI. - subject
Who is it being performed on? A reference link to the Patient. - encounter
Which Encounter led to the order? Another reference link. - occurrence
When is the MRI to take place? - requester
Who asked for the scan? A reference link back to our surgeon. - performer
Who or what is carrying out the scan? This may be a combination of clinic staff (Practitioners) and Devices (the MRI machine itself). - locationReference
Where will it take place? - reasonCode & reasonReference
Why was the order placed? Maybe a SNOMED code for a particular symptom or a reference link to a Condition resource. - insurance
Enough said. - bodySite
Which part of the body is to be looked at?
There’s more, but the above illustrates the amount of relevant information that can be stored or referenced from a single ServiceRequest.
Not all of this will be populated when the resource is created. Information such as the location or the date and time of the scan may come later.
A single ServiceRequest might trigger the creation of a number of Task resources, each one tracking the progress of a different — but related — activity.
- The MRI itself
- The radiologist’s report
- A notification sent to the patient’s GP
- A follow up from the orthopedic surgeon
A ServiceRequest resource is often the umbrella that covers a number of interconnected activities.
It’s the starting point for getting something done.
More about ServiceRequest: http://hl7.org/fhir/R4/servicerequest.html
---