1 / 12

ITI Security Profiles – ATNA, CT

ITI Security Profiles – ATNA, CT. IHE Vendors Webinar 2006 IHE IT Infrastructure Education Robert Horn, Agfa Healthcare. IT Infrastructure Profiles. 2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT)

jpadilla
Download Presentation

ITI Security Profiles – ATNA, CT

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. ITI Security Profiles – ATNA, CT IHE Vendors Webinar 2006 IHE IT Infrastructure Education Robert Horn, Agfa Healthcare

  2. 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 Document Digital Signature (DSG) Notification of Document Availability (NAV) Patient Administration/Management (PAM) 2007 Basic Patient Privacy Consents (BPPC)

  3. ATNA Assets protected • Patient and Staff Safety • ATNA provides minor protections by restricting network access • Most safety related protection is elsewhere in products. Security activity must not interfere with safety. • Patient and Staff Health • As with Safety, ATNA provides minor health protection and must not interfere. • Patient and Staff Privacy • Access Control at the node level can be enforced. • Audit Controls at the personal level are supported. • Note that in Europe there are significant staff privacy protections, not just patient privacy protections, in the laws.

  4. ATNA Node Authentication • Authentication: • 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: • ATNA defines: network connections shall be access controlled. • ATNA requires: System internal mechanisms for both local and network access controls. ATNAdoes not specify policy. See the XDS security presentation from the workshop for an example of the kind of policy that ATNA expects to support. The node authentication ensures that only known partners that share the security policy and cooperate in its implementation are granted access.

  5. ATNA Audit Trail • Accountability and Audit trail:Establish historical record of user’s or system actions over period of time • ATNA Defines: Audit message format and transport protocol

  6. Secure Node Secure Node Actor • Restricted access by login (if applicable to the product) • All access to private information is audited. • Protects PHI • Tests will be defined by project managers.

  7. ATNA Node Authentication • X.509 certificates for node identity and keys • Be prepared for simultaneous use of both CA and self-signed certificates. • Be prepared to accept or replace certificates on very short notice. • TCP/IP Transport Layer Security Protocol (TLS) for node authentication, and optional encryption • TLS is not SSL. • TLS is available from: OpenSSL (which includes both SSL and TLS), as part of Microsoft’s .NET, Sun and IBM’s Java implementations, and other sources.

  8. ATNA Node Authentication • TLS Encryption options: • IHE mandates a minimum mandatory set to ensure that a compatible pair will exist. • Additional encryption options may be implemented • TLS specifies how the encryption will be selected from the proposed list. It need not be one of the IHE minimum set. • Some environments permit NULL encryption (e.g., internal radiology operations). Others do not (e.g., XDS). • ATNA presently specifies mechanisms for using TLS with HTTP, DICOM, and HL7. • DICOM toolkits incorporate TLS support • Some HL7 libraries incorporate TLS support • Some web servers (e.g. Tomcat, Apache) incorporate TLS support.

  9. ATNA Auditing System • Designed for surveillance rather than forensic use. This is not a substitute for internal product detailed logs. • 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 • New profile work will utilize the new schema for messages, so use the new schema unless there is a product need for compatibility with the Radiology interim format.

  10. ATNA Auditing System • Both formats are XML encoded messages, permitting extensions using XML standard extension mechanisms. • Do not redefine current attributes or elements • Only extend when existing attributes or elements are insufficient • Document the source schema for extensions and make it freely available because audit repositories will need it. • If there might be messages using different schema from a single system, use the source field in the syslog message to distinguish the format. All messages from a specific source must use the same schema.

  11. ATNA Record Audit Event • BSD Syslog protocol (RFC 3164) will be part of the Connectathon infrastructure. • Support messages up to 32768 bytes long. • Clients should be configurable to send to any port and destination. • IETF continues to resolve issues surrounding Reliable Syslog (RFC 3195). There will be no connectathon support of testing Reliable Syslog, but private testing may take place.

  12. Consistent Time (CT) • Network Time Protocol ( NTP) version 3 (RFC 1305) for time synchronization • Actor must support manual configuration for NTP sources. • Required accuracy: 1 second • Options: • SNTP (Simple Network Time Protocol) • Secure NTP

More Related