Tracking lab samples and results using Concepts

PIH has a requirement to track a lab test including the need for it to be ordered, if the sample was sent to a reference/outside lab, etc. I would like to create an array to capture the lab flow:

  1. Lab test name (coded)
  2. Need for testing (Y/N)
  3. Sample (coded)
  4. Sample sent to lab (Y/N)
  5. Name of lab (text)
  6. Test performed (datetime)
  7. Test resulted (datetime)
  8. Test results reported (datetime)

@ibacher are there any FHIR resources we should be aware of when modeling this flow and concepts to be used? I was thinking that even if an implementation only wanted to track whether a test was sent and where, they could use this array/set to properly link together the test with its metadata. Ideas?

@ball This was what we were discussing on Thursday.

So, generically in FHIR this would all be handled by a number of different resources, e.g., a sample itself would likely be a FHIR Specimen referenced from the ServiceRequest / order). Whether the sample was sent to the lab would likely be a FHIR Task tied to the specific specimen (which could then have it’s receivedTime updated). Parts of the rest of this are probably parts of the resulting Observation itself, e.g., effectiveDateTime is most likely to represent the time the test was performed. FHIR has an issued field to cover when the results where reported. The test resulted datetime would probably be an extension on the same.

The name of the lab would likely the the “display” value for the organization reference where relevant e.g., the resulting DiagnosticReport, the ServiceRequest and Observation performer, etc.

Admittedly, I’m not sure what the “Need for testing” is capturing.

Someone from PIH (e.g., @ddesimone) could give the official use case, but I would assume “Need for testing” isn’t a property of the specimen or order; rather, it represents decision support/care plan information on whether the selected patient is due for specific testing (e.g., viral load has not been checked within an interval prescribed by care guidelines).

Defer to @ball for the specifics of this use case and certainly defer to others on the modeling of this info. But I can confirm that “need for testing” is something we capture (e.g. Viral Load Routine vs Targeted as @burke was getting at). We’ve captured it as part of the testing construct in our concept dictionary which works well, but that doesn’t mean it needs to be part of the FHIR resource.

a “need for testing” concept was needed recently for pathology. When the clinician performs a procedure (ie. takes a tissue sample), she indicates at the time of the procedure that immunohistochemistry is needed (y/n) for the specimen.

(I can’t think of when you would do this for viral load, but I might be forgetting…)

So it sounds like there is no single FHIR resource which handles the documentation of the entire process of getting an outside lab test performed. I can start by creating an overarching concept which will link together the test name with the relevant meta data and we can then decide what to do when it needs to be converted to FHIR

An additional field was requested: “Date sample sent to lab”

Right… in general FHIR processes will use multiple resources. In very general terms there are resources that document “what was done” (e.g., the lab results) and resources that document “why it was done” (e.g., the orders).

@akanter are you creating a data model for specimens within the concept dictionary?

We already have specimen concepts. This is adding how they are used in terms of the test-specimen process. Sample in the above example was specimen.

Ok. I guess I don’t understand the use case. I would expect lab samples to be handled within a lab system (or lab module) and these attributes as part of the data model. I’m guessing PIH is looking to put these into a comlpex obs as a workaround.

@burke and others…

PIH built, uses, and is enhancing a Lab tracking module for Pathology. This is used at University Hospital in Mirebalais (Haiti) along with a telepathology software application (which is not connected to OpenMRS).

To provide a flavor, there are a few UI enhancements

  • Order pathology form (see form below)
  • Specimen tracking (see list, search, form)
  • Result details (with comments and upload result attachment document)
  • Dashboard widget (see below)



It’s bending my brain to model specimen-level details into patient-level observations. When results are reported, we have obs.accession_number to record a lab’s identifier for the request (which would uniquely tie to the specimen), assuming specimen-levels details would be within the purview of a lab system. When these specimen details are being coerced into observations, where is the accession number for the specimen referred to by this obs group stored? Is it stored in the accession_number of the Sample observation? Or do you also need an “Accession number (text)” as part of your array? :slightly_smiling_face:

I think we probably need the accession number in the array. @ball , is there a link between the OBS and the sample?

PIH deployed Pathology V2 in Haiti over the weekend. In the short term, we are unlikely to rework our new app. No doubt the next version will provide a superior way to model specimen tracking and follow FHIR best-practice.

As for what we currently have in production for pathology tracking:

  • Not using orders
  • Data uses observations including the Specimen number (CIEL:162086) which is text
  • Each specimen is encapsulated by a single encounter: procedures, diagnoses, suspected cancer, urgency, dates of procedure/results, specimen (accession) number, name/phone for clinician to contact with results, attachment (complex obs), specimen sent, etc. Additional data is added along with workflow.
  • We are not using obsgroups

FYI @burke @akanter @cioan