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: TBA
- Contributors: Dawn Cram, Christopher Roth, (Alex), Ken, Matt, Paul, (Louis), Elliot, (recruiting some of the acq app vendors and EMRs)
- 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 (sometimes images augment a procedure, sometimes images are the procedure)
- Organization - how is the data organized to meet the needs of its users, how do the images fit into the medical record
- 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.
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 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 Cases
- Wound Care/Management
- Infectious Diseases
- Burn Care
- Plastic Surgery
- Sports Medicine
- Pathology Samples
- Point of Care Ultrasound
- Nursing/Clinic Photography
- Procedure (Surgery?) Video
- The video isn't ordered. Does Surgery fit the encounter model well?
- Sleep Lab Video
- More likely to be ordered?
Use Case 1: Basic Encounter-Based Imaging
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.
Use Case 2: Surgical documentation
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 3: Inpatient Imaging
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
- Image Acquisition Devices (both Lightweight and Heavy/Integrated)
- Image Archiving Devices
- Electronic Medical Record Systems
- Patient Management Systems?
- Existing Profiles: PAM, WIC, SWF, MHD-I, XDS*, CARD IEO
- DICOM (DIMSE)
- Consumer formats: JPEG, MPEG, PDF, etc
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.
- More analysis here: Order-based vs Encounter-based Imaging - JDI Whitepaper
- And here: The Workflow Challenges of Enterprise Imaging
- Technical approach thoughts
- Perhaps new EBIW profile that parallels SWF
- Perhaps expand WIC?
- Should this be multiple profiles - e.g. EBIW + WIC + Documentation WF and maybe something where SWF & EBIW meet
- Might also be a review of other profiles used with SWF (PDI, XCA-I, BIR, IRWF, etc) to make sure they work with EBIW also
- Derm patient brings a USB stick with some JPEGs, how does that flow through IRWF but as an Encounter-based import?
- List of conventions
- Use admit date as the procedure date (need to also know what was being done at the time of the imaging - procedural context)
- Consider focusing primarily/exclusively on FHIR and DICOMweb?
- If a new "encounter" is spawned for each acquisition, how do you relink those that are really part of the same real encounter
- Issues with semantics clarity between JPEG tags and DICOM tags - acquisition date is what is needed. Be careful not to use modification date from IPC. Standardized mapping needed.
- This goes beyond the definition of Radiology, however 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
- SIIM-HIMSS Enterprise Imaging Workgroup - White Papers
- Should the scope include "self-captured" data from patients at home or remote?
- Review of DICOM Tags and semantics in the context of EBI
- Do we assume the acq apps follow the profile in detail or does the VNA do most of the work
- Continue to delineate EBI vs Enterprise Imaging vs mobile vs consumer vs lightweight vs web APIs vs ...
- Consider categorization into Diagnostic Imaging, Procedural Imaging, and Evidence Imaging (document current patient state)
Technical Approach Ideas
One Proposed solution involves:
- A DICOM MWL SCP uses the visit information associated with the HL7 ADT^A04 event triggered upon registration/arrival of the patient to generate an encounter worklist entry
- The 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
- Considering attributes typically required in Order-based imaging in an Encounter-based context:
- Admit date/time (0038,0020)/(0038,0021) replaces scheduled procedure date/time (0040,0002)/(0040,0003)
- PatientID (0010,0020) and PatientName (0010,0010) populated as usual
- ScheduledProcedureStepSequence (0040,0100) must not be empty, and must contain: ScheduledProcedureStepDescription (0040,0007) (not applicable in encounters-based workflow – not ideal but can provide generic description overwritten by acquisition device based upon series and/or study description from body part/region/etc selection)
- Accession number (0008,0050) will/may be blank or null
- Visit/encounter number (admission ID (0038,0010)) will be provided to the SCU and passed back to the Storage SCP (archive)
- Selection of body part (according to DICOM body part standard) is available on capture device.
- Multiple body part selection can generate a new SUID associated with the image content for each body part selected, and passed to the Storage SCP, along with body part and study description based upon capture device selections.
- Paste this text into a copy of your Brief Proposal
- Move the Summary section here to the end of Section 1 in your Brief Proposal
- Expand details in the Use Case Section of your Brief Proposal
- Distribute material in the Discussion Section of your Brief Proposal into the other bottom sections (5,6,7,8,9) here.
<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">
<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">
<Summarize in a few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">
<Summarize in a line or two market interest & available resources. E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking. Individuals from SFR are willing to participate in Profile development.">
<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">
5. Technical Approach
<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>
<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>
<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>
<Indicate what existing actors could be used or might be affected by the profile.>
<List possible new actors>
<Indicate how existing transactions might be used or might need to be extended.>
New transactions (standards used)
<Describe possible new transactions (indicating what standards might be used for each).>
<Transaction diagrams are very helpful here. Go into as much detail as seems useful.>
Impact on existing integration profiles
<Indicate how existing profiles might need to be modified.>
New integration profiles needed
<Indicate what new profile(s) might need to be created.>
Breakdown of tasks
<As the basis for the effort estimation, enumerate the tasks to develop the Profile text. E.g.>
- <Discuss/Confirm use case list (currently 5) to decide in/out of scope and details>
- <Analyze/choose which report guidelines to use>
- <Resolve open issue on the degree of computer parsability>
- <Draft/Review content definition for Oncology Report (profile use of CCDA)>
- <Draft/Review transaction for Retrieve Report>
6. Support & Resources
<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>
<Identify anyone who as indicated an interest in implementing/prototyping the Profile if it is published this cycle.>
<List technical or political risks that will need to be considered to successfully field the profile. Demonstrate to the TC/PC your understanding/appreciation of the problem space>
8. Open Issues
<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>
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):
- 35% for ...
Internet-Ready_SWF_-_Proposal started to consider encounter-based imaging as well.