Initial Discussion about Support Laboratory Data Exchange with FHIR

Tags: #<Tag:0x00007f01b5c507e8> #<Tag:0x00007f01b5c506f8>

Hi devs:

After I research more about the project, I got few ideas to implement the project. @judy @harsha89 @surangak: I have few questions to be discuss.

  1. As I read about the DICOM standard: “it’s using as a standard for handling, storing, printing, and transmitting information in medical imaging”. Also as mentioned in Wikipedia, I guess OpenMRS created Radiology Module with dcm4chee as a requirement for implementing HL7 standards. As mentioned in diagnostic report resource structure, imagingStudy, image () and presentedForm all are end up with attachment. There are other methods to store image, audio and video – attachment can be used to store any data that has a mime type. So, is it necessary to use DICOM standards? Can’t we store some images such as X-ray, CT, MR, ultrasound without using DICOM?

  2. As I understood, Radiology Module is implemented for handling “Radiology Scheduled Workflow”. Correct me if I’m wrong! :confused: Also http://hl7-fhir.github.io/diagnosticreport.html mentioned that “The DiagnosticReport resource is not intended to support cumulative result presentation (tabular presentation of past and present results in the resource). The DiagnosticReport resource does not yet provide full support for detailed structured reports of sequencing; this is planned for a future release.” So, if we are going to use DICOM standard then I think it’s better to decouple the DICOM standard from the Radiology module and use it in FHIR module? (which means with using DICOM lib directly, such as dcm4che2 DICOM Toolkit. Or any other idea about that? (I don’t know whether Radiology module has a generic interface to satisfy FHIR module needs. In other way, FHIR module has to depend on another module. May be this idea will add additional work on the project.) :worried:

  3. Are we going to concern only about images? Do we have to concern about audio and video as well?

  4. What are the “text” and “contained” fields in this example? Those are not mentioned in the diagnostic report structure. :sweat:

Thank you in advance !. :coffee:

1 Like

Thanks @milan, let’s get this discussion on the road :smile:

  1. Our project title is for supporting Lab data exchange, but i’m a bit concerned what our official OpenMRS process for managing lab data is… Some folks use tools like OpenELIS, others use the OpenMRS simple Lab data module. Does @judy have an opinion as to our scope?

  2. Regarding the storage of DICOM images, I’d rather we give people a list of options. You’ll be working against the OpenMRS core (latest). Does the OpenMRS Radiology module support the core? I don’t know. And plus, what if other people don’t want to use that module? If a DICOM standard image needs to be persisted, but the user specifically doesn’t want to use the Radiology module, we should probably let them use the complex obs feature. I also do think that any format the the radiology module doesn’t support should be persisted using complex obs - so basically, videos and audio should be complex obs.

Have you been able to find any good sample FHIR resources using the demo sites?

This is also a question to @burke, I think. How should OpenMRS manage lab data? For our work on FHIR, should we support the simple lab module and say that lab data belongs inside OpenMRS? Or should we simply say that lab data belongs elsewhere, like OpenELIS, and wash our hands?

1 Like

I think that the OpenMRS Simple Lab Data module you mentioned here is this one (not Laboratory module). Is there any module which uses tools like OpenELIS? (I couldn’t find anything related other than this doc).

Yes, It’s important to know what @judy think about it.

After reading you answer, I have to implement this project in a generic way to switch between storing mechanism such as DICOM standards and Complex Obs support. If it’s the case, then I suggest to start implement using Complex Obs support.

Radiology Module mentioned that “In November 2013, it was determined that this module broke the Spring binding mechanism.” Thus we have to continue with Radiology Module with dcm4chee. @harsha89 said that we are going to use Platform version 1.9.8 with FHIR module. And the module also mentioned that it’s compatible with 1.9.x versions and I also tried it with Platform 1.9.8 version as well.

Did you mean that Complex Obs feature is using DICOM standard for storing images? Correct me if I’m wrong.

Which means we are supposed to implement audio and video formats as well.

This url you provided showing this message (not any useful content). I couldn’t find any example for audio and video formats. Thus I don’t understand about how to upload and download contents. I think other link, also showing examples similar to FHIR diagnostic resource examples.

Thank you in advance!

Here is a brief summary of the discussion that we had so far with @surangak @harsha89 and @judy:

The main issue that should address first was mapping between FHIR Diagnostic Report and OpenMRS. There isn’t table or schema in OpenMRS which is directly mapping to the FHIR Diagnostic Report. But it seems to be Obs API can use to store most of data in Diagnostic Report and need to research about how should the mapping done.

Another problem is how to store complex data objects such as Images, Videos and Audios. If the user need to store in DICOM format, as @surangak suggested it’s better to provide as a option in module configuration. So we can use Radiology module with dcm4chee and Complex Obs Support to store resources. Before going to decide about which tools/modules are used to implement the project, it’s better to investigate what are mostly used tools by the community.

TODO List:

  • Try Radiology Module, Simple Lab Entry Module and Complex Obs Support
  • Compare FHIR Diagnostic Report with OpenMRS core and identify how each other can remaps
  • A survey on what are the most popular tools used by the community to handle Lab data
1 Like

Hi @burke, question to you on how we should manage lab data:

For OpenMRS, should we say that its out of scope for us, and belongs to some other lab system that we need to interact with? Or should we be using the Simple lab module?

My thought is that we allow users to configure which option they want to support via handlers. So basically, we’ll have one handler if the user wants to forward FHIR Lab reports to a different system. But if they want to use simple lab module, they’ll use the hander which persists lab data in this module.

How does that sound?

I just had a discussion with @burke@milan, we have good news for you.

For working with lab data, OpenMRS implementers sometimes use OpenELIS or other tools. But these tools only manage the workflows for lab data testing. We don’t care about these workflows; we care only about the data. So basically, it doesn’t matter because no matter what tools they use, they always persist lab data as observations in OpenMRS.

So, I propose the following workflow:

  1. Diagnostic report sent to FHIR module
  2. FHIR module identifies report as a lab report
  3. FHIR module stores lab data as multiple obs under an Encounter.

We can identify a diagnostic report as a lab report using the ServiceCategory field.

For labs, there would be only one way to store the data (in OpenMRS). But for other types of reports, there may be multiple options. And so, for workflow #3 above, I’d recommend that you implement a handler process. Basically, in the event that there’s multiple ways to persist data, users will write handlers to do what they want.

Is this same as what I mentioned in the following post?

Did you mean that we are not going to care about Simple Lab Module or Radiology Module any more? Note: The latest Simple Lab Entry Module is compatible with Platform version 1.6.0. :confused:

So I think, I have to figure out how to mapping FHIR DiagnosticReport with OpenMRS Obs and Encounter, is it?

Are we going to use Complex Obs Support in order to store data?

I didn’t understand what you exactly meant here. Anyway I got a hint about the implementation. Basically, storing lab data will be one of option in the handler process.

@surangak, @harsha89, @judy, It would be helpful, if you can give me some clarification about my doubts!

Sorry, let me try to re-state.

The simple lab entry module and OpenELIS basically manage workflows for generating lab reports. They don’t introduce any new tables or processes for storing lab data. But both of them store the ultimate lab data in obs. Not as complex obs, but as discrete obs. For example, “CD4 cell count” will be one concept, and there will be a value stored for it using an Obs. So ultimately, while other implementations may use different tools, the lab data makes it into OpenMRS db.

So we don’t need to worry about wether an implementation uses OpenELIS or simple lab.

However, this doesn’t apply to the radiology work. We need to figure out how the Radiology module stores data, and use the same approach. For labs, the approved process is to store lab data in Obs table, and thats what we do.

Perhaps we can have a quick conversation around the use of handlers when you’re free? :smile:

@milan please invite me also when you have the discussion.

Shall we create some test Diagnostic Resource in FHIR module and see how we can handle things? Because we don’t have sample which implement how HAPI support to retrieve images and complex data through post request to HAPI FHIR Providers. While you researching that, let’s start things on that side too.

@surangak what do you think?

I tried to say here, Complex Data store in Obs API. Please see Technical Workflow in Complex Obs Support and Obs API.

Are you trying to say that, “The Laboratory data will be store using Obs in OpenMRS. Then the Radiology data will be store using Radiology module. In that way, we have to identify ways to each case on the categories which are mentioned in Diagnostic Services” ?

Yes, please!. :tired_face: Anyway, I posted what I need to ask. Ping me when you are free.

Great! :grinning: