1. September, 2005What IHE Delivers 1 G. Claeys, Agfa Healthcare (geert.claeys@agfa.com) Audit Trail and Node Authentication

2. 2 Scope Defines basic security features for a system in a healthcare enterprise in order to guarantee :  Only authorized persons have access to PHI (Protected Health Information)  Protect PHI against alteration, destruction and loss  Comply existing Privacy & Security regulations Extends the IHE radiology oriented Basic Security profile (2002) to be applicable to other healthcare uses.

3. 3 Security Mechanism Authentication (user and device) Authorization Accountability (audit trails) Confidentiality Integrity ATNA, EUA ATNA

4. 4 IHE ATNA- Architecture System A System B Secured System Secure network Secured System Central Audit Trail Repository Secure network Local authentication of user Strong authentication of remote node (digital certificates) Audit trail that logs privacy&security related operations

5. 5 All existing IHE actors need to be grouped with a Secure Node actor. Secure Node Audit Record Repository “Any” IHE actor Record Audit Event Time Server Secure Node Authenticate Node Maintain Time IHE ATNA – Actor and Transactions

6. 6 Secure Node Local user authentication  Only needed at “client” node  Authentication mechanism User name and password (minimum) Biometrics, smart card  Secure nodes maintain list of authorized users : local or central (using EUA)  Security policy of hospital defines the relation between user and user id

7. 7 Secure Node (cont.) Mutual device authentication  Establish a trust relationship between 2 network nodes  Strong authentication by exchanging X.509 certificates  Actor must be able to configure certificate list of trusted nodes. TCP/IP Transport Layer Security Protocol (TLS)  Used with DICOM/HL7/HTTP messages  Secure handshake protocol during Association establishment:  Encryption : Intra-muros (default): no encryption Extra-muros : AES128 TLS/SSL negotiations problems were detected at connectathon 2006 USA  Caused by incorrect configuration of SSL/TLS packages (e.g. STunnel)  Guidelines will follow

8. 8 Secure node – additional effort Instrument all applications to detect auditable events and generate audit messages. Ensure that all communications connections are protected (system hardening). Establish a local security mechanism to protect all local resources Establish configuration mechanisms for:  Time synchronization  Certificate management  Network configuration

9. 9 Certificate Management Certificates can be signed by device (self-signing) or via a CA (e.g. hospital)  Use self-signed certificates for testing interoperability  Connectathon has a CA Support at least direct comparison of certificates  Import certificate of each trusted peer device  Compare each received certificate with list of trusted certificate Certificate management white paper  from NEMA’s Security&Privacy committee  www.nema.org/prod/med/security

10. 10 Auditing System Auditing system consists of  List of events that generate audit messages  Audit message format  Transport mechanism Designed for surveillance rather than forensic use.

11. 11 Audit Events Audit triggers are defined for every operation that access PHI (create, delete, modify, import/export) IHE TF describes the supported Audit Trigger per Actor Audit triggers are grouped on transaction/ study level to minimize overhead

12. 12 Audit Message Format XML encoded message IHE Radiology Provisional format  for backward compatibility with radiology ATNA format  Preferred format  Joint effort of IETF/DICOM/HL7/ASTM  XML schema (rfc3881) : www.xml.org/xml/schema/7f0d86bd/healthcare-security- audit.xsd www.xml.org/xml/schema/7f0d86bd/healthcare-security- audit.xsd XSLT transformation is provided to convert “Provisional scheme” to “ATNA” scheme

13. 13 Audit Transport Mechanism Reliable Syslog – cooked mode  RFC 3195  Connection oriented  Support certificate based authentication, encryption  But limited industry support BSD Syslog protocol (RFC 3164)  Preferred transport mechanism for the time being

14. 14 Backward compatibility ATNA is backward compatible with Basic Security (IHE Radiology)  Basic security = Provisional XML scheme + BSD syslog  Applications, supporting Basic Security are ATNA compliant Basic security is deprecated  Basic Security Profile being deprecated by Radiology Option for ATNA  No further extensions  New applications are encouraged to use new message format

15. 15 Audit system - lessons learned BSD Syslog  Ensure that the BSD header format is correct, otherwise the messages may get trashed.  BSD Syslog messages longer than 1k may get truncated -> keep the messages short Date/Time : UTC format  EventDateTime="2006-01-17T17:01:25-06:00“ or  EventDateTime="2006-01-17T17:01:25-06:00Z“ Patient ID  Use either the MRN (preferred) or a properly defined local Patient ID.  Patient Names can be arbitrary format.

16. 16 Audit system - lessons learned (cont.) Active Participant Identification  Use one ActiveParticipant per event  Use an identifiable user as ActiveParticipant  If not possible then use the node/process as ActiveParticipant Node names  Use host names instead of ip addresses Audit Source Id :  hostname or stationName

17. 17 Audit system - lessons learned (cont.) Event Identification (EventID):  use DCM code set (DICOM supplement 95) or IHE code set (ATNA)  avoid proprietary values. Schema checking  Ensure that the messages conform to the schema defined in RFC3881  Do not include schema items with null contents.

18. 18www.ihe-europe.org Frequently Asked Questions Integration Profiles in Technical Frameworks:  Cardiology  IT Infrastructure  Laboratory  Patient Care Coordination  Radiology Connectathon Results Vendor Products Integration Statements Participation in Committees & Connectathons