IHE IT Infrastructure Technical Framework Supplement. Add RESTful Query to ATNA. Draft for Public Comment

Transcription

1 Integrating the Healthcare Enterprise 5 IHE IT Infrastructure Technical Framework Supplement 10 Add RESTful Query to ATNA 15 Draft for Public Comment 20 Date: June 8, 2015 Author: IHE ITI Technical Committee iti@ihe.net 25 Please verify you have the most recent version of this document. See here for Trial Implementation and Final Text versions and here for Public Comment versions. Copyright 2015: IHE International, Inc.

2 Foreword This is a supplement to the IHE IT Infrastructure Technical Framework V11.0. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks. This supplement is published on June 8, 2015 for public comment. Comments are invited and can be submitted at In order to be considered in development of the trial implementation version of the supplement, comments must be received by July 8, This supplement describes changes to the existing technical framework documents. Boxed instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume. Amend Section X.X by the following: Where the amendment adds text, make the added text bold underline. Where the amendment removes text, make the removed text bold strikethrough. When entire new sections are added, introduce with editor s instructions to add new text or similar, which for readability are not bolded or underlined General information about IHE can be found at: Information about the IHE IT Infrastructure domain can be found at: Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at: and The current version of the IHE IT Infrastructure Technical Framework can be found at: Rev Copyright 2015: IHE International, Inc.

3 CONTENTS Introduction to this Supplement... 6 Open Issues and Questions... 6 Closed Issues... 6 General Introduction Appendix A - Actor Summary Definitions Appendix B - Transaction Summary Definitions Glossary Volume 1 Profiles Audit Trail Processing and Use Cases Use Cases Use Case #1 Study Change Tracking use-case Studies Change Tracking use-case Use Case #2 Clinician Personal History of Study views Clinician Personal History of Study views Use Case #3: Data Export Monitoring for administrative and efficiency purposes Exporting Data Monitoring for administrative and efficiency purposes Use Case #4: Patient access to his audit records Patient access to his audit records Use Case Description Use Case #5: Statistical Analysis and Monitoring of EHR Usage Statistical Analysis and Monitoring of EHR Usage Use Case #6: Centralized Warning Alert Audit Facility Centralized Warning Alert Audit Facility Technical Approach Actors/Transactions ATNA Integration Profile Options Filter and Forward Option Retrieve Audit Message Option RESTful ATNA Query Security Considerations ATNA Cross Profile Considerations Required Actor Groupings Volume 2 Transactions Report Audit Event Scope Actor Roles Referenced Standards Interaction Diagram Record Audit Event Trigger Events DICOM and IHE event reports Other event reports Rev Copyright 2015: IHE International, Inc.

4 Audit Message Transports Transmission of Syslog Messages over TLS Reliable Syslog (deprecated) Transmission of Syslog Messages over UDP (formerly:bsd Syslog) Message Semantics Audit Message Formats IHE Audit Trail Message Format RoleIDCode with access control roles Audit Encoding of the Purpose of Use value RFC-3881 format (Deprecated) Expected Actions Security Considerations retired retired Controlled Terminology for IHE Extensions XX Retrieve ATNA Audit Event [ITI-xx] XX.1 Scope XX.2 Actor Roles XX.3 Referenced Standards XX.4 Interaction Diagram XX.4.1 Retrieve ATNA Audit Events XX Trigger Events XX Message Semantics XX Date Query Parameters XX Additional ATNA Query Parameters XX Populating Expected Response Format XX Expected Actions XX.4.2 Retrieve ATNA Audit Event Response Message XX Trigger Events XX Message Semantics XX FHIR encoded bundle of Audit Events Messages XX Expected Actions XX Profile Resource XX Conformance Resource XX.5 Security Considerations XX.5.1 Security Audit Considerations XY Retrieve Syslog Event XY.1 Scope XY.2 Use Case Roles XY.3 Referenced Standard XY.4 Interaction Diagram XY.4.1 Retrieve Syslog Event Request XY Trigger Events Rev Copyright 2015: IHE International, Inc.

5 XY Message Semantics XY Date Query Parameters XY Additional Query Parameters XY Expected Actions XY.4.2 Syslog Event Response Message XY Trigger Events XY Message Semantics XY JSON encoded array of Syslog Messages XY Expected Actions XY.5 Security Considerations XY.5.1 Security Audit Considerations Rev Copyright 2015: IHE International, Inc.

6 Introduction to this Supplement Event logging is a system facility that is used by healthcare applications and other applications. This supplement adds two optional capabilities to the Audit Record Repository (ARR): A Filter and Forward Option to relay selected event reports from one ARR to another. A RESTful query capability. Open Issues and Questions 1. Readers are asked to evaluate to what extent filters should be specified and required within the Filter and Forward Option. Do they seem to be applicable to any implementation that claims this option? 2. There is the possibility to extend this filter capability requirement aligning the type of mandatory filters with mandatory query parameter defined for Audit Record Query transaction (see Section 9.3.2). 3. Only a JSON return format is specified for Retrieve Syslog Messages [ITI-XY]. It delivers a slightly parsed form of the syslog message that makes JSON attributes in a structure that corresponds to the structure define by syslog. Should other forms be supported? Should the unparsed syslog message be returned? 4. Should there be retrieve methods to get most recent N events? This would be a nondeterministic and constantly varying response in most cases. 5. Should a server information query be specified? There are various RFCs from the IETF that specify aspects of server information. 6. Should support of the /.well-known/ path RFC5785 be required or described in transactions ITI-XX and ITI-XY? (This can be an alternative to more complete server information.) For example, PACS servers providing restful access to DICOM objects may respond to /.well-known/dicom in addition to a fully specified URL path. 7. Should the server be required to error for lack of a time period in ITI-XX and ITI-XY or should this be weakened to should or recommend or may? Closed Issues 1. This supplement is being written as additions to the ITI TF-1:9, ATNA, which was written to an older outline template. Rather than redocument ATNA entirely, these section are added using that outline, not the new template. The new sections all fit appropriately into either outline. The Report Audit Event Transaction [ITI-20] is completely rewritten to the current template outline. It was old and written to a very different outline than the current template structure. Merging in the options and their effect on this transaction became very confusing. Rev Copyright 2015: IHE International, Inc.

7 The Node Authentication Transaction [ITI-19] is not affected by this supplement. 2. What audit event log sources should be defined to be supported by the query transaction? The table below is a partial list of event sources. This list is the combination of event sources supported by a variety of event management software. Decision: this version will only mandate support for the IHE ATNA formats and the generic SYSLOG format. The many other formats and transports can be added later as options or by vendors as product options. Examination of a variety of event reporting and logging products resulted in the following list of sources. After discussion and given scope concerns, no additional sources or encodings will be described. 200 Partial List of event sources/codecs considered Name of source Decision IHE ATNA Support Collectd No (perhaps future) Elasticsearch No (perhaps future) Eventlog No (perhaps future) Imap No (perhaps future) Log4j No (perhaps future) Lumberjack No (perhaps future) S3 No (perhaps future) Snmp No (perhaps future) Syslog Support Twitter firehose No (perhaps future) Xmpp No (perhaps future) Zeromq No (perhaps future) Edn No (perhaps future) Fluent No (perhaps future) Json No (perhaps future) Spool No (perhaps future) FHIR No (perhaps future) 3. Event transports were selected as part of the planning decision for this work item. Technical evaluation found no issues with it. Name of source Short Description Issues IHE ATNA Covered in this supplement None Syslog Covered in this supplement None 4. Candidate Query standards Rev Copyright 2015: IHE International, Inc.

8 205 A variety of existing event management products and standards were examined. Most of the existing system use product specific plugins, direct database access, or other methods for providing query access. After review, four candidates were considered worth further evaluation. Name of source Short Description Decision DCM4CHE Open Source implementation of PACS Evaluate archive including ARR as well as much else. At least 5,000 operational downloads, but most probably not for ARR use. Tiani Spirit EHR (awaiting formal EU Public specification. Evaluate name) Implementation underway. Connect / Healtheway/? Published specification. Need to Evaluate determine license, etc., but probably suitable. FHIR Security Event Report Query of a FHIR resource Evaluate Plug-in style (multiple) Direct access to database (multiple) Direct access to flat files (multiple) A variety of product specific mechanisms to write plugins for that product. A variety of product specific mechanisms that document the format and access methods for the internal database used by the product. A variety of product specific mechanisms that document the format and access methods for flat files of messages created by the product. Reject, too product specific, subject to change at will by product vendor Reject, too product specific, subject to change at will by product vendor Reject, too product specific, subject to change at will by product vendor 210 The surviving four were evaluated against the ITI list of evaluation criteria. The general spreadsheet was reviewed and the following table is the result. Evaluation Criteria Results Criteria DCM4CHE Tiani Spirit EHR Connect/Healtheway Stability Early development From an SDO No Govt specification Rev Copyright 2015: IHE International, Inc. Has been deprecated Govt specification Licensing restrictions LGPL v2? CC 0 Implementation Experience Approx 5K installations FHIR (SecurityEvent) DSTU Yes Hackathons, Connectathons Ease of adoption Open Source Will be easy RESTful/SOAP/other RESTful SOAP RESTful ATNA specific query Yes Yes Yes Kind-of Generic SYSLOG query No No No No

9 Criteria DCM4CHE Tiani Spirit EHR Phase 1 decision Acceptance by Intrusion Detection/ Security Analysis vendors Connect/Healtheway FHIR (SecurityEvent) Continue Drop Drop Continue evaluation evaluation? n.a. n.a.? Decision: FHIR was selected as the standard to be used to profile the Query transaction. The FHIR event report is managed as a joint effort among HL7 FHIR, IHE, and DICOM. This makes coordination of the necessary resource changes fairly straightforward. In order to use FHIR the following modification/extension/addition to the query will be needed: We need the same functional capabilities as DCM4CHE. The large installed base of DCM4CHE indicates that the functionality is widely needed. Adapting this functionality to use a FHIR query is a reasonable change if the functional capabilities do not need to change significantly. The generic Syslog query will not fit a FHIR query. This was made optional and a simple query that is similar to FHIR was defined. The major risk item is coordinating release and preparation schedules. In order to fit HL7 publication schedule a reasonable version of the resource and query are needed by 22 March Revisions based upon public comment and TI experience can be handled during the FHIR DSTU cycle. 5. Should we define an actor and transaction for the other syslog messages that are not ATNA schema compliant? Should we mandate support for this kind of message from any secure actor? From any secure node? Or, should these filtering these messages only be mandated when originating on an ATNA compliant node, and support for other nodes be left as a product option? Decisions: The Filter and Forward transaction explicitly state that syslog messages not compliant with ATNA schema can be received. Those messages should be sent using the same protocol requirement defined for ATNA. This was addressed in the ITI-20 rewrite. The query for generic syslog messages was defined and is similar to FHIR in some respects. It is made optional. 6. Should Audit Record Repository always be required grouping with secure node/application or only when it does forwarding? ARR often have lots of PHI, so secure node may be generally appropriate. What about all the other syslog uses? Decision: Not needed the SN/SA grouping for the store/forward option. The text in the options section is sufficient. We have the need to track the Query event without using all Rev Copyright 2015: IHE International, Inc.

10 the requirements introduced by the SN grouping, so there is no requirement to send the audit to another repository via TLS. 7. The Retrieve Syslog Message [ITI-XY] only mandates support for query to return all syslog messages with timestamps within a time window. Should any other queries be mandated? Decision: NO 8. The query option is silent about how the Audit Record Repository determines which syslog messages are stored for later query, how long messages remain available for query, etc. Should there be any requirements put on this? The motivation for this is the wide range of real world situations, ranging from sites that must process tens of thousands of syslog messages per second to sites that manage a few hundred per day. Some sites deal only with major level ATNA security events. Some sites deal with syslog reports of every network connection, ping, firewall warning, etc. Decision: New ITI-20 makes it clear that these issues are decided during implementation and deployment. 9. Have two endpoints - one for syslog, one for ATNA? Have one and let parameters separate? Have two and permit ATNA parameters on syslog? Have two and permit syslog parameters ATNA (FHIR will generate bad request unless there is a FHIR extension defined)? Decision: two endpoints, one FHIR based and one for generic syslog. 10. Should Audit Record Repository always be required grouping with secure node/application or only when it does forwarding? ARR often have lots of PHI, so secure node may be generally appropriate. What about all the other syslog uses? Considerations: The logging of the query event is clearly appropriate. However, there are requirements introduced by the ATNA Secure Node Actor that are not applicable to our scenario where the Audit Source IS the Audit Repository itself: the ARR is required to send Audit messages via UDP or TLS. We SHOULD mandate the creation of Audit Messages structured in accordance to ATNA structure and no other transport requirements. There is another point to take in consideration: once the ATNA query is made, an audit message is created. Should this audit be returned into the same transaction (query Response)? Answer: This is a very important implementation decision, and IHE cannot define requirement for this. Rev Copyright 2015: IHE International, Inc.

11 280 General Introduction Appendix A - Actor Summary Definitions Add the following actors to the IHE Technical Frameworks General Introduction list of Actors: Audit Consumer Actor Definition Retrieves syslog and ATNA audit messages based upon queries using Syslog metadata and ATNA audit message content. Subsequent processing is not defined. 285 Appendix B - Transaction Summary Definitions Add the following transactions to the IHE Technical Frameworks General Introduction list of Transactions: ITI-XX ITI-XY Transaction Definition Retrieve Audit Messages. Retrieves syslog and ATNA audit messages based upon queries using Syslog metadata and ATNA audit message content. Retrieve Syslog Messages. Retrieves syslog messages based upon using the syslog metadata. 290 Glossary Add the following glossary terms to the IHE Technical Frameworks General Introduction Glossary: Glossary Term Syslog metadata Syslog message ATNA message Definition Attributes that classifies the audit message defining: severity of the event, facility and application that sent the message. These are defined in RFC Any message that complies with RFC-5424, regardless of the format of the message body. An ATNA audit log message is a specific kind of syslog message that has a specific format for the message body. A syslog message that complies with the DICOM PS3.15 schema. Rev Copyright 2015: IHE International, Inc.

12 Volume 1 Profiles Replace Section 9.3 Audit Trail Transport with this new Section 9.3 Audit Trail Processing and Use Cases 9.3 Audit Trail Processing and Use Cases Event logging is a system facility that is used by much more than just healthcare applications, and for more purposes than just security auditing. The ATNA audit messages are defined to describe events of particular importance to the healthcare privacy and security purposes. ATNA uses the standard system event logging service defined in RFC-5424 as a transport mechanism Figure 9.3-1: System Event Logging The major elements of system event logging are shown in Figure There are four major processing components: Sources - These components create messages that describe events. The source components might be part of security systems, communications systems, database systems, applications, etc. There are many possible formats for these event messages. Some are proprietary. Some are fully specified by standards. Some comply with formatting frameworks specified by standards. The syslog standard RFC-5424 specifies a messaging and formatting framework. There are a series of mandatory and optional metadata descriptors specified Rev Copyright 2015: IHE International, Inc.

13 as a message header that is followed by free form message body. Messages that comply with this standard are called syslog messages in the rest of this profile. The DICOM standard has specified a message body schema that is to be used for the message body of a syslog message. This message body is highly extensible, and is intended to be profiled and extended for specific medical privacy and security purposes. Messages that comply with this standard are called ATNA messages in the rest of this profile. IHE has profiled the DICOM standard with specific messages to be used in specific situations that arise when implementing IHE profiles. These messages may also be used in other contexts, other profiles, and other situations when appropriate. The IHE messages extend the basic minimum set defined by DICOM. Individual applications may further extend the message set from IHE. Profiling adds and clarifies requirements, rather than remove them. This means that the DICOM requirements apply to all systems, the IHE requirements to IHE systems, IHE transaction requirements to those IHE transactions, etc. Intermediaries and Filters - All of the event messaging methodologies expect to be part of a large directed network that transports event messages from sources to destinations. These destinations may be nodes in a transport network, event message repositories, or event reporting systems. Each node in such a network will a. Receive event messages b. Filter the event messages based upon their metadata and perhaps their contents c. Deliver the filtered messages to other nodes or destinations. Each node may have multiple input sources, multiple filter sets, and multiple destinations. Most of the event transport protocols and source format standards expect that the transports and filters will form a directed acyclic graph (DAG). In other words, loops are not permitted, but it is possible that the same message will arrive more than once because multiple copies took different paths. The Syslog RFC 5424 specifies several transport options (reliable and unreliable) and explains potential DAG structures. The RFC 5424 does not specify a filtering language, but does imply that filters should make use of the metadata header fields at a minimum. The message header metadata defined by RFC-5424 is: Pri - the facility and severity of the event Version - syslog message format version Timestamp - time stamp Hostname - ID of the machine sending the message (not necessarily the transport node ID) App-name - ID of the device or application that originated the message ProcID - Continuity indicator, to denote log system start/stop and similar events MsgID - Message type, specifically identified as a filtering key The header is followed by structured data and the message body. Rev Copyright 2015: IHE International, Inc.

14 DICOM and IHE have specified the use of a secured reliable transport for event messages, with the option of using an unsecured unreliable transport for situations where that is appropriate. (The unreliable unsecured transport is much lower overhead and may be more appropriate for transport within a computer cluster.) Storage and Query - Most deployments have multiple repository destinations that store messages for later query. The repository implementations support a wide variety of repository technologies. These include: a. Flat file systems, often organized by date and category b. Tradition DBMS storage, often with table structure corresponding to the transport message structure elements c. No-SQL data stores, often with the identifying tags corresponding to the transport message structure elements d. Semantic databases e. Object databases f. Flow databases The implementations often provide plugins for some of the database alternatives and a facility to provide additional customized plugins that have special format processing or additional indexing capabilities. The queries available typically depend upon the underlying data repository structure. Examples from the big data world include: a. Use of Google s big-query and big-database facilities. b. Use of Hadoop file system flat file storage combined with Hadoop query processing systems c. Use of normalized associative array storage and highly parallel vector processing for queries spanning billions of individual events. Less exotic queries are the typical queries of database systems using SQL, no-sql methods, etc. that are based upon the message metadata and subsequent processing of message bodies. The FHIR query structure is similar to some of the no-sql query methods. Reporting - There are no standard reports defined by SDOs. There are a variety of standard data formatting approaches, such as standard JSON encodings, CSV file formatting, etc. But most of the reporting requirements are subject to significant local definition and modification. Even apparently simple concepts like breach reporting are highly variable. The definition of a breach varies from state to state within countries and between countries. These reporting requirements are also subject to fairly rapid change and must evolve as the needs of the privacy and security organization change. Rev Copyright 2015: IHE International, Inc.

15 The approach taken by this IHE profile is to provide sufficient query capabilities so that a manageable subset of the event reports can be selected for more detailed analysis and reporting. It does not attempt to embody the complete selection requirements for any particular report. Reporting can also include a variety of dynamic reporting situations such as enterprise dashboards. Event reports showing order queues, backlogs, etc. can be very useful. These applications vary widely. At the present time these are often supported as destinations for filtered event report streams. The internal processing may incorporate stream databases and other such facilities. From the perspective of event reporting architecture these are destination nodes for the transport facilities Use Cases The following healthcare use cases are defined for the filtering, forwarding, and reporting. The reporting does not extend to defining report contents. These use cases expect the transactions to provide selected event information to actors that will then meet local reporting needs. For Query There are many kinds of queries. The following are the query use cases used for this profile. 1. PACS administrators would like to gather a complete change history of data for a specific patient/study/series (e.g., from applying changes from received HL7 messages, performed during Quality Control (QC) operations) to identify who has changed what in case of uncertainty if "something went wrong" (in most cases accidental wrong QC of data) 2. Physicians would like to gather a list of all studies they have accessed within a selectable time frame (personal history of study views) 3. Users responsible for exporting data (e.g., via DICOM C-store to referring physicians via a VPN connection, DICOM Media [Patient CD], etc.) would like to 1. get a list of which studies for a specific patient have already been exported 2. check whether a specific study has already been exported 4. Patients would like to get a list of persons who accessed a specific study (independent of the client system type, e.g., browser, web application, workstation). This access would be mediated by an administrative staffer to manage personal data privacy conflicts. 5. Statistical analysis, e.g., administrators would like to gather statistical usage information to compare the number of studies stored with the number of study accesses within a time frame. 6. A local health authority (LHA) would analyze the digitalization level of clinical employees. This can be evaluated collecting the number of audit records related to a set of relevant transactions: query for documents, retrieve of documents, demographic queries, etc. The data flows for this are very similar to use case 5. Rev Copyright 2015: IHE International, Inc.

16 A security staffer is investigating a possible breach, and needs to know the names of all staff/systems that have had copies of data for a specific patient. The data flow for this is the same as for use case 2, but it will be performed by security staff, using security resources. There are obviously many other possible queries. Those above are the list used for establishing requirements and evaluating transaction requirements. For Relay/Forwarding There are many possible reasons to select and forward audit messages. The following additional use cases used for relay and forwarding uses in this profile. 8. A Repository has agreed to forward audit messages related to important events (e.g., import/export of patient data) to a central audit facility. It wants to maintain all other audit information locally. The local audit repository is configured to filter the local audit messages, select those related to import/export of patient data, and forward just those messages to the central facility. 9. A central warning alert facility has been set up to handle rapid response to security breaches. All the audit repositories are configured to forward all severe security violation messages to an audit repository at the central facility security office. 10. All reports of failed login attempts are forwarded to a central Intrusion Detection System (IDS) Use Case #1 Study Change Tracking use-case This use-case describes the need for PACS administrators to gather a complete change history of data for a specific patient/study/series (e.g., from applying changes from received HL7 messages, performed during Quality Control (QC) operations) to identify who has changed what in case of uncertainty if "something went wrong" (in most cases accidental wrong QC of data) Studies Change Tracking use-case Mr. White is a PACS administrator for the Hope Clinic. Hope Clinic has created a Quality Control system to ensure consistent data display in order to identify problems before they become clinically significant (patient demographic data analysis, patient identifiers merge, access/order information reconciling, etc.). QC operations are performed by many hospital systems and affect different objects (studies, reports, patient demographic record, etc.). Each operation is tracked as an audit event in the Hospital Audit Record Repository. Hope Clinic provides Mr. White a change tracking system able to identify who has changed what in case of uncertainty if "something went wrong". Below is described the situation in which an erroneous merge of patient identities is applied. The QC system identifies a potential merge of two patient identities and this event is propagated to the PACS. However, due to a bug in the Patient Identity Source (that is part of the QC system itself), the merge should not be applied. This merge involves the updates of many reports and studies. After the patient discharge the error is discovered, because unrelated reports and studies Rev Copyright 2015: IHE International, Inc.

17 470 are returned to the patient itself. Mr. White identifies erroneous operations and subsequent events occurred after the receiving of merge request. This can be done, analyzing during a specific time frame, the creation of audit messages related to operations performed on patient reports and studies. Figure : Studies Change Tracking process flow Use Case #2 Clinician Personal History of Study views This use-case describes the scenario in which a clinician would gather the history of studies accessed by himself during his clinical activity using different devices (EHR system, WebApp, Mobile device). This information allows the clinician to: Discover unexpected accesses made that can be related to the disclosing of its access credentials; Revaluate clinical decisions taken; Consolidate to a unique device a complete picture of complex clinical cases Clinician Personal History of Study views Dr. White usually performs his clinical activity using multiple devices. Mr. Brown is a patient home-monitored. Dr. White collects results of home visit using a tablet and he monthly performs a detailed visit in his office. During home visits Dr. White analyzes telemonitoring data collected by some devices (scales, blood pressure devices, etc.) and fix drugs therapies in accordance to Rev Copyright 2015: IHE International, Inc.

18 those data. Every action performed is tracked as an ATNA audit event. Both views and documents creation are logged tracking the user that performed the transaction (e.g., using an XUA identity assertion). During the monthly visit Dr. White would consolidate within his EHR system the whole history of data analyzed and collected using multiple devices. This process allows Dr. White to keep track of his clinical activities and revaluate clinical decisions made in the past. To do that, the EHR system can Query for audit events related to transactions performed by Dr. White during specific time frame. If needed, the EHR system can collect relevant documents that Dr. White wants to store locally. 500 Figure : Clinician Personal History of Study views process flow Rev Copyright 2015: IHE International, Inc.

19 Use Case #3: Data Export Monitoring for administrative and efficiency purposes This use-case describes the scenario in which a user, responsible for data exporting, would check if a specific study has been already exported by other systems (e.g., via Web Access or General Practitioner system). This check provides the important information if a study performed for outpatient has been already consulted or not Exporting Data Monitoring for administrative and efficiency purposes The Hope Clinic provides many ways to export imaging studies and reports created for outpatients: Web Application; WS for GP s EHR systems; ATM Desk staff Mr. White is a hospital employee and he has in charge the monitoring of the reporting status for every document / image produced for outpatients. Reports and Studies not delivered or withdrawn by outpatient lead additional cost to the hospital itself (archiving costs, administrative staff, etc.) and could increase clinical risks (unreported results could affect subsequent clinical decisions). Due to the fact that there are many applications that allow patients and clinicians to withdraw reports, Mr. White needs to monitor audit events produced in a heterogeneous environment: Desk staff and ATM could use a Portable Media Creator system able to store on a portable media (e.g., CD-Patient) images ([RAD-47] Distribute Imaging Information on Media transaction). A Web Application and GP s EHR systems could interact with an XDS-I infrastructure to retrieve images (e.g., using a [RAD-69] Retrieve Imaging Document Set transaction). Each transaction requires the creation of audit messages tracking the Export and Import event. These messages are stored within the same ATNA Audit Record Repository. Mr. White can monitor the reporting status related to every study querying the ATNA ARR system. Using the data collected, the application used by Mr. White can highline pending reports/studies and the operator can undertake other actions to deliver these studies. Rev Copyright 2015: IHE International, Inc.

20 Figure : Exporting Data Monitoring for administrative and efficiency purposes Process flow Use Case #4: Patient access to his audit records This use-case describes the scenario in which the patient would discover the list of people that accessed a specific study. Using those data, the patient should be able to understand if privacy consents expressed were applied in accordingly Patient access to his audit records Use Case Description During a hospitalization Mr. Brown was asked to subscribe a consent document aimed to share documents produced during that clinical event with a research facility. Mr. Brown does not provide this consent because it is worried that his data could be used for marketing purposes. A nurse collects the patient s decision but he forgets to trace it using the HIS system. All the data collected during the hospitalization are used by the research facility to analyze the efficiency of the applied treatment. These accesses are tracked as Export or Disclosure events for a Research purpose. Every access to the same data requested by clinicians involved in the care of the Mr. Brown are tracked as Export or Disclosure events for a Treatment purpose The healthcare facility, which Mr. Brown belongs to, provides on-line access to health information. Mr. Brown can use a web app to disclose this data (shared using and XDS or XCA infrastructure). The web app can also collect audit information related to those documents/studies. Audit records are collected by many ATNA Audit Record Repositories. Rev Copyright 2015: IHE International, Inc.

21 555 Local policies or system configurations (e.g., using the Filter and Forward Option) allows the web app to identify the right Audit Record Repository service that stores relevant records. Using the document/study identifiers the web app can query the identified ATNA Audit Record Repository. The web app reports that the identified documents/studies have been disclosed/exported for treatment and research purposes. 560 Figure : Patient access to his audit records Process Flow Use Case #5: Statistical Analysis and Monitoring of EHR Usage Many Local Health Authorities (LHA) need to monitor the usage of Electronic Health Record systems during clinician s daily activities. EHR usage can be evaluated by monitoring transactions started by specific users. Rev Copyright 2015: IHE International, Inc.

22 EHR usage details can be used to improve workflow, procedure compliance, and other aspects of patient treatment. The audit records provide an indication of activity without exposing as much patient private information. For example, data collected by users that demonstrate high confidence with Electronic Health Record and its functionalities may be considered more reliable compared to data provided manually Statistical Analysis and Monitoring of EHR Usage A Local Health Authority has identified a list of indicators useful to evaluate clinician activity. Among them, the level of digitalization has an important role in identifying the quality of data produced by clinicians. Dr. White has a lot of expertise in using EHR systems. He produces eprescriptions, he monitors patients engaged in tele-monitoring services and he views and produces digital clinical reports. All these operations are based on IHE transactions and require the creation of Audit records. LHA administrators can gather statistical usage information querying for audit records related to transactions initiated by Dr. White. Audit records are stored in many different ATNA audit record repositories cause Dr. White operates on patients belonging to many different enterprises. Analyzing number and type of transactions performed by Dr. White, administrators can identify the level of digitalization of the doctor. Due to that evaluation, clinical data collected by Dr. White are considered highly reliable. Rev Copyright 2015: IHE International, Inc.

23 585 Figure : Statistical Analysis and Monitoring of EHR Usage Process Flow Use Case #6: Centralized Warning Alert Audit Facility A central warning alert facility has been set up to handle rapid response to security breaches. All the audit repositories are configured to forward all severe security violation messages to an audit repository at the central facility Centralized Warning Alert Audit Facility In a HIE environment, many hospitals are federated into the same community. Those hospitals share a common set of policies and, among them, the local Security Officers agreed in managing in a centralized way the breaching detection system. In accordance to this, audit events related to Rev Copyright 2015: IHE International, Inc.

24 600 security violation are forwarded to a centralized audit record repository. The Breaching detection system analyzes audit messages collected, evaluates risk conditions (number and frequency of warnings, warning source location, etc.) and take compensation actions (such as CRLs updates, credentials revocation, etc.). Figure : Centralized Warning Alert Audit Facility Technical Approach There are a wide variety of specific reports and analyses that will be needed. Based on the use cases above and the experience with existing systems, it is assumed that there will be a reporting and analysis system that has extensive database and programmability features. The interoperability need is to retrieve suitable subsets of the total ARR database that will then be combined and analyzed to determine a final result. Rather than support a highly complex query capability, a simple query that results in collections that can then be combined is defined. These capabilities rely on different type of query parameters that can be combined within the same query transaction to fit real scenario needs. Rev Copyright 2015: IHE International, Inc.

25 The ATNA Retrieve Audit Event transaction support queries based on: Patient identifier: this query parameter allows to discover all the events occurred related to a specific patient; User identifier: this query parameter allows discovering all the actions performed by a specific user Object identifier: this query parameter allows discovering each event occurred related to a specific object (like study, reports, image, etc.). Time frame: this query parameter allows discovering all the events occurred during a specific time frame. Event type: this query parameter allows discovering all the occurrences of a specific event (like Data Export, Data Import, Query, Authentication, etc.). Application identifier: this query parameter allows discovering all the events started by a specific application or system. Event Outcome Indicator: this query parameter allows discovering all events characterized by a specific outcome (Success, Failure, etc.) of the related event. For additional analysis beyond that which is fulfilled by the above queries, the Audit Consumer can perform a query for the time frame expected and then perform more detailed analysis locally. Further details about Query semantic are defined in Section ITI TF-2c: 3.XX. Modify ITI TF-1:9.4 as shown, replacement figure provided Actors/Transactions This section defines the actors, transactions, and/or content modules in this profile. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A at Figure shows the actors directly involved in the ATNA Profile and the relevant transactions between them. If needed for context, other actors that may be indirectly involved due to their participation in other related profiles are shown in dotted lines. Actors which have a mandatory grouping are shown in conjoined boxes. Rev Copyright 2015: IHE International, Inc.

26 Figure 9.4-1: Audit Trail and Node Authentication Diagram Rev Copyright 2015: IHE International, Inc.

27 When an implementation chooses to support this Integration Profile for an actor, that actor shall be grouped with the Secure Node Actor. It is required that all IHE actors and any other activities in this implementation support the Audit Trail and Node Authentication Integration Profile. A means must be provided to upload the required certificates to the implementation, e.g., via floppy disk or file transfer via network. Non-IHE applications that process PHI shall detect and report auditable events, and protect access. Table lists the transactions for each actor directly involved in the ATNA Profile. To claim compliance with this Profile, an actor shall support all required transactions (labeled R ) and may support the optional transactions (labeled O ). Table 9.4-1: ATNA Profile - Actors and Transactions Actors Transactions Optionality Reference Audit Record Record Audit Event [ITI-20] R ITI-2a: 3.20 Repository Record Audit Event [ITI- O (See Note 1) ITI-1: ] Retrieve ATNA Audit O (See Note 2) ITI-2c: 3.XX Event [ITI-XX] Retrieve Syslog Event [ITI- XY] O (See Note 2) ITI-2c: 3.XY Audit Consumer Retrieve ATNA Audit Event [ITI-XX] Retrieve Syslog Event [ITI- XY] R O ITI-2c: 3.XX ITI-2c: 3.XY Secure Node Authenticate Node [ITI-19] R ITI-2a: 3.19 Record Audit Event [ITI-20] R ITI-2a:3.20 Maintain Time [ITI-1] R ITI-2a: 3.1 Secure Authenticate Node [ITI-19] O ITI-2a: 3.19 Application Maintain Time [ITI-1] O ITI-2a: 3.1 Record Audit Event [ITI-20] O ITI-2a: 3.20 Secure Node Authenticate Node [ITI-19] R ITI-2a: 3.19 Record Audit Event [ITI-20] R ITI-2a:3.20 Note 1: If the Audit Record Repository claims the Filter and Forward Option, it shall support the Record Audit Event [ITI-20] both as a recipient of the transaction (for incoming event reports) and as a source of the transaction (for forwarded events). Note 2: If the Audit Record Repository claims the Retrieve Audit Message Option, it shall support the transaction [ITI-XX] Retrieve ATNA Audit Event. The Retrieve Syslog Event [ITI-XY] transaction is always optional. Update ITI TF-1:9.5 as shown. This adds options. Rev Copyright 2015: IHE International, Inc.

28 ATNA Integration Profile Options Options that may be selected for this Integration Profile are listed in the Table along with the actors to which they apply. Dependencies between options when applicable are specified in notes. 670 Table 9.5-1: ATNA - Actors and Options Actor Option Name Vol. & Section Audit Record Repository Filter and Forward Option ITI TF-1: Retrieve Audit Message ITI TF-2c: 3.XX Secure Node Radiology Audit Trail RAD TF-1: 2.2.1; RAD TF-3: 5.1 Secure Application Radiology Audit Trail RAD TF-1: 2.2.1; RAD TF-3:5.1 Audit Consumer none - Add Section 9.5.3and to ITI TF-1: Filter and Forward Option An ATNA Audit Repository (ARR) that conforms to the Filter and Forward Option will accept both ATNA audit messages and other Syslog messages as part of transaction [ITI-20] Record Audit Event and shall forward those messages that meet filtering requirements. RFC5424 defines three roles for syslog applications: Syslog Originator, Syslog Relay, and Syslog Collector. Syslog Originator is an application able to create the content of syslog messages and send them, Syslog Collector is an application able to store audit messages and Syslog Relay is an application that can forward audit messages to one or many new Collectors once received. The ATNA Profile identifies the content of specific syslog messages created by IHE actors. Filter and Forward Option relies on syslog transport mechanisms to filter and dispatch audit messages. The Filter and Forward Option uses the [ITI-20] Record Audit Event transaction to forward the selected messages compliant with ATNA schema to another ARR or to another system that will accept such transactions. If an ATNA Audit Record Repository Actor supports this option, then it shall also be able to receive and forward other messages that comply with RFC-5424 in accordance with filtering and forwarding requirements. All the messages shall be sent/received using syslog transport mechanisms defined in transaction [ITI-20] Record Audit Event. This option does not add persistence requirements for syslog messages. Rev Copyright 2015: IHE International, Inc.

29 An ARR that claims this option shall implement filtering functionalities based at least on these criteria: Filters based on Pri: this is the syslog metadata that describes the facility and severity of the event. Filters based on Hostname: this is the syslog metadata that identifies the original machine sending the message. If the Audit message complies with ATNA schema, additional filter criteria shall be supported: Filters based on EventCode attribute: this is an ATNA attribute that identifies the IHE transaction that originates the audit event. An ARR that claims this option can document additional filtering criteria and shall document mechanisms adopted to configure filtering. Additional filtering capabilities may be based upon Syslog (RFC-5424) message metadata elements such as: Timestamp - time stamp App-name - ID of the device or application that originated the message ProcID - Continuity indicator, to denote log system start/stop and similar events MsgID - Message type, specifically identified as a filtering key in RFC Audit messages that comply with the ATNA schema may also be filtered using criteria that examine the values of fields (other than eventcode) defined within the ATNA schema. The same audit message can be sent to one or more destinations. Filter rules shall be identified for each destination configured. This option is not intended to force the Audit Record Repository to store the audit message when forwarding it; this behavior is product specific and is strictly related to domain security policies. No-alterations of the audit message structure and content are permitted while it is forwarded Retrieve Audit Message Option Audit Record Repositories that claim the Retrieve Audit Message Option shall support the ability to query the Repository for audit messages based upon syslog message metadata and contents of ATNA compliant audit messages. An ATNA Audit Record Repository that supports this option shall implement the Retrieve ATNA Audit Event transaction [ITI-XX]. This is a RESTful query from an Audit Consumer to an Audit Record Repository (ARR) using FHIR resources. The Audit Record Repository is maintaining a database of syslog messages that have been received. This database may be a subset of all messages received. The Audit Record Repository will have selection criteria for what kinds of messages are kept for later query, how long different kinds of messages are kept, etc. This query will reflect the contents of Rev Copyright 2015: IHE International, Inc.