Encounter Based Imaging Workflow - Proposal

From IHE Wiki
Jump to navigation Jump to search

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

Summary

Increasingly 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 would specify how to integrate the devices to capture appropriate context, populate relevant indexing fields link to related data, 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 detailing this problem and considerations in solving it. It has been the subject of many 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) 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:

Relevant Current and Past Activities:

5. Technical Approach

New integration profiles needed

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

Impact on existing integration profiles

  • No significant changes to SWF. This is a sister profile.

Existing actors

  • Reuse several from SWF.b, PAM, etc.

New actors

  • Encounter Manager
  • Encounter-oriented Modality (DICOM capable)
  • Encounter-oriented Capture (non-DICOM capable)
  • If the profile needs to isolate requirements specific to Encounter-mode
  • Quasi-Modality
  • a system that does the assembly of pixels from a non-DICOM capable Capture Actor
  • it may make sense to drop the Capture Actor from the profile since we may not have any specific requirements on it and let it communicate with the Quasi-Modality in "typical ways"
  • if we end up needing to define communication between the Capture Actor and the Quasi-Modality because the Capture actor is semi-smart and includes some of the extra metadata.
  • TODO - note in diagram that it's a modality interface so you can enter/update details like on a regular modality. Copy up the procedure bullets from PoC US diagram to Capture.
  • TODO - highlight the proposed actors in the diagrams.
  • do not intend to include an explicit QC Actor (we haven't really called it out in SWF. You do it but it's as you like)

Existing transactions

  • Re-use SWF.b and PAM transactions for storage, patient registration, etc.
  • 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
  • Ken can lead a discussion - 2 flavours:
  • (1) might be "out of the blue", no order, no expectation - EMR would like to create a place-holder order with minimal information because that's how EMRs manage things; don't do this until the image is "available" to viewers (e.g. the EMR browser and launched image viewer) - so maybe the VNA should trigger this?
  • EMR may have a checklist for the Nurse to drive capture during the encounter and the checklist might be smart enough to notify the EMR that data was captured and the images themselves will be available "soon". Could also have a notification from the VNA to confirm availability and "close the loop" and tie to the workflow step earlier.
  • (2) nurse may want to document something as part of a normal/planned step in an encounter so it is almost order-based. EMR knows in advance (maybe only seconds in advance) so proxy order values can be provided/used. This very much helps linking the images to the other artifacts in that encounter. Purpose is known, anatomy is likely known,
  • Then the VNA is finally confirming availability of a known/expected object.

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

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.

Breakdown of tasks

  • Confirm metadata required in the final image object (details of patient, encounter, procedure, pixels)
  • Determine if any CPs needed in DICOM (new attributes or revised descriptions) to hold all the metadata
  • Consider what codesets will be specified by Profile and what is left to deployment (e.g. anatomy/body part, procedure codes, intent)
  • SUNY?
  • Review/revise current Image Store transaction to meet metadata requirements and define the required mappings
  • For PoC US, determine source of each metadata (worklist vs acq device)
  • Review/revise Worklist transaction to provide the required metadata to the device and define the required mappings
  • Review/revise Patient transaction to provide the required metadata to the Encounter Manager
  • May need to create a new HL7 SIU transaction to provide required encounter metadata to the Encounter Manager
  • With that context, look at the same flow with the Camera and the Assembly being in two different actors.
  • Decide if we have time to consider a "push flow" for Record Driven Acquisition (of interest to several participants)
  • Discuss/define the usage of Visit #, Encounter ID, Procedure ID and/or other Enterprise identifiers? (like we did in SWF for Accession #, Study ID, Placer Order, Filler Order)
  • (EMRs didn't grow up in imaging, so they learned it from order-based radiology. EMR GUI/Concepts have adopted radiology concepts but there are still gaps for encounter-based imaging and knitting into the encounter workflow and documentation process in a natural way)(Hard to find the data that has been put in)(People also use the images in a more varied way than in radiology perhaps)(Launching a different viewer for each different data type doesn't scale)(Note this is wider than the medical record itself as other modes of interaction exist)
  • May not address all the consumption/viewing use cases, but to get the metadata right we likely need to catalog and analyze them a bit
  • May need to think through human guidance for metadata collected along the way
  • ER patient identification - the temp id's are very sparsely populated with metadata (male, 50's) - consider those PIR cases here. Any different?
  • TODO rename to Record Driven Acquisition - like "repeat order for current date" since most metadata/context is inherited
  • Need to resolve if there must/could/shouldn't be a mockup order here. Some EMR need the order hook to manage the data group.
  • Might relate to whether its diagnostic or evidentiary (procedure documentation, observation documentation) - See Dr. Roth Whitepaper material
  • Can Encounter be an equivalent hook?
  • 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
  • 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 ...
  • 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.
  • Definitely consider DICOM Worklist for PoC US, but for Use Case 1 might merit a different query-based mechanism to the Quasi-modality (FHIR?)
  • note that the record driven encounter capture might involve working on two different devices (I click on "grab followup image" in my EMR screen, and somehow the camera I pick up is primed now for that capture; conversely I'm using a tablet for EMR and activate the camera - same device)
  • Sub-topics
  • Be clear what IHE will/will not do (e.g. define standard tag/location but not standard procedure codes)
  • 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




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

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.

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.

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.

7. Risks

  • 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

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

Closed Issues

  • 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

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 45%
  • Minimum Useful Effort: 10%

Candidate Editor: Kevin, Kinson?

Retrieved from "http://wiki.ihe.net/index.php?title=Encounter_Based_Imaging_Workflow_-_Proposal&oldid=104088"