In the previous set of blog posts in this series I talked
about how to deal with communication errors,
A modality worklist (MWL) is created by querying a Modality
Worklist provider using the DICOM protocol for studies to be performed at an
acquisition modality. The information that is retrieved includes patient
demographic details (name, ID, birthday, sex, etc.), order details (procedure
code, Accession number identifying the order, etc.) and scheduling details
(referring physician, scheduled date/time etc.). This information is contained
in a scheduling database, which is created by receiving orders for the
department in an HL7 format (ORM messages).
The Worklist provider used to be typically hosted on a
separate server, aka broker or connectivity manager. But increasingly, this
function is embedded in a PACS, a RIS or even EMR that has a radiology package.
Moving this function from the broker to these other systems is the source of
several issues as the original broker was likely rather mature with a lot of
configurability to make sure it matches the department workflow, while some of
these new implementations are still rather immature with regard to
configurability.
The challenge is to provide a worklist with only those examinations
that are scheduled for a particular modality, no more and no less, which is
achieved by mapping information from the HL7 order to a particular modality.
Issues include:
·
The
worklist is unable to differentiate between the same modality at different locations
– An order has a procedure code and description, e.g. CT head. As the order in
HL7 does not have a separate field for modality, the MWL provider will map the
procedure codes to a modality, in this case “CT” so a scanner can do a query
for all procedures to be performed for modality “CT.” The problem occurs if
there is a CT in the outpatient ER, one in cardiology for cardiac exams, one in
main radiology, and one in the therapy department (RT). Obviously, we don’t
want all procedures showing up on all these devices. It might get even more
complicated if a CT in radiology is allocated, let’s say on Fridays to do scans
for RT. We need to distinguish between these orders, e.g. look at the “patient
class” being in-or outpatient, or department, or another field in the order and
map these procedures to a particular station. The modalities will have to
support the “Station Name” or “Scheduled AE-Title” as query keys.
·
The
worklist can only query on a limited set of modality types – Some devices
are not properly configured, for example, a panoramic x-ray unit used for
dentistry should use the modality PX instead of CR, the latter of which might
group them together with all of the other CR units. The same applies for a Bone
Mineral Densitometry (“DEXA”) device; it should be identified as modality BMD
instead of CR or OT (“Other”). Document scanners also should be configured to
pull for “DOC” instead of OT or SC (“secondary Capture”), endoscopy exams need
to be designated ES, and so on. The challenge is to configure the MWL provider
as well as the modality itself to match these modality codes.
·
The
worklist has missing information – A worklist query might not have enough
fields to include all the information needed at the modality. In one particular
instance I encountered, the hospital wanted to see the Last Menstrual Date
(LMD) as it was always on the paper order. Other examples are contrast allergy
information, patient weight for some modalities, pregnancy status, or other
information. If the worklist query does not have a field allocated for these,
one could map this at the MWL provider in another field, preferably a “comment
field” instead of misusing another field that was intended and named for a
different purpose.
·
The
worklist is not being displayed – There could be several reasons, assuming
that you tested the connectivity as described in earlier blogs, i.e. there
could be no match for the matching key specified in the query request, or, the
query response that comes back is not interpreted correctly. In one case a
query response was not displayed at an ultrasound of a major manufacturer
because one of the returned parameters had a value that was illegal, i.e. not
part of the enumerated values defined by the DICOM standard for that field. In
this case, I could only resolve this issue by looking at sniffer responses and
taking those and running them against a validator such as DVTK.
MWL issues are tricky to resolve. It is highly recommended
that one have access to the MWL provider configuration software. Most vendors
will have a separate training class on this device. Be aware that the mapping
tables need to be updated every time a new set of procedure codes is
introduced; therefore, it is an ongoing support effort. Configuring requires
detailed knowledge of HL7 so you can do the mapping into DICOM.
To troubleshoot these issues, a modality worklist simulator
can be very useful. There is a DVTK modality worklist simulator available for
free and a licensed modality simulator from OTech.
In case you need to brush up on your HL7 knowledge, there is
a HL7 textbook available and there are on-line as well as face-to-face training
classes, which include a lot of hands-on exercises.
In the next blog post we’ll spend some time describing the
most common HL7 issues impacting the PACS.
No comments:
Post a Comment