How to Integrate Bahmni with Fuji CR
Understand how Bahmni can be integrated in a simple Radiology workflow
The Plot
In the beginning of this year Jan Swasthya Sahyog (JSS) decided to switch to a digital radiology system from an analog system they had been using for many years. They also wanted it to be integrated with Bahmni EMR which is being used in JSS for last 2 years.
The ask from the doctors was simple — that digital X-Rays taken by the new machine be associated with patient records in Bahmni. This will enable the doctors to view the X-Rays easily within Bahmni EMR.
After their own research and consulting with the Bahmni team, the team at JSS decided to move ahead with Fuji as a vendor to provide a Computed Radiography (CR) machine.
Being on-site at JSS, I took up the job of doing the needed integration from Bahmni side. I was doing this type of integration for the first time and it took me some time to achieve it. Partly it was also because the knowledge of all the functionalities required to achieve this integration was distributed amongst different Fuji engineers belonging to different departments (hardware/modality, software/PACS) who would appear in the scene one-by-one as we encountered various issues.
In the end, however, we were able to achieve this by using a free open-source PACS software, dcm4chee, the protagonist of the plot ;-). The level of automation that we achieved was unseen by the Fuji engineers involved! In the new setup, only a few clicks by the doctor to place the order and to view the results are needed, and no manual entry of patient and X-Ray details are required by the X-Ray technician. The ability to see the digital X-Rays on their iPads and not requiring to go to any fixed stations was better than the expectations of providers at JSS.
Depending upon the functionalities and services provided, a proprietary PACS may cost anywhere from 50k INR to 15 lakhs INR. Since, we used an open source free PACS, we definitely saved 50k INR in expenses, if not more.
In retrospect, just like how the problem statement was simple, even the solution doesn’t look that complex.
Disclaimer
Fuji is one of the many brands available in the market. This post by no means attempts to endorse Fuji. Its presence is merely factual.
The movie
Watch this video to see how it works in reality.
Demystification begins
Now, how was all this achieved?
For anyone who is unfamiliar with this realm, there are a whole new set of terminologies, and a mix of different hardware and software components, which makes the business of integration feel rather complex. When in reality, if achieving integration with the existing components is just the goal, it is fairly simple once you understand the jargon.
There is a lot of material available on the internet with regards to PACS integration. Here, I will try to outline the key concepts at one place which I had required to understand for the purpose of this integration:
HL7
HL7 is a set of international standards for transfer of clinical and administrative data between software applications used by various healthcare providers. For the sake of this integration, we would only be interested in HL7 order (ORM) messages needed to place radiology orders from Bahmni. There are different versions of HL7 standards available (2.x, 3.x, FHIR) and communication between applications may be limited by the compatibility of these versions.
A sample HL7 ORM message :
MSH|^~\&||BahmniEMR^BahmniEMR|||2015093018||ORM^O01|144361629214955435|P|2.5
PID|||GAN225313||test^suresh||19820929000000+0530|M
ORC|NW|ORD-554356|ORD-554356|||||||^^BahmniEMR||d390d057-ec33–45c1–8342–9e23d706aa4d^^Mangal Rastogi
OBR||||1234^Chest1ViewDICOM
Digital Imaging and Communications in Medicine (DICOM) is a standard for handling, storing, printing, and transmitting digital medical images and report data. All modern medical imaging equipment (aka Imaging Modalities) like X-Rays, Ultrasounds, CT (Computed Tomography), and MRI (Magnetic Resonance Imaging) support DICOM and use it extensively.
These equipments and other devices like workstation, server,etc exchanging data using DICOM are often referred to as DICOM nodes connected in a DICOM network.
DICOM standard specifies different DICOM services. The most frequently used and implemented services are storage, storage commitment, query/retrieve, modality worklist, modality performed procedure step and print.
The node implementing a service is referred to as Service Class Provider (SCP) and the node using the service is referred to as Service Class User (SCU). A typical example of SCP is a PACS server which provides storage commitment service to SCUs like modalities which send DICOM images for storage to PACS server.
A SCP-SCU pair can communicate with each other using each other’s AE Title, IP address (or host) and port, all configurable.
Each vendor providing a DICOM compliant device is required to provide a DICOM conformance statement with the device. A DICOM conformance statement is a document describing which DICOM services the device implements. It also includes some details about the specifics of implementation. Connectivity between two DICOM nodes can be evaluated ahead of time by looking at these statements from the vendors.
PACS
A Picture Archiving and Communication System (PACS) is effectively a set of DICOM services required for storage and convenient access to DICOM images from multiple modalities (source machine types). Most modality vendors provide a PACS software for a price. It could also be custom built from some other software vendor. The pricing may vary based on the services packaged with the PACS.
Some examples are Synapse by Fuji, Imagesuite by Carestream. There are also good open-source and/or freely available PACS like dcm4chee (the one we used).
CR
Computed Radiography (CR) is a cost-effective mid-way solution to having digital X-Rays as compared to a full fledged Digital Radiography (DR) system. Most of the sites operating in low-resource settings will prefer to go via the CR route to digitise X-Rays.
This simple and short video I found on YouTube explains it in a nutshell.
The X-Ray is taken actually on an X-Ray machine and then a cassette is inserted into the CR machine to digitise it.
If a CR is being used then from an EMR or PACS integration point of view, the CR and specifically the CR console is the interface that we need to focus on and not the X-Ray machine.
Articles on wikipedia are a good starting point to know more on these topics.
The making
Now that we have understood the basics, here are the Steps to get the integration setup.
1. Choosing a PACS
In this setup, a PACS is required for 3 main services
- HL7 server to listen to ORM messages sent by Bahmni and create worklist items.
- DICOM storage and web enabled access to DICOM images.
- Integration with a webviewer for DICOM images.
JSS wasn’t using any PACS currently. We decided to use dcm4chee, an open source freely available JAVA implementation of DICOM services.
Reference: dcm4chee DICOM conformance statement
2. Choosing a CR
Cost of procurement, services and support in the region are the basic parameters based on which a hospital usually decides which vendor to purchase a CR from. Rightly so, since more or less, all CRs provide similar basic functionalities for the job. Additionally we looked at the DICOM conformance statement and talked to the sales and support personnel to understand whether the CR provides the functionality needed for the integration.
Fuji CR DICOM conformance statement .
3. Setup modality in network
The CR setup consists of 3 equipments
- A digitiser
- A printer
- QC workstation — a desktop machine with modality software installed.
In our setup, what Bahmni really needs to talk to is the QC workstation machine (via the PACS).
So the QC workstation is to be connected in the same subnet as the PACS and assigned IP address such that the PACS and the QC workstation are able to communicate with each other.
The digitiser, the printer and the QC workstation can stay in a separate subnet with the workstation being part of both subnets.
4. Setup dcm4chee
Depending upon the resource availability (new hardware vs disk/CPU on existing hardware), you may choose to setup dcm4chee either on the same machine as your Bahmni services or a separate machine. Separate hardware is usually a good idea. But, with our constraints on hardware, we chose to set it up on the same machine.
Installation
Bahmni wiki has a page on dcm4chee installation.
dcm4chee converts the ORM messages received from Bahmni (pacs-integration service) into worklist items that can be seen on the modality worklist.
We need to setup the modality as an application entity with appropriate issuer of patient ID, otherwise duplicate patient might get created in dcm4chee. The modality in this case makes two types of requests, one for the worklist items and one for sending DICOM images.
The defaults in case of Bahmni and Fuji integration will be:
AE Title : CL-SCU
Port : 104
Issuer of Patient ID : BahmniEMR (same value as the one mentioned in ORM message or orm2dcm_bahmni.xsl)
5. Setup pacs-integration
This Bahmni service converts the orders placed in EMR into HL7 ORM messages that are sent to an HL7 server. In our setup the HL7 server is running in dcm4chee.
In pacs-integration database appropriate AE Title, IP address and port of dcm4chee will have to be set. DCM4CHEE and 2575 are the default AE Title and port of dcm4chee installation that comes with Bahmni.
Installation
Bahmni wiki has a page to guide setting up pacs-integration.
6. Setup modality
We worked with Fuji support technicians to setup the communication between modality and dcm4chee PACS.
Below are the main steps that were done:
- Enable modality to send images to PACS
This would basically mean configuring a network node in modality with AE Title, IP address and port of dcm4chee. The default AE Title and port for Bahmni dcm4chee installation dicom storage service are dcm4chee and 11112 respectively.
2. Enable network worklist feature in the modality software
The vendor technician should be able to do this. The worklist created in dcm4chee would get synced with modality and show up in network worklist on the X-Ray technician’s console.
3. Setup X-Ray menu names and codes in modality
The modality would come with a pre-set list. You can change the names as per the conventions used at your facility and understood by the X-Ray technician. We reduced the preset list to a shorter simpler one used at JSS.
Setting up codes against each X-Ray is important as this would help in auto-selecting the X-Ray name when the order arrives at X-Ray technician’s console. The codes would be setup in Bahmni EMR and sent in radiology order.
7. Setup in OpenMRS
- Create radiology concepts in OpenMRS.
2. Add all the radiology concepts to a concept set Radiology Orders.
3. Set concept class to order type mapping.
4. Setup reference terms and map them to concepts created in step 1.
Refer to Bahmni wiki here and here.
Steps 1, 2 & 4 can be done easily using CSV upload functionality in Bahmni.
This is how a concept after setting up in openMRS would look like:
8. Setup in Bahmni
- Setup the orders tab
Bahmni wiki here explains how to do it. - Ensure that all the users/roles who are supposed to place radiology orders are given the necessary privilege to access the orders tab and place orders.
This has been one of the most used and appreciated functionality at JSS.
I hope this post is useful in understanding and setting up Digital radiology with Bahmni in your facility. If you have more questions, post comments here, or on Bahmni OpenMRS Talk forum.
Disclaimer: The views and opinions expressed by the author are personal to the author and do not necessarily reflect the positions of ThoughtWorks.
