As institutions start to incorporate their multiple imaging sources into an enterprise solution such asprovided by a Vendor Neutral Archive (VNA), they find that the biggest challenge is dealing with the different workflows used by non-radiology departments, which in many cases must be re-invented. There are many different workflow and integration options, as a matter of fact I have identified more than one hundred different combinations as listed below. Hopefully these will converge to a few popular ones, driven by standardization and vendor support.
The traditional radiology and cardiology workflow has matured and is defined in detail by the IHE SWF (Scheduled Workflow) profile, which recently has been updated to SWF.b to incorporate PIR (Patient Information Reconciliation) and requires the support of a more recent version of HL7, i.e. 2.5.1 (this was optional in the first version). PIR specifies the use of updates and merges for reconciliation such as when using a temporary ID and for “John Doe” cases.
The non-radiology and cardiology enterprise imaging workflows are also known as “Encounter Based Imaging Workflow” in contrast to the traditional “Procedure Based Imaging Workflow” as defined by the SWF/PIR IHE profiles mentioned above. The difference is that there is no order being placed prior to the imaging. Despite the lack of an order, we still need the critical metadata for the images which consists of:
1. Imaging context attributes (body part-acquisition info-patient and/or image orientation)
2. Indexing fields (for retrieval such as patient demographics, study, series and image identifiers)
3. Link(s) to related data (reports, measurements)
4. Department/location/specialty information. This is an issue as some of these acquisition devices (e.g. Ultrasound) can be used for different departments. It is not as easy as having a fixed MRI in radiology; now we have devices that can belong to different departments and used in various locations (OR, ER, patient rooms, etc.)
5. References to connect to patient folder especially for the EMR (patient centric access)
This assumes that the practitioner decides to keep the images, which is not necessarily always the case; a user might choose to discard some or all of the images depending on if they need to be part of the permanent electronic patient record and/or need to be shared with other practitioners.
Assuming we want to archive the images, the first step is to figure out how do we get access to the metadata. There are two different workflows:
1. The user retrieves the meta-data first and then acquires the images
2. The user first acquires the images and then matches them up with the metadata (typically at the same device).
The end-result is the same, the workflow is a little bit different as there needs to be a query made by the practitioner to get the data, which could be as simple as scanning a patient barcode, RFID or doing a search based on the patient’s demographic data.
How is this information retrieval being implemented? There are several options:
1. Use the DICOM Modality Worklist (DMWL) similar to the SWF profile. The DMWL in the case of the traditional SWF includes the “What, Where, When, for Whom and How to Identify,” for example, performing a Chest PA X-ray (what), using the portable unit in the ER (where), at 7 am (when), for Mr. Smith (for whom), with a link to the order using the Accession Number and identifying it with Study UID 1.x.y.z (how to identify). In the case of the encounter-based imaging workflow, we only use the “for whom” and “where: as the other information is not known.
Using only patient ID and department, the specification of this DMWL variant is covered by the IHE Encounter Based Imaging Workflow (EBIW) profile, which is geared towards Point of Care (POC) ultrasound. The problem is that DMWL providers are not typically available outside radiology/cardiology and that acquisition devices (think an android based tablet capturing images or a POC US probe connecting to a smartphone) don’t typically support the DMWL client either.
2. Use the Universal worklist and Procedure Step (UPS) as defined in the IHE EBIW, which is basically a DICOMWeb implementation of the traditional worklist, which makes it easier to implement, especially on mobile media. The same issue is true with this solution as with solution (1): who supports it? Note that not only it is an issue with the client software but also the availability of the server, i.e. worklist provider which is somewhat of an unknown outside radiology/cardiology.
3. Use HL7 Query as defined by the PDQ profile, either version 2 or 3.
4. Use FHIR as defined by the PDQ-M profile. Note that the differences between V2 and FHIR is that the traditional PV1 segment which has visit information has been renamed as the FHIR Encounter Resource. So, when you think about encounters, think about the visits in Version 2.
5. Listen to any V2 ADT’s, i.e. patient registration messages.
6. Use an API, preferably web-based if you use a mobile device, direct into an EMR, HIS or ADT system.
7. Do a DICOM Patient information Query (C-Find) to a PACS database assuming that the patient has prior images.
8. Any other proprietary option.
The second step is that we need to add additional information to the metadata that was not provided by the initial meta-data query, i.e., the Accession Number. The Accession Number was initially intended to link an image or set of images with an order and the result (diagnostic report and subsequent billing). Even though there is no order, you’ll find that the Accession number is critical as it is used by the API from an EMR to a PACS and/or VNA to access the images, to link to the results and notes, to make the connection to billing and to associate with study information (Study Instance UID’s).
A so-called “Encounter Manager,” as defined by IHE, as an actor could issue a unique Accession Number. This encounter manager could reside in a PACS, VNA, or broker. To make sure that Accession Numbers are unique and different from other Accession Numbers, such as those issued by RIS or EMR, most institutions use a prefix or suffix scheme. Note that the acquisition device does not have to deal with this Accession Number issue, a DICOM router could do a query for the Accession Number and automatically update the image headers before forwarding it to the PACS/VNA.
The next (optional) step is that an encounter might need to create a “dummy” order, because many EMR’s or HIS systems cannot do any billing or recognize the images that are created without an order, so in many cases, an order is created “after the fact.”
The last step is to notify the EMR that images are available. There are several options for that as well:
1. Create a HL7 V2 ORU (observation result) transaction as defined by the IHE EBIW. This is probably the most common option as EMR’s typically support the ORU.
2. Create a HL7 V2 ORM with order status being updated.
3. Create a DICOM Instance Availability. This is actually used quite a bit (I have seen Epic EMR implementations that use this). IA has more detailed information compared with the HL7 v2 options.
4. Send a Version 2 MDM message which has the advantage that you can use it to provide a link to the images.
5. Use the DICOM MPPS transaction.
6. Use the (retired) DICOM Study Content Notification (still in use by some legacy implementations)
7. Manually “complete” entry in the EMR
8. Use proprietary API implementations.
The scenarios described above assume that patients are always registered, and encounters scheduled. It becomes more complex if there is no patient registration, such as a POC US being used by a midwife at a patient’s home. The same applies for emergency cases, e.g. when using it in an ambulance where the only information might be that it is a 30’s female, or at a disaster area or battlefield (“citizen-1”). In this case, we need a solution similar to the PIR to reconcile the images with information entered after the fact resulting in updates and merges, typically done using HL7 transactions.
Another future complication will be the implementation of patient-initiated imaging, for example, if a patient has a rash and wants to send an image taken with his or her phone to a practitioner or sends images of a scar after surgery to make sure it is healing properly.
As you can see from the above, the challenge with Encounter-Based Imaging is that there are many options for implementations, in theory one could multiply the number of options for each step and you’d come up with many different combinations (2 times 8 times 8 results in theoretically 128! different options).
IHE so far has only addressed two options, the one for POC ultrasound and photo’s in the EBIW profile which specifies DMWL for getting the demographics and using an ORU for the results. In practice, a typical hospital might use 5-10 or so different options for the different departments. Hopefully there will be a couple of “popular” options emerging which will be driven preferably by new IHE profile definitions and supported by the major vendors. In the meantime, if you are involved with enterprise imaging be prepared to spend quite a bit of time determining which option(s) fit best for your workflow, and is supported by your EMR/PACS/VNA/Acquisition modality vendors. You might need to spend a significant amount of time training your users for any additional steps that might be necessary to fit your solution.