RESTful ATNA Transactions

1. RESTful ATNA Transactions Rob Horn (Agfa Healthcare)

2. Proposal Add RESTful PUT/POST transactions for audit events Revise Actor descriptions in the transactions to allow us to simplify the transaction descriptions and separate event related functions from other functions. E.g., a Secure Node has many functions that are unrelated to the reporting of events. These are described in Volume 1. Using the same actor name in the Transaction makes it tricky to re-use the transaction for a different actor that needs to report events unrelated to security functions. This came up in SOLE. Work Effort is small

3. Value Proposition There are use cases where the use of syslog as the transport for delivering event reports to a repository is impractical. SOLE had some of these use cases Delivery of bulk event reports to an outside analyst that lacks regular access to internal facilities. Reporting of events by systems that are unable to provide syslog, e.g., battery powered mobile devices like tablets. Other use cases exist. SOLE did not address these. Reporting of events by applications that lack system logging facility access, e.g., Web Apps. Bulk Delivery between repositories

4. Event Reporting Context Event Reporting (which includes audit logs) is important in many market and technology segments. Computer and Network operations Business Intelligence and Analytics Cyber-security and Forensics Healthcare operations Service and Maintenance LOGs

5. Event Reporting Context Syslog is old and well established for event reporting in these markets. It remains the interoperable baseline. Individual segments have additional event needs that are not shared across market segments. Syslog and market segment specific approaches have co-existed in all the market segments. E.g., Warehouse scale computing uses Journalctl for inside the “machine” and syslog for communication between “machines”. The use of virtualization and containerization makes “machine” a somewhat fuzzy concept. Think of each blade as a “machine”. E.g., Android and Apple use an internal optimized format for system logging inside the device. Both have provided a syslog application for external delivery of the complete log contents. Both have dropped the total log contents delivery in favor of purpose specific filtering and delivery apps. FHIR is of obvious interest to Healthcare Operations, but not the other market segments.

6. Syslog and FHIR We will need to support both. This will lead to some deployment debates within profiles for which transactions should be mandatory or optional. - some existing contexts will clearly prefer syslog events - some contexts will clearly prefer the more constrained FHIR audit events. The profile optionality decisions can be separately from transaction definition. Individual event report rules can be managed by content profile or audit content sections that are external to these transactions. There will be situations where it is not obvious what the optionality should be.

7. Relationship to SOLE SOLE used the ATNA transactions for everything except the delivery of syslog event reports by RESTful PUT/POST. IHE RAD chose the minimal transaction and expects to transfer the responsibility to ITI in a coordinated schedule. At present there are Connectathon activities, etc., being done by RAD. This is just one transaction, so transfer of responsibility should be relatively easy to schedule and coordinate. SOLE defined the “syslog event” RESTful delivery.

8. New in this Workitem Add a FHIR event delivery transaction. Add both transactions as options for the current ATNA actors