1. IT Infrastructure for the Enteprise Mike Henderson Principal Consultant, Eastern Informatics Past co-Chair, IT Infrastructure Technical Committee Charles Parisot GE Healthcare Co-Chair, IT Infrastructure Technical Committee

2. June 28-29, 2005Interoperability Strategy Workshop2 W W W. I H E. N E T Providers and Vendors Working Together to Deliver Interoperable Health Information Systems In the Enterprise and Across Care Settings

3. June 28-29, 2005Interoperability Strategy Workshop3 Integration Profiles PDQ PIX PAM EUA PWP PSA RID CT + ATNA (Already Addressed)

4. June 28-29, 2005Interoperability Strategy Workshop4 IT Infrastructure Profiles 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA) 2005 Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS) Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Cross-Enterprise User Authentication (XUA) Document Digital Signature (DSG) – Notification of Document Availability (NAV) Patient Administration/Management (PAM) Patient Demographic Query (PDQ) Patient name, Patient ID

5. June 28-29, 2005Interoperability Strategy Workshop5 Patient Demographics Query Abstract / Scope Allow quick retrieval of a patient list including common patient names, identifiers, contacts, and visit information Enable selection of correct patient when full identification data may not be available Limits access to only a subset of demographic and visit information

6. June 28-29, 2005Interoperability Strategy Workshop6 Patient Demographics Query Value Proposition Enables access on demand to diverse systems and devices –Participants that do not need continual synchronization of patient registration information –Devices that cannot participate in monitoring of ADT feeds, e.g.: Small-footprint devices Low-memory devices Allow search on full or partial data

7. June 28-29, 2005Interoperability Strategy Workshop7 Patient Demographics Query Transaction Diagram A departmental system that is connected on demand to the registration system. Diverse systems including bedside monitors, physician office systems, lab applications, mobile blood bank registries; might be any system at the point of contact. HL7 Version 2.5, Chapter 5

8. June 28-29, 2005Interoperability Strategy Workshop8 IT Infrastructure Profiles 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA) 2005 Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS) Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Cross-Enterprise User Authentication (XUA) Document Digital Signature (DSG) – Notification of Document Availability (NAV) Patient Administration/Management (PAM) Patient Identifier Cross-referencing for MPI (PIX) (Map patient identifiers across independent identification domains)

9. June 28-29, 2005Interoperability Strategy Workshop9 Patient Identifier Cross-referencing for MPI Abstract / Scope Allow all enterprise participants to register the identifiers they use for patients in their domain Participants retain control over their own domain’s patient index(es) Support domain systems’ queries for other systems’ identifiers for their patients Optionally, notify domain systems when other systems update identifiers for their patients

10. June 28-29, 2005Interoperability Strategy Workshop10 Patient Identifier Cross-referencing for MPI Value Proposition Maintain all systems’ identifiers for a patient in a single location Use any algorithms (encapsulated) to find matching patients across disparate identifier domains Lower cost for synchronizing data across systems –No need to force identifier and format changes onto existing systems Leverages standards and transactions already used within IHE

11. June 28-29, 2005Interoperability Strategy Workshop11 Patient Identifier Cross-referencing for MPI Patient Identification Domain A Patient Identification Domain C Id=X456 Id=Y921 Id=D456 Id=DF45 Patient Identification Cross - reference Domain Patient Identification Domain B Id=123 Id=235 Id=3TY Id=2RT Patient Identity Cross-reference Manager B:X456 =C:2RT A:123 =B:Y921 =C:3TY B:D456 A:235 =B:DF45 A:678 Patient Identity Consumer B:X456 C: 2RT Identity Patient Cross References B:X456 C: ?

12. June 28-29, 2005Interoperability Strategy Workshop12 PIX Integration Profile & MPI The typical view Patient Identification Domain C Patient Identity Cross- reference Manager Patient Identification Domain A (Master Domain) Patient Identification Domain B Master (A) Patient Identity Source Master Patient Index

13. June 28-29, 2005Interoperability Strategy Workshop13 IT Infrastructure Profiles 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA) 2005 Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS) Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Cross-Enterprise User Authentication (XUA) Document Digital Signature (DSG) – Notification of Document Availability (NAV) Patient Administration/Management (PAM) Patient Administration & Management (PAM) Patient Identification, Admission, Movements & Encounters

14. June 28-29, 2005Interoperability Strategy Workshop14 Patient Administration Management Abstract / Scope Coordinates exchange of patient registrations, updates, and movements for all clinical areas Information may be received and processed by consumer applications in any clinical domain Optionally allows unambiguous updating of historic patient movement events Demographic and encounter tracking works in both inpatient and ambulatory care settings

15. June 28-29, 2005Interoperability Strategy Workshop15 Patient Administration Management Value Proposition Optional support levels allow products to offer “light” or “rich” functionality Aligns legacy IHE Radiology and IT Infrastructure transactions with the latest HL7 standard –Permits robust error reporting and automated exception processing Standardizes on HL7 conformance structures –Reduces variance among vendor and implementor specification formats

16. June 28-29, 2005Interoperability Strategy Workshop16 Patient Administration Management Transaction Diagram Patient Demographics Source Patient Demographics Consumer Patient Encounter Source Patient Encounter Consumer Patient Identity Feed Patient Encounter Management

17. June 28-29, 2005Interoperability Strategy Workshop17 Patient Administration Management Actor Grouping Requirements

18. June 28-29, 2005Interoperability Strategy Workshop18 Patient Administration Management Standards Used HL7 Version 2.5 –ADT Registration, Update, and Patient Movement Trigger Events Admission/registration Merge, update, link/unlink Movement management

19. June 28-29, 2005Interoperability Strategy Workshop19 Patient Administration Management Actors Patient Demographics Source –Definition Responsible for maintaining demographics (name, address, etc.) about patient and related persons Supplies new and updated information to Patient Demographics Consumer –Transaction Supported - Required Patient Identity Feed [ITI-30] (as sender)

20. June 28-29, 2005Interoperability Strategy Workshop20 Patient Administration Management Actors Patient Demographics Consumer –Definition Uses demographic information provided by the Patient Demographics Source about a patient –Transaction Supported – Required Patient Identity Feed [ITI-30] (as receiver)

21. June 28-29, 2005Interoperability Strategy Workshop21 Patient Administration Management Actors Patient Encounter Source –Definition Responsible for maintaining encounter information about a patient Supplies new and updated information to the Patient Encounter Consumer Must be grouped with either Patient Demographics Source or Patient Demographics Consumer –Transaction Supported - Required Patient Encounter Management [ITI-31] (as sender)

22. June 28-29, 2005Interoperability Strategy Workshop22 Patient Administration Management Actors Patient Encounter Consumer –Definition Uses patient encounter information provided by Patient Encounter Source –Transaction Supported - Required Patient Encounter Management [ITI-31] (as receiver)

23. June 28-29, 2005Interoperability Strategy Workshop23 Patient Administration Management Patient Id Mgt Transactions Patient Identity Feed [ITI-30] –Definition Patient Demographics Source registers or updates patient Forwards ID, address, NOK, guarantor, etc., to other systems implementing Patient Demographics Consumer –Options Merge Link/Unlink

24. June 28-29, 2005Interoperability Strategy Workshop24 Patient Administration Management Patient Encounter Mgt Transactions Patient Encounter Management [ITI-31] –Definition Patient Encounter Source registers or updates an encounter Forwards encounter information to other systems implementing Patient Encounter Consumer –Location –Providers –Dates, times, etc. –Options Inpatient/Outpatient Encounter Management Pending Event Management Advanced Encounter Management Temporary Patient Transfer Tracking Historic Movement Management

25. June 28-29, 2005Interoperability Strategy Workshop25 Patient Administration Management Encounter Management Options Inpatient/Outpatient Encounter Management –HL7 Trigger Events Admit inpatient (A01/A11) Register outpatient (A04/A11) Discharge patient (A03/A13) Update patient information (A08) Pre-admit patient (A05/A38) Change outpatient to inpatient (A06) Change inpatient to outpatient (A07) Transfer patient (A02/A12)

26. June 28-29, 2005Interoperability Strategy Workshop26 Patient Administration Management Encounter Management Options Pending Event Management –Additional HL7 Trigger Events Pending admit (A14/A27) Pending transfer (A15/A26) Pending discharge (A16/A25)

27. June 28-29, 2005Interoperability Strategy Workshop27 Patient Administration Management Encounter Management Options Advanced Encounter Management –Additional HL7 Trigger Events Change attending doctor (A54/A55) Leave of absence (A21/A52) Return from leave of absence (A22/A53) Move account information (A44) Merge patient ID list (A40)

28. June 28-29, 2005Interoperability Strategy Workshop28 Patient Administration Management Encounter Management Options Temporary Patient Transfers Tracking –Additional HL7 Trigger Events Patient departing – tracking (A09/A33) Patient arriving – tracking (A10/A32)

29. June 28-29, 2005Interoperability Strategy Workshop29 Patient Administration Management Encounter Management Options Historic Movement Management –Uses trigger events of any of the above options that have been adopted –Adds ZBE segment to contain a unique identifier for the movement Standard segment pending adoption by HL7 –Adds Z99 trigger event to allow update of any movement information, based on unique ID in ZBE segment Standard trigger event pending adoption by HL7

30. June 28-29, 2005Interoperability Strategy Workshop30 IT Infrastructure Profiles 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA) 2005 Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS) Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Cross-Enterprise User Authentication (XUA) Document Digital Signature (DSG) – Notification of Document Availability (NAV) Patient Administration/Management (PAM) Enterprise User Authentication (EUA) Single user name & centralized authentication

31. June 28-29, 2005Interoperability Strategy Workshop31 Enterprise User Authentication Scope Support a single enterprise governed by a single set of security policies and having a common network domain. Establish one name per user to be used for all IT applications and devices. Facilitate centralized user authentication management. Provide users with single sign-on.

32. June 28-29, 2005Interoperability Strategy Workshop32 Enterprise User Authentication Value Proposition Meet a basic security requirement –User authentication is necessary for most applications and data access operations. Achieve cost savings/containment –Centralize user authentication management –Simplify multi-vendor implementations Provide workflow improvement for users –Increase user acceptance through simplicity –Decrease user task-switching time. More effective security protection –Consistency and simplicity yields greater assurance.

33. June 28-29, 2005Interoperability Strategy Workshop33 Enterprise User Authentication Use Case: Single Sign On Motivation –Users need to frequently communicate with many non- integrated IT application services. –Managing multiple user identities and passwords is costly to users and system administration. Solution –EUA supports a single common user identity for browser-based applications. –EUA allows multiple user authentication technologies. –EUA uses well-trusted standardized user identity mechanisms: Kerberos and CCOW user context.

34. June 28-29, 2005Interoperability Strategy Workshop34 Enterprise User Authentication Transaction Diagram

35. June 28-29, 2005Interoperability Strategy Workshop35 Enterprise User Authentication Transaction Diagram: CCOW Option

36. June 28-29, 2005Interoperability Strategy Workshop36 IT Infrastructure Profiles 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA) 2005 Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS) Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Cross-Enterprise User Authentication (XUA) Document Digital Signature (DSG) – Notification of Document Availability (NAV) Patient Administration/Management (PAM) Personnel White Pages (PWP) Access to workforce contact information

37. June 28-29, 2005Interoperability Strategy Workshop37 Personnel White Pages (PWP) – Abstract/Scope Provide access to basic information about the human workforce members –Does not include Patients Defines method for finding the PWP Defines query/access method Defines attributes of interest

38. June 28-29, 2005Interoperability Strategy Workshop38 Personnel White Pages (PWP) – Value Proposition Single Authoritative Knowledge Base –Reduce duplicate and unconnected user info database –Single place to update Name Changes New Phone Number Additional Addresses Enhance Workflow and Communications –Providing information necessary to make connections Phone Number Email Address Postal Address

39. June 28-29, 2005Interoperability Strategy Workshop39 Personnel White Pages (PWP) – Value Proposition Enhance User Interactions –Provide user friendly identities and lists List of members Displayable name of a user Initials query Contributes to Identity Management –Additional methods of identity cross verification Name, address, phone number, email Cross reference with Enterprise User Authentication identity –Future expansion likely will contain certificates

40. June 28-29, 2005Interoperability Strategy Workshop40 PWP - Transactions Personnel White Pages Consumer Query for Healthcare Workforce Member Info Provide access to healthcare staff information to systems in a standard manner. Personnel White Pages Directory DNS Server Find Personnel White Pages

41. June 28-29, 2005Interoperability Strategy Workshop41 IT Infrastructure Profiles 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA) 2005 Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS) Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Cross-Enterprise User Authentication (XUA) Document Digital Signature (DSG) – Notification of Document Availability (NAV) Patient Administration/Management (PAM) Patient Synchronized Applications (PSA) Tune multiple applications to same patient

42. June 28-29, 2005Interoperability Strategy Workshop42 Abstract / Scope Patient Synchronization of Multiple Disparate Applications Single Patient Selection When combined with PIX Profile, allows patient synchronization across patient identifier domains When combined with EUA Profile, provides user Single Sign-on (SSO) Patient Synchronized Applications

43. June 28-29, 2005Interoperability Strategy Workshop43 Value Proposition User Convenience: –Eliminates the repetitive task of selecting the patient in each application –Permits the user to select the patient in the application for which they are most familiar and / or appropriate to the clinical workflow Patient Safety: –Ensures all data being viewed across applications is for the same patient Leverage Single Development Effort: –Allows vendors to leverage single CCOW enablement effort to support multiple actors: Patient Context Participant (PSA) User Context Participant (EUA) Patient Synchronized Applications

44. June 28-29, 2005Interoperability Strategy Workshop44 Patient Synchronized Applications Actors Context Manager Actor The IHE Context Manager Actor may encompass more than a CCOW context manager function. It may include a number of other components such as the context management registry and patient mapping agent. Patient Context Participant Actor The Patient Context Participant Actor shall respond to all patient context changes. This actor shall set the patient context provided the application has patient selection capability.

45. June 28-29, 2005Interoperability Strategy Workshop45 Transactions Diagram Patient Synchronized Applications These transactions are required by both Actors to claim compliance

46. June 28-29, 2005Interoperability Strategy Workshop46 Simple Patient Switching Process

47. June 28-29, 2005Interoperability Strategy Workshop47 IT Infrastructure Profiles 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA) 2005 Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS) Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Cross-Enterprise User Authentication (XUA) Document Digital Signature (DSG) – Notification of Document Availability (NAV) Patient Administration/Management (PAM) Retrieve Information for Display (RID) Access patient clinical summaries in presentation format

48. June 28-29, 2005Interoperability Strategy Workshop48 Simple and rapid access to patient information Access to existing persistent documents in well-known presentation formats: CDA, PDF, JPEG. Access to specific key patient-centric information for presentation to a clinician : allergies, current medications, summary of reports, etc.. Links with other IHE profiles - Enterprise User Authentication, Patient Identifier Cross-referencing and Cross Enterprise Document Sharing Retrieve Information for Display Abstract / Scope

49. June 28-29, 2005Interoperability Strategy Workshop49 User Convenience: –Healthcare providers can "see" the information. A significant integration step. –Workflows from within the users ’ on-screen workspace or application. –Complements multiple simultaneous apps workflow of Patient Synchronized Apps Broad Enterprise-Wide access to information: –Web technology for simple clients –Clinical data handling fully assumed by the information source that holds clinical data. Retrieve Information for Display Value Proposition

50. June 28-29, 2005Interoperability Strategy Workshop50 Standards Used: –Web Services (WSDL for HTTP Get). –General purpose IT Presentation Formats: XHTML, PDF, JPEG, CDA L1 (HL7) –Client may be off-the-shelf browser or display application. Two services : –Retrieve of Specific Information: Patient centric: patient ID Type of Request (see next slide) Date, Time, nMostRecent –Retrieve a Document Object Unique Instance Identifier (OID) Type of Request Content Type Expected Retrieve Information for Display Key Technical Properties

51. June 28-29, 2005Interoperability Strategy Workshop51 Transaction Diagram Retrieve Information for Display Display Information Source Retrieve Specific Info for Display [11] Summary of Laboratory Reports Summary of Radiology Reports Summary of Cardiology Reports Summary of Surgery Reports Summary of Intensive Care Reports Summary of Emergency Reports Summary of Discharge Reports List of Allergies List of Medications Retrieve Document for Display [12] Persistent Document Types of Requests Summary of All Reports Summary of Prescriptions

52. June 28-29, 2005Interoperability Strategy Workshop52 Retrieve Information for Display Retrieved Data Presentation and Format - Non Persistent Data Content and Presentation is left to the Information Source Actor. - Persistent Data Documents are provided by the Information Source Actor in one of the Display Actor proposed formats: JPEG, PDF, CDA L1

53. June 28-29, 2005Interoperability Strategy Workshop53 IT Infrastructure Profiles 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA) 2005 Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS) Audit Trail and Note Authentication (ATNA) Personnel White Pages (PWP) 2006 Cross-Enterprise User Authentication (XUA) Document Digital Signature (DSG) – Notification of Document Availability (NAV) Patient Administration/Management (PAM) Audit Trail and Node Authentication (ATNA) – Centralized privacy audit trail and node to node authentication to create a secured domain Consistent Time (CT) – Coordinate time across network systems

54. June 28-29, 2005Interoperability Strategy Workshop54 ATNA Value Proposition Protect Patient Privacy and System Security: –Meet ethical and regulatory requirements Enterprise Administrative Convenience: –Unified and uniform auditing system –Common approach from multiple vendors simplifies definition of enterprise policies and protocols. –Common approach simplifies administration Development and support cost reduction through Code Re-use: –Allows vendors to leverage single development effort to support multiple actors –Allows a single development effort to support the needs of different security policies and regulatory environments.

55. June 28-29, 2005Interoperability Strategy Workshop55 ATNA Security Requirements Reasons: Clinical Use and Privacy –authorized persons must have access to medical data of patients, and the information must not be disclosed otherwise. –Unauthorized persons should not be able to interfere with operations or modify data By means of procedures and security mechanisms, guarantee: –Confidentiality –Integrity –Availability –Authenticity

56. June 28-29, 2005Interoperability Strategy Workshop56 ATNA Security Measures Authentication:Authentication: Establish the user and/or system identity, answers question: “Who are you?” ATNA defines: How to authenticate network connections. ATNA Supports: Authentication mechanisms, e.g. Enterprise User Authentication (EUA) or Cross Enterprise User Authentication (XUA).. Authorization and Access control:Authorization and Access control: Establish user’s ability to perform an action, e.g. access to data, answers question: “Now that I know who you are, what can you do?” ATNA defines: How to authorize network connections. ATNA requires: System internal mechanisms for both local and network access.

57. June 28-29, 2005Interoperability Strategy Workshop57 ATNA Security Measures Accountability and Audit trail:Accountability and Audit trail: Establish historical record of user’s or system actions over period of time, answers question: “What have you done?” ATNA Defines: Audit message format and transport protocol

58. June 28-29, 2005Interoperability Strategy Workshop58 ATNA IHE Goal IHE makes cross-node security management easy: –Only a simple manual certificate installation is needed, although more sophisticated systems can be used –Separate the authentication, authorization, and accountability functions to accommodate the needs of different approaches. –Enforcement driven by ‘a posteriori audits’ and real- time visibility.

59. June 28-29, 2005Interoperability Strategy Workshop59 ATNA Integrating Trusted Nodes System A System B Secured System Secure network Strong authentication of remote node (digital certificates) network traffic encryption is not required, it is optional Secured System Local access control (authentication of user) Audit trail with: Real-time access Time synchronization Central Audit Trail Repository

60. June 28-29, 2005Interoperability Strategy Workshop60 ATNA Node Authentication X.509 certificates for node identity and keys TCP/IP Transport Layer Security Protocol (TLS) for node authentication, and optional encryption Secure handshake protocol of both parties during Association establishment: –Identify encryption protocol –Exchange session keys Actor must be able to configure certificate list of authorized nodes. ATNA presently specifies mechanisms for HTTP, DICOM, and HL7

61. June 28-29, 2005Interoperability Strategy Workshop61 ATNA Auditing System Designed for surveillance rather than forensic use. Two audit message formats –IHE Radiology interim format, for backward compatibility with radiology –IETF/DICOM/HL7/ASTM format, for future growth DICOM Supplement 95 IETF Draft for Common Audit Message ASTM E.214 HL7 Audit Informative documents Both formats are XML encoded messages, permitting extensions using XML standard extension mechanisms.

62. June 28-29, 2005Interoperability Strategy Workshop62 What it takes to be a secure node The entire host must be secured, not just individual actors. The entire host must have appropriate user access controls for identification, authentication, and authorization. All communications that convey protected information must be authenticated and protected from interception. This means every protocol, not just the IHE transactions. All health information activities should generate audit trails, not just the IHE actors.

63. June 28-29, 2005Interoperability Strategy Workshop63 IHE and PHI Protection User Identity → PWP, EUA User Authentication → EUA, XUA Node Authentication → ATNA Security Audit Trails → ATNA Data Integrity Controls → CT, ATNA TLS option Data Confidentiality → ATNA TLS option Access Controls → Future item in IHE roadmap

64. June 28-29, 2005Interoperability Strategy Workshop64 More information…. IHE Web sites: www.ihe.net www.ihe.net Technical Frameworks, Supplements ITI V1.0, RAD V5.5, LAB V1.0 Non-Technical Brochures : Calls for Participation IHE Fact Sheet and FAQ IHE Integration Profiles: Guidelines for Buyers IHE Connect-a-thon Results Vendor Products Integration Statements