Standardized Operational Log of Events (SOLE)

From IHE Wiki
Jump to: navigation, search


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

  • Proposal Editor: Brad Erickson <bje@mayo.edu>
  • Editors: Brad Erickson <bje@mayo.edu>, Steve G. Langer Ph.D. <langer.steve@mayo.edu>
  • Contributors:
  • IHE Mentor: Kevin O'Donnell, backup editor for December TC F2F
  • Domain: Radiology

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.

2. The 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

Analytics Can Save Radiology - 2015.08.20 Diagnostic Imaging Article

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

Systems (that would submit events or analyze events):

  • RIS
  • PACS
  • Speech Recognition
  • EMR
  • Imaging Devices
  • BI tools

Standards

  • ATNA log for submission
    • 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.
  • SWIM terms for coding
    • 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.
  • RESTful ATNA Query for query/retrieve

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.

FHIR has added a “SecurityEvent” resource to support ATNA, and a similar flavor event could be used for SOLE. https://www.hl7.org/fhir/securityevent.html

A useful distinction was raised in ITI that Submission and Query can be handled separately. I.e., defining the standard way of sending an event to a log server can be a separate profile than a standardized way of extracting a set of events from the log server. They could even use entirely different mechanisms, e.g. a RESTful POST for submitting and an SQL Query for extracting, or extraction could be left proprietary depending on the use cases.

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 SOLE Actor Diagram:


2015.08.25.IHE Rad SOLE actor diagram.png


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)
  • Define Codes/IDs for classes of system that generate events (e.g. RIS, PACS, EHR); locations (e.g. buildings) for data sorting, etc.

6. Discussion

The need for standard ways to exchange information about the status of a radiology department has been recognized for years, and was formalized in SIIM’s Workflow Intitiative in Medicine (SWIM). Dashboards have been developed to address this need, but the data they rely on is stored in disparate systems, and in non-standard forms. SWIM worked with RSNA to establish a standard lexicon for workflow events in RadLEX. Now, there needs to be a standard way to communicate event information. There are many standards that COULD serve this purpose. IHE is a good forum to select the best one for our purposes. A more detailed description of the use case, and value proposition has been published in JDI SWIM article.

  • Fit the ATNA model well
  • Expected about 20 events (e.g. order related) will be mandatory
  • Some events will be recommended and some will be optional
  • Consider mandatory to be supported, but configurable to be on or off
  • Need to clearly define what each event mean, especially things like timestamp. There are occasions that different vendors currently interpret the timestamp of certain event differently

7. Risks

  • Performance expectations: Some use cases will depend on certain timeliness, however too high a performance may be unjustifiably costly.
  • Need domain knowledge on RESTful ATNA
  • Kinson will check with Rob Horn about mentoring this profile if selected.

8. Open Issues

  • Will SOLE support multiple event code set simultaneously? Different jurisdiction may have existing code set that are of interest
  • Possibly supported
  • Besides defining the new profile, what is the expectation to retrofit the events to existing profiles like SWF, IRWF, etc.?
  • For existing profile, can introduce events as optional so to not break existing profiles.
  • Can consider named option so can be tested in Connectathon
  • For initial development, make sense to define the 20 or so mandatory events, and then see how these events affect the existing profile where applicable
  • ATNA using Syslog, which is great for workstation, but not necessary common for mobile devices / platform (e.g. iOS, Android), there is no existing standard logging mechanism for these platform
  • Probably need new transport
  • There are new emerging methods that vendors are implementing, something we can look at / reference (e.g. Nagios)



  • Are there other likely event dictionaries?
  • I don't foresee that. I did originally approach the ITI group, and if this concept catches on and generalized, then there might be a broader healthcare event lexicon, and that might be useful
  • Will the Consumer be required to do anything other than retrieve?
  • [ I don't believe so. Performing any analytics is out of scope.


  • Will the Repository be required to support queries, or just bulk or single item retrieval
  • I believe they will. I am thinking there would be a RESTful interface where you could specify the 'groups' of events you wanted returned
  • In ATNA, added an option to filter events and forward events (e.g. forward to another repository based on event types)
  • Minimal is poll only. Pub/Sub may be desirable if some reliable standard is available
  • What security and privacy concerns need to be addressed
  • To tie events for individual patients together, we will need to work with accession numbers. I don't envision cases where we would need any more direct patient information. Of course, the information is business critical, and from that perspective, an agent from outside could 'mine' this to understand their competition, so this should not be openly exposed
  • Can be significant. Minimal information will be logged, e.g. only log patient ID, but not patient name
  • may not even log patient ID, just accession number. Need careful analysis.


  • Is the intention to address standardized data across an institution, across a country or worldwide?
  • I think this should be at least national level for many metrics. The government is moving to more 'performance' type metrics & incentives. These types of events might be included in such metrics, so at least a national level of standardization should be envisioned.
  • Depends on use cases. Something to be discussed. Likely deployment consideration.


  • What mechanism (e.g. Syslog, FHIR, other) will be used for Log Event, Retrieve Event and/or Query Event?
  • Leave as open issue and allocate time for that. I think the precise mechanism is one of the items to be decided. I have been thinking RESTful queries, and perhaps FHIR will now be a more precise fit
  • Can FHIR events work on mobile device?
  • Mobile device requires good connection. startup and shutdown issues.
  • SWIM defines the event list, does it also define what details need to be recorded in each event?
  • Yes.
  • [Agfa] Is there a need for a subscription based notification mechanism, or query/retrieve is enough?
  • That is a good point. I can imagine that a subscription / regular update could be an equally viable and useful mechanism, and should not be discounted
  • Adding it would expand the scope (RESTful Query does not provide it) and it might not be needed for the 80% use case. This is log management not event driven workflow.
  • [Agfa] Given the increasing use of mobile devices, ideally the transactions can support these devices natively. ATNA syslog is fine for server logging, but not necessary logging from mobile devices. Recently there is an ITI profile to support RESTful query on ATNA audit repository.
  • yes that was pointed out to me and I think that could be very useful for this profile as well.

8. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 30% for stationary devices
  • option for mobile event log (+10%)

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Brad Erickson
Rob Horn coach?
Kevin, coach depending on other workload