Difference between revisions of "Radiology Image Sharing Roadmap"
Jump to navigation
Jump to search
| Line 208: | Line 208: | ||
===Scenarios/Use Cases=== | ===Scenarios/Use Cases=== | ||
| − | The following use case summaries | + | ====XDS-I Use Cases==== |
| + | The following use case summaries are taken from the XDS-I profile. | ||
# '''Routine imaging referral.''' The referring physician in his office requests that a patient have an examination done at an imaging facility. The physician expects to have electronic access to the imaging report and to the images if needed after the examination has been performed on his patient. | # '''Routine imaging referral.''' The referring physician in his office requests that a patient have an examination done at an imaging facility. The physician expects to have electronic access to the imaging report and to the images if needed after the examination has been performed on his patient. | ||
# '''Course of Treatment Consult.''' 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. | # '''Course of Treatment Consult.''' 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.''' A general practitioner performs a routine imaging referral, reviews the shared imaging report and chooses to send the patient for evaluation by a specialist (e.g. an oncologist). The specialist needs access to the imaging report and full image set produced at the imaging facility where the patient had been sent by his general practitioner to perform the examination. | # '''Clinical Consult.''' A general practitioner performs a routine imaging referral, reviews the shared imaging report and chooses to send the patient for evaluation by a specialist (e.g. an oncologist). The specialist needs access to the imaging report and full image set produced at the imaging facility where the patient had been sent by his general practitioner to perform the examination. | ||
# '''General imaging record access.''' 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. | # '''General imaging record access.''' 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. | ||
| + | ====PDI Use Cases==== | ||
| + | The following use case summaries are taken from the PDI profile | ||
| + | # '''Use Case 1 - Patient/Referring Physician Viewing:''' 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. Refer to section 15.5 for additional security considerations. | ||
| + | # '''Use Case 2 - Healthcare Enterprise Interchange:''' 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:''' 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:''' 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. | ||
| + | # '''Use Case 3 - Operating Room Viewing:''' 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. | ||
===Observed Needs/Failures=== | ===Observed Needs/Failures=== | ||
Revision as of 08:35, 17 October 2008
Basically we should identify:
- the use cases we think we need to support
- the current tools we have
We can then see
- the gaps (missing tools) we should develop
- the overlaps (redundant tools) we should retire (hopefully none)
The Aspects of Image Sharing is an attempt to think about the key pieces in the use cases that are addressed by the tools.
<WARNING: Half-baked sketch follows>
Aspects of Image Sharing
Image Sharing should address Awareness, Selection and Access of image data.
There are different viable approaches to each of those three aspects of sharing.
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
Selection
Choosing images to make use of.
- Query Approach - evaluate/select based on image details returned in the query
- Notification Approach - see above; trust other system to have selected appropriately
- Keep-or-Toss Approach - get all potential images, evaluate directly and toss unneeded ones
Access
Getting the images.
- Sink Approach - see above
- Pull Approach - retrieve selected images
Update
How you know about updates to images you have copies of.
- Notification Approach
- New Copy?
Transport
How the images are conveyed
- Network vs Media
- Synchronous vs Asynchronous
- Whole vs Incremental
Different approaches have advantages and disadvantages depending on many factors such as network bandwidth, local storage capacity, image persistence times, immediacy of access needs, quality of image metadata, dependence on new software/systems, configuration/maintenance overhead, security needs, privacy needs, etc., etc., etc.
Do we need to elabourate whether access is direct from the source, or indirect through an intermediary (sync issues)?
Do we need to elabourate whether access is synchronous/immediate, or asynchronous/delayed?
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
Current Image Sharing Profiles
| Profile | Notification | 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 | ? | ? | ? | ? | |
- Other Referencing
- KIN
- CPI, PGP
- Image Fusion
What are we trying to accomplish
Scenarios/Use Cases
XDS-I Use Cases
The following use case summaries are taken from the XDS-I profile.
- Routine imaging referral. The referring physician in his office requests that a patient have an examination done at an imaging facility. The physician expects to have electronic access to the imaging report and to the images if needed after the examination has been performed on his patient.
- Course of Treatment Consult. 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. A general practitioner performs a routine imaging referral, reviews the shared imaging report and chooses to send the patient for evaluation by a specialist (e.g. an oncologist). The specialist needs access to the imaging report and full image set produced at the imaging facility where the patient had been sent by his general practitioner to perform the examination.
- General imaging record access. 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.
PDI Use Cases
The following use case summaries are taken from the PDI profile
- Use Case 1 - Patient/Referring Physician Viewing: 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. Refer to section 15.5 for additional security considerations.
- Use Case 2 - Healthcare Enterprise Interchange: 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: 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: 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.
- Use Case 3 - Operating Room Viewing: 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.