Difference between revisions of "Encounter Based Imaging Workflow - Brief Proposal"
(40 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
− | |||
==1. Proposed Workitem: Encounter-Based Imaging Workflow (EBIW)== | ==1. Proposed Workitem: Encounter-Based Imaging Workflow (EBIW)== | ||
Line 12: | Line 11: | ||
==2. The Problem== | ==2. The Problem== | ||
− | Encounter-based Imaging ( | + | 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: | 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) | :* '''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 | :* '''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 | + | :* '''Organization''' - how is the data organized to meet the needs of its users (study, series?) |
:* '''Communication''' - what notifications and "loop-closures" are needed | :* '''Communication''' - what notifications and "loop-closures" are needed | ||
− | :* '''Data Transfer''' - what protocols should be used | + | :* '''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. | 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. | An EBI exercise and profile could provide similar benefits in the expanded medical imaging community. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==3. Key Use Case== | ==3. Key Use Case== | ||
Line 65: | Line 37: | ||
* Infectious Diseases | * Infectious Diseases | ||
* Burn Care | * Burn Care | ||
− | |||
− | |||
* Plastic Surgery | * Plastic Surgery | ||
− | * | + | * Nursing/Clinic Photography |
− | |||
− | |||
− | |||
− | |||
* Point of Care Ultrasound | * Point of Care Ultrasound | ||
− | |||
− | |||
− | |||
− | ===Use Case 1: | + | ===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 | + | |
+ | 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: DICOM | + | ===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. | |
− | + | [[Encounter-based_Imaging_Workflow#High_Level_Workflow|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. | |
− | ===Use | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==4. Standards and Systems== | ==4. Standards and Systems== | ||
Line 128: | Line 90: | ||
:* Image Archiving Devices | :* Image Archiving Devices | ||
:* Electronic Medical Record Systems | :* Electronic Medical Record Systems | ||
− | :* | + | :* Practice Management Systems |
:* Encounter Management System (office/departmental system that provides the encounter context) | :* Encounter Management System (office/departmental system that provides the encounter context) | ||
:* QA System | :* QA System | ||
Line 135: | Line 97: | ||
Potential Standards | Potential Standards | ||
:* Existing Profiles: PAM, WIC, SWF, MHD-I, XDS*, CARD IEO | :* Existing Profiles: PAM, WIC, SWF, MHD-I, XDS*, CARD IEO | ||
− | + | :* DICOM (DIMSE), DICOMweb | |
− | :* DICOM (DIMSE) | + | :* HL7, FHIR |
− | :* HL7 | + | :* Consumer media formats: JPEG, MPEG, PDF, RAW, etc |
− | |||
− | |||
− | :* Consumer formats: JPEG, MPEG, PDF, RAW, etc | ||
Relevant Whitepapers: | Relevant Whitepapers: | ||
:* [https://siim.org/page/himss_siim_white_pap SIIM-HIMSS Enterprise Imaging Workgroup - White Papers] | :* [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-9882-0 A Foundation for Enterprise Imaging - 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-9888-7 Order-based vs Encounter-based Imaging - 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-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] | :* [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: | Relevant Current and Past Activities: | ||
Line 160: | Line 117: | ||
* 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. | * 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. |
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.