How to Associate a Specimen with a Procedure

Suppose I wanted to request a blood draw, so I create a ProcedureRequest. Following standard FHIR Workflow Semantics, ProcedureRequest is a request resource. When the blood draw is completed, a Procedure (event) resource is created to record the results. The principal result is the creation of a Specimen resource for the blood that was drawn. Oddly, while ProcedureRequest can be associated with 0…* Specimen, the Procedure has no such relationship. This seems backwards… since the Specimen(s) are created as a result of the conducting the Procedure, I need a way to associate the Specimen(s) collected with the Procedure.

Any clue why the standard hangs Specimens off ProcedureRequest and not Procedure?

Of course, since the Procedure is basedOn the ProcedureRequest, I could tie the Specimen(s) to the ProcedureRequest and locate them from the Procedure by navigating through basedOn. But this feels clumsy.

Anyone have a better suggestion?

Currently there is no direct link from the Specimen to the Procedure. Feel free to create a tracker on Specimen.

In the meantime you will need to create an extension

Thank you for responding, Eric.
Can you (or someone) point me at the process for creating “a tracker”?

At the bottom of every page in the FHIR spec, there’s a link called “Propose a Change”. If you click on that, there’s a one-time registration process that includes a manual check to ensure you’re a real human. After that, you can submit change requests any time you find an issue, whether that’s a typo, a clarification or a missing feature.

Hi Lloyd, I really appreciate your response. I’m quite new to FHIR and still finding my way around, so I value your willingness to take the time to answer such a basic question. I actually had discovered the “Propose a Change” link, submitted my registration request, and received a confirmation the request was successfully submitted and awaiting approval. But it’s been a couple of days, with no word on approval, so I began to wonder if there were another way. Hopefully, the account approval will come through in the next few days.

At least now I know I’m engaged with the right process for submitting enhancement requests.


Approvals happen in periods of weeks or months, not days. Change proposals are reviewed on work-group calls that happen with varying frequency depending on the work group. And not all calls are devoted to considering change requests. Once approved, there will be a further wait before any agreed change will make it into the continuous integration build. The official release containing changes approved since the last release is slated to be published in December of this year. If you need something sooner than that, you’ll need to use an extension for now.

Hi Lloyd… Sure. I’m very familiar with software change management processes and have no expectation that my software enhancement request would be approved at all, much less in days. The approval process I was referring to was the process for getting my Forge account approved so that I could then submit the software change proposal.

BTW… upon further investigation, I’m now more satisfied with the current FHIR solution and am therefore not even sure I will need to log an enhancement request. In case others have the same question, I discovered there is an (indirect) path from the Procedure resource to the Specimen resource, BOTH via the ProcedureRequest the Procedure was based on AND via a DiagnosticReport associated with the Procedure resource.

A few more details:

  1. In looking at the JSON for some of the FHIR examples (e.g., DiagnosticReport example of F202 bloodculture, I see that the ProcedureRequest is actually contained in the DiagnosticReport’s body. So getting the Specimen info from the DiagnosticReport seems less clumsy than I originally feared. (This particular example doesn’t include a Specimen attached to the ProcedureRequest… but if it were, it seems it would also be present in the DiagnosticReport’s JSON).

  2. The FHIR design is trying to support both cases where the specimen exists prior to a ProcedureRequest asking to have it analyzed and also cases where the specimen is created as a result of performing the requested procedure. In the former case, the ProcedureRequest includes a Reference to the Specimen. In the latter case (which is the case I was originally concerned about), the Specimen has a Reference back to the ProcedureRequest, indicating this is why the specimen was created.

  3. While the Procedure resource doesn’t include a reference to Specimen, it does include a reference to DiagnosticReport which includes a reference to the Specimen it was based on.

Hi Steve,

The HQ staff member who normally handles this is on holiday. I’ve gone in and activated you. Sorry for the delay and thanks for yelling :slight_smile:

  1. In some of the examples, contained is used appropriately (because the resource doesn’t have enough information to stand alone) and sometimes it’s used inappropriately (because the example author was too lazy to create separate instances and link them). In this case, because there’s no date or identifier information, contained is probably appropriate - you wouldn’t be able to distinguish this order from any other.

  2. Yes

  3. Yes

1 Like

I’m logged in to HL7GForge! Many thanks for the personalized attention!