Fhir Diagnostic Report: Implementation and some Recommendations

As a part of the LabLite feature in Bahmni, lab reports need to be uploaded against lab tests of a patient. Using fhir Diagnostic Report resource is ideal in this case. The report includes clinical context such as requesting and provider information, and some mix of atomic results, images, textual and coded interpretations and formatted representation of diagnostic reports. http://hl7.org/fhir/R4/diagnosticreport.html

There are different scenarios where Diagnostic Report could be used effectively:

  • Fulfilment of an order done from EMR - either through OpenELIS (or Senaite in future)
  • Referred out tests
  • In collaboration with external lab services - e.g. Clinic/Hospital only does sample collection, results are uploaded by external entities
  • Patients bringing in reports (maybe separately communicated by Doctor) - i.e uploading without a ServiceRequest/Order

Currently we are working on following use cases:

  1. Uploading a report against a single test
  2. Uploading a report against all tests in a panel
  3. View all reports uploaded for a patient
  4. Uploading a report against an order (ServiceRequest)
  5. Uploading a report for multiple tests.
  6. Upload multiple documents for different tests in a panel
  7. Capturing report context (When and Where the lab test is conducted)


  • Override the service in the extension module and extend the translator to save results. GitHub - Bahmni/openmrs-module-fhir2Extension
  • Store diagnostic report context like subject, encounter, issued date in fhir_diagnostic_report table.
  • Store uploaded report details like url of the file, lab notes in EMR api obs structure.
  • Store relationship between diagnostic report and obs in fhir_diagnostic_report_results table.

During this course, we recommend some of the extensions in the data model and in provider:

  1. To store basedOn field of diagnosticReport resource.
    Recommended Change: Introducing a new nullable column for serviceRequest (e.g order_id) in fhir_diagnostic_report. This column will have reference to the order against which report is uploaded

  2. To store organisation (location_id) when a report is performed by an external laboratory/system. Recommended Change: There could be one more nullable column location_id be introduced in fhir_diagnostic_report_performers table to store details of the external system who has performed the test

  3. To store attachment of DiagnosticReport resource
    Recommended Change: One table to save attachment details like (url, data, contentType, language, etc.): Datatypes - FHIR v4.0.1 Another join table fhir_diagnostic_report_attachments to hold references of attachment and fhir_diagnostic_report.

  4. A new accessControl for fhir_diagnostic_report resource.

  5. Bundle Diagnostic Report Resource Overload create function in DiagnosticReport resource to accept Bundle Diagnostic Report resource. Also we need to come up with a generic code to parse a bundle resource. This would be useful in many scenarios to save multiple network calls:

  • A lab is saving diagnostic report resource for multiple patients, encounters
  • Can send resources which are not part of the server like encounter details, observation results.
  • Saving multiple document for the panel

cc: @angshuonline @ibacher @pmanko @grace |


drawing attention of @janflowers @ccwhite23 @dkayiwa

Update: Priyanka and Angshu brought this topic forward on the FHIR Squad call today, and we discussed this together with Ian, Piotr, and Daniel present. Agreement was reached on this approach as described above.

Next Steps: Priyanka and Angshu to work on this approach, and will share updates in this thread, and share on the FHIR squad call as needed.

Thank you both!!

We have broken down the requirements into bunch of stories. How do you want us to work on this? should we just create them as issues on JIRA? or do you want to go through first?

A few bits of memory on this that occurred to me the other day

So, the initial reason that the baseOn field wasnā€™t implemented in terms of order was that some OpenMRS instances donā€™t use orders at all, but instead use obs groups to collect similar kinds of information. If this is something done exclusively in the fhir2extension module, then I guess do what you want (though itā€™s not great to reuse the existing table in that case), but thatā€™s why itā€™s implemented the way it was.

In general, I agree that some locations are the closest thing we have to organisations in FHIR, but not all of them are. Is there a way we can distinguish ā€œLocation that should be an Organisationā€ from ā€œLocation that shouldnā€™t be an organisationā€, since, e.g., most wards should (probably not) be treated as organisations, though they may be referenced in other ways.

We should be a little careful here. Some of the text implies that data and url are intended to be somewhat mutually exclusive, i.e., if you present the data (base64 encoded version of the binary data inline), likely the url isnā€™t needed (because the URL for the FHIR resource gives you the data) and vice-versa. Iā€™d be hesitant to actually use the data field here as itā€™s likely to greatly increase the amount of traffic needed to, e.g., load a series of diagnostic reports. Similarly, Iā€™m a little hesitant about introducing a table to get the data thatā€™s disconnected from the standard set of obs associated with a patient, if at all possible.

Where is the work being done? Anything done in the FHIR2 module should be a ticket in JIRA as a starting point.

I guess we can use tags to distinguish them

1 Like

We can distinguish org locations as ā€˜visit locationsā€™ while clinics/wards could be just login locations.

Thatā€™s sensible. I think itā€™s just a matter of making sure we have a convention that everyone will be happy with. E.g., I donā€™t know if ā€œvisit locationsā€ is the best name for things if weā€™re talking about, e.g. a diagnostic report thatā€™s generated from a lab not co-located with the clinic (which Iā€™d imagine might be a use-case for the LabLite feature and is certainly a use-case for, e.g., UWā€™s national lab setups).