Standardized Operational Log of Events (SOLE)

1. Proposed Workitem: Standardized Operational Log of Events (SOLE)

• Proposal Editor: Brad Erickson <bje@mayo.edu>
• Editor: Brad Erickson <bje@mayo.edu>
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: 'Radiology

2. The Problem

Summary:

Efficient businesses use business intelligence tools to manage their business. The application of these tools to manage medical care has been limited in part because the information often resides in several different systems, and there are not standard ways to obtain the information. The SOLE profile defines a way to exchange information about events that can then be collected and displayed using standard methods.

Problem:

Healthcare providers have a strong desire to increase throughput and efficiency, both to improve the quality and timeliness of care and to control costs. Such process improvement efforts depend on being able to capture workflow events and apply business intelligence tools. Such initiatives face several problems:

• Event information that is to be logged comes from many different systems but there is no easy way to collect and compile the events into a single collection
• The different systems recording the particular events being logged may have different understandings of the definition of the event, time point or measurement; the result is:

• Within a single institution, data is non-uniform across systems, degrading the value of the information
• Across institutions, it is hard to compare to evaluate best practices

3. Key Use Case

The use case is general, but there is particular interest in the imaging department, which would provide a concrete test case.

• Systems which perform events on a profiled list would send messages in a profiled format containing standardized details to an operational event log server.
• The Event Repository would capture and record the received event messages
• Event Consumers, such as business intelligence tools, workflow engine-management tools, and tools related to performance measurement, would retrieve blocks of event messages from the event log server.

We note here that this proposal focuses on imaging department use. However, we believe that most, if not all, can be applied outside the imaging department. Therefore, we will focus on imaging, but be cognizant of non-imaging potential use.

4. Standards and Systems

The ATNA log has been successful in capturing and providing access to information needed for managing security and has been widely adopted. We would be happy to use the same or similar mechanism for operational events, though validation that it can meet the unique performance requirements must be validated.

The lists and definitions of events would likely be extended over time as new operational areas of the hospital become interested in such logging and analysis. The first draft of the profile could leverage the SWIM (SIIM Workflow Initiative in Medicine) terms that define a number of events and states occurring in an imaging department.

The SWIM list has recently been adopted into the RSNA RadLex codeset and several vendors have participated in pilot demonstrations of capturing such operational logs. It is not clear if there is an equivalent Lexicon for events outside of medical imaging, but this might stimulate the development of such a lexicon. The lack of such a lexicon should not present an impediment to achieving the benefits described above. As standard event terms are created, they can be recognized by IHE as an acceptable code set, and put into practice.

5. Technical Approach

There are two potential approaches to consider: One option is to use a log file similar to the ATNA log. The advantage is that the technology is well understood and simple. The challenge is that the performance may not be sufficient. It is also likely that a consumer will want a subset of events (e.g. all events in the last XXX seconds, or all events in the last hour from facility YY, or all events associated with an exam having a modality code of ‘MR’ for exam type).

A RESTful interface may be the most appropriate mechanism for the request, and possibly for the storage mechanism.

New actors

The actors for the SOLE profile are illustrated in Figure 1.

Actor: Event Creator Role: Sends event information to the Event Repository. Actor: Event Repository Role: Stores events sent from Event Creators, and responds to requests for event information from Event Consumers. Actor: Event Consumer Role: Requests events from the Event Repository. The results would typically be used for displaying status or performance in a department, or for executing new events or work

Figure 1 Actor Diagram

Event Creator Actor ---  RAD-xx: Log Event ---->   Event Log    <------ RAD-yy:  Retrieve Event

Breakdown of tasks

• Discussion/documentation of use cases (e.g. radiology departmental flow, etc.)
• Log Event transaction specification (or review/ modification if ATNA)
• Retrieve Event transaction specification
• Imaging Event Dictionary Review/Specification (e.g. SWIM)

6. Risks

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>

<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>

<What are some of the risks or open issues to be addressed?>

7. Open Issues

Are there other likely dictionaries?

8. Effort Estimates

TBD