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.
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:
Uploading a report against a single test
Uploading a report against all tests in a panel
View all reports uploaded for a patient
Uploading a report against an order (ServiceRequest)
Uploading a report for multiple tests.
Upload multiple documents for different tests in a panel
Capturing report context (When and Where the lab test is conducted)
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:
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
To store organisation (location_id) when a report is performed by an external laboratory/system.
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
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.
A new accessControl for fhir_diagnostic_report resource.
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.
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.
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.
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).