1 / 22

Integrating the Healthcare Enterprise

This workshop explores the integration of healthcare enterprise audit trails and node authentication to create a secure domain, protect patient privacy, and meet regulatory requirements. It also discusses the benefits of centralized authentication and the use of common security measures across multiple vendors.

Download Presentation

Integrating the Healthcare Enterprise

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Integrating the Healthcare Enterprise Audit Trail and Node Authentication Robert Horn Agfa Healthcare IHE Interoperability Workshop

  2. IHE IT Infrastructure 2004-2005 Personnel White Page New Access to workforcecontact information New Retrieve Information for Display Retrieve Information for Display Cross-Enterprise Document Sharing Access a patient’s clinical information and documents in a format ready to be presentedto the requesting user Access a patient’s clinical information and documents in a format ready to be presentedto the requesting user Registration, distribution and access across health enterprises of clinical documents forming a patient electronic health record Patient Demographics Query New Audit Trail & Node Authentication New Centralized privacy audit trail and node to node authentication to create a secured domain. Enterprise User Authentication Enterprise User Authentication Consistent Time Provide users a single nameand centralized authentication processacross all systems Coordinate time across networked systems Patient Synchronized Applications Synchronize multiple applications on a desktop to the same patient Patient Identifier Cross-referencing for MPI Patient Identifier Cross-referencing for MPI Map patient identifiers across independent identification domains Map patient identifiers across independent identification domains IHE Interoperability Workshop

  3. IHE IT Infrastructure 2004-2005 Personnel White Page New Access to workforcecontact information New Retrieve Information for Display Retrieve Information for Display Cross-Enterprise Document Sharing Access a patient’s clinical information and documents in a format ready to be presentedto the requesting user Access a patient’s clinical information and documents in a format ready to be presentedto the requesting user Registration, distribution and access across health enterprises of clinical documents forming a patient electronic health record Patient Demographics Query New Audit Trail & Node Authentication New Centralized privacy audit trail and node to node authentication to create a secured domain. Enterprise User Authentication Enterprise User Authentication Consistent Time Provide users a single nameand centralized authentication processacross all systems Coordinate time across networked systems Patient Synchronized Applications Synchronize multiple applications on a desktop to the same patient Patient Identifier Cross-referencing for MPI Patient Identifier Cross-referencing for MPI Map patient identifiers across independent identification domains Map patient identifiers across independent identification domains IHE Interoperability Workshop

  4. IHE and HIPAA Security • 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 IHE Interoperability Workshop

  5. Scope • Defines basic security features for an individual system for use as part of the security and privacy environment for a healthcare enterprise. • Extends the IHE radiology oriented Basic Security profile (defined in 2002) to be applicable to other healthcare uses. • Supports two categories of network environments • Part of a family of profiles with different kinds of authentication, also including EUA and XUA. IHE Interoperability Workshop

  6. ATNA Profile - 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. IHE Interoperability Workshop

  7. 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 IHE Interoperability Workshop

  8. Security measures • 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 controlEstablish 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. IHE Interoperability Workshop

  9. Security measures • Accountability and Audit trailEstablish 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 IHE Interoperability Workshop

  10. IHE Goal IHE makes cross-node security management easy: • Only a simple manual certificate installation is needed. • Separate the authentication, authorization, and accountability functions to accommodate the needs of different approaches. • Enforcement driven by ‘a posteriori audits’ and real-time visibility. IHE Interoperability Workshop

  11. Integrating trusted nodes • Local access control (authentication of user) • Strong authentication of remote node (digital certificates) • network traffic encryption is not required, it is optional • Audit trail with: • Real-time access • Time synchronization Secured System Secured System Secure network System B System A Central Audit TrailRepository IHE Interoperability Workshop

  12. Secured Domain: integrating trusted nodes Other Actors Other Actors Other Actors Other Actors Secured Node Actor Central Audit TrailRepository Other Actors Other Actors Other Actors Other Actors TimeServer Secured Node Actor Secured Node Actor Secure Node Actor IHE Interoperability Workshop

  13. Network Environments • Physically secured networks • Explicit physical security preventing access by other nodes, or • VPN and VLAN technologies that provide equivalent network isolation. • Protected networks • Physical security that prevents modification or installation of unauthorized equipment • The network is shared with other authorized nodes within the enterprise that should not have unrestricted access to patient information. • Unprotected networks • Not generally supported, although nodes with sufficient node level security and using encryption may be safe. IHE Interoperability Workshop

  14. Node Security • ATNA specifies some of the capabilities that are needed, e.g. access control. • ATNA does not specify policies • ATNA does not specify mechanisms, although other IHE protocols like EUA are obvious candidates. • This permits vendors and enterprises to select technologies and policies that are appropriate to their own purposes without conflicting with the ATNA profile. IHE Interoperability Workshop

  15. 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. IHE Interoperability Workshop

  16. IHE Audit Trail EventsCombined list of IETF and DICOM events IHE Interoperability Workshop

  17. IHE Audit Trail EventsCombined list of IETF and DICOM events IHE Interoperability Workshop

  18. IHE Audit Trail EventsCombined list of IETF and DICOM events IHE Interoperability Workshop

  19. Authenticate Node transaction • 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 IHE Interoperability Workshop

  20. Record Audit Event transaction • Reliable Syslog (RFC 3195) is the preferred transport for Audit Records, although BSD Syslog protocol (RFC 3164) is permitted for backward compatibility with Radiology Basic Security. • Audit trail events and content based on IETF, DICOM, HL7, and ASTM standards. Also, Radiology Basic Security audit event format is allowed for backward compatibility. IHE Interoperability Workshop

  21. What it takes to be a secure node • The Secure node is not a simple add-on of an auditing capability. The larger work effort is: • Instrumenting all applications to detect auditable events and generate audit messages. • Ensuring that all communications connections are protected. • Establishing a local security mechanism to protect all local resources. • Establishing configuration mechanisms for: • Time synchronization • Certificate management • Network configuration • Implement the audit logging facility IHE Interoperability Workshop

  22. More information…. • IHE Web sites: http://www.himss.org/IHE http://www.rsna.org/IHE http://www.acc.org/quality/ihe.htm. • Technical Frameworks: • ITI V1.0, RAD V5.5, LAB V1.0 • Technical Framework Supplements - Trial Implementation • May 2004: Radiology • August 2004: Cardiology, IT Infrastructure • 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 IHE Interoperability Workshop

More Related