Stream: implementers
Topic: Chickens and Eggs (Requests and Specimens)
Colin E. (Feb 09 2021 at 12:27):
As I understand it the general pattern in FHIR is that resources created later in time are expected to refer to resources that were created earlier in time. In principle that makes sense, it's hard to make a "forward reference" to something that doesn't exist yet.
In Pathology requesting we have a need to create a test request (*ServiceRequest *in STU3 or *ProcedureRequest in v4) that will typically then trigger the requirement for a Sample to be taken (Specimen *in FHIR). The Specimen comes after the ServiceRequest in sequence, so the former should contain a reference to the latter.
If this is all happening in a single close-coupled IT environment, it's easy to see how the relevant resources can all spring into existence almost simultaneously, and the IDs cross-referenced. However in the general case the Specimen-taking could be done in a separate location and IT system (e.g. a Phlebotomy clinic), so this requires sufficient information to be passed-forward from the request to be able to link the Specimen to the ServiceRequest.
Note we are working in a messaging environment, so I'm not sure we can assume RESTful queries are available to join things up in subsequent steps, even though that might simplify things. This sounds like a basic pattern that will have already been worked out, but I haven't found it spelled out int the docs, or by searching the forum. It seems like the answer would be-
1) Create the test request for N items in the requesting system
2.1) Create N ServiceRequest resources to be sent to the Lab (as ServiceRequest is restricted to a single orderable item per request)
2.2a) Create (some number M potentially smaller than N) of resources that are ServiceRequests for the collection of the individual samples to be sent to the location that will collect the samples. Or-
2.2b) Create a single Appointment Resource for the patient attending the sample collection service, and bundle the ServiceRequests for the samples in the same message? (this assumes there is a fixed appointment for sample collection, rather than an open ended "drop in centre" type Phlebotomy clinic)
Whatever option is used for step (2) above, the requests to the specimen collection point need to contain enough information (e.g. the ServiceRequest Identifier(s) for the corresponding test). Is there a standard pattern for passing this kind of reference information around? For example one could embed a copy of the complete *ServiceRequest *for the test inside the SeriviceRequest for the sample, but that sounds potentially very wasteful in terms of message size, and raises questions about how much patient data is included, and whether it is strictly necessary.
René Spronk (Feb 09 2021 at 13:23):
In my view, some system knows of, or receives, the N ServiceRequests, and probably a set of N Tasks (without the Task resource, order management will be tricky to support). The system knows how to 'translate' those orders into 'what specimen to draw, in what quantity', so it can create a series of ServiceRequests (each 'basedOn' 0..* of the N ServiceRequests mentioned above). The system that 'translates' the orders into specimen orders has all the information (inclusive of IDs) at hand.
Colin E. (Feb 09 2021 at 16:11):
Thanks René. The point about the intermediate system that understands the complexities of mapping tests to samples makes a lot of sense. I'm not so clear about the use of the Task resources though. Is a Task more appropriate than a second ServiceRequest (per Test) for the intermediate job of sorting out the specimens because that step is likely to be an automated process not a human one?
Lloyd McKenzie (Feb 09 2021 at 16:24):
Task allows you to manage the step-by-step tracking of what happens. ServiceRequest is more about the authorization. Tasks can exist in a hierarchy of components. ServiceRequests can only exist in relationship of one ServiceRequest fulfills another ServiceRequest, but there's no notion of 'component'.
René Spronk (Feb 09 2021 at 18:06):
The first video on http://www.ringholm.com/column/FHIR_HL7_IHE_XDS_year_in_review.htm may be helpful to demonstrate the use of Task in a lab ordercomms scenario.
Last updated: Apr 12 2022 at 19:14 UTC
