An open-source implementation for RFC3881.

Vulpe, Anca Diana ; Vulpe, Marius Cristian ; Sisak, Francisc 等

1. MOTIVATION

The majority of the HASes have to keep records of the operations they perform preferably in a format that is standardized (like the XML schema definition format proposed in RFC3881 and in DICOM's Supplement 95). Additional requirements in this respect can also be found in IHE's "IT Infrastructure Technical Framework--Integration profiles".

However in most of the cases this information has a low-business value for the system that produces it and therefore is not in the focus of a particular HAS provider.

As a consequence, the people working for and HAS solution need a possibility to keep these records in a secure and reliable way with a minimal effort (the used API must be easy to use). Additionally, keeping this records must not affect dramatically the performance of the HAS. Interoperability is also in focus as systems from different vendors can be integrated at the same enterprise site. Here is a short analysis of the minimum features:

* Secure. Because of the privacy laws (e.g. HIPPA in United States), the audit messages' content in HAS applications are confidential. Therefore all the records must be end-to-end (from the generation to the storage) secured (either by restricting the access to them or by encrypting the transmitted information).

* Reliable. This implies 0% information loss (every audit message must be stored).

* Fast. The used API must not affect significantly the application's performance. By analogy with the logging systems, recording an audit event should have a minimal performance impact.

* Easy to use. The API's used for audit message generation must be easy to use by the HAS developers and integration/configuration of the API must be minimal.

* Interoperable. The best way to explain this feature is a quote from (http://www.ihe-europe.net/links/): "IHE in Europe promotes interoperability between IT systems in European health care. With over 280 autonomous regions, achieving a seamless flow of relevant information between IT systems of different healthcare systems presents unique challenges for cross-border interoperability."

* Cheap. Using the system must imply cost reductions for the customer. When referring to cost decreases two areas are in focus: maintenance costs and licensing costs.

2. AVAILABLE IMPLEMENTATIONS

The only (and best-known) publicly-available implementation for the mentioned RFC is dcm4che (http://www.dcm4che.org/). This is "a collection of open source applications and utilities for the healthcare enterprise".

Analyzing this implementation one may observe that the focus is the implementation of the DICOM standard and not the auditing part, so this is not a purely dedicated implementation for the generation, storage and management of healthcare audit information.

3. TARGET ARCHITECTURE

Figure 1 (AMS Architecture) presents the components available within the proposed Audit Management System. Essentially the system has two main development areas:

1) Client API that represents what typically an HAS developer would use.

2) AMS server representing the system that manages the client-produced audit messages.

[FIGURE 1 OMITTED]

3.1 Client API

The HAS developer should have the possibility to easily integrate an AMS client API into his application. This API allows the user to:

* Create an audit message with all the parameters.

* Fire audit message events.

* Register/deregister listeners for audit messages occurrence.

The component that handles the audit message (AM) is the listener. Some possible behaviors for AM listeners are:

* Storing temporarily the audit message on the HAS application; this has the advantage that is very fast and the used libraries (dependencies) can be very small.

* Connecting to the AMS server and submitting the AM in a transactional manner; this is a heavyweight solution and can affect the performance of the HAS.

* Connecting to the AMS in an asynchronous and nontransactional manner; this is also a heavyweight solution as it might involve more dependencies for the AMS connection.

Note that other client API solutions can be imagined and the important aspect is that the user must use the same interface, but the application integrator has the freedom to switch the implementations based on the application's requirements.

Preferably, the client API will have more "flavors" (i.e. it can be composed out of Java API, C++ API, .Net API etc.). As an example, the Java API can use:

* JAXB for verification against XSD, marshaling and unmarshaling of XML-formatted audit messages. This ensures compatibility with the JEE standards documented in JSR 222 and described in the Java EE 5 Tutorial.

* Different audit message listeners (used for flat/compressed/encrypted file storage, EJB client, MDB client, Web service client), depending on the functionality the user needs.

The development of such client APIs will be done using a "per request" model and can vary a lot, depending on the platform where it will be used. As an example a tomograph can have an embedded library that generates RFC3881-compliant audit messages.

3.2 AMS Server

The idea of the AMS server is to have a centralized management solution, instead of disparate deployments (i.e. each HAS to have its own audit message system).

The main components of the AMS system are:

1. Protocol adapter is the part that helps gathering the audit messages from various/heterogeneous systems. Normally each type of client API has an associated protocol adapter. For example, one protocol adapter can use SCP protocol to collect the audit messages generated by several equipments while another protocol adapter can provide an end point for online EJB client.

2. Persistence layer facilitates keeping the audit messages in a format that allows easy handling of the information (e.g. generating reports, searching for certain audit messages, etc.). It also facilitates the discrimination between the different HAS applications/enterprise sites because it is not yet very well defined, from an architectural perspective, if the EIS persisting the audit messages will be a centralized one or different customer's data will be stored in different EISes.

3. Enterprise information system is the repository for audit messages. It might be composed of several sub-repositories (e.g. depending on the enterprise site ID). For easiness in data handling, in most of the cases the EIS is represented by a relational database.

4. Administrative interface is the interface that allows configuring the AMS server, viewing the audit information or generating reports. It is composed from two parts: an API used to connect to the persistence layer (that can also be used to develop applications) and a visual component in web format. One important scenario for the administrative interface is the capability of the user to track the evolution of a patient from the hospitalization moment until the exit from hospital (this might include both medical care operations and financial operations).

Technically, the plan for AMS server is to have it implemented as a mix between a standard Java application and a JEE application running on UNIX and using some opensource application server (like JBoss). However the main technical focus on the AMS will be the ease in maintenance and the portability (especially in the EIS area).

3.2 Backup System

Because all the audit messages have to be kept for archiving purposes, a backup system has to be provided. This system must keep the audit messages in the raw, unaltered format.

As an example, the backup system can be realized as a data storage machine equipped (as example) with Solaris and ZFS, as a huge amount of data can be stored (order of terabytes).

4. FURTHER STEPS

Currently the team working for this project has set up the architecture and started the first iterations regarding the client API.

The very next steps are to:

* create a basic end-to-end solution, as presented in the target architecture;

* find an adequate licensing model (as a business friendly model is intended, probably the Apache license will be selected);

* choose the most convenient public hosting service (Sourceforge or Google are the considered options).

5. CONCLUSION

As the healthcare enterprises rely more and more on computing systems, the necessity of tracking the activities in such enterprises increases. There are many examples of hazard cases where patients suffered because of malfunctioning in some hardware or software, therefore some laws force the HASes vendors to provide the mentioned tracking capability.

Even if some parts of the legislation are clear, currently the healthcare IT industry is divided by various standards produced by many heterogeneous working groups (sometimes organized on geopolitical basis).

One alternative to get one of these standards the most used standard in industry is to provide publicly available reference implementations. Historically, some good examples are TCP/IP standards (versus OSI stack) or the APIs standardized using the Java Specification Request.

The current project has as a main goal the promotion of the RFC3881, by providing an open-source implementation that can be easily integrated into commercial products.

6. REFERENCES

ACC; HIMMS; RSNA, (2007). IT Infrastructure Technical Framework, vol 1., pp. 56-65 (http://www.ihe.net/Technical_Framework/upload/IHE_ITI _TF_4_0_Vol1_FT_2007_08_22.pdf)

DICOM Standards Committee, Working Group 14, (2004). Digital Imaging and Communications in Medicine, Supplement 95: Audit Trail Messages, (pp. 2-10) (ftp://medical.nema.org/medical/dicom/supps/sup95_fz.pdf)

DCM4CHE (http://www.dcm4che.org/)

Jendrock, E.; Ball, J.; Carson, D.; Evans, I.; Fordin, S. & Haase, K. (2007). Java(TM) EE 5 Tutorial, Prentice Hall PTR, 978-0321490292.

RFC3881, (2004). (http://www.faqs.org/rfcs/rfc3881.html)