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

Latest revision as of 17:42, 11 August 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) 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 Placed in Paper Record or Scanned into EMR without metadata
Images Not Available to the Care Team
Limited Data Sharing with Affiliated Hospitals

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 (study, series?)
Communication - what notifications and "loop-closures" are needed
Data Transfer - what protocols should be used to move the different pieces of data and metadata

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.

3. Key Use Case

Dermatology
Wound Care/Management
Infectious Diseases
Burn Care
Plastic Surgery
Nursing/Clinic Photography
Point of Care Ultrasound

Use Case 1: Imaging with Simple Devices (often non-DICOM at initial point of capture)

Many departments capture clinical photos for documentation, follow up care, and diagnostics.

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 storage. (Advanced video management like editing and annotation is out of scope)
- Orders are not a required element clinically
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.

Use Case 2: Point of Care Ultrasound (DICOM modalities in "Order-less" workflow)

Traditional DICOM modalities (capable of Modality Worklist, C-Store, Storage Commitment) are also used in workflows where the imaging procedure is not explicitly Scheduled or Ordered. E.g. Point of Care Ultrasound for the following scenarios:

Inpatient Status Check
- A registered inpatient is in their bed in a ward
- An ultrasound is performed to determine the state of the bladder (empty, partial, full), or confirm placement of a PIC line or needle
- Key point: imaging is not "diagnostic" in the sense of radiology but rather evidentiary or for simple assessment
  - Such an image might still be referred to radiology if something strange was observed.

Emergency Room Evaluation
- Patient presents in the Emergency Room and is registered with an ER designation (between in-patient and out-patient)
- ER physician decides to capture US images proving a certain disorder, disease state or procedural evidence such as soft tissue infection
- The imaging may be diagnostic, but it is "interpreted locally" rather than in a subsequent reading step.

Outpatient Supplemental Information
- Patient makes scheduled visit to Breast Surgeon for abnormal lump detected by PCP.
- Patient arrives and is registered/checked in as outpatient
- Surgeon decides to take ultrasound images to evaluate/characterize the lump or document no evidence of lump.

If the patient & encounter metadata, and perhaps some procedure metadata, can be pre-staged, the modality could use Worklist to obtain and apply the full metadata to the image at the time of capture in the same way as done for scheduled/ordered imaging (like Radiology). The imaging protocol (selected on the US device) might provide body part, procedure type and purpose of imaging.

Supporting Diagrams for the above two use cases

Future Use Cases

As part of keeping the scope practical, several use cases (See Discussion) were identified as explicitly being out of scope for the first profile.

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: PAM, WIC, SWF, MHD-I, XDS*, CARD IEO
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:

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. 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, this proposal will:

Address two key use cases
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
Aggregate and combine the metadata and pixels for the two identified use cases
Notify the EMR when study becomes available
Address basic clinical usage of the images, but consider deferring more complex downstream activities in the first release.

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

Marshalling and conveying metadata:

Procedure codes are appropriate for some encounter-based imaging but placing an order is not necessary (and would disrupt their workflow)
Well-populated metadata is critical, but patient metadata comes from the EMR, encounter metadata may come from a Practice Management System or Department System, and procedure metadata may need to be entered at the time of capture.
Worklists are an effective tool to deliver good metadata to smart devices, but encounter-based imaging and devices may need other mechanisms.

Capture Process

Usage varies in the different departments/use cases

Be clear what IHE will/will not do (e.g. define standard tag/location but not standard procedure codes)

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

Facilitate Image Consumption

Understand downstream usage of the data.

@@ Line 1: / Line 1: @@
 __NOTOC__
 ==1. Proposed Workitem: Encounter-Based Imaging Workflow (EBIW)==
@@ Line 12: / Line 11: @@
 ==2. The Problem==
-Encounter-based Imaging ([[Encounter_Based_Imaging_Workflow_-_Proposal#3._Key_Use_Cases|a burgeoning area of activity]]) is needs to be supported as well as Order-based Imaging (aka [[Scheduled Workflow]]).
+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 Placed in Paper Record or Scanned into EMR without metadata
+:* Images Not Available to the Care Team
+:* Limited Data Sharing with Affiliated Hospitals
 EBI needs the same kind of committee analysis we did for SWF:
@@ Line 18: / Line 23: @@
 :* '''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)
+:* '''Organization''' - how is the data organized to meet the needs of its users (study, series?)
 :* '''Communication''' - what notifications and "loop-closures" are needed
-:* '''Data Transfer''' - what protocols should be used for the different artifacts
+:* '''Data Transfer''' - what protocols should be used to move the different pieces of data and metadata
 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==
@@ Line 65: / Line 37: @@
 * Infectious Diseases
 * Burn Care
-* Ophthalmology
-* Otolaryngology
 * Plastic Surgery
-* Podiatry
+* Nursing/Clinic Photography
-* 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).
+===Use Case 1: Imaging with Simple Devices (often non-DICOM at initial point of capture)===
-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.
+Many departments capture clinical photos for documentation, follow up care, and diagnostics.
-* 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.
+Capture devices include digital cameras, smartphones and tablets (using iOS, Android and camera-specific OS).
-* 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.
+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.
-===Use Case 2: DICOM capable devices deployed in an unmanaged non-order based workflow (e.g Point of Care Ultrasound)===
+* Patient makes appointment for Dermatology visit.
-TODO: Write some text here
+* 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 storage. (Advanced video management like editing and annotation is out of scope)
+** Orders are not a required element clinically
+* 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 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 2: Point of Care Ultrasound (DICOM modalities in "Order-less" workflow)===
-===Use Case x1: Surgical documentation (Future scope)===
+Traditional DICOM modalities (capable of Modality Worklist, C-Store, Storage Commitment) are also used in workflows where the imaging procedure is not explicitly Scheduled or Ordered. E.g. Point of Care Ultrasound for the following scenarios:
-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.
+* '''Inpatient Status Check'''
+** A registered inpatient is in their bed in a ward
+** An ultrasound is performed to determine the state of the bladder (empty, partial, full), or confirm placement of a PIC line or needle
+** Key point: imaging is not "diagnostic" in the sense of radiology but rather evidentiary or for simple assessment
+*** Such an image might still be referred to radiology if something strange was observed.
-There may be some common needs between this and the [[Cardiac Cath Workflow]] profile.
+* '''Emergency Room Evaluation'''
+** Patient presents in the Emergency Room and is registered with an ER designation (between in-patient and out-patient)
+** ER physician decides to capture US images proving a certain disorder, disease state or procedural evidence such as soft tissue infection
+** The imaging may be diagnostic, but it is "interpreted locally" rather than in a subsequent reading step.
-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.
+* '''Outpatient Supplemental Information'''
+** Patient makes scheduled visit to Breast Surgeon for abnormal lump detected by PCP.
+** Patient arrives and is registered/checked in as outpatient
+** Surgeon decides to take ultrasound images to evaluate/characterize the lump or document no evidence of lump.
-This creates a two-fold problem where:
+If the patient & encounter metadata, and perhaps some procedure metadata, can be pre-staged, the modality could use Worklist to obtain and apply the full metadata to the image at the time of capture in the same way as done for scheduled/ordered imaging (like Radiology). The imaging protocol (selected on the US device) might provide body part, procedure type and purpose of imaging.
-* 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.
+[[Encounter-based_Imaging_Workflow#High_Level_Workflow|Supporting Diagrams for the above two use cases]]
-===Use Case x2: Patient provided images (e.g. Dermatology) (Future scope)===
+===Future Use Cases===
-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.
+As part of keeping the scope practical, several use cases (See Discussion) were identified as explicitly being '''out of scope''' for the first profile.
-===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==
@@ Line 128: / Line 90: @@
 :* Image Archiving Devices
 :* Electronic Medical Record Systems
-:* Patient Management Systems
+:* Practice Management Systems
 :* Encounter Management System (office/departmental system that provides the encounter context)
 :* QA System
@@ Line 135: / Line 97: @@
 Potential Standards
 :* Existing Profiles: PAM, WIC, SWF, MHD-I, XDS*, CARD IEO
-:* DICOMweb
+:* DICOM (DIMSE), DICOMweb
-:* DICOM (DIMSE)
+:* HL7, FHIR
-:* HL7
+:* Consumer media formats: JPEG, MPEG, PDF, RAW, etc
-::* PCD domain Encounter-based Patient Identification Management whitepaper
-:* FHIR
-:* Consumer formats: JPEG, MPEG, PDF, RAW, etc
 Relevant Whitepapers:
 :* [https://siim.org/page/himss_siim_white_pap SIIM-HIMSS Enterprise Imaging Workgroup - White Papers]
 :* [https://link.springer.com/article/10.1007/s10278-016-9882-0 A Foundation for Enterprise Imaging - JDI Whitepaper]
-:* [https://link.springer.com/article/10.1007/s10278-016-9883-z Enterprise Imaging Governance - JDI Whitepaper]
-:* [https://link.springer.com/article/10.1007/s10278-016-9885-x Considerations for Exchanging and Sharing Medical Images for Improved Collaboration and Patient Care - JDI Whitepaper]
 :* [https://link.springer.com/article/10.1007/s10278-016-9888-7 Order-based vs Encounter-based Imaging - JDI Whitepaper]
-:* [https://link.springer.com/article/10.1007/s10278-016-9887-8 The Current State and Path Forward for Enterprise Image Viewing - JDI Whitepaper]
 :* [https://link.springer.com/article/10.1007/s10278-016-9897-6 The Workflow Challenges of Enterprise Imaging - JDI Whitepaper]
 :* [https://link.springer.com/article/10.1007/s10278-016-9899-4 Technical Challenges of Enterprise Imaging - JDI Whitepaper]
+:* PCD Encounter-based Patient Identification Management whitepaper
 Relevant Current and Past Activities:
@@ Line 158: / Line 115: @@
 ==5. Discussion==
-''<Include additional discussion or consider a few details which might be useful for the detailed proposal>''
+* 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.
-:''<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>''
-:''<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>''
+'''Scope Management''': Instead of addressing the full spectrum of challenges related to encounter-based imaging workflow, this proposal will:
-:''<What are some of the risks or open issues to be addressed?>''
+:* Address two key use cases
+:* 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
+:* Aggregate and combine the metadata and pixels for the two identified use cases
+:* Notify the EMR when study becomes available
+:* Address basic clinical usage of the images, but consider deferring more complex downstream activities in the first release.
+'''Specific Technical Gaps''' (e.g. relative to Scheduled Workflow):
+:* Marshalling and conveying metadata:
+::* Procedure codes are appropriate for some encounter-based imaging but placing an order is not necessary (and would disrupt their workflow)
+::* Well-populated metadata is critical, but '''patient metadata''' comes from the EMR, '''encounter metadata''' may come from a Practice Management System or Department System, and '''procedure metadata''' may need to be entered at the time of capture.
+::* Worklists are an effective tool to deliver good metadata to smart devices, but encounter-based imaging and devices may need other mechanisms.
+:* Capture Process
+::* Usage varies in the different departments/use cases
+:::* Be clear what IHE will/will not do (e.g. define standard tag/location but not standard procedure codes)
+:* 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
+:* Facilitate Image Consumption
+::* Understand downstream usage of the data.