Your SlideShare is downloading. ×
Interoperability Between Healthcare Applications
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Interoperability Between Healthcare Applications

4,652
views

Published on


0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,652
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
215
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Interoperability between Heterogeneous Healthcare Information Systems John Gillson ICW Labs
  • 2. Interoperability
    • What is interoperability in the healthcare informatics domain?
    • ” Interoperability is the ability of heterogeneous healthcare information systems and software applications to communicate, to exchange data accurately, effectively, and consistently, and to use the information that has been exchanged” Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project; Dogac, Namli,Okcan, Laleci, Kabak and Eichelberg; pg. 1; http://www.ehealthnews.eu/images/stories/pdf/ride.pdf
  • 3. A Lack of Interoperability
    • There is currently a major challenge for the healthcare industry in achieving interoperability among applications provided by different vendors
    • Each hospital department or medical clinic may use multiple applications to share clinical and administrative information among applications
    • These applications could be legacy applications or state-of-the-art applications
    • Unfortunately, each application may support multiple communications interfaces that must be continually modified and maintained
    • Achieving interoperability among heterogeneous healthcare information systems is very important because it will reduce costs associated with healthcare and will contribute to more effective and efficient patient treatment, management, and care
  • 4. Message Interoperability - Health Level Seven (HL7)
    • HL7 version 2.x (HL7 v2.x) application protocol for electronic data exchange is the industry standard for transporting clinical and administrative information between heterogeneous healthcare applications
    • The standard is based on the concept of application-to-application message exchange
    • HL7 version 3 (HL7 v3), like HL7 v2.x, is a standard for exchanging messages among information systems that implement healthcare applications
    • As a main difference to HL7 v2.x, HL7 v3 adopts an Object Oriented (OO) approach using Unified Modeling Language (UML) principles which is based on a data model called the Reference Information Model (RIM)
    • HL7 messages are XML documents that can be validated against XML schemas derived from the conceptual models
    • Unfortunately as it stands right now, there is an interoperability problem between HL7 v2.x and HL7 v3 messages because there is no well-defined mapping between these messages
  • 5. Message Interoperability - Reference Information Model (RIM)
    • HL7’s RIM is a “static model of healthcare information representing the aspects of the healthcare domain undertaken so far by HL7 standards development activities”
    • The HL7 v3 standard development process defines rules used to implement and derive domain-specific information models from the RIM, finally generating XML schema definitions (XSD) associated with a particular message type
    • The HL7 RIM standard “provides a substantial level of message functionality between applications by structuring envelopes which support message exchange between applications
    • HL7 message envelopes are called wrappers , initially modeled by defining classes and relationships in the RIM
    • These specifications are then used to create the XML schema for the message wrappers, following a process outlined in the HL7 Message Development Framework” [4]
  • 6. Message Interoperability - RIM continued…
    • Within the RIM, all HL7 messages are embedded into a Transmission Wrapper
    • The Transmission Wrapper is there in order to identify and transfer the message
    • Sender applications use the Control Act Wrapper to communicate receiving information about the event that triggered the exchanged message
    • The Control Act Wrapper is there to decide what to do with the message, and is part of the message semantics
    • Transmission Wrappers and Control Act Wrappers are used as envelopes for the Message Body
    • The Message Body consists of the data to be used to perform the requested action
    • Together, the Control Act Wrapper and the HL7 Message Body constitute the complete semantics of HL7 Messages
  • 7.
    • The RIM is the ultimate source from which all HL7 v3 protocol specification standards draw their information related content
    Message Interoperability - RIM continued… Source: Web Services Enablement for Healthcare HL7 Applications - Regio
  • 8. HL7 functionalities – Business Logic component
    • SENDER
    • “ Create an XML representation of a specific HL7 Message Type that includes Body, Control Wrapper, and Transmission Wrapper
    • Pass that message to the Web Service Adapter for its transmission to the Receiver Application” [4]
    • RECEIVER
    • “ Retrieve the HL7 Message received by the Web Service Adapter, and unfold the Transmission Wrapper, Control Wrapper, and Message Body from the received XML Message
    • Verify the HL7 Message satisfies the business rules and constraints for that Interaction
    • Check if the Sender Application required an Application Level Acknowledge (HL7 Message Type MCI) and – in that case – send that message” [4]
  • 9. HL7 functionalities – Business Logic component Source: Web Services Enablement for Healthcare HL7 Applications - Regio
  • 10. HL7 functionalities – Web Service Adapter component
    • SENDER
    • “ Read the Transmission Wrapper of received HL7 Messages to determine how to reach the ultimate recipient (for example Receiver Application) on the Web Services Infrastructure, configuring the SOAP Envelope accordingly
    • Based on HL7 Message Type, application configuration and policies (for example, security) prepare a SOAP message, containing the HL7 XML message as a SOAP body part to be sent over the Web Services Infrastructure
    • Pass the SOAP Message to the Web service proxy for transmission on the wire
    • Get ready to receive and – optionally – store related Accept or Application Level acknowledgement messages from the Receiver, whenever requested by the Sender” [4]
    • RECEIVER
    • “ Receive the SOAP message from the Web Service stub
    • Verify the received SOAP message satisfies application configuration and policies constraints (for example, security)
    • Possibly store the received message in a a persistent form of memory
    • Optionally unfold the HL7 XML message from the SOAP message and check schema compliance for the received HL7 Message with the expected HL7 Message Type
    • Verify if any communication (Accept) level acknowledgement needs to be performed, and in that case prepare an appropriate message to be sent to the original Message Sender.
    • Pass the HL7 Message to the Receiver Application” [4]
  • 11. HL7 functionalities – Business Logic component Source: Web Services Enablement for Healthcare HL7 Applications - Regio
  • 12. HL7 Patient Referral example Sarah Johnson 12345 HL7-v3 Patient Referral Network Transmitting 11011010 HL7-v3 Patient Referral 12345 Sarah Johnson ^ ^ Application 1: HIS Database and back end applications Application 2: HIS Database and back end applications Interface Engine Interface Engine Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac
  • 13. Communicating via Web Services Sarah Johnson 12345 <id> </id> <name> </name> <surname> </surname> </patient> <patient> Processing HL7- v3 Patient Referral Web Service Processing HTTP over TCP/IP Transmitting 11011010 <id> </id> <name> </name> <surname> </surname> </patient> <patient> HL7- v3 12345 Johnson Sarah Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac
  • 14. Electronic Healthcare Record (EHR)
    • The EHR of a patient is represented as a digitally stored healthcare information record about an individual’s lifetime with the purpose of supporting continuity of care, education and research, and ensuring confidentiality at all times
    • A number of standardization efforts are in place to provide the interoperability of EHRs such as CEN/TC EHRcom, openEHR, and HL7 Clinical Document Architecture (CDA)
    • Standards such as CEN/TC 251 EHRcom, openEHR, and CDA aim to structure and markup the clinical content for the purpose of patient data exchange
    • There is also an industry initiative called Integrating the Healthcare Enterprise (IHE) which specifies the Cross-Enterprise Document Sharing (XDS) integration profile for this purpose
    • As previously discussed with HL7 messaging, considerable clinical information about a patient is passed around through the messages exchanged among healthcare applications
    • So what are the differences between the patient data contained in an HL7 message compared with the patient data contained in an EHR?
    • The differentiation is evident because an EHR is the collection of relevant data about an individual’s lifetime usually in a document structure
  • 15. GEHR/openEHR Initiative
    • This approach uses a two-level methodology to model the EHR structure
    • In the first level, a generic reference model that is specific to the healthcare domain is developed and contains only a few classes (e.g. role, act, entity, participation)
    • In the second level, healthcare and application specific concepts such as blood pressure, cholesterol, blood glucose, lab results, etc. are modeled as archetypes
    • An archetype definition basically consists of three parts: descriptive data, constraint rules, and ontological definitions
    • Descriptive data types include parameters for containing a unique identifier for the archetype, a machine-readable code describing the clinical concept modeled by the archetype
    • Constraint rules are the core of the archetype and define restrictions on the valid structure and content of the EHR record
    • Ontological definitions define the controlled vocabulary or machine-readable codes that can be used in specific instances of the archetype
  • 16. CEN/TC 251 and ENV/EN 13606 EHRcom
    • A message-based standard for the exchange of electronic healthcare records.
    • It consists of five parts :
      • The Reference Model,
      • Archetype Interchange Specification,
      • Reference Archetypes and Term Lists,
      • Security Features, and
      • Exchange Models (communication protocol).
  • 17. HL7 Clinical Document Architecture (CDA)
    • The HL7 CDA is a document markup standard that specifies the structure and semantics of “clinical documents” for the purpose of exchange
    • A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content
    • CDA documents are encoded in XML
    • CDA is organized into three levels where each level iteratively adds more structure to clinical documents
    • Level One focuses on the content of narrative documents with high-level context such as parties, roles, dates and time, places and structural organization of headings
    • Level Two models the fine-grained observations and instructions within each heading through a set of RIM Act classes
    • Level Three specifies semantics each information entity by a unique code which enables machine processing
  • 18. IHE Cross-Enterprise Document Sharing (XDS)
    • There is also an industry initiative called Integrating the Healthcare Enterprise (IHE) which specified the Cross-Enterprise Document Sharing (XDS) integration profile for this purpose
    • The basic idea of IHE XDS is to store healthcare documents in an ebXML registry/repository architecture to facilitate their sharing
    • IHE XDS handles healthcare documents in a content neutral way
  • 19. IHE Retrieve Information for Display (RID)
    • RID provides a simple and rapid read-only access to patient-centric clinical information that is located outside the user's current application
    • Supports access to documents with CDA Level One, PDF and JPG formats
    • It is defined as a Web service by providing its WSDL description with a binding to HTTP GET
  • 20. Summary of EHR Standards Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac IHE XDS profile is content neutral; it does not specify how content should be structured and encoded. However, IHE continues to specify further profiles and one recent profile IHE XDS MS HL7 specifies medical summaries based on HL7 CDA standards and CRS CDA implementation IHE RID profile d oes n ot specify content; it s upports access t o existing p ersistent documents in well- k nown presentation formats such as CDA Level One, PDF and JPEG. CDA is organized into Three levels: “Level One“ Focuses on the content of n arrative documents; is only human readable. Level Two CDA models the fine-grained o bservations a nd instructions within each heading through a set of RIM Act classes. A completely structured document where the semantics of each i nformation entity is specified by a unique code will only be possible with “ Level Three&quot;. A reference m odel and the d ata structures for EHR content are d efined . EHR Content IHE XDS IHE RID HL7 CDA EHRcom
  • 21. Summary of EHR Standards Source: Key Issues of Technical Interoperability Solutions in eHealth; Dogac In IHE XDS, the network and transport protocol is Internet; the messaging protocol is ebXML messaging (SOAP with attachments) over HTTP or SMTP (email) The network and transport protocol is Internet; the messaging protocol is Web services (http GET). HL7 CDA does not define how EHRs can be communicated; t he specification states that CDA documents can be transmitted in HL7 messages (in OBX segment) designed to transfer clinical documents. The Message package, which i s u nder d evelopment as EN 13606-5, will define how to c ommunicate t he EHR extract to a requesting process. EHR Communication Layer IHE XDS IHE RID HL7 CDA EHRcom
  • 22. Master Patient Index (MPI)
    • A component which allows for generating a unique patient ID in heterogeneous patient management systems
    • Demographic patient data can be connected across hospital boundaries aiming at the integration of different application systems
    • Serves as the basis for a cross-facility electronic patient record
    • Automatically link local data set from various source systems to unique patient identifications – extensive editing options
    • Create and edit data sets
    • Identify and import data set changes
  • 23. Master Patient Index (MPI) ‏ Main Patient Data Sarah Johnson ID = 1, H X Sarah Johnson ID = 63, MPI Sarah Johnson ID = 47, GP Y Jack Smith ID = 23, H X Jack Smith ID = 84, MPI Jack Smith ID = 1, GP Y GP Y Local Patient Data Hospital X MPI - Business Logic Sarah Johnson ID = 1 Sarah Johnson ID = 47 Jack Smith ID = 23 Jack Smith ID = 1
  • 24. MPI - New Admission Hospital 1 New admission Master Patient Index (MPI) ‏ New index patient New Sarah Johnson ID = 1, Hospital 1 Sarah Johnson ID = 67, MPI Sarah Johnson ID = 1 Recycle Sarah Johnson ID = 1, Hospital 1 Map Sarah Johnson ID = 1, Hospital 1 Sara Johnston ID = 13, MPI Recycle Bin
  • 25. MPI - Change of Patient Data Set Master Patient Index (MPI) ‏ Keep ? Decide Sarah Johanson ID =1, Hospital 1 Sarah Johnson ID = 67, MPI Sarah Johanson ID = 67, MPI Hospital 1 Changed data set Sarah Johanson ID = 1 Break up New Sarah Johanson ID =1, Hospital 1 Sarah Johnson ID = 67, MPI Sarah Johanson ID = 90, MPI ? Recycle Bin Recycle Sarah Johanson ID =1, Hospital 1 Break up mapping
  • 26. Virtual Medical Record (VMR)
    • Unified view of medical data from various source systems and personal health records
    • Centralized availability of medical data and encounters, as well as documents and images
    • Export medical data, such as diagnoses, procedures, medications and lab results
    • Extensive search and filter mechanisms
    • Upload documents; call up, fill in and edit forms
    • Standardized interface for integrated source systems – for bidirectional exchange of medical data
    • Web-based integration interface – seamless access to the EPR from third-part applications
  • 27. Combining MPI and VMR Virtual Medical Record (VMR) ‏ Master Patient Index (MPI) ‏ Jack Smith ID = 1, Hospital 2 ID = 47, Hospital 1 Jack Smith ID = 47, Hospital 1 Jack Smith ID = 1, Hospital 2 Case 1 Document 1 Case 2 Case 3 Document 3 Document 5 Document 4 Document 2
  • 28. Healthcare Service Bus (HSB)
    • EMRs must be used and integrated into clinical practices to make disparate systems interoperable; this is where the HSB comes into the picture
    • The HSB is a healthcare-specific services integration platform based on the Enterprise Service Bus (ESB); these are sometimes also referred to as a Medical Service Bus (MSB)
    • The HSB is built on ESB technology, providing extra features and enriched services specific to the healthcare domain; these services will provide rich, complex and high-value communication in geographically dispersed environments or inter-organization applications
    • HSB will provide a rich bundle of core platform services to enable rapid development; it will enable applications to easily consume services of third party services
    • For example, using the HSB, clinical and billing systems can be integrated using sophisticated workflows
  • 29. HSB landscape
  • 30. Achieving Interoperability
    • With all these technologies we have talked about thus far, how would an application achieve interoperability among the vast possibilities of technologies used to facilitate an interoperable, heterogeneous healthcare informatics domain?
    • The answer would most readily be found in an application called Professional Exchange Server (PXS) developed by InterComponentWare, Inc. (ICW)
  • 31. CASE STUDY Professional Exchange Server (PXS)
    • Allowing for smooth data flow across institutions and sectors, PXS aims at allowing a holistic view of medical data from heterogeneous systems and electronic medical records
    • PXS essentially bridges the gap between different organizations within the healthcare informatics domain
    • By bridging the gap between disparate healthcare informatics systems, PXS enables highly integrated care scenarios across different healthcare sectors
    • By linking local patient data sets and automatic cross-organizational patient identifications, PXS provides a unified patient view on medical patient data across organizations
    • PXS is not meant to replace systems or procedures, but rather to non-invasively leverage the existing messaging infrastructure
    • PXS integrated clinical information systems in a secure and controlled manner and enables the flow of information between doctors and hospitals
  • 32. PXS – Overview of Functionality
    • PXS consists of 4 key components and 1 adapter:
      • Master Patient Index (MPI)
      • Virtual Medical Record (VMR)
      • Medical Service Bus (MSB)
      • Document Management Adapter (DMA)
      • LifeSensor Adapter (LSA)
    • PXS offers an MPI to link together patient records referring to the same physical person
    • Through the VMR, retrieval of medical information on any patient in any hospital that the patient is associated is definitely possible
    • The MSB component is included as a plug-in to the local hospital’s communication server, which processes patient information and forwards this information to the MPI and VMR
    • The DMA correspondingly provides the patient record with access to the medical documents stored in the hospital’s primary systems
    • The LSA connects the VMR to the patient’s LifeSensor PHR and thus ensures a smooth exchange of information between hospitals, patients and physicians
  • 33. PXS – General architecture PXS Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Medical Service Bus (MSB) ‏ Document Management Adapter (DMA) ‏ Browser Patient Hospital HIS, RIS, PACS... Practitioner PCD, PVS... Hospital HIS, RIS, PACS... Practitioner PCD, PVS... P 1 Browser H 1 H n P n LifeSensor Adapter (LSA) HL7 HL7 HL7 HL7 HTTP HTTP Physician
  • 34. PXS - Hospital Group Connectivity Source: ICW Developer Network – New to ICW Professional Exchange Server
  • 35. PXS – Components PXS System Components Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Document Management Adapter (DMA) ‏ Medical Service Bus (MSB) ‏
  • 36. PXS – MPI
    • The MPI component allows for generating a unique patient ID, called an index patient , in heterogeneous patient management systems
    • Demographic patient data can be connected across hospital boundaries aiming at the integration of different hospital systems
    • The MPI is the basis and foundation for a cross-facility electronic patient record
    • For each patient record in the hospitals’ patient management systems, a local copy with the essential information needed for patient mapping is maintained inside the MPI database
    • These local copies of the patient data are referred to as data sets from the MPI perspective
    • These data sets can be mapped on a reference patient record to the aforementioned index patient
    • These mappings can link data sets of different hospitals with one index patient
  • 37. PXS – MPI continued…
    • Similarity of patient records is calculated using a flexible probabilistic model that assignes scored describing the degree of similarity
    • The MPI used a weighted probabilistic model of estimating the probability that the patient data sets refer to the same index patient
    • Each probability comparison is given a probability for these matches, and using mathematical algorithms, a score for a match, a non-match, and a missing value is computed
    • The scores of the individual comparisons are summarized and normalized into a range between 0 and 1
    • 0 means that all relevant attributes are different, 1 means that all relevant attributes are equal
    • As we discussed earlier the HL7 v3 messaging, the MPI receives HL7 v3 messages in order to maintain its internal data structures, e.g., admission, changing of data sets, modification and merge of patients
  • 38. PXS – MPI continued… Source: ICW Developer Network – New to ICW Professional Exchange Server
  • 39. PXS – Components PXS System Components Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Document Management Adapter (DMA) ‏ Medical Service Bus (MSB) ‏
  • 40. PXS – VMR
    • The VMR component gives access to demographic and medical patient data and documents for healthcare professionals
    • The VMR provides different views on various medical data such as encounters, diagnoses, observations, and documents of a patient
    • Document content is either copied into the VMR database or alternatively remains inside the primary system
    • The VMR then only maintains corresponding pointers or references to these documents within the primary systems
    • The functionality of the VMR allows for all medical records from all connected data sets to be assembled and displayed as a cross-facility patient record
  • 41. PXS – VMR continued… Source: ICW Developer Network – New to ICW Professional Exchange Server
  • 42. PXS – Components PXS System Components Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Document Management Adapter (DMA) ‏ Medical Service Bus (MSB) ‏
  • 43. PXS – DMA
    • Retrieving and displaying documents is done independently by the DMA.
    • The underlying technology of the DMA encapsulates all technical information and strategies to retrieving a document from its storage and controlling issues such as caching, format conversion, etc
    • The DMA allows patient documents to be accessed in the clinical information system
    • In order to be viewed in the VMR, the DMA must request from the primary system, the necessary documents
    • All common document formats are supported as well as CDA documents
    • The capabilities of the DMA are numerous; the DMA has internal caching facilities to display documents quickly and is capable of connecting various hospital primary systems and storage devices
    • The functionality extends further by offering connectivity for viewing and editing DICOM images stemming from Ultrasound, MRT or CT devices
  • 44. PXS - Components PXS System Components Master Patient Index (MPI) ‏ Virtual Medical Record (VMR) ‏ Document Management Adapter (DMA) ‏ Medical Service Bus (MSB) ‏
  • 45. PXS – MSB
    • The MSB component, embedded as a plug-in to the hospital’s communication server, establishes the connection between hospital information systems and the PXS components by setting up constraints for HL7 messaging
    • The MSB’s main functional task is to translate messages from the hospital environment into HL7 v3 messages, which is used by all components to import and export patient data
    • The translation of HL7 v2.x messages to HL7 v3 messages was illustrated earlier with regards to the interoperability issues between HL7 versions
    • The MSB is a very important component for providing these message translation services
    • In addition, the MSB manages the message routing, message buffering and translation of messages
  • 46. PXS – MSB continued…
  • 47. PXS – LSA
    • The LSA component allows for seamless integration of a hospital’s electronic patient record with the patient-centric LifeSensor PHR
    • Medical data and documents can be imported into the patient’s PHR and correspondingly, data and documents of the PHR can be imported into the hospital’s VMR
    • This bidirectional communication enables the seamless exchange of medical information between hospitals, patients, and physicians
    • The LifeSensor PHR is very important to the patient since this is his/her own view of their own medical data and documents
  • 48. References
    • [1] Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak and Eichelberg; pg. 1; http://www.ehealthnews.eu/images/stories/pdf/ride.pdf
    • [2] Towards Interoperable Healthcare Information Systems: The HL7 Conformance Profile Approach; Snelick, Rontey, Gebase, Carnahan; p. 2; http://www.itl.nist.gov/div897/ctg/messagemaker/papers/IESA2007.rsnelick.pdf
    • [3] Key Issues of Technical Interoperability Solutions in eHealth and the RIDE Project; Dogac, Namli, Okcan, Laleci, Kabak and Eichelberg; pg. 2; http://www.ehealthnews.eu/images/stories/pdf/ride.pdf
  • 49. References continued…
    • [4] Web Services Enablement for Healthcare HL7 Applications – Web Services Basic Profile Reference Implementation; Mauro Regio, Microsoft Corporation; http://msdn.microsoft.com/en-us/library/ms954603.aspx
    • [5] Aims of the openEHR Architecture http://www.openehr.org/releases/1.0.1/html/architecture/overview/Output/aims.html
    • [6] HL7 Clinical Document Architecture, Release 2.0 http://xml.coverpages.org/CDA-Release2-Unofficial.html
    • [7] Electronic Business using eXtensible Markup Language http://en.wikipedia.org/wiki/EbXML
    • [8] WS/PIDS: Standard Interoperable PIDS in Web Services Environments; Vasilescu, Dorobantu, Govoni, Padh, Ki Mun http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=04358877
  • 50. References continued…
    • [9] SNOMED CT http://en.wikipedia.org/wiki/SNOMED_CT
    • [10] LOINC http://en.wikipedia.org/wiki/LOINC
    • [11] Key Issues of Technical Interoperability Solutions in eHealth (IST-027065 RIDE Project); Dogac http://www.ehealthconference2006.org/pdf/DOGAC.pdf
    • [12] ICW Developer Network – PXS Technical Whitepaper (must be a registered member of the ICW Developer Network to view the documents) http://idn.icw-global.com/fileadmin/downloads/PRG/TechnicalWhitepaper_en_US_PRG_PXS__2.0_DE_en_US_2.0.pdf
    • [13] ICW Developer Network – New to ICW Professional Exchange Server http://idn.icw-global.com/solutions/icw-professional-suite/professional-exchange-server/new-to-pxs.html
  • 51. References continued…
    • [14] ICW Professional Suite – Professional Exchange Server http://www.icw-global.com/fileadmin/user_upload/pdf/brochures/icw-professional-suite/stuffer/icw-pxs-en.pdf