Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The following requirements help frame the need for standardization to support Foreign Exam Management.  They assume integration between local RIS / PACS and a shared DI-R already existsuse cases outlined below are intended to provide additional context and frame the needs that candidate standards must meet. The use cases here are summarized and excerpted from a discussion document of the Canada Health Infoway Immunization Interoperability Working Group[1].

Panel
titleTable of Contents

Table of Contents
indent20px
stylecircle

UC-1 Workflow

The focus of FEM use cases is acquisition (“fetching”) of relevant foreign exams for display and use by health care providers during the course of a current patient encounter.  Image sets can be very large and therefore the ability to “pre-fetch” images before they are required for viewing is desired to improve user productivity. 

These use cases do not make any assumptions about the setting in which care is being delivered (e.g. primary care physician’s office, mobile immunization clinic, hospital, etc.) or the means by which providers record the information (e.g. desktop EMR software, mobile device, tablet, etc.).  It is preferred that candidate standards should, where possible, help to support and enable the delivery of care in any setting, and the viewing or recording of immunization data on any device.

UC-1 View Immunization History (No Forecast)

A provider reviews a patient’s immunization history for a purpose other than determining which vaccines a patient requires, examples:

    • History is required for proof of immunizations (i.e. to print a ‘Yellow Card’) or to determine immunity for differential diagnosis
    • Some applications may require that only a subset of vaccination history be returned/displayed (e.g. masking as a result of consent directives)

A patient views their own immunization history via a personal health record application

UC-2 View Immunization History (With Forecast)

A provider reviews a patient’s immunization history with a view to determining which vaccines the patient currently requires

  • Once again, some applications may require that only a subset of vaccination history be returned/displayed  (e.g. masking as a result of consent directives)

A patient views their own immunization history via a personal health record application, and wishes to know which vaccines they currently require

UC-3 Administer Immunization and Record Event

A provider administers an immunization to a patient and records the immunization

  • The record will likely include information regarding the provider who administered the immunization and the location
  • Some applications may require the ability to record informed consent

A patient records and immunization that was administered to them in a personal health record application

UC-4 Record Immunization History

A provider records one or more past immunization events as part of a history taking

  • The record will likely include information regarding the provider who administered the immunization and the location

A patient records one or more past immunizations using a personal health record application

UC-5 Update Existing Immunization Record

A provider updates or changes an existing record of an immunization

A patient updates or changes an existing record of an immunization using a personal health record application

The information captured would be very similar to Administer Immunization and Record Event or Record Immunization History

The XDS Affinity Domain Implementation Guide identifies a number of use cases which are summarized here:

UC-1.1 Pre-Fetching

    • Patient related events at the local facility trigger an automatic search for relevant prior exams on the DI-R:
      • Basic example: request related prior images when an exam is ordered, initiate query on patient arrival to radiology,
      • Non-radiology example: patient arrival at clinic (e.g. oncology, neurology) triggers search for relevant exams, or
      • Report only example: similar to examples above but return reports only.
    • Relevant image sets and reports are automatically retrieved and brought in to the local hospital system for review.
    • Information retrieved should not be archived locally as it remains available from the DIR.

UC-1.2 Ad-Hoc or On-Demand Image Fetch

    • A user at the local facility manually initiates a query to find existing relevant prior images for a specified patient and selects image sets of interest from a list of results.
    • Relevant image sets and reports are retrieved and brought in to the local hospital system for review.
    • Information retrieved should not be archived locally as it remains available from the DIR.

UC-1.3 Amendments

    • Identifies steps to replace foreign report when a report is amended after pre-fetch.
    • Identifies steps to replace an image set when an image is added or changed after pre-fetch.

UC-1.4 Emergency Patients

    • Identifies options to use DI-R / FEM to improve workflow when patient arrives at hospital via ambulance.

UC-2 Identification of Relevant Prior Exams

Fetching or pre-fetching of relevant information requires consistent use of metadata to determine relevance.

  • Identifiers used to specify the acquisition modality and anatomic region of the study need to be standardized.

UC-3 Retention of Foreign Information

Foreign content should be identifiable within local systems and should not be archived or retained long term.