IHE IT Infrastructure
5
Technical Framework Supplement
Add RESTful Query to ATNA
10
Draft for Public Comment
15
Date: June 8, 2015
20
Author: IHE ITI Technical Committee
Email: [email protected]
Please verify you have the most recent version of this document. See here for Trial 25
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 30
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 http://www.ihe.net/ITI_Public_Comments. In order to be considered in development of the trial implementation version of the supplement, comments must be received by July 8, 2015.
35
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 40
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: http://ihe.net. 45
Information about the IHE IT Infrastructure domain can be found at: http://ihe.net/IHE_Domains.
Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at: http://ihe.net/IHE_Process and
http://ihe.net/Profiles. 50
The current version of the IHE IT Infrastructure Technical Framework can be found at: http://ihe.net/Resources/Technical_Frameworks.
CONTENTS
55
Introduction to this Supplement ... 6
Open Issues and Questions ... 6
Closed Issues ... 6
General Introduction ... 11
60 Appendix A - Actor Summary Definitions ... 11
Appendix B - Transaction Summary Definitions ... 11
Glossary ... 11
Volume 1 – Profiles ... 12
9.3 Audit Trail Processing and Use Cases ... 12
65 9.3.1 Use Cases ... 15
9.3.1.1 Use Case #1 Study Change Tracking use-case ... 16
9.3.1.1.1 Studies Change Tracking use-case ... 16
9.3.1.2 Use Case #2 Clinician Personal History of Study views ... 17
9.3.1.2.1 Clinician Personal History of Study views ... 17
70 9.3.1.3 Use Case #3: Data Export Monitoring for administrative and efficiency purposes ... 19
9.3.1.3.1 Exporting Data Monitoring for administrative and efficiency purposes .... 19
9.3.1.4 Use Case #4: Patient access to his audit records ... 20
9.3.1.4.1 Patient access to his audit records Use Case Description ... 20
75 9.3.1.5 Use Case #5: Statistical Analysis and Monitoring of EHR Usage ... 21
9.3.1.5.1 Statistical Analysis and Monitoring of EHR Usage ... 22
9.3.1.6 Use Case #6: Centralized Warning Alert Audit Facility ... 23
9.3.1.6.1 Centralized Warning Alert Audit Facility ... 23
9.3.2 Technical Approach ... 24
80 9.4 Actors/Transactions ... 25
9.5 ATNA Integration Profile Options ... 28
9.5.3 Filter and Forward Option ... 28
9.5.4 Retrieve Audit Message Option ... 29
9.8 RESTful ATNA Query Security Considerations ... 30
85 9.9 ATNA Cross Profile Considerations ... 31
9.10 Required Actor Groupings ... 31
Volume 2 – Transactions ... 33
3.20 Report Audit Event ... 33
3.20.1 Scope ... 33
90 3.20.2 Actor Roles ... 33
3.20.3 Referenced Standards ... 34
3.20.4 Interaction Diagram ... 35
3.20.4.1 Record Audit Event ... 35
3.20.4.1.1 Trigger Events ... 35
95 3.20.4.1.1.1 DICOM and IHE event reports ... 36
3.20.4.1.1.3 Audit Message Transports ... 39
3.20.4.1.1.3.1 Transmission of Syslog Messages over TLS ... 39
3.20.4.1.1.3.2 Reliable Syslog (deprecated) ... 39
100 3.20.4.1.1.3.3 Transmission of Syslog Messages over UDP (formerly:BSD Syslog) ... 39
3.20.4.1.2 Message Semantics ... 40
3.20.4.1.3Audit Message Formats ... 40
3.20.4.1.3.1IHE Audit Trail Message Format ... 41
105 3.20.4.1.3.1.1 RoleIDCode with access control roles ... 41
3.20.4.1.3.1.2 Audit Encoding of the Purpose of Use value ... 42
3.20.4.1.3.2RFC-3881 format (Deprecated) ... 42 3.20.4.1.4 Expected Actions ... 43 3.20.5 Security Considerations ... 43 110 3.20.6 retired ... 43 3.20.7 retired ... 44
3.20.8 Controlled Terminology for IHE Extensions ... 44
3.XX Retrieve ATNA Audit Event [ITI-xx] ... 45
3.XX.1 Scope ... 45
115 3.XX.2 Actor Roles ... 45
3.XX.3 Referenced Standards ... 45
3.XX.4 Interaction Diagram ... 46
3.XX.4.1 Retrieve ATNA Audit Events ... 46
3.XX.4.1.1 Trigger Events ... 46
120 3.XX.4.1.2 Message Semantics ... 46
3.XX.4.1.2.1 Date Query Parameters ... 46
3.XX.4.1.2.2 Additional ATNA Query Parameters ... 47
3.XX.4.1.2.3 Populating Expected Response Format ... 50
3.XX.4.1.3 Expected Actions ... 50
125 3.XX.4.2 Retrieve ATNA Audit Event Response Message ... 51
3.XX.4.2.1 Trigger Events ... 51
3.XX.4.2.2 Message Semantics ... 51
3.XX.4.2.2.1 FHIR® encoded bundle of Audit Events Messages ... 53
3.XX.4.2.3 Expected Actions ... 54
130 3.XX.4.2.4 Profile Resource ... 54
3.XX.4.2.5 Conformance Resource ... 54
3.XX.5 Security Considerations ... 54
3.XX.5.1 Security Audit Considerations ... 54
3.XY Retrieve Syslog Event ... 55
135 3.XY.1 Scope ... 55
3.XY.2 Use Case Roles ... 55
3.XY.3 Referenced Standard ... 55
3.XY.4 Interaction Diagram ... 56
3.XY.4.1 Retrieve Syslog Event Request ... 56
140 3.XY.4.1.1 Trigger Events ... 56
3.XY.4.1.2 Message Semantics ... 56
3.XY.4.1.2.1 Date Query Parameters ... 57
3.XY.4.1.2.2 Additional Query Parameters ... 57
3.XY.4.1.3 Expected Actions ... 58
145 3.XY.4.2 Syslog Event Response Message ... 58
3.XY.4.2.1 Trigger Events ... 59
3.XY.4.2.2 Message Semantics ... 59
3.XY.4.2.2.1 JSON encoded array of Syslog Messages ... 59
3.XY.4.2.3 Expected Actions ... 60
150 3.XY.5 Security Considerations ... 60
3.XY.5.1 Security Audit Considerations ... 60
Introduction to this Supplement
Event logging is a system facility that is used by healthcare applications and other applications. 155
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 160
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).
165
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 non-170
deterministic 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 175
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
180
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 185
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.
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? 190
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.
195
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.
Partial List of event sources/codecs considered
200
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
A variety of existing event management products and standards were examined. Most of 205
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 archive including ARR as well as much else. At least 5,000 operational downloads, but most probably not for ARR use.
Evaluate
Tiani Spirit EHR (awaiting formal name)
EU Public specification. Implementation underway.
Evaluate Connect / Healtheway/ ? Published specification. Need to
determine license, etc., but probably suitable.
Evaluate
FHIR Security Event Report Query of a FHIR resource Evaluate Plug-in style (multiple) A variety of product specific
mechanisms to write plugins for that product.
Reject, too product specific, subject to change at will by product vendor Direct access to database (multiple) A variety of product specific
mechanisms that document the format and access methods for the internal database used by the product.
Reject, too product specific, subject to change at will by product vendor
Direct access to flat files (multiple) 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
The surviving four were evaluated against the ITI list of evaluation criteria. The general 210
spreadsheet was reviewed and the following table is the result.
Evaluation Criteria Results
Criteria DCM4CHE Tiani Spirit
EHR
Connect/Healtheway FHIR®
(SecurityEvent)
Stability Early
development
Has been deprecated DSTU
From an SDO No Govt
specification
Govt specification Yes
Licensing restrictions LGPL v2 ? CC 0 Implementation Experience Approx 5K installations 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
Criteria DCM4CHE Tiani Spirit EHR
Connect/Healtheway FHIR®
(SecurityEvent) Phase 1 decision Continue
evaluation
Drop Drop Continue evaluation
Acceptance by Intrusion Detection/ Security Analysis vendors ? n.a. n.a. ? Decision:
FHIR® was selected as the standard to be used to profile the Query transaction. The 215
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:
220
• 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 225
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 2015. Revisions based upon public comment and TI experience can be handled during the FHIR® DSTU cycle.
230
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?
235
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.
240
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 245
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
250
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. 255
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 260
syslog parameters ATNA (FHIR® will generate 400 - 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 265
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 270
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)?
275
Answer: This is a very important implementation decision, and IHE cannot define requirement for this.
General Introduction
280
Appendix A - Actor Summary Definitions
Add the following actors to the IHE Technical Frameworks General Introduction list of Actors:
Actor Definition
Audit Consumer Retrieves syslog and ATNA audit messages based upon queries using Syslog metadata and ATNA audit message content. Subsequent processing is not defined.
Appendix B - Transaction Summary Definitions
Add the following transactions to the IHE Technical Frameworks General Introduction list of
285
Transactions:
Transaction Definition
ITI-XX Retrieve Audit Messages. Retrieves syslog and ATNA audit messages based upon queries using Syslog metadata and ATNA audit message content.
ITI-XY Retrieve Syslog Messages. Retrieves syslog messages based upon using the syslog metadata.
Glossary
Add the following glossary terms to the IHE Technical Frameworks General Introduction Glossary:
290
Glossary Term Definition
Syslog metadata Attributes that classifies the audit message defining: severity of the event, facility and application that sent the message. These are defined in RFC-5424.
Syslog message 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.
Volume 1 – Profiles
Replace Section 9.3 Audit Trail Transport with this new Section 9.3 Audit Trail Processing and Use Cases
295
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. 300
Figure 9.3-1: System Event Logging 305
The major elements of system event logging are shown in Figure 9.3-1. 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.
310
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
as a message header that is followed by free form message body. Messages that comply 315
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 320
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 325
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 330
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 335
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 340
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:
345
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)
350
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
DICOM and IHE have specified the use of a secured reliable transport for event 355
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 360
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 365
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 370
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. 375
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 380
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 385
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 390
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.
395
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 400
destination nodes for the transport facilities. 9.3.1 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.
405
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 410
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 415
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 420
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 425
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.
7. 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 430
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
435
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 440
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.
445
10.All reports of failed login attempts are forwarded to a central Intrusion Detection System (IDS).
9.3.1.1 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®
450
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). 9.3.1.1.1 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 455
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 460
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 465
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.
470
Figure 9.3.1.1.1-1: Studies Change Tracking process flow
9.3.1.2 Use Case #2 Clinician Personal History of Study views 475
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;
480
• Revaluate clinical decisions taken;
• Consolidate to a unique device a complete picture of complex clinical cases. 9.3.1.2.1 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 485
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
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).
490
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 495
Dr. White wants to store locally.
Figure 9.3.1.2.1-1: Clinician Personal History of Study views process flow 500
9.3.1.3 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 505
outpatient has been already consulted or not.
9.3.1.3.1 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; 510
• 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
515
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: 520
• 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). 525
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. 530
Figure 9.3.1.3.1-1: Exporting Data Monitoring for administrative and efficiency purposes Process flow
9.3.1.4 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 535
accessed a specific study. Using those data, the patient should be able to understand if privacy consents expressed were applied in accordingly.
9.3.1.4.1 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 540
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 545
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
550
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. 555
The web app reports that the identified documents/studies have been disclosed/exported for treatment and research purposes.
Figure 9.3.1.4.1-1: Patient access to his audit records Process Flow 560
9.3.1.5 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
EHR usage details can be used to improve workflow, procedure compliance, and other aspects of 565
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.
570
9.3.1.5.1 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 575
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. 580
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.
585
Figure 9.3.1.5.1-1: Statistical Analysis and Monitoring of EHR Usage Process Flow
9.3.1.6 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 590
repository at the central facility.
9.3.1.6.1 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 595
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.).
600
Figure 9.3.1.6.1-1: Centralized Warning Alert Audit Facility
9.3.2 Technical Approach
There are a wide variety of specific reports and analyses that will be needed. Based on the use 605
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 610
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.
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;
615
• 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 620
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.
625
• 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.
630
Modify ITI TF-1:9.4 as shown, replacement figure provided.
9.4 Actors/Transactions
This section defines the actors, transactions, and/or content modules in this profile. General
635
definitions of actors are given in the Technical Frameworks General Introduction Appendix A at http://www.ihe.net/Technical_Framework/index.cfm.
Figure 9.4-1 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.
640
When an implementation chooses to support this Integration Profile for an actor, that actor shall 645
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 650
access.
Table 9.4-1 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”).
655
Table 9.4-1: ATNA Profile - Actors and Transactions
Actors Transactions Optionality Reference
Audit Record Repository
Record Audit Event [ITI-20] R ITI-2a: 3.20
Record Audit Event [ITI-20]
O (See Note 1) ITI-1: 9.5.3
Retrieve ATNA Audit Event [ITI-XX]
O (See Note 2) ITI-2c: 3.XX
Retrieve Syslog Event [ITI-XY]
O (See Note 2) ITI-2c: 3.XY
Audit Consumer
Retrieve ATNA Audit Event [ITI-XX]
R ITI-2c: 3.XX
Retrieve Syslog Event [ITI-XY]
O 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
Application
Authenticate Node [ITI-19] O ITI-2a: 3.19 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
660
[ITI-XX] Retrieve ATNA Audit Event. The Retrieve Syslog Event [ITI-XY] transaction is always optional.
9.5 ATNA Integration Profile Options
665
Options that may be selected for this Integration Profile are listed in the Table 9.5-1 along with the actors to which they apply. Dependencies between options when applicable are specified in notes.
Table 9.5-1: ATNA - Actors and Options 670
Actor Option Name Vol. & Section
Audit Record Repository Filter and Forward Option ITI TF-1: 9.2.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 9.5.4 to ITI TF-1:9.5 9.5.3 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 675
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 680
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 685
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
690
mechanisms defined in transaction [ITI-20] Record Audit Event.
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 695
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 700
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:
705
• 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-5424. Audit messages that comply with the ATNA schema may also be filtered using criteria that 710
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. 715
No-alterations of the audit message structure and content are permitted while it is forwarded. 9.5.4 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.
720
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 725
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
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.
730
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.
735
Figure 9.5.4-1: Retrieve Audit Message Option diagram
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
740
section number.
9.8 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. 745
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 750
• messages related to IHE transactions or compliant with DICOM Audit Message Schema (DICOM PS3.15 Section A.5)
http://medical.nema.org/medical/dicom/current/output/chtml/part15/sect_A.5.html
• other syslog messages compliant with RFC-5424. 755
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 760
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 765
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, 770
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.
775
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 780
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.
9.10 Required Actor Groupings
Internally within the ATNA Profile, some ATNA actors are grouped with other ATNA actors to 785
Table 9.10-1: ATNA - Required Actor Groupings
ATNA Actor Actor to be
grouped with
Reference Content Bindings
Reference Audit Record Consumer Secure Node or
Secure Application
Volume 2 – Transactions
790Replace 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.
795
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.
800
- 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 3.20.6-1: Audit Record trigger events and Section 3.20.7 Audit Message Format. Both of these are now in Section 3.20.4. Placeholder destinations have been preserved.
805
3.20 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.
810
3.20.1 Scope
This transaction is used to report auditable events to an Audit Record Repository. 3.20.2 Actor Roles
Figure 3.20.2-1: Use Case Diagram 815
Record Audit Event Any Grouped
Actor Audit Record Repository A
Audit Record Repository B
Table 3.20.2-1: Actor Roles
Actor: Any actor or any other application that is grouped with the Secure Node Actor or Secure Application Actor.
Role: Create an audit record and transmit this record to the Audit Record Repository.
Actor: Audit Record Repository
Role: Recipient:Receive an audit record from the Audit Record Creator and store this for audit purposes.
Role: Source: Copy an audit record and transmit this record to another Audit Record Repository. When ARR supports the Filter and Forward Option.
3.20.3 Referenced Standards
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 3 - 2011
ASTM: E2147-01 Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems
NIST: SP 800-92 Guide to Computer Security Log Management.
W3C: Recommendation: Extensible Markup Language (XML) 1.0
3.20.4 Interaction Diagram
3.20.4.1 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 825
forward event reports to other Audit Record Repositories if they support the Filter and Forward Option, as defined in ITI TF-1:9.5.3.
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 830
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. 3.20.4.1.1 Trigger Events
There are two trigger events: 835
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.
840
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.
Forward? Audit Record Repository Audit Record Repository Any Grouped Actor Record Audit Event [ITI-20] Record Audit Event [ITI-20]
3.20.4.1.1.1 DICOM and IHE event reports 845
IHE specifies that events defined in Table 3.20.6-1 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
850
due to numerous references to it in other documents, was not changed.
Table 3.20.6-1: Audit Record trigger events
Trigger Event Description Source Vocabulary
Actor-start-stop Startup and shutdown of any actor. Applies to all actors. Is distinct from hardware powerup and shutdown.
DICOM PS 3.15 A.5.3 “Application Activity” Audit-Log-Used The audit trail repository has been accessed or modified by
something other than the arrival of audit trail messages.
DICOM PS 3.15 A.5.3 “Audit Log Used” Begin-storing-instances Begin storing SOP Instances for a study. This may be a mix
of instances.
DICOM PS 3.15 A.5.3 “Begin Transferring DICOM Instances” Health-service-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. See note below.
IHE Extension (ITI TF-2a: 3.20.7.3) “Health Services Provision Event” Instances-deleted SOP Instances are deleted from a specific study. One event
covers all instances deleted for the particular study.
DICOM PS 3.15 A.5.3 “DICOM Instances Accessed” or “DICOM Study Deleted” Instances-Stored Instances for a particular study have been stored on this
system. One event covers all instances stored for the particular study.
DICOM PS 3.15 A.5.3 “DICOM Instances Transferred” Medication Medication orders and administration within an instance or
episode of care. This includes initial order, dispensing, delivery, and cancellation.
See note below.
IHE Extension (ITI TF-2a: 3.20.7.3) “Medication Event”
Mobile-machine-event Mobile machine joins or leaves secure domain. DICOM PS 3.15 A.5.3 “Network Entry” Node-Authentication-failure A secure node authentication failure has occurred during
TLS negotiation, e.g., invalid certificate.
DICOM PS 3.15 A.5.3 “Security Alert” Order-record-event 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.
DICOM PS 3.16 Annex D “Order Record”
Patient-care-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
IHE Extension (ITI TF-2a: 3.20.7.3) “Patient Care Resource Assignment”
Patient-care-episode Specific patient care episodes or problems that occur within an instance of care. This includes initial assignment, updates
IHE Extension (ITI TF-2a: 3.20.7.3) “Patient Care
Trigger Event Description Source Vocabulary or amendments, resolution, completion, and cancellation.
See note below.
Episode” 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: 3.20.7.3) “Patient Care Protocol”
Patient-record-event Patient record created, modified, or accessed. DICOM PS 3.16 Annex D “Patient Record”
PHI-export Any export of PHI on media, either removable physical media such as CD-ROM or electronic transfer of files such as email. Any printing activity, paper or film, local or remote, which prints PHI.
DICOM PS 3.15 A.5.3 “Export”
PHI-import Any import of PHI on media, either removable physical media such as CD-ROM or electronic transfers of files such as email.
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”
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 task-grouping 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 role-based 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 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.
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.
Study-Object-Event Study is created, modified, accessed, or deleted. This reports on addition of new instances to existing studies as well as creation of new studies.
DICOM PS 3.15 A.5.3 “DICOM Instances Accessed” Study-used 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 “DICOM Instances Accessed”
3.20.4.1.1.2 Other event reports
Events that do not correspond to DICOM events or IHE Extension events can be reported. They 855
shall comply with DICOM PS 3.15 A.5 schema (see
http://medical.nema.org/medical/dicom/current/output/chtml/part15/sect_A.5.html). 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.
3.20.4.1.1.3 Audit Message Transports 860
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 865
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
870
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-3164.
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 875
Actors may choose to utilize either of the transport mechanisms, unless they also comply with another Profile that further restricts the use.
3.20.4.1.1.3.1 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 880
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.
3.20.4.1.1.3.2 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.
885
3.20.4.1.1.3.3 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
