Encounter Based Imaging Workflow for Lightweight Devices - Proposal

From IHE Wiki
Jump to navigation Jump to search

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 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. Digital photography use is expanding rapidly.

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 MUE limits, 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
  • Endoscopy?

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

Follows the broad 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 an 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, WIC, SWF, WIA, XDS*
  • DICOM (DIMSE), DICOMweb
  • HL7, FHIR
  • Consumer media formats: JPEG, MPEG, PDF, RAW, etc

Relevant Whitepapers:

Relevant Current and Past Activities:

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, PDQm, 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

Transactions

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

Profile

  • Design/Add Use Case diagram for (1 or 2) scenarios
  • Consider Record Driven Acquisition (Not MUE)
  • e.g. take followup picture; like "repeat order for current date" since most metadata/context is inherited
  • consider both SLR case (I click "grab followup image" in my EMR screen, and somehow the picture I take on the camera I pick up gets annotated) and smart device case (I'm using a tablet for EMR and activate the built in camera)
  • Consider Guided Acquisition (Not MUE)
  • send/display instructions ("First photo the whole left arm", "confirm", "Now zoom halfway in to the lesion", "Now turn on the special lighting and fill 75% of the image with the lesion", ...) to the operator to collect a better image set and correctly annotate the images collected.

Topics/Debates

  • Consider mapping semantics between JPEG tags and DICOM tags (Not MUE)
  • 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)
  • could introduce the actual camera (like the CT gantry) as an actor with a transaction to host the mapping
  • Review other profiles used with SWF (PDI, XCA-I, BIR, IRWF, etc) for EBIW compatibility (Not MUE)
  • e.g. Dermatology patient brings USB stick with some JPEGs for Encounter-based import using IRWF

Scope Management: Reminder: 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

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

8. Open Issues

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):

  • x%
  • Minimum Useful Effort: y%

Candidate Editor: Kevin

Retrieved from "http://wiki.ihe.net/index.php?title=Encounter_Based_Imaging_Workflow_for_Lightweight_Devices_-_Proposal&oldid=111141"