Difference between revisions of "Encounter Based Imaging Workflow - Brief Proposal"

From IHE Wiki
Jump to navigation Jump to search
Line 161: Line 161:
  
 
* '''Scope Management''': Instead of addressing the full spectrum of challenges related to encounter-based imaging workflow, the focus of this proposal is to address the following questions:
 
* '''Scope Management''': Instead of addressing the full spectrum of challenges related to encounter-based imaging workflow, the focus of this proposal is to address the following questions:
:* What are the few key use cases we plan to cover in our first pass? See Key Use Cases section for further discussion
+
:* Focus on the two key use cases identified. See Key Use Cases section for further discussion
:* What metadata (related to the patient, encounter, procedure, etc.) needs to be associated with the images in those use cases?
+
:* Define the minimal necessary set of metadata (related to the patient, encounter, procedure, etc.) associated with those use cases
:* What is the source of each piece/set of metadata?
+
:* Identify the source(s) of each piece/set of metadata
:* Where does the metadata and pixels get combined and how is each piece of metadata transported to the place of aggregation?
+
:* Try to limit to two pathways to aggregate and combine the metadata and pixels for the two identified use cases
:* What is the mechanism to ''close the loop'' so that the EMR is aware when the study becomes available?
+
:* Address notification to EMR when study becomes available
 +
 
 +
* During the design, we would keep the clinical usage of the images in mind, but the profile may not address some of the downstream activities in the first release.
  
 
* '''Niche risk''' - solving an instance of the problem instead of the broad class
 
* '''Niche risk''' - solving an instance of the problem instead of the broad class

Revision as of 12:35, 21 July 2017


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

  • 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 / Kinson Ho
  • Contributors: See Support & Resources
  • Domain: Radiology

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)

3. Key Use Case

  • 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.

  • 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, may be used to document various states of wounds, bedsores, or other disorders.
  • Orders are not a required element clinically.
  • Example: 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 as evident of care or for 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: DICOM capable devices deployed in an unmanaged non-order based workflow (e.g Point of Care Ultrasound)

TODO: Write some text here

The following cases have been identified and decided to be out of scope for this profile proposal. They are documented here for reference only and will be considered in the future.

Use Case x1: 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.

Use Case x2: Patient provided images (e.g. Dermatology) (Future scope)

Instead of capturing images by the provider during the patient encounter, patient captured images (e.g. using a consumer camera or phone) and provided to the provider during the visit. In this case, the contextual metadata associated to the metadata can be very limited or unspecific.

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

After the images are captured, sometimes there are additional image processing steps that need to be performed. For example:

  • Annotation
  • QA
  • Color correction

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:

Relevant Current and Past Activities:

5. Discussion

  • IHE is a good venue to solve the encounter-based workflow problem because currently there are many proprietary ad-hoc workflows trying to deal with similar problems. As a start, IHE can create a profile to establish basic encounter-based imaging workflow that are broadly applicable to many specialties. Future enhancements can be introduced for additional support for various specialties.
  • Scope Management: Instead of addressing the full spectrum of challenges related to encounter-based imaging workflow, the focus of this proposal is to address the following questions:
  • Focus on the two key use cases identified. See Key Use Cases section for further discussion
  • Define the minimal necessary set of metadata (related to the patient, encounter, procedure, etc.) associated with those use cases
  • Identify the source(s) of each piece/set of metadata
  • Try to limit to two pathways to aggregate and combine the metadata and pixels for the two identified use cases
  • Address notification to EMR when study becomes available
  • During the design, we would keep the clinical usage of the images in mind, but the profile may not address some of the downstream activities in the first release.
  • Niche risk - solving an instance of the problem instead of the broad class
  • e.g. Is the point-of-care US solution developed applicable to point-of-care endoscopy/photography?
  • 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.
  • focus on general metadata, not device/specialty specific, but allow extension from specialty specific code (e.g. dermatology anatomy codes)
  • might need domain specialty attributes
  • 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 Cerner
  • 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, PCD (patient identification for encounter-based workflow) - Cochair Action Item
  • They have already engaged domain vendors and adapted SWF. Their experience/advice will be important. Specifically, they understand their domain details.
  • Invite other domains to present their workflow and see how harmonize/divert this solution compared to what they have already had
  • 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 solution