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

From IHE Wiki
Jump to navigation Jump to search
 
(118 intermediate revisions by 2 users not shown)
Line 1: Line 1:
__NOTOC__
+
{{TOCright}}
 
==1. Proposed Workitem: Encounter-Based Imaging Workflow (EBIW)==
 
==1. Proposed Workitem: Encounter-Based Imaging Workflow (EBIW)==
  
* Proposal Editor: Kevin O'Donnell
+
* Proposal Editor: Kevin O'Donnell / Kinson Ho
* Proposal Contributors: Elliot Silver, Christopher Roth, Dawn Cram, Alex Towbin, Ken Parsons, Paul Lipton, ...
+
* Proposal Contributors: Elliot Silver, Christopher Roth, Dawn Cram, Alex Towbin, Ken Persons, Paul Lipton, ...
* Editor: TBA
+
* Editor: Kevin O'Donnell / Kinson Ho
* Contributors: Dawn Cram, Christopher Roth, (Alex), Ken, Matt, Paul, (Louis), Elliot, (recruiting some of the acq app vendors and EMRs)
+
* Contributors: See [[Encounter_Based_Imaging_Workflow_-_Proposal#6._Support_.26_Resources|Support & Resources]]
 
* Domain: Radiology
 
* 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.
 +
 +
IHE is a good venue to solve this because many proprietary ad-hoc workflows are emerging/exist but are inconsistent, incomplete and poorly integrated. The need is real. All that is missing is a profile to drive integrated, complete, consistent solutions. As with SWF, an IHE solution could avoid the costs and incompatibilities of the proprietary solutions.
  
 
==2. The Problem==
 
==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]]).
+
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:
 
:* '''Use Cases''' - what are the different ways encounter-based imaging is performed
 
:* '''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)
 
:* '''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)
+
:* '''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
+
:* '''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 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.   
 
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.   
Line 24: Line 39:
 
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.
  
Sites have highlighted EBI related problems like:
+
==3. Key Use Case==
:* 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):
+
* Dermatology
:* Order Placement:
+
* Wound Care/Management
::*Procedure codes are appropriate for some encounter based imaging but an order per se is not necessary (and would disrupt their workflow)
+
* Infectious Diseases
::* 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.
+
* Burn Care
 +
* Plastic Surgery
 +
* Nursing/Clinic Photography
 +
* Point of Care Ultrasound
  
:* Loop Closure
+
===Use Case 1: Imaging with Simple Devices (often non-DICOM at initial point of capture)===
::* 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
+
Many departments capture clinical photos for documentation, follow up care, and diagnostics.
::* 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 devices include digital cameras, smartphones and tablets (using iOS, Android and camera-specific OS).
 
 
:* 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==
+
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.
  
EBI Examples:
+
* Patient makes appointment for Dermatology visit.
:* Dermatology
+
* Patient arrives and is registered/checked in as an outpatient (OP)
:* Wound Care/Management
+
* At the Provider's discretion, clinical photos are taken to document disease processes, pathologies or disorders.
:* Infectious Diseases
+
** Image content may include photos of multiple body parts.
:* Burn Care
+
** Image content may include basic video storage. (Advanced video management like editing and annotation is out of scope)
:* Ophthalmology
+
** Orders are not a required element clinically
:* Otolaryngology
+
* 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.
:* Plastic Surgery
 
:* Podiatry
 
:* ER/Trauma
 
:* Dentistry
 
:* 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===
+
===Use Case 2: Point of Care Ultrasound (DICOM modalities in "Order-less" workflow)===
  
Numerous departments capture clinical photos for documentation, follow up care, and in some cases, diagnostics (such as dermascope or OCT).  
+
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:
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)
+
* '''Inpatient Status Check'''
* images lack a source of metadata so only an image is captured lacking important details like:
+
** A registered inpatient is in their bed in a ward
** patient demographics, visit/encounter details/context, body part examined
+
** An ultrasound is performed to determine the state of the bladder (empty, partial, full), or confirm placement of a PIC line or needle
* 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
+
** Key point: imaging is not "diagnostic" in the sense of radiology but rather evidentiary or for simple assessment
* 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.
+
*** Such an image might still be referred to radiology if something strange was observed.
* 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)
+
* '''Emergency Room Evaluation'''
* cumbersome workflow for clinical care providers
+
** Patient presents in the Emergency Room and is registered with an ER designation (between in-patient and out-patient)
** 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
+
** 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.
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===
+
* '''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.
  
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.  
+
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.
  
There may be some common needs between this and the [[Cardiac Cath Workflow]] profile.
+
[[Encounter-based_Imaging_Workflow#High_Level_Workflow|Supporting Diagrams for the above two use cases]]
  
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:
+
Basically follows the pattern of SWF: Establishing encounter/patient/context, conveying metadata, capturing/storing image data, indexing/archiving images, finding/accessing/using images.  Encounter-based imaging should get the same end result as if the clinician placed the order.  Want to support the same analytics, access/indexing of the 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.
+
'''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.
  
===Use Case 3: Inpatient Imaging===
+
===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.
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==
 
==4. Standards and Systems==
Line 131: Line 109:
 
:* Image Archiving Devices
 
:* Image Archiving Devices
 
:* Electronic Medical Record Systems
 
:* Electronic Medical Record Systems
:* Patient Management Systems?
+
:* Practice Management Systems
 +
:* Encounter Management System (office/departmental system that provides the encounter context)
 +
:* QA System
 +
:* Encounter Imaging Consumer
  
 
Potential Standards
 
Potential Standards
 
:* Existing Profiles: PAM, WIC, SWF, MHD-I, XDS*, CARD IEO
 
:* 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
:* FHIR
+
 
:* Consumer formats: JPEG, MPEG, PDF, 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-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-9899-4 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. 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.
 +
 
 +
'''Existing actors'''
 +
* Reuse several from SWF.b, PAM, etc.
 +
:* ADT, Modality (Encounter-oriented DICOM capable)
 +
 
 +
'''New actors''' (names provisional)
 +
* Encounter Manager
 +
:* manages and provides encounter metadata and marshaled patient demographics
 +
* Image Capture (non-DICOM capable)
 +
:* might be dropped if no real requirements and Quasi-Modality does all the work
 +
* Quasi-Modality
 +
:* assembles pixels from a Capture Actor with worklist metadata and perhaps operator input
 +
 
 +
'''Existing transactions'''
 +
* Will reuse or clone several from SWF.b, PAM, etc. for storage, patient registration, etc. (see below)
 +
:* See also Cardiology, Pathology etc as source of transactions or transaction text.
 +
 
 +
'''New transactions (standards used)'''
 +
* [[Encounter-based_Imaging_Workflow#High_Level_Workflow | Working diagrams]]
 +
* Clone/revise existing transactions to minimize risk and cost
 +
:* Manage Encounter (e.g. based on Patient Encounter Management ITI-31)
 +
::* Create "Placeholder" Order?
 +
:* Query Encounter Worklist (e.g. based on Query Modality Worklist)
 +
:* Store Images (e.g. based on Store Images)
 +
:* Store Documents (e.g. based on existing document storage)
 +
* Truly new transactions?
 +
:* Notify Procedure Results?
 +
 
 +
* TODO - note in diagram that Quasi-modality may have 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 (it's not called out in SWF. You do it but it's as you like)
 +
* TODO rename to Record Driven Acquisition - like "repeat order for current date" since most metadata/context is inherited
 +
 
 +
===Breakdown of tasks===
 +
 
 +
'''Scope Management''': This proposal will not address all challenges related to encounter-based imaging workflow, rather it will:
 +
:* Address two key use cases
 +
:* Define the minimal necessary set of metadata (related to the patient, encounter, procedure, and pixels)
 +
:* Identify the source(s) of each piece of metadata
 +
:* Define how those are aggregated and combined with the pixels
 +
:* Notify the EMR when study becomes available
 +
:* Consider basic clinical usage of the images, but defer complex downstream activities
 +
 
 +
'''Steps:'''
 +
* '''Confirm metadata''' required in the final image object (details of patient, encounter, procedure, pixels)
 +
:* Consider what codesets will be specified by Profile and what is left to deployment (e.g. anatomy/body part, procedure codes, intent) SUNY?
 +
::* Will not get into standardizing codes on behalf of clinical specialties
 +
:* Won't profile all the consumption/search/viewing use cases, but to get the metadata right we likely need to catalog and analyze them a bit
 +
::* e.g. how to find desired images? how to categorize them for use/management? how to rank them for relevance?
 +
:* Consider metadata for linking to other results: e.g. surgical report, accession #s for other ordered procedures
 +
::* i.e. how are encounter images woven into clinical notes/clinical record/documentation workflow
 +
* '''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 (DICOM CP1736 is addressing EXIF mapping details)
 +
:* If needed, CP DICOM (new attributes or revised descriptions, new/revised CIDs) to hold all the metadata
 +
* Review/'''revise current Image Store transaction''' to meet metadata requirements and define the required mappings
 +
* For PoC US Case, determine source of each metadata (worklist vs acq device)
 +
:* Consider source/quality for populating key tags (Body part!)
 +
* Review/'''revise Worklist transaction''' to provide the required metadata to the device and define the required worklist-to-image mappings
 +
* Review/'''revise Patient ADT or PDQ transaction''' to provide the required metadata to the Encounter Manager
 +
:* Consider what assumptions we make about the likely environment, or presence of other actors like "PDQ Supplier"
 +
* '''Create? HL7 SIU transaction''' to provide required encounter metadata to the Encounter Manager
 +
:* Planned Case : Provider uses image to document something as a normal/planned step in an encounter (e.g. part of checklist) so it is almost order-based. EMR can expect it so proxy order values could be provided/used. These help linking images to the other artifacts in that encounter.  Purpose is known, anatomy is likely known.
 +
:* Ad Hoc Case : "out of the blue", no order, no expectation. EMR would still like to create a place-holder order internally with minimal information because that's how EMRs manage things but still needs availability notification (see below)
 +
* For Simple Camera Case, look at the same flow with the Camera and the Assembly being in two different actors.
 +
* 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)
 +
* 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?
 +
* '''Consider Notification to EMR''' of new Procedure Results
 +
:* EMR needs to know when it is safe to launch a viewer pointed at the acquired image, so availability notification from the VNA/PACS matters.  Otherwise the EMR has to poll/probe
 +
:* EMR may also want notification from PoC that data was captured and the images themselves will be available "soon".
 +
 
 +
 
 +
Bonus work:
 +
* Consider a "push flow" for Record Driven Acquisition (of interest to several participants)
 +
* 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"
 +
* Diagram Diagnostic Imaging, Procedural Imaging and Evidence Imaging
 +
:* Delineate EBI vs Enterprise Imaging vs mobile vs consumer vs lightweight vs web APIs vs ...
 +
* Consider a FHIR PDQm/WIC variant for the Simple Camera?
 +
:* record driven acquisition might involve 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) or one device/client (I'm using a tablet for EMR and activate the built in camera)
 +
 
 +
==6. Support & Resources==
 +
The SIIM-HIMSS Enterprise Imaging group and ad hoc EBIW IHE SIG has already coalesced a number of collaborators, many of whom have helped on the proposal and are interested in working on the profile.
 +
 
 +
* '''Healthcare''': Chris Roth (Duke), Dawn Cram (Ochsner), 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.
 +
 
 +
==7. Risks==
 +
 
 +
* '''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
 +
 
 +
* '''Niche risk''' - solving an instance of the problem instead of the broad class
 +
:* Reach out to IHE (imaging) - Eyecare, Cardiology, Pathology, Endoscopy, PCD (patient identification for encounter-based workflow) - '''Cochair Action Item'''
 +
:* Historically they have successfully borrowed heavily from IHE Rad work and engaged domain vendors.
 +
:* Their experience/advice will be important.  Specifically, they understand their domain details.
 +
:* focus on general metadata, not device/specialty specific, but allow extension from specialty specific code (e.g. dermatology anatomy codes)
 +
 
 +
* 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?)
  
==5. Discussion==
+
* 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
  
'''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.
+
==8. Open Issues==
  
:More analysis here: [http://link.springer.com/article/10.1007/s10278-016-9888-7 Order-based vs Encounter-based Imaging - JDI Whitepaper]
+
* Possible order-based approach
:And here: [http://link.springer.com/article/10.1007/s10278-016-9897-6 The Workflow Challenges of Enterprise Imaging ]
+
** Arrival/Registration of the patient triggers an HL7 ADT^A04 containing visit information
 +
** DICOM MWL SCP generates an encounter worklist entry based on the HL7 ADT^A04
 +
** Capture device (DICOM MWL SCU) queries the worklist and uses Patient/Visit rather than Patient/SPS/Service Request to populate the images
 +
*** PatientID (0010,0020) and PatientName (0010,0010) populated as usual
 +
*** Accession number (0008,0050) will/may be blank or null
 +
*** Visit/encounter number (admission ID (0038,0010))
 +
*** 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?
 +
*** Scheduled Procedure Step Sequence (0040,0100) must not be empty
 +
*** Scheduled Procedure Step Description (0040,0007) best known at PoC (e.g. body part/region/etc selection also used in series and/or study description)
 +
*** 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
  
:Technical approach thoughts
+
'''Other Considerations'''
:: Perhaps new EBIW profile that parallels SWF
+
* EMR Imaging GUI/Concepts were adopted from (order-based) radiology. There are still gaps for encounter-based imaging and knitting into the encounter workflow and documentation process in a natural way. It's hard to find data that has been put into the patient record.  Encounter images are used in more varied ways (in the EMR and beyond the EMR) than radiology perhaps. Launching a different viewer for each different data type doesn't scale.
:: Perhaps expand WIC?
+
* May need to think through human guidance for metadata collected along the way
:: Should this be multiple profiles - e.g. EBIW + WIC + Documentation WF and maybe something where SWF & EBIW meet
+
* ER patient identification - the temp id's are very sparsely populated with metadata (male, 50's) - consider those PIR cases here. Any different?
:: 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?
+
'''Closed Issues'''
:: 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.
+
* How are final images encoded? in DICOM - CLOSED
 +
:* Expect to support both STOW-RS and C-STORE (both transactions already exist) - CLOSED
  
:This goes beyond the definition of Radiology, however RAD profiles have provided a basis for other imaging domains
+
* 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
:: 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 - '''[http://siim.org/page/himss_siim_white_pap White Papers]'''
 
  
:Should the scope include "self-captured" data from patients at home or remote?
+
* 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
  
: Review of DICOM Tags and semantics in the context of EBI
+
* 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
  
: Do we assume the acq apps follow the profile in detail or does the VNA do most of the work
+
* 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
  
:Continue to delineate EBI vs Enterprise Imaging vs mobile vs consumer vs lightweight vs web APIs vs ...
+
* Issue: Bias toward older (DICOM/HL7) '''VS''' newer (DICOMweb/FHIR) technologies? Focus on HL7 v2 + DICOM + DICOMweb for this profile - CLOSED
  
:Consider categorization into Diagnostic Imaging, Procedural Imaging, and Evidence Imaging (document current patient state)
+
* Issue: Should the scope include "self-captured" data from patients at home or remote? Deferred, focus on workflow within hospitals - CLOSED
:: [http://link.springer.com/article/10.1007/s10278-016-9882-0 A Foundation for Enterprise Imaging - JDI Whitepaper]
 
  
===Technical Approach Ideas===
+
==9. Tech Cmte Evaluation==
One Proposed solution involves:
+
Technical Evaluation
* 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
+
:* No significant technical issues seen. Plan is to use minor variations of known/deployed standards.
* 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.
 
  
==See Also==
+
Effort Evaluation (as a % of Tech Cmte Bandwidth):
 +
:* 40%
 +
:* Minimum Useful Effort: 25%
 +
::* Single Use Case (whichever one seems simpler)
  
[[Internet-Ready_SWF_-_Proposal]] started to consider encounter-based imaging as well.
+
Candidate Editor: Kevin, Kinson?

Latest revision as of 12:32, 21 September 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

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.

IHE is a good venue to solve this because many proprietary ad-hoc workflows are emerging/exist but are inconsistent, incomplete and poorly integrated. The need is real. All that is missing is a profile to drive integrated, complete, consistent solutions. As with SWF, an IHE solution could avoid the costs and incompatibilities of the proprietary solutions.

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


Basically follows the pattern of SWF: Establishing encounter/patient/context, conveying metadata, capturing/storing image data, indexing/archiving images, finding/accessing/using images. Encounter-based imaging should get the same end result as if the clinician placed the order. Want to support the same analytics, access/indexing of the imaging.

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.

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.

Existing actors

  • Reuse several from SWF.b, PAM, etc.
  • ADT, Modality (Encounter-oriented DICOM capable)

New actors (names provisional)

  • Encounter Manager
  • manages and provides encounter metadata and marshaled patient demographics
  • Image Capture (non-DICOM capable)
  • might be dropped if no real requirements and Quasi-Modality does all the work
  • Quasi-Modality
  • assembles pixels from a Capture Actor with worklist metadata and perhaps operator input

Existing transactions

  • Will reuse or clone several from SWF.b, PAM, etc. for storage, patient registration, etc. (see below)
  • See also Cardiology, Pathology etc as source of transactions or transaction text.

New transactions (standards used)

  • Manage Encounter (e.g. based on Patient Encounter Management ITI-31)
  • Create "Placeholder" Order?
  • Query Encounter Worklist (e.g. based on Query Modality Worklist)
  • Store Images (e.g. based on Store Images)
  • Store Documents (e.g. based on existing document storage)
  • Truly new transactions?
  • Notify Procedure Results?
  • TODO - note in diagram that Quasi-modality may have 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 (it's not called out in SWF. You do it but it's as you like)
  • TODO rename to Record Driven Acquisition - like "repeat order for current date" since most metadata/context is inherited

Breakdown of tasks

Scope Management: This proposal will not address all challenges related to encounter-based imaging workflow, rather it will:

  • Address two key use cases
  • Define the minimal necessary set of metadata (related to the patient, encounter, procedure, and pixels)
  • Identify the source(s) of each piece of metadata
  • Define how those are aggregated and combined with the pixels
  • Notify the EMR when study becomes available
  • Consider basic clinical usage of the images, but defer complex downstream activities

Steps:

  • Confirm metadata required in the final image object (details of patient, encounter, procedure, pixels)
  • Consider what codesets will be specified by Profile and what is left to deployment (e.g. anatomy/body part, procedure codes, intent) SUNY?
  • Will not get into standardizing codes on behalf of clinical specialties
  • Won't profile all the consumption/search/viewing use cases, but to get the metadata right we likely need to catalog and analyze them a bit
  • e.g. how to find desired images? how to categorize them for use/management? how to rank them for relevance?
  • Consider metadata for linking to other results: e.g. surgical report, accession #s for other ordered procedures
  • i.e. how are encounter images woven into clinical notes/clinical record/documentation workflow
  • 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 (DICOM CP1736 is addressing EXIF mapping details)
  • If needed, CP DICOM (new attributes or revised descriptions, new/revised CIDs) to hold all the metadata
  • Review/revise current Image Store transaction to meet metadata requirements and define the required mappings
  • For PoC US Case, determine source of each metadata (worklist vs acq device)
  • Consider source/quality for populating key tags (Body part!)
  • Review/revise Worklist transaction to provide the required metadata to the device and define the required worklist-to-image mappings
  • Review/revise Patient ADT or PDQ transaction to provide the required metadata to the Encounter Manager
  • Consider what assumptions we make about the likely environment, or presence of other actors like "PDQ Supplier"
  • Create? HL7 SIU transaction to provide required encounter metadata to the Encounter Manager
  • Planned Case : Provider uses image to document something as a normal/planned step in an encounter (e.g. part of checklist) so it is almost order-based. EMR can expect it so proxy order values could be provided/used. These help linking images to the other artifacts in that encounter. Purpose is known, anatomy is likely known.
  • Ad Hoc Case : "out of the blue", no order, no expectation. EMR would still like to create a place-holder order internally with minimal information because that's how EMRs manage things but still needs availability notification (see below)
  • For Simple Camera Case, look at the same flow with the Camera and the Assembly being in two different actors.
  • 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)
  • 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?
  • Consider Notification to EMR of new Procedure Results
  • EMR needs to know when it is safe to launch a viewer pointed at the acquired image, so availability notification from the VNA/PACS matters. Otherwise the EMR has to poll/probe
  • EMR may also want notification from PoC that data was captured and the images themselves will be available "soon".


Bonus work:

  • Consider a "push flow" for Record Driven Acquisition (of interest to several participants)
  • 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"
  • Diagram Diagnostic Imaging, Procedural Imaging and Evidence Imaging
  • Delineate EBI vs Enterprise Imaging vs mobile vs consumer vs lightweight vs web APIs vs ...
  • Consider a FHIR PDQm/WIC variant for the Simple Camera?
  • record driven acquisition might involve 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) or one device/client (I'm using a tablet for EMR and activate the built in camera)

6. Support & Resources

The SIIM-HIMSS Enterprise Imaging group and ad hoc EBIW IHE SIG has already coalesced a number of collaborators, many of whom have helped on the proposal and are interested in working on the profile.

  • Healthcare: Chris Roth (Duke), Dawn Cram (Ochsner), 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.

7. Risks

  • 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
  • Niche risk - solving an instance of the problem instead of the broad class
  • Reach out to IHE (imaging) - Eyecare, Cardiology, Pathology, Endoscopy, PCD (patient identification for encounter-based workflow) - Cochair Action Item
  • Historically they have successfully borrowed heavily from IHE Rad work and engaged domain vendors.
  • Their experience/advice will be important. Specifically, they understand their domain details.
  • focus on general metadata, not device/specialty specific, but allow extension from specialty specific code (e.g. dermatology anatomy codes)
  • 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

  • Possible order-based approach
    • Arrival/Registration of the patient triggers an HL7 ADT^A04 containing visit information
    • DICOM MWL SCP generates an encounter worklist entry based on the HL7 ADT^A04
    • Capture device (DICOM MWL SCU) queries the worklist and uses Patient/Visit rather than Patient/SPS/Service Request to populate the images
      • PatientID (0010,0020) and PatientName (0010,0010) populated as usual
      • Accession number (0008,0050) will/may be blank or null
      • Visit/encounter number (admission ID (0038,0010))
      • 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?
      • Scheduled Procedure Step Sequence (0040,0100) must not be empty
      • Scheduled Procedure Step Description (0040,0007) best known at PoC (e.g. body part/region/etc selection also used in series and/or study description)
      • 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

Other Considerations

  • EMR Imaging GUI/Concepts were adopted from (order-based) radiology. There are still gaps for encounter-based imaging and knitting into the encounter workflow and documentation process in a natural way. It's hard to find data that has been put into the patient record. Encounter images are used in more varied ways (in the EMR and beyond the EMR) than radiology perhaps. Launching a different viewer for each different data type doesn't scale.
  • 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?

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

Technical Evaluation

  • No significant technical issues seen. Plan is to use minor variations of known/deployed standards.

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

  • 40%
  • Minimum Useful Effort: 25%
  • Single Use Case (whichever one seems simpler)

Candidate Editor: Kevin, Kinson?