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 [email protected] 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.

30 the data storage at the time of the query. IHE does not specify the criteria for message selection, archival, retention interval, etc. These are set by local policy and are often different for different Audit Record Repositories. An ATNA Audit Record Repository that supports this option may implement the Retrieve Syslog Event transaction [ITI-XY]. This query retrieves syslog messages of any format or schema. The retrieval query uses the Syslog message elements only. This query is a RESTful query that is similar in some respects to a FHIR query. Figure : Retrieve Audit Message Option diagram 740 Add Section 9.8, 9.9, 9.10 to ITI TF-1:9 as shown. This adds new sections that correspond to new sections in the new template. When we do a redoc of Section 9 these will move to a new section number RESTful ATNA Query Security Considerations The RESTful ATNA Query supplement defines a new transaction for the ATNA Audit Record Repository Actor that enables sharing of sensitive information related to patients and systems. Audit Record Repositories have been considered in many implementations and projects as a black-box able to store relevant information for security and monitoring purposes. Those systems have not historically been designed to provide external access to stored records. Security Officers and System Architects should consider this and analyze the risks of disclosing data stored in the Audit Record Repository. The RESTful ATNA Retrieve Audit Message transaction defines how to retrieve audit records grouped in two categories: Rev Copyright 2015: IHE International, Inc.

31 messages related to IHE transactions or compliant with DICOM Audit Message Schema (DICOM PS3.15 Section A.5) other syslog messages compliant with RFC Analysis should include consideration of the content of the other syslog messages. The content of those messages is not profiled by IHE or DICOM, and they may include PHI or other sensitive information. Accordingly, access control mechanisms on the Actors and queries are strongly recommended. The IUA Profile should be considered for the authorization controls The ATNA Audit Record Repository can be grouped with an IUA Resource Server Actor to enforce policies and authorization decisions. The Audit Consumer Actor can be grouped with an Authorization Client Actor to provide authorization information to the ATNA Audit Record Repository. Access controls should restrict access to this data appropriately. Retrieve ATNA Audit Event and Retrieve Syslog Event transactions can involve the disclosure of sensitive information. The logging of this event, as a query event, is clearly appropriate. However, the ATNA Profile does not mandate the grouping of the ATNA Audit Record Repository with an ATNA Secure Node Actor because that grouping introduces requirements (in particular Connect-a-thon requirements) that are not applicable to this scenario (e.g., it is reasonable that this audit message is not sent to another system using Syslog over TLS protocol, but it is directly stored within the ARR database.). Also the Audit Source is the Audit Repository itself and this introduces potential feedback loops. Implementation of these audit reports cannot blindly follow the ATNA Profile rules. The Record Audit Event [IT-20] already includes some the audit requirements for the ATNA Audit Record Repository, such as reporting accesses to the ARR. Security Officers that plan audit infrastructure based on Filter and Forward Option (see Section 9.5.3) should take in consideration issues related to recursive message flows and should design the message flows as Directed Acyclic Graphs. 9.9 ATNA Cross Profile Considerations The ATNA Secure Node and Secure Application Actors are often grouped with other actors from many domains. The security requirements that are common to healthcare applications are defined in these two actors. Rather than reproduce all those requirements, other Actors are simply grouped with one of these two actors Required Actor Groupings Internally within the ATNA Profile, some ATNA actors are grouped with other ATNA actors to convey security requirements, as shown in Table Rev Copyright 2015: IHE International, Inc.

32 ATNA Actor Audit Record Consumer Table : ATNA - Required Actor Groupings Actor to be grouped with Secure Node or Secure Application Reference ITI TF-1: Content Bindings Reference Rev Copyright 2015: IHE International, Inc.

33 790 Volume 2 Transactions Replace current Section 3.20 in Volume 2a with the following Note to reviewers: This is a re-organized ITI-20. It has been cut and pasted into the new supplement outline. This has reduced some duplicate text. There are also English improvements for readability. The identified technical changes are: - All references to RFC-3881 and IHE Provisional Audit Format (the old Radiology format) are marked as deprecated, and external references removed. - TLS requirements have been modified to allow TLS 1.2 and later, not just TLS 1.2. TLS is officially recommended for syslog. - Some sections are retired and notes added to reflect the redoc effort, and to deal with external references into this transaction. All of the references found so far in ITI and other Frameworks have been to Table : Audit Record trigger events and Section Audit Message Format. Both of these are now in Section Placeholder destinations have been preserved Report Audit Event This section corresponds to Report Audit Event [ITI-20] of the IHE IT Infrastructure Technical Framework. This transaction is used by the all IHE actors that support the Audit Trail and Node Authentication Integration Profile to report auditable events to the Audit Record Repository actors Scope This transaction is used to report auditable events to an Audit Record Repository Actor Roles Any Grouped Actor Audit Record Repository B Audit Record Repository A Record Audit Event 815 Figure : Use Case Diagram Rev Copyright 2015: IHE International, Inc.

34 Table : Actor Roles Actor: Role: Actor: Role: Role: Any actor or any other application that is grouped with the Secure Node Actor or Secure Application Actor. Create an audit record and transmit this record to the Audit Record Repository. Audit Record Repository Recipient: Receive an audit record from the Audit Record Creator and store this for audit purposes. Source: Copy an audit record and transmit this record to another Audit Record Repository. When ARR supports the Filter and Forward Option Referenced Standards 820 IETF: The Syslog Protocol. (RFC 5424) Transmission of Syslog Messages over TLS (RFC 5425) Transmission of Syslog Messages over UDP (RFC 5426) Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications (RFC 3881). DICOM: PS ASTM: E Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems NIST: SP Guide to Computer Security Log Management. W3C: Recommendation: Extensible Markup Language (XML) 1.0 Rev Copyright 2015: IHE International, Inc.

35 Interaction Diagram Any Grouped Actor Audit Record Repository Audit Record Repository Record Audit Event [ITI-20] Forward? Record Audit Event [ITI-20] Record Audit Event An actor that detects an event that should be reported uses the Record Audit Event to send a report about the event to an Audit Record Repository. Audit Record Repositories may copy and forward event reports to other Audit Record Repositories if they support the Filter and Forward Option, as defined in ITI TF-1: The event recording mechanism is defined by RFC-5424 Syslog. DICOM has defined a basic event report schema, and some basic event descriptions. IHE has extended this to define other specific event reports for security and privacy events. Other organizations and systems may also use these event schema for reporting security and privacy events. The underlying syslog system is also used for a wide variety of event reporting purposes. The DICOM and IHE event reports can be mixed together with other event reports in other formats Trigger Events There are two trigger events: 1. A Secure Node or Secure Application that detects an event that should be reported to the Audit Record Repository for security and privacy reasons. This transaction does not specify all the policies or reasons for reporting events. They may be specified in other profiles, they may be specified by local law or regulation, or they may be specified by local policy. 2. An Audit Record Repository that supports Filter and Forward Option (ITI TF-1:9.5.3) determines that a copy of the event report should be sent to another Audit Record Repository. This transaction does not specify what rules or policies are used to determine that an event report should be copied and forwarded. Rev Copyright 2015: IHE International, Inc.

36 DICOM and IHE event reports IHE specifies that events defined in Table shall be reportable by means of the IHE Audit Trail. This applies to all such events for all actors in any IHE profile. Additional reportable events are often identified for specific events in other IHE profiles, and will be documented in that profile. Note that the table number below is carried over from an older version of Section 3.20 and due to numerous references to it in other documents, was not changed. Rev Copyright 2015: IHE International, Inc. Table : Audit Record trigger events Trigger Event Description Source Vocabulary Actor-start-stop Startup and shutdown of any actor. Applies to all actors. Is DICOM PS 3.15 A.5.3 distinct from hardware powerup and shutdown. Application Activity Audit-Log-Used Begin-storing-instances Health-service-event Instances-deleted Instances-Stored Medication The audit trail repository has been accessed or modified by something other than the arrival of audit trail messages. Begin storing SOP Instances for a study. This may be a mix of instances. Health services scheduled and performed within an instance or episode of care. This includes scheduling, initiation, updates or amendments, performing or completing the act, and cancellation. See note below. SOP Instances are deleted from a specific study. One event covers all instances deleted for the particular study. Instances for a particular study have been stored on this system. One event covers all instances stored for the particular study. Medication orders and administration within an instance or episode of care. This includes initial order, dispensing, delivery, and cancellation. See note below. DICOM PS 3.15 A.5.3 Audit Log Used DICOM PS 3.15 A.5.3 Begin Transferring DICOM Instances IHE Extension (ITI TF-2a: ) Health Services Provision Event DICOM PS 3.15 A.5.3 DICOM Instances Accessed or DICOM Study Deleted DICOM PS 3.15 A.5.3 DICOM Instances Transferred IHE Extension (ITI TF-2a: ) Medication Event Mobile-machine-event Mobile machine joins or leaves secure domain. DICOM PS 3.15 A.5.3 Network Entry Node-Authentication-failure Order-record-event Patient-care-assignment Patient-care-episode A secure node authentication failure has occurred during TLS negotiation, e.g., invalid certificate. Order record created, accessed, modified or deleted. Involved actors: Order Placer. This includes initial order, updates or amendments, delivery, completion, and cancellation. See note below. Staffing or participant assignment actions relevant to the assignment of healthcare professionals, caregivers attending physician, residents, medical students, consultants, etc. to a patient It also includes change in assigned role or authorization, e.g., relative to healthcare status change, and de-assignment Specific patient care episodes or problems that occur within an instance of care. This includes initial assignment, updates DICOM PS 3.15 A.5.3 Security Alert DICOM PS 3.16 Annex D Order Record IHE Extension (ITI TF-2a: ) Patient Care Resource Assignment IHE Extension (ITI TF-2a: ) Patient Care

37 Trigger Event Description Source Vocabulary or amendments, resolution, completion, and cancellation. Episode See note below. Patient-care-protocol Patient association with a care protocol. This includes initial assignment, scheduling, updates or amendments, completion, and cancellation. See note below. IHE Extension (ITI TF-2a: ) Patient Care Protocol Patient-record-event Patient record created, modified, or accessed. DICOM PS 3.16 Annex D Patient Record PHI-export PHI-import Any export of PHI on media, either removable physical media such as CD-ROM or electronic transfer of files such as . Any printing activity, paper or film, local or remote, which prints PHI. Any import of PHI on media, either removable physical media such as CD-ROM or electronic transfers of files such as . DICOM PS 3.15 A.5.3 Export DICOM PS 3.15 A.5.3 Import Procedure-record-event Procedure record created, modified, accessed or deleted. DICOM PS 3.16 Annex D Procedure Record Query Information A query has been received, either as part of an IHE transaction, or as part other products functions. For example: 1) Modality Worklist Query 2) Instance or Image Availability Query 3) PIX, PDQ, or XDS Query Notes: The general guidance is to log the query event with the query parameters and not the result of the query. The result of a query may be very large and is likely to be of limited value vs. the overhead. The query parameters can be used effectively to detect bad behavior and the expectation is that given the query parameters the result could be regenerated if necessary. DICOM PS 3.15 A.5.3 Query Rev Copyright 2015: IHE International, Inc.

38 Trigger Event Description Source Vocabulary Security Alert Security Administrative actions create, modify, delete, query, and display the following: Configuration and other changes, e.g., software updates that affect any software that processes protected information. Hardware changes may also be reported in this event. 1. Security attributes and auditable events for the application functions used for patient management, clinical processes, registry of business objects and methods (e.g., WSDL, UDDI), program creation and maintenance, etc. 2. Security domains according to various organizational categories such as entity-wide, institutional, departmental, etc. 3. Security categories or groupings for functions and data such as patient management, nursing, clinical, etc. 4. The allowable access permissions associated with functions and data, such as create, read, update, delete, and execution of specific functional units or object access or manipulation methods. 5. Security roles according to various taskgrouping categories such as security administration, admissions desk, nurses, physicians, clinical specialists, etc. It also includes the association of permissions with roles for role-based access control. 6. User accounts. This includes assigning or changing password or other authentication data. It also includes the association of roles with users for rolebased access control, or permissions with users for user-based access control. 7. Unauthorized user attempt to use security administration functions. 8. Audit enabling and disabling. 9. User authentication revocation. 10. Emergency Mode Access (aka Break-Glass) Security administration events should always be audited. DICOM PS 3.15 A.5.3 Security Alert User Authentication Study-Object-Event Study-used This message describes the event of a user log on or log off, whether successful or not. No Participant Objects are needed for this message. Study is created, modified, accessed, or deleted. This reports on addition of new instances to existing studies as well as creation of new studies. SOP Instances from a specific study are created, modified or accessed. One event covers all instances used for the particular study. DICOM PS 3.15 A.5.3 User Authentication. For log off based on inactivity, specify UserIsRequestor=false in the User element to indicate that this was not user initiated. DICOM PS 3.15 A.5.3 DICOM Instances Accessed DICOM PS 3.15 A.5.3 DICOM Instances Accessed Rev Copyright 2015: IHE International, Inc.

39 Other event reports Events that do not correspond to DICOM events or IHE Extension events can be reported. They shall comply with DICOM PS 3.15 A.5 schema (see Neither the IHE profiles nor DICOM restrict private extensions to the schema. Any private extensions shall comply with the W3C XML encoding rules for the use of schemas, namespaces, etc Audit Message Transports The Secure Node or Secure Application Actor shall create the Audit Record and transmit this to the Audit Record Repository as soon as possible. When for some reason the Audit Record Repository is not available, the Secure Node or Secure Application Actor shall store the Audit Record in a local buffer until the Audit Record Repository is available again. The local Audit Record at the Secure Node or Secure Application Actor may be deleted when this record has been transmitted to the Audit Record Repository. This profile defines two transport mechanisms for the audit messages: 1. Transmission of Syslog Messages over TLS (RFC5425) with The Syslog Protocol (RFC5424) which formalizes sending syslog messages over a streaming protocol protectable by TLS 2. Transport utilizing the Transmission of Syslog Messages over UDP (RFC5426) with The Syslog Protocol (RFC5424) which formalizes and obsoletes BSD Syslog protocol defined in RFC The Audit Record Repository shall support both transport mechanisms for the receipt of messages. Given that Audit Record Repository must accept both transports, the Secure Node Actors may choose to utilize either of the transport mechanisms, unless they also comply with another Profile that further restricts the use Transmission of Syslog Messages over TLS Transmission of Syslog Messages over TLS (RFC5425) with The Syslog Protocol (RFC5424) formalizes sending syslog messages over a streaming protocol protectable by TLS. The RFC5424 states that this MUST be TLS version 1.2. For this transport that requirement is relaxed to be that it MUST be TLS, version 1.2 or later is RECOMMENDED Reliable Syslog (deprecated) The Reliable Syslog cooked mode is no longer specified by this profile. Applications using Reliable Syslog should switch to transmission of syslog messages over TLS Transmission of Syslog Messages over UDP (formerly:bsd Syslog) Transmission of Syslog Messages over UDP (RFC5426) with The Syslog Protocol (RFC5424) formalizes and obsoletes the BSD syslog protocol (RFC3164). This syslog is appropriate in some Rev Copyright 2015: IHE International, Inc.

40 situations, it was defined in the IHE Radiology Technical Framework, and it is a widely used legacy protocol. Note that the underlying UDP transport might not accept messages longer than 1024 or the MTU size minus the UDP header length. Long syslog messages may be truncated. The Audit Repository must be prepared for arbitrary truncation of messages. The IHE Provisional schema uses shortened names to reduce the size of messages, but some may exceed the largest size supported by the underlying transport. When syslog messages are truncated the resulting XML will be incorrect and will need to be corrected by the Audit Repository to close the truncated portions of the message. Because of this potential for truncated messages and other security concerns, the transmission of syslog messages over TLS is recommended Message Semantics An Audit Log is a record of actions performed on data by users. Actions are queries, views, additions, deletions and changes. The IHE actor creates an Audit Record when an IHE transaction-related event occurs or when a non-transaction event occurs. The syslog message shall be created and transmitted as described in RFC 5424 and the following subsections. ATNA actors shall take into account the following points: 1. The XML audit message may contain Unicode characters that are encoded using the UTF-8 encoding rules. UTF-8 avoids utilizing the control characters that are mandated by the syslog protocol, but it may appear to be gibberish to a system that is not prepared for UTF-8. Audit repositories must accept UTF-8 encodings and store them without damage, e.g., preserve all 8 bits. 2. The PRI field shall be set using the facility value of 10 (security/authorization messages). Most messages should have the severity value of 5 (normal but significant), although applications may choose values of 4 (Warning condition) if that is appropriate to the more detailed information in the audit message. This means that for most audit messages the PRI field will contain the value <85>. Audit repositories shall be prepared to deal appropriately with any incoming PRI value. 3. The MSGID field in the HEADER of the SYSLOG-MSG shall be set to IHE+RFC (minus the quotes). 4. STRUCTURED-DATA is not used for IHE ATNA audit messages, since the MSG field itself holds structured data. 5. The MSG field of the SYSLOG-MSG shall be present and shall be an XML structure following the DICOM PS3.15 A.5 format, as specified in this profile Audit Message Formats The IHE has defined two audit record formats: an initial IHE Provisional Audit Record format that is now retired, and the IHE Audit Trail Message Format. An IHE actor shall utilize one or both of these audit record formats. Rev Copyright 2015: IHE International, Inc.

41 The IHE Audit Trail format. This is a schema based on the standards developed and issued by the IETF, HL7, and DICOM organizations to meet the medical auditing needs as specified by ASTM. The 2. IHE Provisional Audit Record format is defined below for backward compatibility purposes. This was initially defined as part of the IHE Radiology technical framework. Its use is deprecated. No extensions will be made by IHE and new applications should use the new IHE Audit Trail format. All audit record formats utilize XML encoding and are defined by XML schema IHE Audit Trail Message Format The DICOM Standard, Part 15, Annex A.5 Audit Trail Message Format Profile provides vocabulary and specification of a schema for events that may occur in the context of DICOM equipment. This XML schema was defined based upon joint work by IHE, HL7, DICOM, ASTM E31, and the Joint NEMA/COCIR/JIRA Security and Privacy Committee. The IHE IT Infrastructure technical framework recommends use of this schema for audit records generated by all IHE actors. The DICOM Standard provides a schema for the basic messages and states that extensions are valid. This profile does not restrict private extensions that comply with the W3C XML encoding rules for the use of schemas, namespaces, etc. IHE has extended it for more general healthcare use. IHE profiles have defined additional events and appropriate auditing messages for those events. These are often directly associated with IHE transactions. They are documented in the context of those transactions, and are not documented as part of this transaction. These audit requirements may be found in the technical frameworks from any IHE domain, not just the ITI domain. The notation used in this documentation, which often is in the form of an audit message table, is that used in the DICOM standard. The messages shall be encoded as instances based on the DICOM schema. IHE has defined reports of events that are associated with a patient to identify a single patient. In situations where there is an event that applies to more than one identifiable patient, there shall be a separate audit message for each patient RoleIDCode with access control roles When describing a human user s participation in an event, the RoleIDCode value should represent the access control roles/permissions that authorized the event. RoleIDCode is a CodedValueType. Use of standards based roles/permissions is recommended, rather than use of site or application specific codes. Many older security systems are unable to produce this data, hence it is optional, but should be provided when known. For example: at a site "St Fraser" they have defined a functional role code "NURSEA" for attending nurse. This can be represented as EV("NURSEA", "St Fraser", "Attending Nurse") Rev Copyright 2015: IHE International, Inc.

42 Candidate standards based structural/functional role codes can be found at ISO, HL7, ASTM, and various other sources Audit Encoding of the Purpose of Use value The Purpose of Use value in the schema indicates the expected ultimate use of the data, rather than a likely near term use such as send to X. As explained in the IHE Access Control White Paper, there are Access Control decisions that are based on the ultimate use of the data. For example a Patient may have provided a BPPC Consent/Authorization for treatment purposes, but explicitly disallowed any use for research regardless of de-identification methods used. The purpose of use is also included in the ATNA audit log to enable some forms of reporting of Accounting of Disclosures and Breach Notification. To enable this type of Audit Logging and Access Control decision the XUA Assertion [ITI-40] includes the intended purpose for which the data will be used. One specific PurposeOfUse would be a Break-Glass / Emergency-Mode- Access. The PurposeOfUse value will come from a Value-Set. This Value-Set should be derived from the codes found in ISO 14265, or XSPA. Implementations should expect that the Value-Set used may be using locally defined values. The use of the IHE Sharing of Value-Sets (SVS) Profile may assist with this. When a PurposeOfUse value is available it shall be encoded in the EventIdentification section as PurposeOfUse element encoded as a CodedValueType. For example, the following is how an explicit Disclosure can be recorded when an application knows that the act meets the measure of a Disclosure in the legal domain. Field Name Opt Value Constraints Event EventID M EV(110106, DCM, Export ) AuditMessage/ EventIdentification EventActionCode M R (Read) EventDateTime M not specialized EventOutcomeIndicator M not specialized PurposeOfUse O EV(12, , Law Enforcement ) EventTypeCode M EV( IHE0006, IHE, Disclosure ) Source (Document Repository) (1) Destination (Document Consumer) (1) Audit Source (Document Repository) (1) Document (1..n) RFC-3881 format (Deprecated) The use of RFC3881 has been deprecated by IHE and IETF. Rev Copyright 2015: IHE International, Inc.

43 Expected Actions An Audit Record Repository (ARR) shall accept any event message that complies with RFC5424. For each report it may: 1. Discard the event report as irrelevant. E.g., an ARR may choose to discard event messages that are in a format that it does not understand. 2. Retain the event report in an internal data store. 3. Select the event report to be copied and forwarded to another ARR, if the receiving ARR supports Filter and Forward Option (ITI TF-1:9.5.3). 4. Perform other processing on the event report. The expectation is that the internal data store will be used for subsequent analysis and reporting purposes. This transaction does not constrain the kind of event reports that can be conveyed, nor does it specify the capacity or capabilities of the data store in the ARR. The ARR may apply a variety of data retention rules to the data store. This transaction does not specify data retention rules. These are usually dependent upon the purposes assigned to a specific ARR. The ARR may apply a variety of selection and forwarding rules to any event. This transaction does not specify selection or forwarding rules. There is no requirement that the selection and forwarding correspond in any way to the decisions to retain or discard a report. For example, an ARR might choose to forward reports in a format that it does not understand to another ARR that will understand them, and then discard those reports Security Considerations The use of TLS is recommended because the event reports often contain PHI or other sensitive information. The TLS version shall be 1.2 or later. It is not required, because there are other means of protection that may be more appropriate. Transactions are allowed to use other means but the decision to use something other than TLS 1.2 or later should be based upon a security and privacy risk analysis. The data store within the ARR may contain sensitive information, and the ARR analysis facilities may allow sensitive queries. It will be a high visibility target for malicious actors, and should be protected accordingly. The ARR is required to generate event reports for various kinds of use of the data store and configuration changes. This is specified above in Section retired Note: In an older version of this document there was a Table : Audit Record trigger events that was referenced in many profiles and transactions defined elsewhere in IHE documents. This table has moved to Section DICOM and IHE event reports. This section is retired as part of document re-organization. Most of it is now part of Section Rev Copyright 2015: IHE International, Inc.

44 retired Note: In an older version of this document there was a Section Audit Message Formats that was referenced in many profiles and transactions defined elsewhere in IHE documents. This section is now Audit Message Formats. This section is retired as part of document re-organization. Most of it is now part of Section Controlled Terminology for IHE Extensions This profile defines the following controlled terminology for use in the IHE extensions Coding Scheme Designator Coding Scheme Version Context ID ccc1 Audit Event ID Type: Extensible Version: 2004xxxx Code Value Code Meaning IHE IHE0001 Health Services Provision Event IHE IHE0002 Medication Event IHE IHE0003 Patient Care Resource Assignment IHE IHE0004 Patient Care Episode IHE IHE0005 Patient Care Protocol IHE Code Definitions (Coding Scheme Designator IHE Coding Scheme Version 2004 ) Code Value Code Meaning Definition Notes IHE0001 Rev Copyright 2015: IHE International, Inc. Health Services Provision Event Health services scheduled and performed within an instance or episode of care. This includes scheduling, initiation, updates or amendments, performing or completing the act, and cancellation. IHE0002 Medication Event Medication orders and administration within an instance or episode of care. This includes initial order, dispensing, delivery, and cancellation. IHE0003 Patient Care Resource Assignment Staffing or participant assignment actions relevant to the assignment of healthcare professionals, caregivers attending physician, residents, medical students, consultants, etc. to a patient It also includes change in assigned role or authorization, e.g., relative to healthcare status change, and de-assignment IHE0004 Patient Care Episode Specific patient care episodes or problems that occur within an instance of care. This includes initial assignment, updates or amendments, resolution, completion, and cancellation. IHE0005 Patient Care Protocol Patient association with a care protocol. This includes initial assignment, scheduling, updates or amendments, completion, and cancellation.

45 Add Section 3.XX Retrieve ATNA Audit Event and 3.XY Retrieve Syslog Event to Volume 2c XX Retrieve ATNA Audit Event [ITI-xx] This transaction supports the retrieval of ATNA audit messages from the Audit Record Repository in accordance to a set of query parameters that determine the retrieved event reports. This transaction allows the retrieval of audit events created via transaction [ITI-20] Record Audit Event. This transaction is a profiling of a standard FHIR query of the audit event. 3.XX.1 Scope The Retrieve ATNA Audit Event transaction is used to retrieve ATNA events recorded in an ATNA Audit Record Repository. The result of this retrieval is a FHIR bundle of AuditEvent resources that match with a set of query parameters XX.2 Actor Roles Table 3.XX.2-1: Actor Roles Actor: Role: Actor: Role: Audit Record Repository Provides storage for ATNA audit events, and responds to queries for a portion of the stored records. Audit Consumer Queries for ATNA audit records XX.3 Referenced Standards RFC2616 IETF Hypertext Transfer Protocol HTTP/1.1 RFC4627 The application/json Media Type for JavaScript Object Notation (JSON) RFC6585 IETF Additional HTTP Status Codes RFC5424 The Syslog Protocol RFC3339 Date and Time on the Internet: Timestamps HL7 FHIR Fast Health Interoperability Resources v0.5.0 (aka DSTU 2.0) Rev Copyright 2015: IHE International, Inc.

46 3.XX.4 Interaction Diagram XX.4.1 Retrieve ATNA Audit Events This is an HTTP GET parameterized query from an Audit Consumer to an Audit Record Repository that has stored ATNA audit records received via [ITI-20] Record Audit Event transactions. Those records that are stored within a datastore can be retrieved in accordance to specific query parameters. The implementation of Access Control systems are strongly encouraged as described in Security Considerations section, and are out of scope for this transaction. The response to this query will reflect the contents of the audit records stored on the Audit Record Repository at the time of the query initiation. 3.XX Trigger Events The Audit Consumer sends a Retrieve ATNA Audit Events message when it needs ATNA Audit Events to process or analyze. 3.XX Message Semantics The Retrieve ATNA Audit Event message is an HTTP GET request sent to the RetrieveATNAAuditEvent URL on the Audit Record Repository. This is the search target is formatted as: date<=start-time&date>=stop-time>&<query> where: <authority> shall be represented as a host (either IP address or DNS name) followed optionally by a port. The Audit Record Repository may use <path> to segregate the RetrieveATNAAuditEvent RESTful service implementation from other REST-based services. Two dates are the required search parameters. They define a time period for the query. It enables an Audit Consumer to query for AuditEvent resources created during a specific time frame. See Section 3.XX <query>, if present, represents a series of encoded name-value pairs representing filters for the query. See Section 3.XX The use of http or https is a policy decision, but https is usually appropriate due to confidentiality of content stored in ATNA audit records XX Date Query Parameters The two date parameters shall be present in every query by the Audit Consumer and shall be supported by the Audit Record Repository. These parameters allow the Audit Consumer to specify the time frame of creation of Audit Events of interest and enable the Audit Consumer to Rev Copyright 2015: IHE International, Inc.

47 1100 constraint the number of Audit Events returned. The start-time and stop-time shall be in RFC format. Note: RFC-3339 format is the format mandated by Syslog for time stamps and is a sub-set of the XML date-time data format used by FHIR. This search parameter shall be encoded as shown below: date=>[starting_datetime]&date=<[ending_datetime] 1105 To retrieve AuditEvents resources created during the whole day: The Audit Record Repository shall apply matching criteria to AuditEvents resources characterized by AuditEvent.event.dateTime field valued within the time Frame specified in the Request message. The Audit Record Repository shall apply other matching criteria following rules defined by FHIR DSTU 2 Section ( 3.XX Additional ATNA Query Parameters The query parameters in this section may be supported by the Audit Consumer and shall be supported by the Audit Record Repository. These parameters can be used by the Audit Consumer Actor to refine query requests. The Audit Consumer shall encode all query parameters per RFC 3986 percent encoding rules. Although FHIR allows unconstrained use of AND and OR operators to make queries of unlimited complexity, this profile constrains the queries allowed. Multiple query parameters shall only be combined using AND & operators. The OR, operator shall be used only within a single query parameter that has multiple values. address is a parameter of string type. This parameter specifies the identifier of the network access point (NetworkAccessPointID) of the user device that creates the Audit Events. The value of this parameter shall contain the substring to match. For example: 01&date=< &address= The Audit Record Repository shall match this parameter with the AuditEvent.participant.network.identifier field. Rev Copyright 2015: IHE International, Inc.

48 patientid is a parameter of token type. This parameter specifies the identifier of the patient involved in the event as object. The value of this parameter shall contain the namespace URI (that represents the assigned authority for the identifier) and the identifier. For example: 01&date=< &patientid=urn:oid: The Audit Record Repository shall match this parameter with the AuditEvent.object.identifier field. A match with other fields SHALL NOT be reported in query responses identity is a parameter of token type. This parameter specifies unique identifier for the object. The parameter value should be identified in accordance to the object type; however the value shall carry, at minimum, one of namespace URI (as defined in RFC 3986), or identifier, or both. For example:?identity=urn:oid: ,?identity=urn:oid: FJ or?identity= FJ. The Audit Record Repository shall match this parameter with the AuditEvent.object.identifier field that is of type identifier (ParticipantObjectID in DICOM schema). object-type is a parameter of token type. This parameter specifies the type of the object. The parameter value shall contain the namespace URI defined by FHIR and a coded value. See for available codes. The Audit Record Repository shall match this parameter with the AuditEvent.object.type field that is of code type. role is a parameter of token type. This parameter specifies the role played by the object. The parameter value shall contain the namespace URI defined by FHIR and a coded value. See for available codes. To retrieve all the audit messages related to the document object with the unique id 12345^ a fully specified request would be: 01&date=< &role= 3 The Audit Record Repository shall match this parameter with the AuditEvent.object.role field Rev Copyright 2015: IHE International, Inc.

49 1175 source is a parameter of string type. This parameter identifies the source of the audit event (DICOM AuditSourceID). e.g., retrieve Audit Event resources produced by the audit source application characterized by id &date=< &source=urn:oid: The Audit Record Repository shall match this parameter with the AuditEvent.source.identifier field type is a parameter of token type. This parameter represents the identifier of the specific event audited. The parameter value shall contain the namespace URI and a coded value. Codes available are defined by DICOM and IHE (see ITI TF-1: Table : Audit Record trigger events) For example, to retrieve Audit Event resources related to PHI Export Events 01&date=< &type= The Audit Record Repository shall match this parameter with the AuditEvent.type field (DICOM EventID). participant is a parameter of string type. This parameter identifies the user that participated in the event. e.g.,: The Audit Record Repository shall match this parameter with the AuditEvent.participant.userId field. subtype is parameter of token type. This parameter identifies the specific IHE transaction that originates the audit event. The parameter value shall contain the namespace URI urn:ihe:event-type-code. For example, to retrieve Audit Events resources related to Retrieve Document Set [ITI-43] transactions 01&date=< &subtype=urn:ihe:event-type-code ITI-43 The Audit Record Repository shall match this parameter with the AuditEvent.subtype field (DICOM EventTypeCode). outcome is a parameter of token type. This parameter represents whether the event succeeded or failed. The parameter value shall contain the namespace URI Rev Copyright 2015: IHE International, Inc.

50 and a code taken from the related value set. Codes available can be found at To retrieve Audit Events resources related to failed events: 01&date=< &outcome= 4,8,12 The Audit Record Repository shall match this parameter with the AuditEvent.event.outcome field (DICOM EventOutcomeIndicator). 3.XX Populating Expected Response Format The FHIR standard provides encodings for responses as either XML or JSON. The Audit Record Repository shall support both message encodings. The Audit Consumer shall support one and may optionally support both. The Audit Consumer should indicate the desired response format using the http Accept header. Audit Consumer may provide a _format parameter carrying at least one of the values in Table 3.XX Multiple values in the accept header or _format parameter indicate the Audit Consumer is capable of processing responses in either response encoding Table 3.XX : Desired Response Encoding Response Encoding _format parameter value JSON Application/json+fhir XML application/xml+fhir XX Expected Actions The Audit Record Repository (ARR) maintains a database ATNA Audit Records. The rules for selection of syslog messages to be retained, retention interval rules, etc. are not specified by this transaction. When performing matching based on the query parameters, the Audit Record Repository shall: 1. Select all messages that have a time interval specified in the request URL. If these query parameters are missing, the Audit Record Repository shall return a 400 Bad Request HTTP status code. 2. If query parameters not defined in Section 3.XX (e.g., _sort, _include FHIR search result parameters) are specified in the request URL, then 1. If the parameter is not supported, it shall be ignored; 2. If the parameter is supported, the matching shall comply with the matching rules for that datatype in FHIR. 3. All matching resources shall be returned. Rev Copyright 2015: IHE International, Inc.

51 The Audit Record Repository shall return matching resources using the Retrieve ATNA Audit Event Response Message. See Section 3.XX If the Request format does not match with requirement defined in Section 3.XX.4.1.2, the Audit Record Repository shall return a 400 Bad Request HTTP status code. 3.XX.4.2 Retrieve ATNA Audit Event Response Message The Audit Record Repository shall return a HTTP Status code appropriate to the processing and may return AuditEvents resources in the message body XX Trigger Events The Audit Record Repository creates this message when it receives and processes a Retrieve ATNA Audit Event message. 3.XX Message Semantics When the query is successfully processed, the Audit Record Repository shall return the AuditEvent resources that match the request query parameters, encoded as a FHIR bundle of AuditEvent resources. The Bundle format shall adhere to rules defined in ITI TF-2x: Appendix Z.1. In addition to those requirements, the Bundle.type parameter shall be set to searchset. The Content-Length entity-header field shall be returned, unless this is prohibited by the rules in RFC2616 Section 4.4, or subsequent versions of the HTTP specification. Note: RFC2616 specifies that this field should be returned. This transaction strengthens that requirement. The Content-Type of the response will depend upon the requested response format indicated by Audit Consumer via the _format parameter Table 3.XX : Response Type related to Requested format _format parameter value Bundle Format Content-Type application/json+fhir FHIR JSON Bundle application/json+fhir; charset=utf-8 application/xml+fhir ATOM Feed (RFC 4287) application/xml+fhir; charset=utf If the date query parameter is missing (see Section 3.XX ), the Audit Record Repository shall return HTTP response code Bad Request. If the specified parameters do not result in any matching Audit Event, the Audit Record Repository shall return either HTTP response-code 404 (not found) with the suggested reasonphrase No Audit Event found, or an empty FHIR bundle. Rev Copyright 2015: IHE International, Inc.

52 If the requested data size is excessive, the Audit Record Repository may respond with HTTP 206 Partial Content. If the response is 206 Partial Content, then the response body may contain a subset of the messages that match the query. Other HTTP response codes may be returned by the Audit Record Repository, indicating conditions outside of the scope of this transaction, for example, 401 Authentication Failed might be returned if Audit Record Repository is grouped with the Kerberized Server Actor in the EUA Profile. The Audit Record Repository should complement the returned error code with a human readable description of the error condition. Audit Record Repository may return HTTP redirect responses (responses with values of 301, 302, 303 or 307) in response to a request. Audit Consumers must follow redirects, but if a loop is detected, it may report an error. Table 3.XX describes the mapping rules between AuditEvent FHIR resources and DICOM audit message format (this table is defined in FHIR Table ). The AuditEvent resource shall encode all the data within the DICOM format of the syslog Audit Message. Table 3.XX : FHIR AuditEvent resource Mapping VS. DICOM AuditEvent DICOM Message event EventIdentification purposeofevent participant ActiveParticipant role RoleIdCode reference location policy media MediaType network Rev Copyright 2015: IHE International, Inc.

53 AuditEvent purposeofuse source site identifier type object identifier reference type role lifecycle sensitivity name description Query Detail Type Value DICOM ParticipantObjectName ParticipantObjectDescription XX FHIR encoded bundle of Audit Events Messages When the query is successful, the message shall contains a HTTP response status code of 200, and a body containing a FHIR bundle of AuditEvent FHIR resources. Example XML format: Rev Copyright 2015: IHE International, Inc.

54 <Bundle> <type>searchset</type> <total>3</total> <link rel="self" href=" 01&date=< "/> <entry> <base value=" <resource> <AuditEvent>... </AuditEvent> <resource> </entry> <entry> <base value=" <resource> <AuditEvent>... </AuditEvent> <resource> </entry> <entry> <base value=" <resource> <AuditEvent>... </AuditEvent> <resource> </entry> </Bundle> 3.XX Expected Actions When the Audit Consumer receives the result of the search operation initiated, it can further process data received within the FHIR bundle of AuditEvents resources. 3.XX Profile Resource Audit Record Repository implementing transaction [ITI-XX] shall provide a Profile Resource as described in ITI TF-2x: Appendix Z.3 indicating all query parameters and data elements implemented by the Audit Record Repository. 3.XX Conformance Resource Audit Record Repository implementing transaction [ITI-XX] shall provide a Conformance Resource as described in ITI TF-2x: Appendix Z.4 indicating the query operation for the AuditEvent Resource has been implemented and shall include all query parameters implemented for the AuditEvent Resource 3.XX.5 Security Considerations See the general Security Considerations in ITI TF-1: XX.5.1 Security Audit Considerations None Rev Copyright 2015: IHE International, Inc.

55 3.XY Retrieve Syslog Event This transaction supports the retrieval of audit messages from the Audit Record Repository subject to parameters that limit the retrieval XY.1 Scope The Retrieve Syslog Event transaction is used to retrieve events recorded in Syslog event reports. Audit Record Repository Audit Consumer Retrieve Syslog Messages XY.2 Use Case Roles Actor: Audit Record Repository Role: Provides storage for audit records, and responds to queries for a portion of the stored records. Actor: Audit Consumer Role: Queries for audit records. 3.XY.3 Referenced Standard RFC2616 IETF Hypertext Transfer Protocol HTTP/1.1 RFC4627 The application/json Media Type for JavaScript Object Notation (JSON) RFC6585 IETF Additional HTTP Status Codes RFC5424 The Syslog Protocol RFC3339 Date and Time on the Internet: Timestamps Rev Copyright 2015: IHE International, Inc.

56 3.XY.4 Interaction Diagram Audit Consumer Audit Record Repository Retrieve Syslog Event Request Syslog Event Response XY.4.1 Retrieve Syslog Event Request This is an HTTP GET parameterized query from an Audit Consumer to an Audit Record Repository (Audit Record Repository). 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 may have selection criteria for what kinds of messages are kept for later query, how long different kinds of messages are kept, etc. The response to this query will reflect the contents of the audit records stored on the Audit Record Repository at the time of the query initiation. 3.XY Trigger Events This message is sent when the Audit Consumer needs syslog records to process. 3.XY Message Semantics The Retrieve Syslog Event Request message is an HTTP GET request sent by the Audit Consumer to the RetrieveSyslogEvent URL on the Audit Record Repository. The search target is formatted as: Where: <location> a locally defined root part of arbitrary URL path. Two dates are the required query parameters. They define a time period for the query. See Section 3.XY <query> if present, represents additional query parameters. See Section 3.XY Syslog search parameters. Rev Copyright 2015: IHE International, Inc.

57 The Audit Consumer may indicate in the Accept acceptance of JSON (i.e., application/json). In the absence of an Accept preference, JSON shall be used. The Audit Record Repository shall support JSON format. 3.XY Date Query Parameters Note: RFC-3339 format is the format mandated by Syslog for time stamps and is a sub-set of the XML date-time data format used by FHIR. The two date parameters shall be present in every query by the Audit Consumer and shall be supported by the Audit Record Repository. These parameters allow the Audit Consumer to specify the time frame of creation of Audit Events of interest and enable the Audit Consumer to constraint the number of Audit Events returned. The start-time and stop-time shall be in RFC format. To retrieve AuditEvents resources created during the whole day: the query URL is: 3.XY Additional Query Parameters The query parameters in this section may be supported by the Audit Consumer and shall be supported by the Audit Record Repository. The Audit Consumer may include additional query parameters. These query parameters shall be encoded in accordance with RFC 2616 for encoding GET queries. The query string is encoded as a list of query parameter/value pairs, using the parameter names in column 2 of Table 3.XY to indicate the syslog message element being matched. There is a query parameter assigned for each syslog message element. In all cases: The query values shall be encoded as strings. The Syslog message is considered to match if the value string is a sub-string found in the specified message element. Table 3.XY : RetrieveAuditEvent Parameters for Syslog Parameters Syslog RFC-5424 element PRI VERSION HOSTNAME APP-NAME PROCID MSG-ID MSG Retrieve Syslog Event Query Parameter pri version hostname app-name procid msg-id msg 1415 Rev Copyright 2015: IHE International, Inc.

58 HTTP allows for multiple instances of a parameter to be requested with different values. Multiple values of the same parameter name shall be treated as an OR relationship for string matches. The Audit Consumer may combine different query parameters. The Audit record Repository will match those parameter with AND relationship. The matching of different query parameters is combined with an AND relationship. Some examples of how this works are: A query for hostname=frodo and hostname=bilbo will return the combination of all event reports from the hosts Frodo and Bilbo during the time interval. A query for hostname=frodo and proc-id=system it means all events from the host Frodo with proc-id of system during the time interval. A query for hostname=frodo, hostname=bilbo, and proc-id=system will return the combination of all event reports from the hosts Frodo and Bilbo that have the proc-id of system during the time interval. This form of query is not a substitute for additional processing by the Audit Consumer. The Audit Record Repository can return large blocks of audit event reports. The Audit Consumer may need to perform further processing to select the information needed for a report. The Audit Record Repository shall provide documentation indicating which parameters it supports and what extensions have been made. 3.XY Expected Actions The Audit Record Repository (ARR) maintains a database of syslog messages. The rules for selection of syslog messages to be retained, retention interval rules, etc. are not specified by this transaction. The Audit Record Repository shall return syslog records that reflect the match to all of the query parameters provided by the Audit Consumer. The Audit Record Repository shall respond with a Syslog Event Response message described in Section 3.XY.4.2. The matching process shall be: 1. Select all messages that have a time interval specified in the request URL. If these query parameters are missing, the Audit Record Repository shall return a 400 Bad Request HTTP status code. 2. If query parameters not defined in Section 3.XY are specified in the request URL, then if the parameter is not supported, it shall be ignored; 3. All matching resources shall be returned. 3.XY.4.2 Syslog Event Response Message The Audit Record Repository shall return a HTTP Status code appropriate to the processing and may return syslog messages in the message body. Rev Copyright 2015: IHE International, Inc.

59 3.XY Trigger Events The Audit Record Repository creates this message when it receives and processes a Retrieve Syslog Event Request message XY Message Semantics When the query is successful, the Audit Record Repository shall return the audit records that match encoded as a JSON entries array. The Content-Length entity-header field shall be returned, unless this is prohibited by the rules in RFC 2616 Section 4.4, or subsequent versions of the HTTP specification. Note: RFC 2616 specifies that this field should be returned. This transaction strengthens that requirement. If the date parameters are missing, the Audit Record Repository shall return HTTP response code Bad Request. If the specified parameters do not result in any matching Syslog Events, the Audit Record Repository shall Syslog Events found, or an empty JSON entries array. If the requested data size is excessive, the Audit Record Repository may respond with HTTP 206 Partial Content, or other error codes. If the response is 206 Partial Content, then the response body may contain a subset of the Syslog Events that match the query. Note: Other HTTP response codes may be returned by the Audit Record Repository, indicating conditions outside of the scope of this transaction, for example, 401 Authentication Failed might be returned if Audit Record Repository employs IUA and is given an expired authorization token or is grouped with the EUA Profile Kerberized Server. The Audit Record Repository should complement the returned error code with a human readable description of the error condition. Audit Record Repository may return HTTP redirect responses (responses with values of 301, 302, 303 or 307) in response to a request. Audit Consumers must follow redirects, but if a loop is detected, it may report an error. 3.XY JSON encoded array of Syslog Messages When the query is successful, the Syslog Event Response message shall contains a HTTP response status code of 200, and a body containing a JSON Array of Syslog messages. Example: { { Pri : string, Version: string, Timestamp: T00:05 Hostname: string App-name: string Procid: string Rev Copyright 2015: IHE International, Inc.

60 Msgid : string Structured-data : string Msg : string1 } { Pri : string, Version: string, Timestamp: T00:05 Hostname: string App-name: string Procid: string Msgid : string Msg : string2 } { Pri : string, version: string, Timestamp: T00:05 Hostname: string App-name: string Procid: string Msgid : string Msg : string3 } 1520 } Each individual Syslog message is encoded by parsing the message elements defined in RFC 5424 as strings identified by the element name in RFC If the syslog message lacks one of these elements, the corresponding element shall be omitted from the JSON encoding XY Expected Actions The Audit Consumer Actor shall interpret the response message returned by the Audit Record Repository and process the response in some manner specific to its application function. 3.XY.5 Security Considerations See the general Security Considerations in ITI TF-1: XY.5.1 Security Audit Considerations None Rev Copyright 2015: IHE International, Inc.