Enhanced SOLE for AI

Enhanced SOLE for AI Power Point presentation

1. Proposed Workitem: Enhanced SOLE for AI

• Proposal Editor: Chris Lindop, Neil Tenenholtz, Rob Horn, Brian Bialecki
• Editor: <Name of candidate Lead Editor for the Profile, if known>
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: <Domain name Radiology

1. Summary

Applications, in particular AI Algorithms, are increasingly moving to distributed architectures. Right-sizing the resources for these applications is vital to provide cost-effective offerings. In the presence of system failures, it is also essential to understand the root cause. However, we currently lack the ability to effectively log, in a unified fashion, actions and interactions between these distributed architectures, significantly impeding our ability to understand their behaviors

Standardized Operational Logging of Events (SOLE) offers an existing framework for logging events related to patients, equipment, staff, and facilities. When logging events communicated by computer systems though, this standard currently lacks a mechanism to link related events (i.e.,tracing).

The W3C Trace Context provides a standard for identifying and communicating such interactions. This proposed extension to SOLE will include W3C Context Trace elements in SOLE messages to improve our understanding of the relationships

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 which include:

• Clinical workflow restructuring and optimization (existing in SOLE)
• Disaster support and readiness (existing in SOLE)
• Resource utilization and bottleneck identification (extended)
• Resource allocation for algorithms and workflows (new)
• Fault identification and troubleshooting (new)

The SOLE profile currently lacks the capability to address the complexity introduced by AI and distributed, cloud-native applications. This profile extends SOLE to address these gaps.

3. Key Use Case

A study is acquired. An Orchestrator/Task Manager invokes one or more applications. I need to:

• Right-size the resources for an AI Application
• Allocate the resources to optimize the algorithm performance
• Decide how much CPU, accelerator capacity, memory, bandwidth, and storage are needed
• Determine the current uptime, response latency, request volume, and algorithm utilization
• Troubleshoot a problem
• Assess model licensing

'Should I pay for a machine running 24 hours or on-demand running?'

4. Standards and Systems

SOLE, Standardize Operational Logging of Events

IHE_RAD_Suppl_SOLE.pdf

W3C Trace Context

www.w3.org/TR/trace-context-1 (V1, status: recommendation)

w3c.github.io/trace-context (v2, status: draft)

5. Discussion

1. This proposal is a result of an ad hoc committee formed within IHE/ACR to address “CP-458 SOLE: Add events to support AIR and AIW-I”.
2. Detailed proposed changes were initially discussed as part of the IHE Maintenance and to be included in this workitem.
3. With many proprietary methods available today and W3C developing the common standard, it is appropriate for IHE to converge on a single, industry-wide method that benefits community at large.
4. This approach will leverage the existing actors/transactions in SOLE with enhancements that address the AI workflow and use cases outlined above.

Risks and Open Issues

1. What to do about traced transactions using protocols that W3C has not specified (e.g. DICOM DIMSE, HL7 v2)? (out-of-scope?)

6. Technical Approach

Describe the new use case elaborating on the W3C approach and what this means for patient workflows in a hospital:

• Early traces allow for greater understanding of the patient experience but if any system doesn’t carry the trace id forward the link is broken and the connection can no longer be made
• Administrators may be more concerned with unifying traces in their department, in computer workflows (e.g., algorithm inference), etc in which case the initial trace id should be set later
• Regardless, any system should adhere to the rule of carrying forward any valid trace id and setting a new one if one is not set

For example, what this means for the patient experience how the new fields are used.

<This section describes the technical scope of the work and the proposed approach to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility. The Technical Committee may revise/expand this section when doing the effort estimation.> <If any context or "big picture" is needed to understand the transaction, actor and profile discussion below, that can be put here> <If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.> <The material below also serves as the breakdown of tasks that the technical committee will use to estimate the effort required to design, review and implement the profile. It helps a lot if it is reasonably complete/realistic.>

<READ PROPOSER HOMEWORK IN Proposal Effort Evaluation FOR GUIDANCE ON POPULATING THE FOLLOWING SECTIONS >

Actors

• (NEW) No New Actors
• <List existing actors that may be given requirements in the Profile.>

Transactions

• (NEW) No New Transactions.
• <List existing transactions that may be used and which might need modification/extension.>
• Adding new fields to the Event Object mapped from the W3C Trace Context fields.

Profile

• <Describe the main new profile chunks that will need to be written.>
• <List existing profiles that may need to be modified.>

Decisions/Topics/Uncertainties

• <List key decisions that will need to be made, open issues, design problems, topics to discuss, and other potential areas of uncertainty>
• <Credibility point: A proposal for a profile with any degree of novelty should have items listed here. If there is nothing here, it is usually a sign that the proposal analysis and discussion has been incomplete.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.> <Identify anyone who has indicated an interest in implementing/prototyping the Profile if it is published this cycle.>

7. Risks

<List real-world practical or political risks that could impede successfully fielding the profile.> <Technical risks should be noted above under Uncertainties.>

8. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.> Effort Evaluation (as a % of Tech Cmte Bandwidth):

• xx% for MUE
• yy% for MUE + optional

Editor: TBA SME/Champion: TBA <typically with a technical editor, the Subject Matter Expert will bring clinical expertise; in the (unusual) case of a clinical editor, the SME will bring technical expertise>