Encounter Based Imaging Workflow for Lightweight Devices - Proposal

1. Proposed Workitem: Encounter-Based Imaging Workflow (EBIW) for Lightweight Devices

• Proposal Editor: Kevin O'Donnell / Kinson Ho
• Proposal Contributors: Elliot Silver, Christopher Roth, Dawn Cram, Alex Towbin, Ken Persons, Paul Lipton, ...
• Editor: Kevin O'Donnell
• Contributors: See Support & Resources
• Domain: Radiology

Summary

This proposal builds on the work of the 2017-18 EBIW workitem by addressing lightweight devices such as digital cameras, smartphones and tablets.

The rapidly growing practice of encounter-based imaging needs robust integration, data management and workflow similar to what order-based imaging enjoys via the SWF Profile.

The Encounter-Based Imaging Workflow Profile specifies how to obtain appropriate context metadata, populate relevant indexing fields, link to related data, and ensure the images are accessible and well-knit into the medical record. However, due to bandwidth constraints, that work was restricted to Point-of-Care Ultrasound. Extending it to encounter-based digital photography (and similar "lightweight" devices) would address an even larger use case.

Experts from Duke, U Miami, Mayo, and Northwestern have already authored several whitepapers detailing this problem and considerations in solving it. It has been the subject of many conference sessions. These experts have agreed to participate in the profile development and contribute their institutional experience tackling this problem and encourage their vendors to participate.

IHE is a good venue to solve this because proprietary adhoc workflows are emerging/exist but are inconsistent, incomplete and poorly integrated. The need is real. All that is missing is a profile to drive integrated, complete, consistent, standards-based solutions. As with SWF, an IHE solution could avoid the costs and incompatibilities of proprietary solutions.

2. The Problem

Encounter-based Imaging (a burgeoning area of activity) needs to be supported as well as Order-based Imaging (aka Scheduled Workflow) but today it is not.

• Time is lost on awkward workflow and data capture and lack of automation
• Images are Absent from or Scattered throughout the EMR
• Silo-ization of the medical imaging record
• Images are Placed in the Paper Record or Scanned into the EMR without metadata
• Images are Not Available to the Care Team
• Image Sharing with Affiliated Hospitals is Very Limited

The EBIW Profile models an effective flow of data to manage encounter-based images in an integrated patient record.

Implementers of products based on devices like digital cameras and smartphones expect lightweight interfaces to obtain relevant metadata and store the images.

The SWF exercise in the late 90's contributed to an extended period of robust departmental interoperability. Extending EBIW to lightweight devices could provide similar benefits.

3. Key Use Case

• Dermatology
• Wound Care/Management
• Infectious Diseases
• Burn Care
• Plastic Surgery
• Nursing/Clinic Photography

Use Case 1: Imaging with Simple Devices

Many departments capture clinical photos for documentation, follow up care, and diagnostics (often non-DICOM at initial point of capture).

Capture devices include digital cameras, smartphones and tablets (using iOS, Android and camera-specific OS).

The Provider interacts with some kind of "Encounter Management" system in the course of the patient visit. It might be part of the EHR, or a practice management package, etc.

• Patient makes appointment for Dermatology visit.
• Patient arrives and is registered/checked in as an outpatient (OP)
• At the Provider's discretion, clinical photos are taken to document disease processes, pathologies or disorders.
  • Image content may include photos of multiple body parts.
  • Image content may include basic video. (Advanced video management like editing and annotation is out of scope)
  • Orders are not clinically required
• Patient demographics (from the EHR), Encounter metadata (from the EHR or visit management system) and Procedure metadata provide the context details which are combined with the captured image pixels and stored in the medical record.
• The EMR is notified of the existence and details of the newly captured images.

Supporting Diagram for the use case

Basically follows the pattern of SWF: Establishing encounter/patient/context, conveying metadata, capturing/storing image data, indexing/archiving images, finding/accessing/using images. Encounter-based imaging should get the same end result as if the clinician placed the order. Want to support the same analytics, access/indexing of the imaging.

Goals:

• Identify all images associated with the care event, through the assignment of a unique study identifier,
• Associate images with a patient encounter, usually through a modality worklist or patient schedule,
• Find/filter images based on the department, the type of imaging performed and the anatomical region,
• Access/view images based on a reference in a report or note describing the visit where the images were obtained, and
• Support imaging metadata to serve business intelligence needs.

Future Work

As part of keeping the scope practical, some work (See Discussion) is identified as being out of scope for this proposal.

4. Standards and Systems

Potential Systems

• Image Acquisition Devices (both Lightweight and Heavy/Integrated)
• Image Archiving Devices
• Electronic Medical Record Systems
• Practice Management Systems
• Encounter Management System (office/departmental system that provides the encounter context)
• QA System
• Encounter Imaging Consumer

Potential Standards

• Existing Profiles: EBIW, PAM, WIC, SWF, WIA, XDS*
• DICOM (DIMSE), DICOMweb
• HL7, FHIR
• Consumer media formats: JPEG, MPEG, PDF, RAW, etc

Relevant Whitepapers:

• SIIM-HIMSS Enterprise Imaging Workgroup - White Papers
• A Foundation for Enterprise Imaging - JDI Whitepaper
• Order-based vs Encounter-based Imaging - JDI Whitepaper
• The Workflow Challenges of Enterprise Imaging - JDI Whitepaper
• Technical Challenges of Enterprise Imaging - JDI Whitepaper
• PCD Encounter-based Patient Identification Management whitepaper

Relevant Current and Past Activities:

• INSERT LINK EBIW Profile from 2017-18.
• Encounter-based_Imaging_Workflow A special interest group that has started the discussion on encounter based imaging workflow
• Internet-Ready_SWF_-_Proposal started to consider encounter-based imaging as well.

5. Technical Approach

Impact on existing integration profiles

• Consider adding a new actor and two new transactions to EBIW (still in early TI) to "complete" the profile.
• Alternatively might package it as a Named Option or a separate Profile

Existing actors

• Encounter Manager

• manages and provides encounter metadata and marshaled patient demographics

• Image Manager/Archive

• stores acquired images and notifies Result Aggregator of new data

• Result Aggregator

• receives notifications of new encounter-based images

New actors (names provisional)

• Lightweight Modality (or something)

• obtains metadata and applies it to images it stores (using lightweight APIs)

Existing transactions

• Reuse RAD-132 Notify Imaging Results

New transactions (standards used)

• Mirror RAD-130 Get Encounter Imaging Context using a RESTful API (such as FHIR, UPS-RS or something in those lines)
• Mirror RAD-131 Store Encounter Images using STOW-RS (clone/tweak RAD-108 Store Instances Over the Web)

Breakdown of tasks

TODO - Finish editing this section to reflect the remaining work

Mostly it involves replicating the semantics of two transactions using RESTful interfaces instead.

Scope Management: This proposal will not address all challenges related to encounter-based imaging workflow, rather it will:

• Address two key use cases
• Define the minimal necessary set of metadata (related to the patient, encounter, procedure, and pixels)
• Identify the source(s) of each piece of metadata
• Define how those are aggregated and combined with the pixels
• Notify the EMR when study becomes available
• Consider basic clinical usage of the images, but defer complex downstream activities

• TODO - note in diagram that Quasi-modality may have a modality interface so you can enter/update details like on a regular modality. Copy up the procedure bullets from PoC US diagram to Capture.
• TODO rename to Record Driven Acquisition - like "repeat order for current date" since most metadata/context is inherited

Steps:

• Review DICOM Tags and semantics in the context of EBI

• Consider mapping semantics between JPEG tags and DICOM tags (need acquisition date, be careful not to use IPC modification date, trusted)
• reference: EXIF metadata available from camera (DICOM CP1736 is addressing EXIF mapping details)
• If needed, CP DICOM (new attributes or revised descriptions, new/revised CIDs) to hold all the metada

• For Simple Camera Case, look at the same flow with the Camera and the Assembly being in two different actors.
• Consider Notification to EMR of new Procedure Results

• EMR needs to know when it is safe to launch a viewer pointed at the acquired image, so availability notification from the VNA/PACS matters. Otherwise the EMR has to poll/probe
• EMR may also want notification from PoC that data was captured and the images themselves will be available "soon".

Bonus work:

• Consider a "push flow" for Record Driven Acquisition (of interest to several participants)
• Review other profiles used with SWF (PDI, XCA-I, BIR, IRWF, etc) for EBIW compatibility

• e.g. Dermatology patient brings USB stick with some JPEGs for Encounter-based import using IRWF

• Diagram Diagnostic Imaging, Procedural Imaging and Evidence Imaging

• Delineate EBI vs Enterprise Imaging vs mobile vs consumer vs lightweight vs web APIs vs ...

• Consider a FHIR PDQm variant for the Simple Camera?

• record driven acquisition might involve two different devices (I click on "grab followup image" in my EMR screen, and somehow the camera I pick up is primed now for that capture) or one device/client (I'm using a tablet for EMR and activate the built in camera)

6. Support & Resources

The SIIM-HIMSS Enterprise Imaging group and ad hoc EBIW IHE SIG has already coalesced a number of collaborators, many of whom have helped on the proposal and are interested in working on the profile.

• Healthcare: Chris Roth (Duke), Dawn Cram (Ochsner), Ken Persons (Mayo), Matt Hayes (Northwestern),
• Vendors: Dan Rice (Ricoh USA), David Clunie (Pixelmed), Elliot Silver (McKesson), John Hansen (Merge), Kevin O'Donnell (Toshiba), Kinson Ho (McKesson), Mike Bressack (Karl Storz), Rob Mitchell (Merge), Thomas Pickard (ImageMoverMD)

In addition to the whitepapers, the Healthcare participants bring their experiences (clearer understanding of the needs, things that did and didn't work well) from their existing projects to tackle this in practice.

At SIIM 2016, Dawn Cram, Chris Roth and Alex Tobin gave presentations highlighting the issue and Elliot Silver recognized a profile proposal in the making.

7. Risks

• If we build it, will they come? Will image vendors implement this?

• Miami, Duke have found definite interest from the vendors (perhaps by focussing on a specific group, ophth/endo?)

• Vendors may stick with proprietary solution that already exist and unwilling to switch to a standard-based solution

• Solution of this profile tries to be aligned with existing solutions

9. Tech Cmte Evaluation

Technical Evaluation

• No significant technical issues seen. Plan is to use minor variations of known/deployed standards.

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

• 40%
• Minimum Useful Effort: 25%

Candidate Editor: Kevin