From IHE Audit Trails to XES Event Logs Facilitating Process Mining

Transcription

1 40 Digital Healthcare Empowering Europeans R. Cornet et al. (Eds.) 2015 European Federation for Medical Informatics (EFMI). This article is published online with Open Access by IOS Press and distributed under the terms of the Creative Commons Attribution Non-Commercial License. doi: / From IHE Audit Trails to XES Event Logs Facilitating Process Mining Ferdinand PASTER a a,1 and Emmanuel HELM a University of Applied Sciences Upper Austria Abstract. Recently Business Intelligence approaches like process mining are applied to the healthcare domain. The goal of process mining is to gain process knowledge, compliance and room for improvement by investigating recorded event data. Previous approaches focused on process discovery by event data from various specific systems. IHE, as a globally recognized basis for healthcare information systems, defines in its ATNA profile how real-world events must be recorded in centralized event logs. The following approach presents how audit trails collected by the means of ATNA can be transformed to enable process mining. Using the standardized audit trails provides the ability to apply these methods to all IHE based information systems. Keywords. Data Mining, Standards, Process Assessment, Quality of Health Care Introduction Process mining (PM) is an emerging research field which links data mining to business process management. The idea in to utilize log-messages recorded from information systems to disclose valuable process information. There are three types of process mining: Discovery, Conformance and Enhancement. The most frequently seen use case is process Discovery. Here event data from computer based information systems is exploited to disclose as-is processes and communicate them via process models. 1 Recently applications of process mining to the healthcare domain are attracting attention. A number of research initiatives applied these techniques to log-data from a variety of systems, e.g. 2,3, where focus was process discovery. The source format of log-data differs from system to system, i.e. every implementation needs a specific preprocessing and conversion step. Preprocessing of the log, the preparation for further process mining steps, is a complex task that already raises many questions 4. As a result of our research, we found that there is no work using standardized log-data from distributed health information systems. Integrating the Healthcare Enterprise (IHE) is an international initiative by healthcare professionals and industry to improve the integration and interoperability of Hospital Information Systems (HIS). IHE is globally recognized and has more than 700 member organisations. Furthermore it is used in national and international healthcare projects, e.g. the the European epsos project. 5 To achieve user accountability IHE defines the Audit Trail and Node Authentication (ATNA) profile. ATNA declares that all IHE actors have to push records generated by their activities to a centralized Audit 1 Corresponding Author.

2 F. Paster and E. Helm / From IHE Audit Trails to XES Event Logs Facilitating Process Mining 41 Record Repository (ARR) 6. To record transactions, the ATNA Audit Trail is based on the Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications (RFC-3881). It finds common ground for requirements from different organizations like HL7, IHE, DICOM, ASTM and the NEMA/COCIR/JIRA Security and Privacy Committee. 7 This paper presents an approach aimed at preparing IHE compliant ATNA Audit Trails for further analysis by the means of process mining, with focus on process Discovery. Log data is created from large numbers of different systems with their own proprietary data format and semantics. Because log data is the key input of process mining, a very important aspect is to provide a standardized data format for the event logs. Previously MXML was used as an Extensible Markup Language (XML)-based format for log exchange. To overcome the limitations of MXML, mostly about extensibility, XES (extensible Event Stream) was developed by the TU Eindhoven. In September 2010 the IEEE Task Force on Process Mining accepted XES as standard for log data exchange. 8 XES defines three basic objects: Log, Trace and Event. Log (the process) contains a collection of Traces (execution instances) and a Trace contains a collection of Events. Each object can contain an arbitrary set of strongly typed attributes, e.g. String, Boolean, Timestamp, etc. To add semantics to these data types, XES defines the concept of extensions. An extension dictates a set of attributes, their type and keys with a specific semantic meaning. For mutual understanding, standard extensions were defined, e.g. Concept, Organizational, Time, etc. In order to investigate the valuable information from IHE information systems by the means of process mining, the ATNA log-data has to be preprocessed and transformed to the XES format. 1. Methods To support a methodical approach, a transformation architecture was developed, recognizing XML as the basis of both, the source and the target format, cf. Figure 1. The transformation architecture is based on the Meta Object Facility (MOF) standard and influenced by a Model Driven Interoperability (MDI) approach was 9, 10 developed. Figure 1. Transformation architecture based on the MOF standard. 9

3 42 F. Paster and E. Helm / From IHE Audit Trails to XES Event Logs Facilitating Process Mining On the M 3 level, XML serves as a meta-meta-model for the two meta-models below, i.e. both, RFC-3881 and XES, conform to it (see Figure 1). Between the two meta-models at M 2 the means of mapping components is defined. At M 1, the specific instance of the RFC-3881 model, the Audit Trail, is transformed into a specific instance of the XES model, the Mining Log. Both models on the M 1 layer conform to their respective meta-model. Of course, according to the MOF standard, the Audit Trail is also just a model representing the actual real-world events on M o. A universal transformation approach should only incorporate information available in all possible audit messages. Table 1. Selected RFC-3881 fields. 1-6 are mandatory according to are only mandatory if the ParticipantObjectIdentification is present. Nr Location/Name Description from RFC EventIdentification/EventID Identifier for a specific audited event, e.g., a menu item, program, rule, policy, function code, application name, or URL. It identifies the performed function. 2 EventIdentification/ EventDateTime Universal coordinated time (UTC), i.e., a date/time specification that is unambiguous as to local time zones. 3 EventIdentification/ Indicates whether the event succeeded or failed. EventOutcomeIndicator 4 ActiveParticipant/UserID Unique identifier for the user actively participating in the event. 5 ActiveParticipant/ UserIsRequestor Indicator that the user is or is not the requestor, or initiator, for the event being audited. 6 AuditSourceIdentification/ Identifier of the source where the event originated. AuditSourceID 7 ParticipantObjectIdentification/ ParticipantObjectID Identifies a specific instance of the participant object. 8 ParticipantObjectIdentification/ ParticipantObjectIDTypeCode Describes the identifier that is contained in Participant Object ID. According to DICOM the fields 1-6 in Table 1 are mandatory in the Audit Trail, whereas 7-8 are mandatory only in context of the ParticipantObjectIdentification section which is optional as whole. However when the audit logs of two independent IHE-compliant systems were checked, it was found that the ParticipantObject- Identification is usually recorded. The XES format does not determine mandatory fields. However there is the option to define so called global attributes for the traces and events. Global attributes must be present for each trace or event element in the log, i.e. if event is defined to have certain global attributes, all events in the log must determine those. Commonly understood semantics can be added by the means of the standard extensions explained in section 1.1. Table 2. Three examples of mapped attributes and their semantics according to 8 RFC-3881 XES extension Semantic extension description 8 EventDateTime time:timestamp The date and time, at which the event has occurred. EventID concept:instance Represents an identifier of the activity instance whose execution has generated the event. UserID org:resource The name, or identifier, of the resource having triggered the event. Table 2 outlines the mapping of three sample attributes from RFC-3881 to XES. To determine which fields should be mapped to which XES attributes attempted to find the most suitable semantic match based on the RFC-3881 descriptions, taking DICOM

4 F. Paster and E. Helm / From IHE Audit Trails to XES Event Logs Facilitating Process Mining 43 plus IHE extensions and the descriptions of the XES standard extension types into account. After the mapping of the fields is defined, the actual transformation takes place. The goal is to transform the ATNA XML audit messages to XES XML, i.e. source and target are both manifested as XML files. Transformation is a three step process. Firstly the Audit Trail is checked for validity against the RFC-3881 schema. Secondly the conversion is done by the means of XSLT (Extensible Stylesheet Language Transformation). Finally the resulting XES Mining Log file is validated against the XES schema. 2. Results The test Audit Trail used as input was generated using an IHE system based on the OpenHealthTools 2 framework. In the test case a Provide & Register Document Set-b transaction was recorded. The resulting audit message comprises four parts: EventIdentification, ActiveParticipant, AuditSourceIdentification and the ParticipantObjectIdentification. For the information content of these fields cf. Table 1. By means of the transformation definition, relevant data is extracted and transformed to the XES format as shown in Listing 1. Listing 1. XES Event generated from a Provide & Register Document Set-b Audit Message 01 <event> 02 <date key="time:timestamp" value=" t14:12: :00"/> 03 <string key="concept:name" value="iti-41"/> 04 <string key="concept:instance" value="110107"/> 05 <container> 06 <string key="org:resource" value="documentsource@ "/> 07 <string key="org:role" value="source"/> 08 </container> 09 <container> 10 <string key="org:resource" value=" 11 <string key="org:role" value="destination"/> 12 </container> 13 </event> The transformed event in Listing 1 shows which information we identified as being the most relevant for process mining. It includes date and precise time when the event occurred. The type of event: ITI-41 (Provide & Register Document Set-b) and the type of DICOM action are also described ( = Import). Line 05 to 12 describe the communicating actors. Since an IHE transaction is recorded by both sides, a second audit message of the type ITI-41 with the DICOM action (Export) will be present. This event is just an example that could be part of a bigger workflow like the standard process in a radiological department: 1. Patient admission (ITI-9) 2. Place radiology order (RAD-2) 3. Query for previous findings (ITI-43) 2 last accessed

5 44 F. Paster and E. Helm / From IHE Audit Trails to XES Event Logs Facilitating Process Mining 4. Create clinical report (ITI-41), etc. 3. Discussion In the course of our work with XES as target format, some issues in the transformation process that might need further investigation became apparent. The main issue identified within the model transformation is the trace identification. Traces, the execution instances of the logged process, i.e. the patient pathway and all surrounding events, are difficult to identify. There is no identifier referencing specific hospitalizations. In this approach the audit events were assigned to a trace based on the patient identifier. The second issue occurs during the transformation mapping. We attempted to find the most suitable semantic match based on the descriptions of the two meta-models, RFC-3881 and the XES standard extensions. Our defined criteria might be biased as we were only using IHE actors and therefore audit trails which have their origin in the radiology field. To expand our decisions further research is required. An approach based on IHE compliant Audit Trails brings the potential to apply process mining to more than only a specific system. Hence, clinical pathways extending over different IHE compliant hospitals, physicians, etc. can be detected and analyzed. This work aims to establish a first step enabling process mining on ATNA based Audit Trails. However as stated previously, there are still many questions to be answered and further research to be conducted, in order to beneficially apply process mining to IHE based healthcare systems. References [1] Van der Aalst W, et al. Process mining manifesto, Business process management workshops, Berlin Heidelberg (2012) [2] Mans R, et al. Application of process mining in healthcare a case study in a dutch hospital. Biomedical Engineering Systems and Technologies. Springer Berlin Heidelberg (2009), [3] Rebuge Á, Ferreira DR, Business process analysis in healthcare environments: A methodology based on process mining. Information Systems 37.2 (2012), [4] Bozkaya M, Joost G, van der Werf JM. Process diagnostics: a method based on process mining, Information, Process, and Knowledge Management, eknow'09 (2009). [5] epsos European Patients Smart Open Services: Technical Background, Accessible via: (last access: ). [6] IHE International, Audit Trail and Node Authentication (ATNA). IHE IT Infrastructure (ITI) Technical Framework Volume 1 (ITI TF-1) Integration Profiles (2013), [7] Marshall G, RFC 3881 Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications, Request for Comments: 3881 (2004). [8] Günther C, Verbeek E, XES Standard Definition 2.0, (2014). [9] Object Management Group, OMG: Meta Object Facility (MOF) Core Specification (2014), [10] Elvesæter B, et al, Towards an interoperability framework for model-driven development of software systems, Interoperability of enterprise software and applications, Springer London (2006), [11] NEMA, DICOM PS a - Security and System Management Profiles, (2014).