Summer Internship

Experience
Project Report
On
-Study of industry Standards used in Radiology
At SEIMENS India Pvt. Ltd.

As a part of Summer Training June-July 2014 in

B.E. (Electronics Instrumentation & Ctrl)
At Thapar University, Patiala

Mr. Vikas Manoria

Chief Manager (Sales)
Siemens India
Gurgaon

Amod Bansal
2 yr (101205008)
EIED
Thapar University,
Patiala
nd

Supervisor
Submitted by

ACKNOWLEDGEMENTS
I would like to thank all those people whose voluntary efforts continue to defy the received
wisdom. With the fast approaching deadlines, this project would not have been possible without
the help and support of many. I express my gratitude to Mr. Vikas Manoria for providing his
valuable inputs.
I also express my gratitude toward my family and friends without whose support and cooperation this project would not have been possible.

INTRODUCTION
With the advent of the internet and telecommunication technologies, data communication has
become an integral part of any organization. Organizations rely on networks to share the data.
Many large organizations have their own network for the exchange of information. With the
advancements in technology many networks from small work groups are connected via routers
and bridges which enable sharing of information on a large scale.
Growing demands for network communication are no longer restricted to the business world.
Since the 1990s, hospitals have begun to interconnect diagnostic imaging devices. These devices
are connected to a central archiving system (PACS). PACS provides storage and management
services for diagnostic images and reports.
Implementing integrated information systems can be a complex and expensive. Healthcare
professionals seeking to acquire or upgrade systems do not have a convenient, reliable way of
specifying a level of adherence to communication standards sufficient to achieve truly efficient
interoperability. Great progress has been made in establishing such standards DICOM and
HL7, notably, are now highly advanced. But a gap persists between the standards that make
interoperability possible and the actual implementation of integrated systems. To fill in that gap
has, until now, required expensive, site-specific interface development to integrate even
standards-compliant systems.

ABOUT SIEMENS
Siemens was founded by Werner Von Siemens and his partner Johann George Halske with 10
employees in a small building in Berlin on October 12, 1847.

In 1848, Siemens and Halske build the first long-distance telegraph line in Europe. The
500-km route extended from Berlin to Frankfurt. In 1850, the founders younger brother, Carl
Wilhelm Siemens started to represent the company in London. In 1867, Siemens completed the
monumental Indo-European telegraph line.
In 1881, a Siemens AC Alternator driven by a watermill was used to power the worlds
First electric street lighting in the town of Godalming, United Kingdom.
In 1847, Werner von Siemens designed a pointer telegraph that was faster & more reliable than
any other device of its kind. Three core companies were combined to form Siemens AG
[Aktiengesellschaft] in 1966 & reorganization in 1969 and then various segments the
precursors to todays Groups-were formed in the Basic Organization Of Siemens AG. At the
same time sub groups were converted to independent companies like Bosch-SiemensHausgerate-GmbH.
The history of Siemens is filled with technological milestones: the pointer Telegraph and
Dynamo, the electric train and the electric street light, the electron microscope and cardiac
pacemaker, electronic automation and the worlds largest and most powerful Gas Turbine.
In 1881, Siemens Brothers built the worlds first public-sector power plant in Godalming in
the south of England. The facility generated Electricity for street lights. It did this, by the way,
with zero carbon dioxide emissions, since it was driven by Hydraulic Energy from the river
Wey. In 1884, Siemens used electricity to light up posch Berlin boulevard unter den Linden.
In addition to its electric generators and Transformer business, the company also began making
steam turbines in the 1920s. Other innovations were worlds first electric locomotive (1879) and
5

the worlds first electric streetcar (1881).The first national subsidiary was established in Russia in
1855, followed by an English subsidiary in 1858.

As Werner envisioned, the company he started from strength to strength in every field of
electrical engineering. Siemens is today a technology giant in more than 190 countries.
QUALITY POLICY
For Siemens, quality is a driving factor which strengthens our ambition to assume a worldleading role in our environment of logistics automation and material handling technology.
Our Quality Policy is: "Customer Satisfaction through Continuous Improvement."
Help us to get nearer to our goal, and to become better in our efforts to achieve top quality in all
the products and services that we supply push us to the limit!

SIEMENS IN INDIA
For over 50 years, Siemens has been active in India, where it holds leading positions in its
Energy, Industry and Healthcare Sectors, while Siemens IT Solutions and Services functions
across all three Sectors. In 2008, Siemens India was the top ranked company by Business Week
in its annual rating of Asias 50 companies. Siemens was also ranked No. 1in the Corporate
Reputation by The Wall Street Journal in its survey of Asias 200 most admired companies. In
fiscal 2008 sales to customers in India amounted to almost EUR 1.9 billion.
The Siemens Group in India has emerged as a leading inventor, innovator and implementer of
leading-edge technology enabled solutions operating in the core business segments of Industry,
Energy and Healthcare. The Groups business is represented by various companies that span
across these various segments. Siemens brings to India state-of-the-art technology that adds
value to customers through a combination of multiple high-end technologies for complete
solutions. The Group has the competence and capability to integrate all products, systems and
services. It caters to Industry needs across market segments by undertaking complete projects
such as Hospitals, Airports and Industrial units.
The Siemens Group in India comprises of 17 companies, providing direct employment to over
18,000 persons. Currently, the group has 21 manufacturing plants, a wide network up of Sales
and Service offices across the country as well as over 500 channel partners.
Today, Siemens, with its world-class solutions plays a key role in Indias quest for developing
modern infrastructure and energy sectors. Siemens consolidates its innovative offerings in the
Energy sector by combining its full range expertise in the areas of Power Generation (PG) and
Power Transmission & Distribution (PTD). Utilizing the most advanced plant diagnostics and
systems technologies, Siemens provides

Comprehensive services for complete power plants and for rotating machines such as gas and
steam turbines, generators and compressors. By combining the most advanced laboratory
diagnostics, imaging systems and healthcare information technology, Siemens Healthcare
division enables clinicians to diagnose disease earlier and more accurately, making a decisive
contribution to improving the quality of healthcare.
At Siemens, end-to-end products, systems and solutions for industrial and building automation as
well as infrastructure installations are provided. These turnkey solutions cover project
management, engineering and software, installation, commissioning, after- sales service, plant
maintenance and training.

Syngo
Syngo goes beyond the boundary of imaging centers. It comes with a complete network solution
that allows secured, virtual, private connection over the internet. It provides services and values
to the physicians without having to wrestle with complicated configurations requiring a lot of
expertise. It seamlessly integrates the best in class functionality from the following application
modules to create a unique, role-based workflow solution that optimizes your business process.

syngo Imaging XS (PACS)

syngo Workflow (RIS)
Mammography applications
Scheduling Applications
syngo Voice (Voice Recognition)
Syngo Portal Radiologist (Radiology Workflow Management)

The syngo via can be used as a stand-alone device or together with a variety of
syngo.via-based software options which are medical devices in their own right.
Although some pre-requisites include:
An Internet connection to clinical network
DICOM COMPLIANCE
Meeting of minimum hardware requirements and adherence to local data security
regulations.
Here in this project we discuss about DICOM which is a standard for transmitting information in
medical imaging and IHE Integration Profiles which describe a workflow scenario and
document how to use established standards like DICOM, HL7 etc.
DICOM An Introduction
DICOM or Digital Imaging and Communication in Medicine are 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.
DICOM e n a b l e s t h e i n t e g r a t i o n 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".

HISTORY OF DICOM
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 doseplanning 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.
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 run
out of 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.
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 versionnumbered using the release year, like "the 2007 version of DICOM".

THE PROTOCOL TCP/IP

The Internet Protocol suite is the networking model and a set of communications protocols
used for the internet and similar networks. It is commonly known as TCP/IP, because of its
most important protocols, the Transmission Control Protocol (TCP) and the Internet
Protocol (IP) were the first networking protocols defined in this standard.

10

TCP/IP provides end-to-end connectivity specifying how data should be formatted, addressed,
transmitted, routed and received at the destination. It has four abstraction layers which are used
to sort all related protocols according to the scope of networking involved. From lowest to
highest, the layers are:
The link layer contains communication technologies for a single network
segment (link) of a local area network.
The internet layer (IP) connects independent networks, thus establishing
internetworking.
The transport layer handles host-to-host communication.
The application layer contains all protocols for specific data communications
services on a process-to-process level. For example, the Hypertext Transfer Protocol
(HTTP) specifies the web browser communication with a web server.
The TCP/IP model and related protocols are maintained by the Internet Engineering
Task Force (IETF).

KEY ARCHITECTURAL PRINCIPLES

An early architectural document, RFC 1122, emphasizes architectural principles over layering.
End-to-end principle: This principle has evolved over time. Its original
expression put the maintenance of state and overall intelligence at the edges, and
assumed the Internet that connected the edges retained no state and concentrated on speed
and simplicity. Real-world needs for firewalls, network address translators, web content
caches and the like have forced changes in this principle.
Robustness Principle: "In general, an implementation must be conservative in its
sending behavior, and liberal in its receiving behavior. That is, it must be careful to send
well-formed datagrams, but must accept any datagram that it can interpret (e.g., not
object to technical errors where the meaning is still clear)." "The second part of the
principle is almost as important: software on other hosts may contain deficiencies that
make it unwise to exploit legal but obscure protocol features."

11

LAYERS IN THE INTERNET PROTOCOL SUITE

DICOM AND TCP/IP

DICOM uses the transport layer security and SSL protocols for the exchange of data between the
host and the client servers as they are cryptographic protocols that exist in the application layer
of the TCP/IP protocol. These protocols provide communicational security over the internet.
They use asymmetric cryptography for authentication of key exchange and symmetric
encryption for confidentially and message authentication codes for message integrity.
In the TCP/IP model view, TLS AND SSL encrypt the data of network connections at lower sub
layer of its application layer. First the session layer has a handshake using an asymmetric cypher
in order to establish cipher settings and a shared key for that session, then the presentation layer
encrypts the rest of the communication using a symmetric cypher and that session key. In both
models TLS and SSL work on behalf of the underlying transport layer, whose segments carry the
encrypted data.

12

SETTING UP A SECURE CONNECTION BETWEEN CLIENT AND SERVER USING

SSL AND TLS
When the client and the server have decided to use TLS, they negotiate a stateful connection by
using a handshaking procedure. During this handshake, the client and server agree on various
parameters used to establish the connections security.
The client sends the server the client's SSL version number, cipher settings, sessionspecific data, and other information that the server needs to communicate with
the client using SSL.
The server sends the client the server's SSL version number, cipher settings, sessionspecific data, and other information that the client needs to communicate
with the server over SSL. The server also sends its own certificate, and if the client is
requesting a server resource that requires client authentication, the server requests
the client's certificate.
The client uses the information sent by the server to authenticate the server. If the
server cannot be authenticated, the user is warned of the problem and informed that an
encrypted and authenticated connection cannot be established. If the server can be
successfully authenticated, the client proceeds to the next step.
Using all data generated in the handshake thus far, the client (with the
cooperation of the server, depending on the cipher in use) creates the pre-master
secret for the session, encrypts it with the server's public key (obtained from the server's
certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.
If the server has requested client authentication (an optional step in the
handshake), the client also signs another piece of data that is unique to this
handshake and known by both the client and server. In this case, the client sends both the
signed data and the client's own certificate to the server along with the encrypted premaster secret.
If the server has requested client authentication, the server attempts to
authenticate the client. If the client cannot be authenticated, the session ends. If the client
can be successfully authenticated, the server uses its private key to decrypt the premaster secret, and then performs a series of steps (which the
client also performs, starting from the same pre-master secret) to generate the master
secret.
Both the client and the server use the master secret to generate the session keys,
which are symmetric keys used to encrypt and decrypt information exchanged during the
SSL session and to verify its integrity (that is, to detect any changes in the data between
the time it was sent and the time it is received over the SSL connection).
The client sends a message to the server informing it that future messages from the
client will be encrypted with the session key. It then sends a separate

13

(encrypted) message indicating that the client portion of the handshake is

finished.
The server sends a message to the client informing it that future messages from the
server will be encrypted with the session key. It then sends a separate (encrypted)
message indicating that the server portion of the handshake is finished.
The SSL handshake is now complete and the session begins. The client and the server use the
session keys to encrypt and decrypt the data they send to each other and to validate its integrity.
This is the normal operation condition of the secure channel. At any time, due to internal or
external stimulus (either automation or user intervention), either side may renegotiate the
connection, in which case, the process repeats itself.
This concludes the handshake and begins the secured connection, which is encrypted and
decrypted with the key material until the connection closes.
If any one of the above steps fails, the TLS handshake fails and the connection is not created.

DICOM- 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.

14

Fig: .dcm
Image
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.

Fig: MATLAB Command window for viewing DICOM

Images

15

DICOM IMAGE DISPLAY

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

DICOM 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.

16

 STORE
The DICOM Store service is used to send images or other persistent objects
(structured reports, etc.) to a 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 PACS.
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 to help ensure consistency
between various display devices, including hard copy printout.

17

 OFF-LINE MEDIA (DICOM FILES)

The off-line media files describe 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. 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 (multipurpose internet mail extensions) 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.
DICOM TRANSMISSION PROTOCOL 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 TCP or 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.

18

IHE INTEGRATION PROFILES

The IHE initiative is designed to bridge the gap. Under IHE healthcare professional, including
members of its sponsoring organizations, the Healthcare Information and Management Society
(HIMSS) and the Radiological Society of North America (RSNA), identify the integration
capabilities they need to work efficiently to provide patient care.

19

IHE has defined ten integration profiles as of its 2002-2003 cycle. The description of the profiles
is given below includes the clinical problems addressed and the general categories of
information and imaging involved.
SCHEDULED WORKFLOW (SWF)
The Scheduled workflow integration profile establishes a seamless flow of information
that supports efficient patient care work-flow in a typical imaging encounter. It specifies
transactions that maintain the consistency of patient information from registration
through ordering, scheduling, imaging acquisition, storage and viewing.

PATIENT INFORMATION RECONCILIATION (PIR)

The Integration Profile extends Scheduled Workflow by providing the means to match
images acquired for an unidentified patient with the patients registration and order
history.
Enterprise-wide information system that manages patient registration and
services ordering ( ADT/registration system, HIS)
Radiology department information system that manages department
scheduling (RIS) and image management/archiving (PACS)
Acquisition modalities

Fig: Patient Information Reconciliation

 CONSISTENT PRESENTATION OF INFORMATION (CPI)

The CPI Integration Profile specifies a number of transactions that maintain the
consistency of presentation for gray scale images and their presentation state
information. It also defines a standard contrast curve, the Grayscale Standard Display
Function, against which different types of display and hardcopy output devices can be
calibrated. Thus it supports hardcopy, softcopy and mixed environments.
The systems included in this profile are hospital wide and radiology department image
rendering systems such as:
Review or diagnostic image softcopy display stations (stand-alone or
integrated with a HIS, RIS or PACS)
Image Management and archiving systems (PACS)
Hardcopy image producing systems on various media such as film or paper.
Acquisition modalities.

Fig: Consistent Presentation of Information

 PRESENTATION OF GROUPED PROCEDURES (PGP)

The PGP Integration Profile addresses the complex information management problems
entailed when the information for multiple procedures is obtained in a single acquisition
step. PGP provides the ability to view image subsets resulting from a single acquisition
and relate each image subset to a different requested procedure.
A single image set is produced, but the combined use of scheduled workflow and
consistent presentation of images transactions allows separate viewing and interpretation
of the subset of images related to each requested procedure.
The PGP Integration Profile extends the Scheduled Workflow Integration Profile and
the Consistent Presentation of Images Integration Profile. Systems involved include:
Acquisition modalities
Image management and archiving systems (PACS)
Radiology departmental information systems that manage department
scheduling (RIS)
Diagnostic image softcopy display stations( integrated with a RIS or a
PACS)

Fig: Presentation of Grouped Procedures

 ACCESS TO RADIOLOGY INFORMATION (ARI)

The Access to Radiology Information Integration Profile specifies support for query
transaction providing access to radiology information, including images and related
reports. This is useful both to the radiology department and to other departments such
as pathology, surgery and oncology. Non radiology information may also be
accessed if made available in DICOM format.
This profile includes both enterprise-wide and radiology department imaging and
reporting systems such as:

Review or diagnostic image softcopy display stations

Reporting stations
Image management and archiving systems (PACS)
Report repositories

Fig: Access to Radiology Information

KEY IMAGE NOTE

The Key Image Note Integration Profile enables the user to flag one or more images
from a link with the study. The images flagged are inserted with a user comment field
stating the purpose of the flagged images. These notes are

Properly stored, archived and displayed as the images move among systems that
support the integration profile.
This integration profile includes both the departmental imaging systems and the
hospital-wide image distribution systems such as:
Review or diagnostic image softcopy display stations
Image management and archiving systems (PACS)
Acquisition Modalities

Fig: Key Image Note

(KIN)

SIMPLE IMAGE AND NUMERIC REPORT (SINR)

The Simple Image and Numeric Report Integration profile facilitates the use of
technological advances like voice recognition and specialized reporting packages, by
separating the functions of reporting into discrete actors for creation, management,
storage and viewing. Separating these functions while

Defining transactions to exchange the reports between them enables a vendor to include
one or more of these functions in an actual system.
The reports exchanged have a simple structure: a title; an observation context; and one
or more sections each with a heading, text, image references, and optionally, coded
measurements.
This Integration profile involves both the department imaging and reporting systems and
hospital wide information systems such as:
Review or diagnostic image softcopy display stations (stand-alone or integrated
with a HIS, RIS, PACS or Modality)
Reporting stations (stand-alone or integrated with a HIS, RIS PACS or
Modality)
Report Management systems (stand-alone or integrated with a HIS, RIS, PACS
or Modality)
Report repositories (stand-alone or integrated with a HIS, RIS or PACS)

Fig: Simple Image and Numeric Reporting

(SINR)

 POST PROCESSING WORKFLOW (PWF)

The Post-Processing Workflow Integration Profile addresses the need to schedule and
track the status of the steps of the typical post-processing workflow, such as
Computer-Aided Detection or Image Processing. Work lists for each of these tasks are
generated and can be queried, work items can be selected and the resulting status
returned from the system performing the work to the system managing the work.
Image management and archiving systems (PACS)
Radiology departmental information systems that manage department
scheduling (RIS)
Diagnostic image softcopy display stations (integrated with RIS or PACS),
especially those that perform post-processing functions such as Computer-Aided
Detection and Image Processing.

Fig: Post Processing

Workflow

 CHARGE POSTING
The Charge Posting Integration Profile specifies the exchange of information related to
charges among departmental systems, enterprise-wide information systems and billing
systems. Departmental Systems provide billing with precise information about
procedures performed, while enterprise-wide information system provides information
about the patients demographics, accounts, insurance, and guarantors. The exchange
provides all of the procedure data required to generate a claim, resulting in more
complete, timely and accurate billing.

Fig: Workflow diagram of Charge Posting

Enterprise-wide information systems that manage patient registration and
services ordering (i.e. admit-discharge transfer/ registration system and hospital
information system)
Radiology department information systems that manage department
scheduling and image management/archiving.
billing systems

Fig: Charge
Posting
BASIC SECURITY
The Basic Security Integration Profile establishes basic security measures that can help
protect the confidentiality of patient information as a part of an institutions over-all
security policies and procedures. It provides institutions with a mechanism to consolidate
audit trail events on a user activity across several systems interconnected in a secure
manner.
The security measures defined in the Basic Security Integration Profile include user and
node authentication as well as audit transactions. To support these transactions, the IHE
framework defines a new actor, the Secure Node. A Secure Node actor is grouped with
other actors wishing to participate in transactions under the auspices of Basic Security.
The Secure Node actor is responsible for managing the authentication process between
itself and its partner and another IHE actor/Secure Node pair. A user, for example,
might log in to a review workstation that implements the Image Display actor combined
with a Secure Node actor. How the user is authenticated to the workstation is left to the
site and the vendor to decide. Once identified to the Image Display/Secure Node pair,
the user could, for example, request images from an Image Manager/Secure Node
pair. The two Secure Node actors

In this example would then perform an IHE-specified transaction to authenticate that

these two systems are indeed permitted to interact.

Fig: Basic
Security

These Integration Profiles have been developed and tested by vendors representing the imaging
and information systems market. These vendors and others have begun to offer IHE
integration capabilities in commercial products. Moreover, institutions worldwide have begun
using IHE Integration Profiles to acquire and implement integrated systems. IHE
Integration Profiles help users and vendors organize their integration priorities and communicate
about plans and requirements.

REFERENCES
Integrating the Healthcare enterprise
http://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise
http://www.ihe-europe.net/benefits-ihe/74/finding-ihe-profiles
http://healthcare.siemens.com/services/it-standards/ihe-integrating-the-healthcareenterprise
Basic DICOM Operations,
http://www.medicalconnections.co.uk/kb/Basic_DICOM_Operations
The Basic Structure of DICOM, www.sgsmp.ch/dicom/parisot1.pdf
Digital Imaging Communication in Medicine,
www.eng.tau.ac.il/~gannot/MI/Dicom.ppt