As institutions start to incorporate their multiple imaging
sources into an enterprise solution such as
provided 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.
