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