Implementing ATNA on a FHIR server

Dec 10, 2012

This is the first of a series of posts that I’ll be making about the trial implementation of the IHE XDS profile using FHIR resources. Note that the status of the FHIR resources for XDS is a strawman - both HL7 and IHE are looking at these and evaluating their suitability for use for providing a mobile friendly gateway to an XDS system, but neither organization has committed to this approach yet - we have to see how well it works. The first step in the implementation is to provide a working security logging framework since this is a fundamental requirement for all XDS actors. This post describes the way that ATNA (rfc 3881) is implemented using FHIR resources.

Firstly, a quick primer for rfc 3881: a security log message is sent from an application to a specialized security logging server that provides logging and analysis services. The security log message is sent using either UDP or secure-TCP, with a specified xml format at the end - the XML part is what is specified in RFC 3881. The XML specifies the kind of event the took place, information about the user and system context in which it takes place, and information about what system objects were affected by the operation - and whether the operation succeeded or not. The ATNA actors describe a simple flow - event records are created on one system, and sent to the other system for storage. No other interactions are allowed.

In order to reproduce this functionality, the FHIR specification defines the “SecurityEvent” resource. This resource includes a few of the fields from the security event log itself and the content specified by RFC 3881. In a RESTful context, the source system creates the resource - using either XML or JSON, and posts it to the security logging system using an HTTP post (a FHIR “create” event).The HTTP post can be secured using SSL to reproduce the same functionality as the secure-TCP syslog equivalent.

A RESTful approach based on FHIR is better because:

  • syslog is alien to many developers these days, while HTTP/SSL libraries are ubiquitous
  • There are many HTTP/network configuration, debugging and manipulation frameworks and services
  • JSON is defined out of the box, and equivalent and interconvertable with the XML format
  • The exchange is easy to extend and leverage

The last point requires some clarification. To start with, the “create” function is only one of many defined by FHIR - there is also update, and delete, though these would generally by disabled in a security logging system, or at least highly restricted. There is also the ability to read existing security logs, search them, and use pub/sub to replicate some or all of the events on other systems. These operations are not the basis for a full security event analysis service, but do open up the system for more reuse.

In addition, FHIR defines many other functions that can be used, such as profiles and conformance statements, and also offers the ability to bundle the security information about the operation along with the operation itself - that resolves a conundrum with the existing ATNA spec - do you log before you find out whether the operation works, or afterwards, when you might not be able to log it? Other FHIR framework advantages also apply, such as RDF based mappings into a ontological reasoning systems. It would be reasonable to expect that at some point in the near future this would be a useful addition to security analysis services.

Trying it out

There’s a public FHIR server offering ATNA functionality. You can get a list of security events on the system as html, xml or as JSON, or you can create new events on the system by posting the appropriate XML or JSON to http://hl7connect.healthintersections.com.au/svc/fhir/securityevent (or https:, though the server uses a self signed certificate). The system doesn’t allow updates or deletes to security events (as defined in the conformance profile here).

To assist with testing, this server offers a IHE-certified ATNA server on port 3099 of hl7connect.healthintersections.com.au (also known as ec2-107-20-116-177.compute-1.amazonaws.com). Both UDP and secure TCP are offered (secure TCP uses the trusted certificate issued to Health Intersections from Gazelle). Any ATNA Audit Records sent to this server will be added to the FHIR repository as SecurityEvent resources, and will show up in the feeds.

Anyone is welcome to use this test server to work up a FHIR Security Event logging or handling system. I’d especially appreciate feedback with regard to the performance of the ATNA-FHIR bridge - I’m not sure how solid the conversion of codes is.

FHIR Connectathon

The next FHIR connectathon is focused on XDS. Because we are focusing on the interfaces, not the system functionality, production of security events is not required. But I encourage everyone to implement these anyway - this is pretty simple stuff once you have done anything with FHIR.