Encounter Based Imaging Workflow - Proposal

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

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

Summary

Increasing amounts of medical imaging is done outside the context of an ordered procedure. Such "encounter-based imaging" needs robust integration, data management and workflow similar to what order-based imaging enjoys via the SWF Profile.

A new Encounter-Based Imaging Workflow Profile could specify how to integrate the devices to capture appropriate context, link to related data, populate relevant indexing fields and ensure the images are accessible and well knit into the medical record.

Experts from Duke, U Miami, Mayo, and Northwestern have already authored several whitepapers outlining this problem and considerations in solving it. It has been the subject of several 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.

As with SWF, an IHE solution could avoid the costs and incompatibilities of the proprietary solutions that are already starting to emerge.

2. The Problem

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

EBI needs the same kind of committee analysis we did for SWF:

• Use Cases - what are the different ways encounter-based imaging is performed
• Metadata - what context details need to be captured, stored, conveyed (to support capture, search and review)
• Linkage - what other artifacts/results do the images need to be linked to, and how
• Organization - how is the data organized to meet the needs of its users, how do the images fit into the medical record (sometimes images augment a procedure - surgical video, sometimes images are the procedure - diagnostic)
• Communication - what notifications and "loop-closures" are needed
• Data Transfer - what protocols should be used for the different artifacts

Even with many vendors converging on similar concepts, the SWF exercise in the late 90's was valuable to tease out subtle details, resolve elements of disagreement and confusion in the implementer community, and nail down various technical details. It contributed to an extended period of robust departmental interoperability.

An EBI exercise and profile could provide similar benefits in the expanded medical imaging community.

Costs of Status Quo: Sites have highlighted EBI related problems like:

• Images Absent from or Scattered throughout EHR
• Silo-ization of the medical imaging record
• Images Not Available to Care Team
• Images Placed in Paper Record or Scanned into EHR
• Limited Access to Images within EHR Context
• Limited Data Sharing w/ Acquired & Affiliated Hospitals

Specific Technical Gaps (e.g. relative to Scheduled Workflow):

• Order Placement:

• Procedure codes are appropriate for some encounter based imaging but an order per se is not necessary (and would disrupt their workflow)
• While image metadata achieved through the placement of an order is unarguably necessary, requiring the placement of an order is not necessary to achieve the same end result when images are captured following an encounters based workflow as addressed in this profile proposal.

• Loop Closure

• In Order based there is an order and a report to close the loop

• EBI has multiple kinds of results - endo images, surg notes, all linked to the procedure
• EMR can backfill orders, but the cross result linkage on a different system is a problem, esp when exchanging with other institutions
• DICOM Study is a grouping method, but with a JPEG on a disk, the context/linkage metadata is missing.

• Data flow

• should get the same end result as if the clinician placed the order

• Want to support the same analytics, access/indexing of the imaging

• Capture Process

• Consider focusing initially on the capture process (there is some risk in the varied usage needs in the different departments/use cases)

• Although downstream usage of the data can't be completely ignored.
• What is the end result of the first profile - e.g. what is passed to the EHR to index, find, display, provide to physicians
• A big gap is labelling/tagging to know the procedure behind the encounter image
• Body part is not well populated (2,000 for some dermatology groups, 1 for others) - device should provide it, but often not well done, also tags are lacking for some purposes
• Sharing tags with order-based makes it easy to pair, but need it to be easy

• Will need to be clear what we will/will not do (e.g. start with standard tag/location but standardizing procedure codes is not typically done yet)

History: 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.

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,
• Enable view images within the EHR or directly from the EHR through a link associated with the note or report describing the visit where the images were obtained,
• Easily identify the type of imaging performed and the anatomical region through an EHR imaging description,
• Associate report or note describing the visit where the images were obtained with images in enterprise viewer, and
• Search necessary imaging metadata to serve business intelligence needs.

To achieve the goals, this profile will focus on three questions:

• Assuming that there is no order being placed, how can the acquisition device conveniently obtain the encounter information to associate context with the acquired images?
• What are the list of mandatory metadata? (department, encounter, body part, patient, etc.)
• What is the transport mechanism to communicate metadata and images from acquisition devices to downstream systems?
• What is the mechanism for downstream system to query/retrieve the stored metadata and images?

3. Key Use Cases

• Dermatology
• Wound Care/Management
• Infectious Diseases
• Burn Care
• Ophthalmology
• Otolaryngology
• Plastic Surgery
• Podiatry
• ER/Trauma
• Dentistry
• Sports Medicine
• Pathology Samples
• Point of Care Ultrasound
• Nursing/Clinic Photography
• Procedure Video (e.g. Surgery, the video isn't ordered)
• Sleep Lab Video (More likely to be ordered?)

Use Case 1: Basic Encounter-Based Imaging for non-DICOM capable devices

Numerous departments capture clinical photos for documentation, follow up care, and in some cases, diagnostics (such as dermascope or OCT). Capture devices include digital cameras, smartphones and tablets and run on platforms including iOS, Android and camera specific operating systems.

Option 1a: Unmanaged capture (bad)

• images lack a source of metadata so only an image is captured lacking important details like:
  • patient demographics, visit/encounter details/context, body part examined
• linking image content in the EHR or HIS, and future retrieval, and multidisciplinary relativity is virtually impossible without cumbersome and sometimes inaccurate manual indexing workflows
• downstream EHR image consumers need this information to know if clicking through a hyperlinked set of images will be valuable for them or not, and having a relevant procedure name helps them greatly decide that.
• many image creators need this metadata for teaching file granularity purposes (to identify a set of images as a specific body part, and differentiate it from other images from the same encounter).
• hospital credentialing people need to see what procedures providers are performing to make sure they are performing in the scope of their work (this was a big issue at one of the contributor institutions)
• providers want to know what kind of case volumes they had, and driving analytics later requires a level of specificity to orders metadata current unavailable without the cumbersome workflows.

Option 1b: Require order placement (bad)

• cumbersome workflow for clinical care providers
  • they must interrupt their clinical workflow to interact with a different system and generate order details, some of which are irrelevant, others should be generated automatically

Option 1C: Encounter-based imaging (good)

• use the systems/information associated with the current patient encounter to generate the needed context details and populate them in the image artifacts created.
• the images (clinical photos) that will be taken are not known prior to the visit, but rather, are at the provider's discretion during the visit.
  • Patient makes appointment for Dermatology visit.
  • Patient arrives for Dermatology visit and is registered/checked in, as a patient class of OP (outpatient)
  • EHR or HIS triggers an ADT^A04 release
  • Provider may or may not decide to take clinical photos of the patient during the visit to document disease processes, pathologies or disorders.
    • If the provider decides to take clinical photos for evidentiary or diagnostic reasons (ie - dermascope), image content may include photos of multiple body parts.

Note: Basic video capture and store is part of scope. Advanced video management (e.g. annotation, point of interest, editing, etc.) are out of scope.

Use Case 2: Point-of-Care Ultrasound (DICOM capable devices deployed in an unmanaged non-order based workflow)

TODO: Write some text here

Use Case Y: Post-Acquisition Imaging Process (Future scope)

TODO: Update text here

• • Annotation
  • QA
  • Color correction

Use Case 2: Surgical documentation (Future scope)

During a surgical case, and pre and post-surgery, various image capture devices/modalities are used to document the procedure and provide diagnostic information required to monitor patient care or ensure xxx during the procedure. Scope video and still images, US (usually performed by anesthesia), external photography (often used by plastics), and ECG monitoring are some of the image content captured pre, during, and post procedure following an encounters based workflow. Orders are not a required element clinically and capture is either at the discretion of the Surgeon, as with video capture, or is inherently part of the procedure itself as with ECG monitoring.

There may be some common needs between this and the Cardiac Cath Workflow profile.

Other imaging may be requested of a diagnostic specialty by the Surgeon pre, during, or post procedure, requiring an orders based workflow, as with x-rays performed by Radiology, OCT performed by Ophthalmology or Neurodiagnostic monitoring.

This creates a two-fold problem where:

• placing orders for the image content performed at the discretion of the provider creates a cumbersome workflow, often requiring manual reconciliation intervention by staff following the procedure
• all imaging associated with the procedure is divided across orders which may not be tied to the surgical visit/encounter, since the orders placed for the requesting department often generate their own visit/encounter.

Additional complexity is noted when the procedure is performed on a patient already admitted as an inpatient. Whereas when an ambulatory surgical patient is registered/arrived specifically for a surgical visit/encounter an ADT^A01 (admit) or ADT^A04 (registration), depending upon EHR or information system and technical build) will be triggered and can follow the same workflow as with an outpatient Dermatology visit, an already admitted inpatient will trigger an ADT transfer which does not include the encounter/visit number of the admitting surgical department.

Inpatient Imaging

TODO: Merge into Use Case 1

Photos and other images captured on inpatients by unit. Orders are not a required element clinically and capture is at the discretion of the care provider and may be used to document various states of wounds, bedsores, or other disorders.

The DICOM MWL SCP requires update of patient location following unit transfers for MWL distribution. The Storage SCP requires update of patient location following unit transfers and retention of all unit locations through an admission encounter for reconciliation workflows and including exception workflows.

4. Standards and Systems

Potential Systems

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

Potential Standards

• Existing Profiles: PAM, WIC, SWF, MHD-I, XDS*, CARD IEO
• DICOMweb
• DICOM (DIMSE)
• HL7

• PCD domain Encounter-based Patient Identification Management whitepaper

• FHIR
• Consumer formats: JPEG, MPEG, PDF, RAW, etc

Relevant Whitepapers: TODO: Add the addition whitepaper from HIMSS-SIIM working group

• Order-based vs Encounter-based Imaging - JDI Whitepaper
• A Foundation for Enterprise Imaging - JDI Whitepaper
• The Workflow Challenges of Enterprise Imaging
• SIIM-HIMSS Enterprise Imaging Workgroup - White Papers
• Internet-Ready_SWF_-_Proposal started to consider encounter-based imaging as well.

5. Technical Approach

New integration profiles needed

• Encounter-Based Image Workflow Profile, modeled in part on SWF.b (order-based workflow)

Impact on existing integration profiles

• Once we see what EBIW looks like, figure out if there are useful groupings or options in other profiles.
• No intention to make this part of SWF or to make significant changes to SWF.

Existing actors

• Likely reuse several from SWF.b, PAM, etc.

New actors

• Encounter-oriented Modality Actor (DICOM capable)
• Encounter-oriented Capture Actor (non-DICOM capable)

• If the profile needs to isolate requirements specific to Encounter-mode

Existing transactions

• Might re-use several SWF.b and PAM transactions for storage, MPPS, MWL, patient registration.
• PDQm, WIC and MHD-I transactions could also be useful or we could group with those profiles.

New transactions (standards used)

• Likely a few new transactions that are variations of existing transactions

• Encounter Management

• (e.g. based on Patient Encounter Management (ITI-31) with additional requirements to queue up the metadata for image capture.)
• possibly creation of "placeholder" order?

• Store Images (e.g. based on WIC)
• Store Documents (e.g. based on existing document storage)
• Notification of Procedure

TODO: Draft transactions which will help effort estimate. To be discussed by EBIW group before TC evaluation.

Breakdown of tasks

• Policy choice

• Greenfield-sites vs existing; new tech vs adapt old tech (entrenched product habits); "maturity" of industry

• Consider if alternative mechanisms are warranted for metadata transfer to modality

• HL7, DMWL, both? FHIR? IHE PDQm? SMART?
• Might consider this profile as a stepping stone to DICOMweb/FHIR since many existing encounter-based imaging devices have not already implemented DIMSE.

• Discuss/Confirm use case list to decide in/out of scope and details

• Extract/model the technical use cases

• Decide what parts of SWF to borrow (same submission and commitment of images)

• Establishing encounter/patient/context, conveying metadata, capturing/storing image data, indexing/archiving images, finding/accessing/using images
• distinguish between provider captured images and patient captured images
• 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

• Analyze Procedure metadata and linking to other results

• e.g. surgical report, accession #s for other ordered procedures

• Consider additional consumption requirements/usage patterns

• Focus on metadata that needs to support downstream consumption (e.g. how to find the desired images? what metadata are essential for the general proper consumption of the images?) requirement
• Design weaving of encounter images into clinical notes/clinical record/documentation workflow

• Draft the actor/transaction interactions (Vol 1) based on whitepaper use cases and paralleling SWF
• Clone and revise transactions we can't use directly
• Target transaction map and technology choices at end of kickoff meeting (Nov).

• The following tasks are nice to have if time permits

• Separable task: 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
• List conventions like "Use admit date as the procedure date"; "Find procedure context by searching EMR for entries at/near image capture time"

• Separable task: Diagram Diagnostic Imaging, Procedural Imaging and Evidence Imaging

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

6. Support & Resources

The work already done in the SIIM-HIMSS Enterprise Imaging group and elsewhere has already coalesced a number of collaborators, many of whom have helped on the proposal and are interested in working on the profile.

TODO: Add EBIW special interest group and the wiki

Already joining the proposal preparation calls:

• Healthcare: Chris Roth (Duke), Dawn Cram (U Miami), 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.

7. Risks

• Scope risk - taking on too much work overall - nail down a useful chunk for this cycle early on

• One proposal is to focus on the broad workflow but not get into domain-specific details

• Niche risk - solving an instance of the problem instead of the broad class

• IHE Rad cochairs will reach out to IHE imaging (Eyecare, Cardiology, Pathology, Endoscopy, Dental) to make sure they are engaged in the requirements and work. Historically they have successfully borrowed heavily from IHE Rad work.

• Option risk - trying to incorporate/allow too many different mechanisms/technologies - needs the usual IHE attempt to balance inclusion against convergence to reduce the development/maintenance/coordination load.
• EMR Participation - this profile must consider EMR interactions so we need their participation but that's traditionally been sparse in IHE Rad.

• Ken Persons and Thomas Pickard will reach out to Matt Doyle from Epic
• Mike Bressack can talk to Cerner
• Elliot Silver will talk to McKesson EMR
• Rob Mitchell will contact Julie Pekarek <jpekarek@us.ibm.com> to see if the E-Orders Coalition can be used as a recruiting/engagement channel

• Reach out to IHE (imaging) - Eyecare, Cardiology, Pathology, Endoscopy, - Cochair Action Item

• They have already engaged domain vendors and adapted SWF. Their experience/advice will be important. Specifically, they understand their domain details.

• 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?)

8. Open Issues

• Issue: Order-based but finesse auto-placement of the order VS work from clean/minimal slate? - Simplified
  • Possible order-based approach
    • Arrival/Registration of the patient triggers an HL7 ADT^A04 event containing visit information
    • DICOM MWL SCP generates an encounter worklist entry based on the HL7 ADT^A04
    • Capture device (DICOM MWL SCU) at the visit/encounter location queries the worklist and uses Patient/Visit rather than Patient/SPS/Service Request to populate the images
    • Consider required Order-based imaging attributes in an Encounter-based context:
      • PatientID (0010,0020) and PatientName (0010,0010) populated as usual
      • Accession number (0008,0050) will/may be blank or null
      • Admit date/time (0038,0020)/(0038,0021) replaces scheduled procedure date/time (0040,0002)/(0040,0003)
      • Selection of body part (using DICOM codes) is done on capture device.
      • ScheduledProcedureStepSequence (0040,0100) must not be empty
      • ScheduledProcedureStepDescription (0040,0007) better known by acquisition device (e.g. body part/region/etc selection also used in series and/or study description)
      • Visit/encounter number (admission ID (0038,0010)) used by SCU in image headers to Storage SCP
      • For multiple body part selection, should each body part be a new Series, or a whole new Study?
    • If a new "encounter" is spawned for each acquisition, how do you relink those that are really part of the same actual encounter
  • Possible non-order-based approach

• How are final images encoded? in DICOM - CLOSED

• Expect to support both STOW-RS and C-STORE (both transactions already exist) - CLOSED

• Should imags be linked to reports or pasted directly into them? - Linked by using the shared encounter ID, which is part of the metadata. - CLOSED

• What is the scope of uniqueness for Encounter/Visit numbers? - Uniqueness is handled by qualifying the encounter ID with an assigning authority - CLOSED

• For in-patient, encounter is unique in the EMR across the enterprise, or unique within the scope of issuing system
• For out-patient, encounter is unique for each department

• And do they link to Accession#s for in-patients? Is implicit order required or not?

• maintain harmonization for workflow and data management between encounter-driven and order-driven environments, especially for people and devices that operate in both contexts

• Issue: Is this a "Radiology Profile? Yes - CLOSED
  • Historically RAD profiles have provided a basis for other imaging domains
  • RAD is the closest thing IHE has to a general Medical Imaging domain
  • Have TC members who understand the solution technologies well
  • Need contributors who understand the use cases well
    • Would be advisable to solicit collaborators from Cardiology, Eyecare, and perhaps ITI

• Issue: Bias toward older (DICOM/HL7) VS newer (DICOMweb/FHIR) technologies? Focus on HL7 v2 + DICOM + DICOMweb for this profile - CLOSED

• Issue: Should the scope include "self-captured" data from patients at home or remote? Deferred, focus on workflow within hospitals - CLOSED

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

• 45%
• could use narrowing of clinical range as a ballast adjustment.
• alternatively could focus on a chunk of the workflow - e.g. context+capture.

Candidate Editor: Dawn Cram (Teri?) Mentor: Elliot, Kevin?