Radiology Image Sharing Roadmap
Sharing Images is a fundamental part of "Integrating Radiology".
Many Profiles already address Image Sharing Use Cases.
Additional Gaps need to be addressed by profiling Available Standards.
To structure the analysis we should consider Aspects of Image Sharing such as:
Our goal is enough profiles to address the needs while avoiding profiles that duplicate functions in incompatible ways.
<<Might also be instructive to write up the Life Cycle of an image from acquisition, QA, reading, circulation, archiving/retention, etc granting that the order can be a bit fluid, there are implications in terms of changeability, existence of cross-references, etc.>>
<<Do we want to talk about Architectural Use Cases as well?>>
Use Cases
This is what are we trying to accomplish.
<<Isn't this really just a list of all the cases that are true for patient data in general. And access control/consent/etc is the current issue with those. In any case we shouldn't be different. Consider the access credentials being provisioned from the ITI world, then use appropriate mechanisms to disseminate the (large) dataset. E.g. implement credentials using web services/grid services (almost off-the-shelf), but consider most efficient bulk transfers.>>
<<Should we list the authorization/consent capabilities in each use case or consider it as an orthogonal issue?>>
"In-house" Reading of Images
(SWF) A radiologist reads images of a patient scanned at their facility (either as an in-patient or out-patient) in order to generate a report with findings.
Routine imaging referral
(XDS-I)(PDI) A referring physician sends a patient for an exam at an imaging facility. The physician needs prompt access to the resulting imaging report and often to key images or the entire study. The images also can be useful for explaining the situation and treatment options to the patient.
Course of Treatment Consult
(XDS-I) An emergency physician orders an imaging examination for a patient at his hospital. After reviewing the preliminary report the ER physician decides to consult a surgical specialist at the regional hospital for advice on a course of action. For this, the surgical specialist accesses the images and preliminary report and reviews them in order to propose, on the phone, a course of action for the patient.
Clinical Consult
(XDS-I) A general practitioner performs a routine imaging referral, reviews the imaging report and chooses to send the patient for evaluation by a specialist (e.g. an oncologist). The specialist needs access to both the imaging report and full image set. In some cases the specialist may wish to do specialized processing/viewing of the images.
General imaging record access
(XDS-I) A patient relocates or decides to change her physician. The new physician needs to retrieve relevant information from the patient record, review its content, including recent labs and imaging studies. A similar situation occurs when a patient is admitted for an emergency and timely access to the patient’s past information is required, including prior imaging studies.
Patient/Referring Physician Viewing
(PDI) Diagnostic and therapeutic imaging data, such as images and reports, is received on media potentially serving multiple use cases. The patient or the referring physician can view the data, either with a viewer application residing on the same media or using a web browser. This data is not necessarily intended as a basis for diagnostic or therapeutic processes, and may just be informative data. For security and privacy reasons, media given to a patient would not contain data of other patients.
Healthcare Enterprise Interchange
(PDI) One or more patients’ data, such as images, reports or complete studies, is received on media to enable a diagnostic or therapeutic care process. Media data are imported at a different site, generally for the purpose of a “second read import” or “reference import”.
Second Read Import
(IRWF) Media data is imported to the Image Manager/Archive to be read/over read. In order to avoid data conflicts, key patient/study attributes may need to be reconciled with existing local data. Images and related presentation states can be sent to a Print Composer to be printed.
Reference Import
(IRWF) Media data is imported to the Image Manager/Archive and/or Report Repository to become part of the patient history. It may be used as “relevant prior” data for future reads. In order to avoid data conflicts, key patient/study attributes may need to be reconciled with existing local data.
Operating Room Viewing
(PDI) Media data is used to enable diagnostic or therapeutic processes in environments without a reliable network connection. The volume of data can be very large and may contain image data, post-processing results and reports. In the operating room, the surgical staff receives the media and reads its contents using advanced viewing capabilities, which may include manipulating or processing images.
Gaps
These are Observed Needs/Failures in the current Image Sharing landscape.
Think of Image Consumers who are being poorly served by the current infrastructure. What is a critical need they have which is unacceptably difficult?
Referring Docs: View current images quickly/conveniently
- AMA policy statement on problems with viewing images from removable media; PDI addresses transport needs, though not universally deployed.
- Consider image access via EHR system.
- Provide different presentations of same data or provide different data to meet viewing capabilities of EHR.
- Requirements vary depending on physician role
Specialists: Process current images on specialty applications
- (eg, surgeons)
Maintain/Access a longitudinal record of Imaging Studies
- Patient or provider view with patient focus of longitudinal record of imaging studies
- Avoid duplicate studies; historicals available for review and comparison
- Patient mobility requires transfer of studies
- Provide data to PHR systems or accounts
Distributed workflow
- Imagine acquisition, reading and referring are at three different sites
- Need to address the case when sites are not on the same local network
- Consider policy and administration issues (eg, ID domains)
PACS Administrators: Migrate PACS Data
- Migration of large amounts of image data from one PACS to another is currently slow, awkward, and difficult
- <describe the various coercions and data alignments required>
- Should only be considered in the sense of a bulk synchronization
"Federate"/Coordinate multiple PACS in an Organisation
- Synchronization of updates and deletes is an issue
- Delete needs to address both delete of bad data and delete of past-holding-period data
- Consider offering "last chance to copy" or transfer of ownership
- Need to manage primarily at study level rather than image instance level
See/Use relationships between images/series/studies
- Data Relationships - don't provide a good map of how data elements fit together
- Between images/series/studies
- Prior relationships
- Stress-rest images
- Cancer staging
- Pre- and post-surgical
- Radiology report and image studies
- Non-radiology reports (eg, lab, path)
- Between images/series/studies
<<Where should we get into the managed release of access/awareness? After the report is available, they might want to only release it to the oncologist who is going to discuss it with the patient initially?>>
Profiles
See Aspects of Image Sharing (below) for descriptions of Notification, Selection, Access, etc.
| Profile | Awareness | Selection | Access | Update | Transport |
|---|---|---|---|---|---|
| "Local" Network | |||||
| SWF (Mod-PACS) | Sink (C-Store) | Keep | Sink (C-Store) | PIR | |
| SWF (PACS-Disp) | Query (C-Find) | Query (C-Find) | Pull (C-Store) | none | |
| ARI | Query? | Query (C-Find) | Pull (C-Store) | none | |
| TCE (PACS-Dest) | Sink (KIN Tag) | Keep-or-Toss | Sink (C-Store) | none | |
| MAWF | |||||
| Sneakernet | |||||
| PDI/IRWF | Sink | Keep-or-Toss | Sink (CD) | none | |
| "Distributed" Network | |||||
| XDS-I Retrieval (Consumer-Registry-Repository-Source) | Query (SOAP) | Query | Pull (C-Store/WADO) | none | |
| XDS-I Submission (Source-Repository-Registry) | Sink (SOAP) | Keep | Sink (SOAP) | re-publish manifest | |
| Proposed Additions | |||||
| XDS-I.b | Query (MTOM) | Query | Pull (C-Store/WADO) | none | |
| PDI+ | Sink | Keep-or-Toss | Sink (CD/DVD/USB) | none | |
| XCA-I | ? | ? | ? | ? | |
| Image Management | ? | ? | ? | Delete/Update/Replace | |
| Federated Storage | ? | ? | ? | ? | |
| Notification of Doc Availability (NAV) | ? | ? | ? | ? | |
<<Need to add a column for security issues?>
<<Maybe add a column with links up to the Use Cases addressed by the profile>>
- Other Referencing
- KIN
- CPI, PGP
- Image Fusion
Aspects of Image Sharing
Image Sharing should address Awareness, Selection, Access, Update and Transport of image data.
There are different viable approaches to each of those aspects of sharing.
Different approaches have advantages and disadvantages for a given use case depending on many factors such as expected network bandwidth, local storage capacity, image persistence times, stability/changeability of images, immediacy of access needs, quality of image metadata, dependence on new software/systems, configuration/maintenance overhead, security needs, privacy needs, etc., etc., etc.
In some scenarios there may be one or more intermediary systems between the "source" and "consumer" of the images. This may introduce additional issues, for example: synchronization, performance. It may also result in different approaches being used for different parts of the same use case.
Awareness
Knowing there are images that might be of use.
- Sink Approach - depend on systems to push potentially useful images.
- Notification Approach - depend on systems to tell you about the existence of potentially useful images.
- Query Approach - ask systems what images are available
- Subscribe Approach - sort of a cross between Query and Notification
Patient consent is a consideration with Awareness, possibly as a precondition/gatekeeper. Patient consent process may influence ease of implementation of approaches above.
Note: A worklist (reading) is commonly used to make systems/users aware of relevant images.
Selection
Choosing images to make use of.
- Query Approach - evaluate/select based on image details returned in the query
- Sink Approach - see above; trust other system to have selected appropriately
- Notification Approach - see above; select based on image details provided in the notification
- Keep-or-Toss Approach - get all potential images, evaluate directly and toss unneeded ones
Access
Getting the images.
- Sink Approach - see above
- Pre-caching is one form of Sink.
- Pull Approach - retrieve selected images
Getting the rendering.
- Streaming Approach - rather than sending images, images are rendered at origin and rendering is conveyed (eg, Web client)
Update
How you know about updates to images you have copies of.
- Ignorance/Blind Apathy Approach - No awareness of updates.
- Polling Approach - Requery or re-retrieve images to check for changes.
- Notification Approach - Receive notification that "something" is different. Granularity could vary.
- Delta Approach - Receive list of differences.
- New Copy?
Transport
How the images are conveyed
- Network vs Media
- Synchronous vs Asynchronous
- Whole vs Incremental
Should consider how Transport applies to each of the above Aspects.
Available Standards
What do we have to work with?
DICOM Mechanisms
- C-Store
- push across a typical network
- Retrieve
- pull across a network, basically a C-Store invoked by the receiver
- Part 10 - Files
- almost by definition push, asynchronous
- profiled for a large variety of media: CD, DVD, USB, ZIP, Email, FTP
- with/without compression
- includes a MIME type
- Supplement 119 - Instance and Frame Level Retrieve
- Part 18 - WADO - Web Access to Persistent DICOM Objects
- HTTP based pull across the web
- WG-10 Web Services
- NADO - Notification of Availability of DICOM Objects
- QIDO - Query by ID for DICOM Objects
- Supplement 118 - Application Hosting
- includes mechanisms for accessing objects
- File based or abstract model
- (DICOM Print)
- Push to hardcopy