Summer Internship Experience
Project Report On
-Study of industry Standards used in RadiologyAt 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 ManoriaAmod Bansal
Chief Manager (Sales)2nd yr (101205008)
Siemens IndiaEIED
GurgaonThapar University, Patiala
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 co- operation 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. The500-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 worldsFirst 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-Siemens-Hausgerate-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 the
worlds first electric streetcar (1881).The first national
subsidiary was established in Russia in 1855, followed by an
English subsidiary in 1858.
11
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 world- leading 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
applicationsScheduling Applicationssyngo 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 ofsyngo.via-based software options which are medical
devices in their own right.
Although some pre-requisites include:An Internet connection to
clinical networkDICOM COMPLIANCEMeeting 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 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".
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 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.
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
version-numbered 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.
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 EngineeringTask 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."
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.
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, session-specific 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, session-specific data, and other information that the
client needs to communicatewith 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-mastersecret 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 thishandshake 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 pre-master
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
pre-master secret, and then performs a series of steps (which
theclient 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
(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.
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
DICOM IMAGE DISPLAY
To promote identical gray scale 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 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.
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.
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 InternetAssigned 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 CommunicationLayer (ISCL) over TCP or UDP 2762
registered port for DICOM using Transport Layer Security (TLS)
overTCP 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.
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.
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 modalitiesImage management and archiving systems
(PACS)Radiology departmental information systems that manage
department scheduling (RIS)Diagnostic image softcopy display
stations( integrated with a RIS or aPACS)
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 stationsReporting
stationsImage 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 stationsImage
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 orModality)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
enterprisehttp://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprisehttp://www.ihe-europe.net/benefits-ihe/74/finding-ihe-profileshttp://healthcare.siemens.com/services/it-standards/ihe-integrating-the-healthcare-enterpriseBasic
DICOM
Operations,http://www.medicalconnections.co.uk/kb/Basic_DICOM_OperationsThe
Basic Structure of DICOM, www.sgsmp.ch/dicom/parisot1.pdfDigital
Imaging Communication in
Medicine,www.eng.tau.ac.il/~gannot/MI/Dicom.ppt