How to Connect an Ultrasound to DICOM or

PACS
JULY 10, 2015 BY BRIAN GILL

Understanding one of the most confusing parts of ultrasound

setup

A DICOM software option makes image transfer easy, but it can be difficult to set up.

Hands down, the most frequent support call I receive involves DICOM setup on an ultrasound
machine. I dont think Ive gone a week without having a customer call about their DICOM and
network settings.

From what is an IP address to failed image transfer, this can be a complicated issue,
particularly for those without an existing IT department.

The problem, though, is that this is not something I can resolve over the phone. At the bottom of
this post, Ive outlined the most common problems experienced when setup is done properly.
That list solves 95% of problems. The rest of this post gives an overview of whats needed to get
set up.

DICOM is one of the most misunderstood and confusing things for experienced and
inexperienced users. Unfortunately, theres nothing out there that explains it well. Theres a
reason for that the reason is that its different for every machine, every network, and every
radiologist. All three components are given unique, specific information that can only be
provided by parties directly involved with the network.

If you need to know more about DICOM and PACS, youll see some definitions at the end of this
post.

Lets look at this as though youre having FedEx

pick up images and deliver them to your radiologist. In order to do so, you must have a FedEx
account, an address from which FedEx can pick up your images, and a delivery address. When
these addresses are confirmed, you can schedule FedEx to pick up and deliver your images
whenever you so desire.

In the DICOM Networking world, this is very similar. You need three things: 1) a network
connected to the Internet, 2) your own network address that will let your machine connect to the
Internet, and 3) a network address to deliver the images. These addresses are called IP Addresses,
and theyre unique to your machine and theirs. In place of your name, they have something
called an AE Title, which uniquely identifies you as the sender. Finally, theres a port number,
which is similar to saying the images will only be accepted via FedEx (not UPS, USPS, or other
carrier).

So, in order to get connected, you need to connect to the network, and provide your ultrasound
with the proper addresses and information for delivery.

So, unless you run your own network and plan to read your own studies, you cant do this on
your own. Setting up DICOM requires the help of at least one IT professional one on the
receiving (server) side, and probably one for your own network.

If you have an IT person, it is best to try and let them take over.

Following the steps below, youll be armed with the proper information and steps to get your
DICOM images sent properly to the radiologist.
STEP 1: Call the person, department or company
who will be receiving and reading your studies. Tell them you need the DICOM information to
enter into your ultrasound machine. That person is going to give you a list that has a bunch of
numbers and names. This list will include, but is not limited to:

AE TITLE

IP ADDRESS

Device Name/Computer Name

PORT

There are often a lot of other parameters that youll find on a DICOM setup page. You likely
wont need a lot of this information, so dont worry if its not provided. The items you really
need are the AE Title, IP Address, and Port number. For other DICOM services (worklist, print,
etc), you will be given other information to input on the corresponding services screen. Dont
change the other stuff unless its specifically requested.

Once you receive the information, set it aside where you can refer to it later. If you were unable
to obtain this information, stop here and come back once you have it.
 STEP 2: Connect to your own network. This can
be tricky. If you have an IT person, I highly recommend you ask this person to get your machine
connected to the network. Its worth the money to get it done correctly.

Youll want to take the IT person to your network setup on the ultrasound machine. Check your
user manual for its location, or see if we have a video on reaching your network setup screen
in our library of free Ultrasound Training Videos.

They will also need access to your network router or company server to ensure the machine is set
up properly and a firewall is not blocking network traffic from the machine.

Now that youre connected, its time to enter your DICOM information and test the connection.

STEP 3: Find the DICOM setup screen on your

ultrasound machine. Most often, this is found in the same general area as your Network
configuration screen. If you cant find it, refer to your user manual or see if we have a video on
reaching your setup screen in our library of free Ultrasound Training Videos.

Note: You may see a lot of available DICOM services: Store, Print, Commit, Worklist, and
others. The setup is much the same for each of these services. Typically, youll start with
DICOM Store. And once you set up the initial DICOM Store service, the others are relatively
straightforward.

Here, you may be asked to enter a Computer Name. If you were not given one to enter, then you
can put in your own information without fear of a connection problem.
Next, youll need to enter the AE Title, IP Address, and Port number. They may also give you a
subnet or other information. Enter whatever theyve given you if there is a spot on the machine
to enter it (sometimes theyll give you more information than you need).

When entering the information, you must type it EXACTLY as its provided. An incorrectly
typed AE Title or IP address will result in a failure when sending images.

When this is entered, many machines have a

Verify button, that will send information to the server and wait to get an OK response. Press
Verify.

Whether you have a Verify option or not, you should send some test images to the radiologist and
make sure they receive everything properly.

If you have errors, check your network connection and make sure youve entered all the
information exactly as it was provided. If that doesnt help, take a look at the troubleshooting I
have at the end of this post.

Can I use WiFi?

At this time, few ultrasounds support WiFi. Despite some

claims, its rare that you can go purchase a WiFi card and plug it into the USB port. HIPAA is the
most-cited reason why its not enabled, although some machines are WiFi enabled.

If you do have WiFi, however, this process does not change. You still need to follow the steps in
order to send and receive studies.

Problems? Troubleshooting your DICOM Connection

Images not transferring or are you getting a failed message? At least 9 out of 10 calls I get are
resolved by correcting one or all of the following problems:
1. Check your AE TITLE. It must be the EXACT same on the ultrasound as it is on the DICOM
server. If one letter, space, or anything is off, the server will reject your images without telling
you why.

2. Is there a firewall? This is extremely common and can be on your network or theirs. First,
check with the IT person handling your network. Next, check with the IT person on the receiving
end.

3. Check your network connection. A loose connection to the wall or incorrect or illegal IP
Address is more common than you would think.

What are DICOM and PACS?

DICOM is an industry standard that is designed to allow easy communication across multiple
modalities among multiple manufacturers. What does that mean? Basically it means that all
medical machines that are DICOM compliant must speak the same language when they send
information across the network. This allows the person reading the studies to have one piece of
software (a DICOM reader) to read the studies. Before DICOM, manufacturers each had their
own language and it required multiple software programs in order to read the studies.

PACS is a complete image archival and storage system and is what receives and archives images
transferred via DICOM. Essentially, it describes the computer servers that receive the patient
data and images. PACS can be a server in your office, a cloud, or hospital IT department. You do
not need PACS to read DICOM. PACS is just a term to describe a system that may include a
DICOM server that receives the images you send in the DICOM format. .

Good Luck!

Manufacturers often make this more difficult than it should be. GE, for example, has a complex
setup for services, devices, buttons, and network settings. Its not often explained well nor
straightforward. When it works, however, their setup can be extremely powerful and versatile.
For most, though, its WAY more than you need. The manual usually isnt that helpful, so youll
need to read it through a few times to understand the complete process.

DICOM
From Wikipedia, the free encyclopedia
[hide]This article has multiple issues. Please help improve it or discuss these
issues on the talk page.
This article needs attention from an expert on the subject. (July 2011)
This article needs additional citations for verification. (April 2011)

Digital Imaging and Communications in Medicine (DICOM) is a standard for handling,

storing, printing, and transmitting information in medical imaging. It includes a file format
definition and a network communications protocol. The communication protocol is an
application protocol that uses TCP/IP to communicate between systems. DICOM files can be
exchanged between two entities that are capable of receiving image and patient data in DICOM
format. The National Electrical Manufacturers Association (NEMA) holds the copyright to this
standard.[1] It was developed by the DICOM Standards Committee, whose members[2] are also
partly members of NEMA.[3]

DICOM enables the integration of scanners, servers, workstations, printers, and network
hardware from multiple manufacturers into a picture archiving and communication system
(PACS). The different devices come with DICOM conformance statements which clearly state
which DICOM classes they support. DICOM has been widely adopted by hospitals and is
making inroads in smaller applications like dentists' and doctors' offices.

DICOM is known as NEMA standard PS3, and as ISO standard 12052:2006 "Health informatics
-- Digital imaging and communication in medicine (DICOM) including workflow and data
management".

PS 3.20: Transformation of DICOM to and from HL7 Standards PDF (570 KB)

Contents
1 History

o 1.1 Derivations

2 Data format

3 Image display

4 Value representations

5 Services

o 5.1 Store

o 5.2 Storage commitment

o 5.3 Query/Retrieve

o 5.4 Modality worklist

o 5.5 Modality performed procedure step

 o 5.6 Printing

o 5.7 Off-line media (files)

6 Application areas

7 Port numbers over IP

8 Disadvantages

9 HL7

10 IHE

11 See also

o 11.1 DICOM Software

o 11.2 Medical Records Standards Initiatives, Standards and Organizations

12 References

13 External links

History

Front page of ACR/NEMA 300, version 1.0, which was released in 1985
DICOM is the First version of a standard developed by American College of Radiology (ACR)
and National Electrical Manufacturers Association (NEMA).

In the beginning of the 1980s, it was very difficult for anyone other than manufacturers of
computed tomography or magnetic resonance imaging devices to decode the images that the
machines generated. Radiologists and medical physicists wanted to use the images for dose-
planning for radiation therapy. ACR and NEMA joined forces and formed a standard committee
in 1983. Their first standard, ACR/NEMA 300, was released in 1985. Very soon after its release,
it became clear that improvements were needed. The text was vague and had internal
contradictions.

In 1988 the second version was released. This version gained more acceptance among vendors.
The image transmission was specified as over a dedicated 2 pair cable (EIA-485). The first
demonstration of ACR/NEMA V2.0 interconnectivity technology was held at Georgetown
University, May 2123, 1990. Six companies participated in this event, DeJarnette Research
Systems, General Electric Medical Systems, Merge Technologies, Siemens Medical Systems,
Vortech (acquired by Kodak that same year) and 3M. Commercial equipment supporting
ACR/NEMA 2.0 was presented at the annual meeting of the Radiological Society of North
America (RSNA) in 1990 by these same vendors. Many soon realized that the second version
also needed improvement. Several extensions to ACR/NEMA 2.0 were created, like Papyrus
(developed by the University Hospital of Geneva, Switzerland) and SPI (Standard Product
Interconnect), driven by Siemens Medical Systems and Philips Medical Systems.

The first large-scale deployment of ACR/NEMA technology was made in 1992 by the US Army
and Air Force, as part of the MDIS (Medical Diagnostic Imaging Support) program based at f Ft.
Detrick, Maryland. Loral Aerospace and Siemens Medical Systems led a consortium of
companies in deploying the first US military PACS (Picture Archiving and Communications
System) at all major Army and Air Force medical treatment facilities and teleradiology nodes at a
large number of US military clinics. DeJarnette Research Systems and Merge Technologies
provided the modality gateway interfaces from third party imaging modalities to the Siemens SPI
network. The Veterans Administration and the Navy also purchased systems off this contract.

In 1993 the third version of the standard was released. Its name was then changed to "DICOM"
so as to improve the possibility of international acceptance as a standard. New service classes
were defined, network support added and the Conformance Statement was introduced. Officially,
the latest version of the standard is still 3.0. However, it has been constantly updated and
extended since 1993. Instead of using the version number, the standard is often version-
numbered using the release year, like "the 2007 version of DICOM".

While the DICOM standard has achieved a near universal level of acceptance amongst medical
imaging equipment vendors and healthcare IT organizations, the standard has its limitations.
DICOM is a standard directed at addressing technical interoperability issues in medical imaging.
It is not a framework or architecture for achieving a useful clinical workflow. RSNA's
Integrating the Healthcare Enterprise (IHE) initiative layered on top of DICOM (and HL-7)
provides this final piece of the medical imaging interoperability puzzle.
Derivations

There are some derivations from the DICOM standard into other application areas. These
include:

DICONDE - Digital Imaging and Communication in Nondestructive Evaluation, was

established in 2004 as a way for nondestructive testing manufacturers and users to share
image data.[4]

DICOS - Digital Imaging and Communication in Security was established in 2009 to be

used for image sharing in airport security.[5]

Data format
DICOM differs from some, but not all, data formats in that it groups information into data sets.
That means that a file of a chest x-ray image, for example, actually contains the patient ID within
the file, so that the image can never be separated from this information by mistake. This is
similar to the way that image formats such as JPEG can also have embedded tags to identify and
otherwise describe the image.

A DICOM data object consists of a number of attributes, including items such as name, ID, etc.,
and also one special attribute containing the image pixel data (i.e. logically, the main object has
no "header" as such: merely a list of attributes, including the pixel data). A single DICOM object
can have only one attribute containing pixel data. For many modalities, this corresponds to a
single image. But note that the attribute may contain multiple "frames", allowing storage of cine
loops or other multi-frame data. Another example is NM data, where an NM image, by
definition, is a multi-dimensional multi-frame image. In these cases, three- or four-dimensional
data can be encapsulated in a single DICOM object. Pixel data can be compressed using a variety
of standards, including JPEG, JPEG Lossless, JPEG 2000, and Run-length encoding (RLE).
LZW (zip) compression can be used for the whole data set (not just the pixel data), but this has
rarely been implemented.

DICOM uses three different Data Element encoding schemes. With Explicit Value
Representation (VR) Data Elements, for VRs that are not OB, OW, OF, SQ, UT, or UN, the
format for each Data Element is: GROUP (2 bytes) ELEMENT (2 bytes) VR (2 bytes)
LengthInByte (2 bytes) Data (variable length). For the other Explicit Data Elements or Implicit
Data Elements, see section 7.1 of Part 5 of the DICOM Standard.

The same basic format is used for all applications, including network and file usage, but when
written to a file, usually a true "header" (containing copies of a few key attributes and details of
the application which wrote it) is added.

Image display
To promote identical grayscale image display on different monitors and consistent hard-copy
images from various printers, the DICOM committee developed a lookup table to display
digitally assigned pixel values. To use the DICOM grayscale standard display function
(GSDF),[6] images must be viewed (or printed) on devices that have this lookup curve or on
devices that have been calibrated to the GSDF curve.[7]

Value representations
Extracted from Chapter 6.2 of PS 3.5-2007: Data Structure and Encoding PDF (1.43 MiB)

Value Representation Description

AE Application Entity
AS Age String
AT Attribute Tag
CS Code String
DA Date
DS Decimal String
DT Date/Time
FL Floating Point Single (4 bytes)
FD Floating Point Double (8 bytes)
IS Integer String
LO Long String
LT Long Text
OB Other Byte
OF Other Float
OW Other Word
PN Person Name
SH Short String
SL Signed Long
SQ Sequence of Items
SS Signed Short
ST Short Text
TM Time
UI Unique Identifier
UL Unsigned Long
UN Unknown
US Unsigned Short
UT Unlimited Text

In addition to a Value Representation, each attribute also has a Value Multiplicity to indicate the
number of data elements contained in the attribute. For character string value representations, if
more than one data element is being encoded, the successive data elements are separated by the
backslash character "\".
Services
DICOM consists of many different services, most of which involve transmission of data over a
network, and the file format below is a later and relatively minor addition to the standard.

Store

The DICOM Store service is used to send images or other persistent objects (structured reports,
etc.) to a picture archiving and communication system (PACS) or workstation.

Storage commitment

The DICOM storage commitment service is used to confirm that an image has been permanently
stored by a device (either on redundant disks or on backup media, e.g. burnt to a CD). The
Service Class User (SCU: similar to a client), a modality or workstation, etc., uses the
confirmation from the Service Class Provider (SCP: similar to a server), an archive station for
instance, to make sure that it is safe to delete the images locally.

Query/Retrieve

This enables a workstation to find lists of images or other such objects and then retrieve them
from a picture archiving and communication system.

Modality worklist

This enables a piece of imaging equipment (a modality) to obtain details of patients and
scheduled examinations electronically, avoiding the need to type such information multiple times
(and the mistakes caused by retyping).

Modality performed procedure step

A complementary service to Modality Worklist, this enables the modality to send a report about a
performed examination including data about the images acquired, beginning time, end time, and
duration of a study, dose delivered, etc. It helps give the radiology department a more precise
handle on resource (acquisition station) use. Also known as MPPS, this service allows a modality
to better coordinate with image storage servers by giving the server a list of objects to send
before or while actually sending such objects.

Printing

The DICOM Printing service is used to send images to a DICOM Printer, normally to print an
"X-Ray" film. There is a standard calibration (defined in DICOM Part 14) to help ensure
consistency between various display devices, including hard copy printout.

Off-line media (files)

The off-line media files correspond to Part 10 of the DICOM standard. It describes how to store
medical imaging information on removable media. Except for the data set containing, for
example, an image and demography, it's also mandatory to include the File Meta Information.

DICOM restricts the filenames on DICOM media to 8 characters (some systems wrongly use 8.3,
but this does not conform to the standard). No information must be extracted from these names
(PS3.10 Section 6.2.3.2). This is a common source of problems with media created by developers
who did not read the specifications carefully. This is a historical requirement to maintain
compatibility with older existing systems. It also mandates the presence of a media directory, the
DICOMDIR file, which provides index and summary information for all the DICOM files on the
media. The DICOMDIR information provides substantially greater information about each file
than any filename could, so there is less need for meaningful file names.

DICOM files typically have a .dcm file extension if they are not part of a DICOM media (which
requires them to be without extension).

The MIME type for DICOM files is defined by RFC 3240 as application/dicom.

The Uniform Type Identifier type for DICOM files is org.nema.dicom.

There is also an ongoing media exchange test and "connectathon" process for CD media and
network operation that is organized by the IHE organization. MicroDicom is free Windows
software for reading DICOM data.

Application areas
Extracted from Chapter C.7.3.1.1.1 of PS 3.3-2011: Information Object
Definitions PDF (6.51 MiB)

Modality Description Status

AS Modality of type Angioscopy Retired
BI Modality of type Biomagnetic Imaging
CD Modality of type Color Flow Doppler Retired 2008
CF Modality of type Cinefluorography Retired
CP Modality of type Colposcopy Retired
CR Modality of type Computed Radiography
CS Modality of type Cystoscopy Retired
CT Modality of type Computed Tomography
DD Modality of type Duplex Doppler Retired 2008
DG Modality of type Diaphanography
DM Modality of type Digital Microscopy Retired
DS Modality of type Digital Subtraction Angiography Retired
DX Modality of type Digital Radiography
EC Modality of type Echocardiography Retired
ECG Modality of type Electrocardiograms
EM Modality of type Electron Microscope
ES Modality of type Endoscopy
FA Modality of type Fluorescein Angiography Retired
FS Modality of type Fundoscopy Retired
GM Modality of type General Microscopy
HC Modality of type Hard Copy
IO Modality of type Intra-oral Radiography
LP Modality of type Laparoscopy Retired
LS Modality of type Laser Surface Scan
MA Modality of type Magnetic Resonance Angiography Retired
MG Modality of type Mammography
MR Modality of type Magnetic Resonance
MS Modality of type Magnetic Resonance Spectroscopy Retired
NM Modality of type Nuclear Medicine
OP Modality of type Ophthalmic Photography
OPM Modality of type Ophthalmic Mapping
OPR Modality of type Ophthalmic Refraction
OPV Modality of type Ophthalmic Visual Field
OT Modality of type Other
PT Modality of type Positron Emission Tomography (PET)
PX Modality of type Panoramic X-Ray
RD Modality of type Radiotherapy Dose (a.k.a. RTDOSE)
RF Modality of type Radio Fluoroscopy
RG Modality of type Radiographic Imaging (conventional film screen)
RTIMAG Modality of type Radiotherapy Image
RP Modality of type Radiotherapy Plan (a.k.a. RTPLAN)
RS Modality of type Radiotherapy Structure Set (a.k.a. RTSTRUCT)
RT Modality of type Radiation Therapy
SM Modality of type Slide Microscopy
SR Modality of type Structured Reporting
ST Modality of type Single-Photon Emission Computed Tomography Retired 2008
TG Modality of type Thermography
US Modality of type Ultrasound
VF Modality of type Videofluorography Retired
VL Modality of type Visible Light
XA Modality of type X-Ray Angiography
XC Modality of type External Camera (Photography)

Port numbers over IP

DICOM have reserved the following TCP and UDP port numbers by the Internet Assigned
Numbers Authority (IANA):

104 well-known port for DICOM over Transmission Control Protocol (TCP) or User
Datagram Protocol (UDP). Since 104 is in the reserved subset, many operating systems
require special privileges to use it.

2761 registered port for DICOM using Integrated Secure Communication Layer (ISCL)
over TCP or UDP

2762 registered port for DICOM using Transport Layer Security (TLS) over TCP or UDP

11112 registered port for DICOM using standard, open communication over TCP or UDP

The standard recommends but does not require the use of these port numbers.

Disadvantages
According to a paper presented at an international symposium in 2008, the DICOM standard has
problems related to data entry. "A major disadvantage of the DICOM Standard is the possibility
for entering probably too many optional fields. This disadvantage is mostly showing in
inconsistency of filling all the fields with the data. Some image objects are often incomplete
because some fields are left blank and some are filled with incorrect data."[8]

HL7
DICOM is a standard for handling, storing, printing, and transmitting information in medical
imaging. The communication protocol is an application protocol that uses TCP/IP to
communicate between systems. DICOM files can be exchanged between two entities that are
capable of receiving image and patient data in DICOM format. The National Electrical
Manufacturers Association (NEMA) holds the copyright to this standard. It was developed by the
DICOM Standards Committee, whose members are also partly members of NEMA.[9]

This article contains content that is written like an advertisement. Please help improve
it by removing promotional content and inappropriate external links, and by adding
encyclopedic content written from a neutral point of view. (December 2014)

Health Level Seven (HL7), is a non-profit organization involved in the development of

international healthcare informatics interoperability standards.[1] "HL7" also refers to some of
the specific standards created by the organization (e.g., HL7 v2.x, v3.0, HL7 RIM). The HL7
Strategic Initiatives document is a business plan for our products and services and was designed
specifically to meet the business needs of its members and stakeholders. Derived from
collaborative efforts with its members, government and non-government agencies and other
standards development organizations, the Strategic Initiatives are five high-level organizational
strategies that are supported by a detailed tactical plan with clearly defined objectives,
milestones, and metrics for success.[10]

Both of the standards are focused on the data exchange and the data compatibility. Among many
standards for the syntax, HL7 and DICOM are most successful. However, everything could not
be handled by HL7 solely. DICOM is good for radiology images, but, other clinical images are
already handled by other lighter data formats like JPEG, TIFF. So, it is not realistic to use only
one standard for every area of clinical information.[11]

Opening the HL7 and DICOM standards in order to foster the integrated use of persistent health
information objects is proposed as a step towards the creation of the health information
infrastructure.[12]

IHE
Integrating the Healthcare Enterprise (IHE) was founded in 1997 by members of the
Radiological Society of North America (RSNA) and the Healthcare Information and
Management Systems Society for the purpose of improving interoperability between information
systems. The IHE initiative was charged with the task of using existing standards of health care
data communication such as DICOM and HL7 to improve exchange of medical information
beyond the radiology department at the hospital level or health systems level. Just as radiologists
were confronted in the past with imaging connectivity incompatibilities, entire health systems are
continually faced with the task of connecting multiple disparate information systems in which
the only reliable communications pathway is the paper printout.

The IHE working group is a panel made up of industry representatives from medical informatics
and imaging vendors as well as medical professionals. Their primary focus is to develop a
common information model of medical information exchange. The devised IHE technical
framework consists of a common lexicon that defines specific medical information transactions
using the existing standards of medical information exchange (DICOM and HL7). The specifics
of these transactions have been worked out in great detail so that vendors have been free to
independently develop solutions to meet the goals of the technical framework. In the year 2001
to 2002, 30 companies took part in the testing and implementation of the IHE demonstrations.[13]

See also
DICOM Software

3DSlicer - a free, open source software package for image analysis and scientific
visualization, with the integrated support of components of DICOM standard

GDCM - Grassroots DICOM library for medical files

 GDCM sample as PNG

Ginkgo CADx Cross-platform DICOM viewer

MicroDicom - DICOM viewer for Windows

OsiriX - Image processing application dedicated to DICOM images

Orthanc - Lightweight, RESTful DICOM store

XnView - supports .dic / .dicom for MIME type application/dicom [14]

Medical Records Standards Initiatives, Standards and Organizations

Health Level 7, a non-profit organization involved in the development of international

healthcare informatics interoperability standards

Integrating the Healthcare Enterprise (IHE), an industry sponsored non-profit

organization based in the US state of Illinois