
Of key importance is that you need to be involved with the
planning process. If you are not aware when these new connections are going to
happen, you often are faced with issues that could have been prevented. Unfortunately,
with regard to the planning process, it is like the chicken and egg problem. if
you have not been able to demonstrate that proper planning saves time and
money, they might not involve you in the planning, and if you are not involved from
the start, you aren’t able to demonstrate that initial involvement pays off. I
don’t have a solution for this except for diligently probing what is happening
so you can get involved.
Assuming that you know when the expected delivery of the new
modality will take place, for example, in four weeks, you can start the planning
process, which consists of the following:
1.
Prepare
the network and addressing infrastructure - If the unit is going to be at a
fixed location, you need to make sure that the physical network connection is
available, in the case of a wireless connection you need to work with IT to
provide a reliable connection that is fast enough to facilitate querying a Worklist and sending
images. Assuming that you use a VLAN in radiology,
you need to work with IT to make sure that the routers are configured to allow
access to the devices that it will need to communicate with. An IP address
needs to be assigned, as well as an AE-Title. Good
practice dictates that the new device uses a standard port number for the DICOM
connection that is assigned by the IANA to be 11112. I hear from some of PACS
administrators that service engineers are sometimes hesitant and initially
unwilling to assign the port number and AE-Title that you are assigning to the
device, but I suggest that you not give in and insist that they follow the
rules and conventions of your institution.
2.
Request
the DICOM conformance statement of the new device - Compare this document with
those of the devices the modality needs to interface with, which is first of
all the PACS and second the specifications of the Modality Worklist provider, which
might be in the PACS, RIS or provided as a separate broker. This also requires
a bit of persistence, as in many cases, your interface with the vendor is
through their sales channel and in my experience they often provide incorrect
or out-of-date documentation. Make sure that the documentation meets the exact
version and model number that you are installing.
3.
Check
compatibility for image and related information to be exchanged - Using the
conformance statements, check if there is anything that is sent by the modality
that might not be supported by the PACS. Examples are: a new, enhanced CT or MR
image type, for mammography the support for the new breast tomosynthesis
images, for ultrasound the support for Structured Reports containing
the measurements, for a CR a DICOM Presentation state
that contains shutter information, for a CT a dose Structured Report, for
mammography again, the support of CAD marks, for a
cardiology device support of IVUS (intravascular ultrasound) or
IV-OCT (Intravascular Optical Coherence Tomography), and so
on. If support at the PACS is lacking, one might consider an upgrade of the
PACS software, which in many cases is unlikely to happen in the required
timeframe, which means that you have to work on either a work-around or
degrading the modality to send an older, well known and supported image type. Examples
of workarounds for dose Structured Reports are screen shots, for enhanced
objects maybe using “conventional” CT, MR objects; for breast tomosynthesis it
might mean falling back to proprietary solutions and doing the diagnosis at a
modality workstation. Note that some of these fallbacks have major impacts on workflow.
4.
Check the
Modality Worklist interface for its filtering capability and completeness
- If the new modality is a replacement
and/or addition to an existing set of modalities sharing the same workload, one
can reuse the Modality Worklist settings of the old unit. Examples are adding
an ultrasound to an existing department or an additional portable digital X-ray
unit. However, if you are installing a modality that is new, let’s say a dental
panoramic X-ray unit, a bone-density device, a new IVUS in cardiology or a new
outpatient CT, you need to prepare the Worklist provider or broker so that the
query for the Worklist from this modality provides only the procedures to be
done at the new device.
Note that the Worklist information is created by converting the orders encoded
in a HL7 format, which includes a procedure code and NOT the modality code
(e.g. CT, MR, US, etc.), therefore, the broker decides based on the procedure
code which modality is going to be performing the study, which might not always
be a sufficiently enough discriminator. Examples are a dental unit and radiology
unit both sharing “CR” or a radiology and cone beam CT in dentistry sharing “CT,”
or an in- and out-patient CT that needs a different Worklist. In these cases,
other information in the requisition such as whether it is an inpatient or
outpatient, or certain procedures that identify the specialty, need to be
mapped to a certain location indicator (Station Name or scheduled AE-Title), which
can be used as a filter by the provider.
In addition to being able to filter the Modality Worklist so that it only
displays the procedures to be done at that specific modality, one should also
check the worklist contents. Depending on the modality, certain information such as pregnancy status,
weight, allergic reactions, contrast allergy and others, depending on the
specific workflow and practice in the institution, might need to be retrieved
and displayed. If certain information is missing, one should develop a
work-around, which could be as simple as mapping that information from the
header in a “comment field,” or, less preferable, in a non-used field.
Hopefully one can avoid the need to access the RIS, EMR or other source of the
order information and all of it is provided in the Worklist, but in a worst
case, that might be the only option. The key is to be prepared for these
workarounds and develop them upfront instead of discovering after the fact that
it is not working.
5.
Simulate
the modality connection - One can use a modality simulator such as OT-DICE
or DVTK that can request a Worklist that
mimics the query of the new modality by using the same addressing (station
AE-Title, IP address, port number) and uses the same filters for the queries.
This requires scheduling dummy procedures and having the Worklist provider
configured to do the correct mapping. Configure this at the PACS side as well,
as most PACS systems also require that the new AE-Title be added to the list of
devices that are allowed to communicate with the database, and, if applicable,
pull images from the archive. In a best case scenario your institution has a
test broker and test PACS that can be used to do the testing, which is the case
for most institutions, but if not, the only option you have is to use the production
PACS to do this. For the patients one can use test patients, and use a test
pattern for the image.
6.
Simulate
the PACS core and viewing capability - Get images and any other related
objects that are to be generated by the new modality, such as presentation states,
structured reports for measurements, dose reports, CAD marks, etc. from the
vendor on a CD and import these either directly into the PACS, or even better,
upload them in your modality simulator to simulate the behavior of the new
modality as closely as possible. Display the images on the viewing station, and
test the applicable interfaces with the reporting system for DICOM Structured
Reports (SR’s) containing the measurements and a radiation dose management
system for the dose SR’s. Pay particular attention to the hanging protocols,
i.e. that the images are displayed in the correct presentation, which requires
the interpretation of parameters such as series and study descriptions in the
DICOM header. Good practice is also to run the CD data through a validator such
as DVTK to find if there are any potential DICOM standard violations that might
eventually cause problems.
If, for some reason, you are unable to do any, or some of
these steps in advance, you use the same strategy during or after the
installation in case there are issues. For example, if you cannot get the new
modality to communicate, first look at the conformance statements, try a
simulator and capture the communication using a DICOM sniffer to see exactly
what happens between the two devices. However, when possible, I strongly
recommend taking the pre-emptive route as it is less stressful and better
practice. I recommend creating a “new modality pre-installation” policy and
have your department and involved parties sign off on it. It would contain a
checklist of the items to be reviewed prior to installation. Similarly, there
would be a “new modality installation” policy that spells out what to do before
you allow a service engineer from the vendor to leave, which would function as
a mini-acceptance checklist to prevent a call-back because something does not
quite work. Assuming that you take all these precautions, the chances for plug and
play are not always guaranteed but definitely much better.