Post on 05-Jan-2016
IT Infrastructure for the Enteprise
IT Infrastructure for the Enteprise
Mike HendersonPrincipal Consultant, Eastern Informatics
Past co-Chair, IT Infrastructure Technical Committee
Charles ParisotGE Healthcare
Co-Chair, IT Infrastructure Technical Committee
June 28-29, 2005 Interoperability Strategy Workshop2
W W W . I H E . N E TW W W . I H E . N E T
Providers and VendorsWorking Together to Deliver
Interoperable Health Information SystemsIn the Enterprise
and Across Care Settings
June 28-29, 2005 Interoperability Strategy Workshop3
Integration ProfilesIntegration Profiles
• PDQ• PIX• PAM• EUA• PWP• PSA• RID • CT + ATNA (Already Addressed)
June 28-29, 2005 Interoperability Strategy Workshop4
IT Infrastructure ProfilesIT 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)
2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)
2006Cross-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
June 28-29, 2005 Interoperability Strategy Workshop5
Patient Demographics QueryPatient Demographics QueryAbstract / ScopeAbstract / 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
June 28-29, 2005 Interoperability Strategy Workshop6
Patient Demographics QueryPatient Demographics QueryValue PropositionValue 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
June 28-29, 2005 Interoperability Strategy Workshop7
Patient Demographics QueryPatient Demographics QueryTransaction DiagramTransaction Diagram
A departmental system that is A departmental system that is connected on demand to the connected on demand to the registration system.registration system.
Diverse systems including Diverse systems including bedside monitors, physician bedside monitors, physician office systems, lab applications, office systems, lab applications, mobile blood bank registries; mobile blood bank registries; might be any system at the point might be any system at the point of contact.of contact.
HL7 Version 2.5, Chapter 5
June 28-29, 2005 Interoperability Strategy Workshop8
IT Infrastructure ProfilesIT 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)
2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)
2006Cross-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)
June 28-29, 2005 Interoperability Strategy Workshop9
Patient Identifier Cross-referencing for MPIPatient Identifier Cross-referencing for MPIAbstract / ScopeAbstract / 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
June 28-29, 2005 Interoperability Strategy Workshop10
Patient Identifier Cross-referencing for MPIPatient Identifier Cross-referencing for MPIValue PropositionValue 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
June 28-29, 2005 Interoperability Strategy Workshop11
Patient Identifier Cross-referencing for MPIPatient 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: Y 921 = C: 3TY B :D456
A :235 = B: DF45 A:678
Patient Identity Consumer
B:X456C: 2RT
IdentityPatientCross References
B:X456C: ?
June 28-29, 2005 Interoperability Strategy Workshop12
PIX Integration Profile & MPIPIX Integration Profile & MPIThe typical viewThe typical view
Patient Identification Domain C
Patient Identity Cross-reference Manager
Patient Identification Domain A(Master Domain)
Patient Identification Domain B
Master (A) PatientIdentity Source
Master PatientIndex
June 28-29, 2005 Interoperability Strategy Workshop13
IT Infrastructure ProfilesIT 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)
2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)
2006Cross-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
June 28-29, 2005 Interoperability Strategy Workshop14
Patient Administration ManagementPatient Administration ManagementAbstract / ScopeAbstract / 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
June 28-29, 2005 Interoperability Strategy Workshop15
Patient Administration Management Patient Administration Management Value PropositionValue 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
June 28-29, 2005 Interoperability Strategy Workshop16
Patient Administration Management Patient Administration Management Transaction DiagramTransaction Diagram
Patient Demographics
SourcePatient Demographics
Consumer
Patient Encounter Source
Patient Encounter Consumer
Patient Identity Feed
Patient Encounter Management
June 28-29, 2005 Interoperability Strategy Workshop17
Patient Administration Management Patient Administration Management Actor Grouping RequirementsActor Grouping Requirements
OR
Patient Demographics Source
Patient Demographics Consumer
Patient Encounter Source
Patient Encounter Consumer
← Patient Identity Feed [ITI-030]
→ Patient Encounter Management [ITI-031]
Patient Demographics Consumer
Patient Encounter Source
Patient Encounter Consumer
Patient Demographics Source
→ Patient Identity Feed [ITI-030]
→ Patient Encounter Management [ITI-031]
June 28-29, 2005 Interoperability Strategy Workshop18
Patient Administration Management Patient Administration Management Standards UsedStandards Used
HL7 Version 2.5– ADT Registration, Update, and Patient Movement
Trigger Events• Admission/registration• Merge, update, link/unlink• Movement management
June 28-29, 2005 Interoperability Strategy Workshop19
Patient Administration Management Patient Administration Management ActorsActors
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)
June 28-29, 2005 Interoperability Strategy Workshop20
Patient Administration Management Patient Administration Management ActorsActors
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)
June 28-29, 2005 Interoperability Strategy Workshop21
Patient Administration Management Patient Administration Management ActorsActors
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)
June 28-29, 2005 Interoperability Strategy Workshop22
Patient Administration Management Patient Administration Management ActorsActors
Patient Encounter Consumer– Definition
• Uses patient encounter information provided by Patient Encounter Source
– Transaction Supported - Required• Patient Encounter Management [ITI-31] (as receiver)
June 28-29, 2005 Interoperability Strategy Workshop23
Patient Administration Management Patient Administration Management Patient Id Mgt TransactionsPatient 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
June 28-29, 2005 Interoperability Strategy Workshop24
Patient Administration Management Patient Administration Management Patient Encounter Mgt TransactionsPatient 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
June 28-29, 2005 Interoperability Strategy Workshop25
Patient Administration Management Patient Administration Management Encounter Management OptionsEncounter 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)
June 28-29, 2005 Interoperability Strategy Workshop26
Patient Administration Management Patient Administration Management Encounter Management OptionsEncounter Management Options
Pending Event Management– Additional HL7 Trigger Events
• Pending admit (A14/A27)• Pending transfer (A15/A26)• Pending discharge (A16/A25)
June 28-29, 2005 Interoperability Strategy Workshop27
Patient Administration Management Patient Administration Management Encounter Management OptionsEncounter 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)
June 28-29, 2005 Interoperability Strategy Workshop28
Patient Administration Management Patient Administration Management Encounter Management OptionsEncounter Management Options
Temporary Patient Transfers Tracking– Additional HL7 Trigger Events
• Patient departing – tracking (A09/A33)• Patient arriving – tracking (A10/A32)
June 28-29, 2005 Interoperability Strategy Workshop29
Patient Administration Management Patient Administration Management Encounter Management OptionsEncounter 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
June 28-29, 2005 Interoperability Strategy Workshop30
IT Infrastructure ProfilesIT 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)
2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)
2006Cross-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
June 28-29, 2005 Interoperability Strategy Workshop31
Enterprise User AuthenticationEnterprise User AuthenticationScopeScope
• 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.
June 28-29, 2005 Interoperability Strategy Workshop32
Enterprise User AuthenticationEnterprise User AuthenticationValue PropositionValue 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.
June 28-29, 2005 Interoperability Strategy Workshop33
Enterprise User Authentication Enterprise User Authentication Use Case: Single Sign OnUse 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.
June 28-29, 2005 Interoperability Strategy Workshop34
Enterprise User AuthenticationEnterprise User AuthenticationTransaction DiagramTransaction Diagram
June 28-29, 2005 Interoperability Strategy Workshop35
Enterprise User AuthenticationEnterprise User AuthenticationTransaction Diagram: CCOW OptionTransaction Diagram: CCOW Option
June 28-29, 2005 Interoperability Strategy Workshop36
IT Infrastructure ProfilesIT 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)
2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)
2006Cross-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
June 28-29, 2005 Interoperability Strategy Workshop37
Personnel White Pages (PWP) – Personnel White Pages (PWP) – Abstract/ScopeAbstract/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
June 28-29, 2005 Interoperability Strategy Workshop38
Personnel White Pages (PWP) – Personnel White Pages (PWP) – Value PropositionValue 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
June 28-29, 2005 Interoperability Strategy Workshop39
Personnel White Pages (PWP) – Personnel White Pages (PWP) – Value Proposition 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
June 28-29, 2005 Interoperability Strategy Workshop40
PWP - TransactionsPWP - Transactions
PersonnelWhitePages
ConsumerQuery for Healthcare Workforce Member Info
Provide access to healthcare staff informationProvide access to healthcare staff information to systems in a standard manner. to systems in a standard manner.
PersonnelWhite Pages
Directory
DNS Server
Find PersonnelWhite Pages
June 28-29, 2005 Interoperability Strategy Workshop41
IT Infrastructure ProfilesIT 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)
2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)
2006Cross-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
June 28-29, 2005 Interoperability 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 ApplicationsPatient Synchronized Applications
June 28-29, 2005 Interoperability 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 ApplicationsPatient Synchronized Applications
June 28-29, 2005 Interoperability Strategy Workshop44
Patient Synchronized ApplicationsPatient Synchronized ApplicationsActorsActors
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.
June 28-29, 2005 Interoperability Strategy Workshop45
Transactions Diagram
Patient Synchronized ApplicationsPatient Synchronized Applications
These transactions are required by both Actors to claim compliance
June 28-29, 2005 Interoperability Strategy Workshop46
Simple Patient Switching ProcessSimple Patient Switching Process
Change Context [6]
Follow Context [13]
Patient Context Participant 1 (clinical data repository)
Context Manager
User closes application
Join Context [5]
Patient Context Participant 2 (cardiology)
Join Context [5]
Change Context [6]
Follow Context [13]
Leave Context [7]
Leave Context [7]
User closes application
User selects patient A
User selects patient B
Application tunes to patient A
June 28-29, 2005 Interoperability Strategy Workshop47
IT Infrastructure ProfilesIT 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)
2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)
2006Cross-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
June 28-29, 2005 Interoperability 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 DisplayRetrieve Information for DisplayAbstract / ScopeAbstract / Scope
June 28-29, 2005 Interoperability 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 DisplayRetrieve Information for DisplayValue PropositionValue Proposition
June 28-29, 2005 Interoperability 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 DisplayRetrieve Information for DisplayKey Technical PropertiesKey Technical Properties
June 28-29, 2005 Interoperability Strategy Workshop51
Transaction Diagram
Retrieve Information for DisplayRetrieve Information for Display
Display InformationSource
Retrieve Specific Info for Display [11]
Summary of Laboratory Reports
Summary of Radiology ReportsSummary of Cardiology ReportsSummary of Surgery ReportsSummary of Intensive Care ReportsSummary of Emergency ReportsSummary of Discharge ReportsList of AllergiesList of Medications
Retrieve Document for Display [12]
Persistent Document
Types ofRequests
Summary of All Reports
Summary of Prescriptions
June 28-29, 2005 Interoperability Strategy Workshop52
Retrieve Information for DisplayRetrieve 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
June 28-29, 2005 Interoperability Strategy Workshop53
IT Infrastructure ProfilesIT 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)
2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)
2006Cross-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 domainConsistent Time (CT) – Coordinate
time across network systems
June 28-29, 2005 Interoperability Strategy Workshop54
ATNAATNAValue PropositionValue 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.
June 28-29, 2005 Interoperability Strategy Workshop55
ATNAATNASecurity RequirementsSecurity 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
June 28-29, 2005 Interoperability Strategy Workshop56
ATNAATNASecurity MeasuresSecurity 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.
June 28-29, 2005 Interoperability Strategy Workshop57
ATNAATNASecurity MeasuresSecurity 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
June 28-29, 2005 Interoperability Strategy Workshop58
ATNAATNAIHE GoalIHE 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.
June 28-29, 2005 Interoperability Strategy Workshop59
ATNAATNAIntegrating Trusted NodesIntegrating Trusted Nodes
System A System B
Secured SystemSecure 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 TrailRepository
June 28-29, 2005 Interoperability Strategy Workshop60
ATNAATNANode AuthenticationNode 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
June 28-29, 2005 Interoperability Strategy Workshop61
ATNAATNAAuditing SystemAuditing 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.
June 28-29, 2005 Interoperability Strategy Workshop62
What it takes to be a secure nodeWhat 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.
June 28-29, 2005 Interoperability Strategy Workshop63
IHE and PHI ProtectionIHE 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
June 28-29, 2005 Interoperability Strategy Workshop64
More information….More information….
• IHE Web sites: 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