Page History

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 exists.use 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].

For a detailed use case list and required business rules please visit the Business Requirements space:

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.).  Although some references to software applications are specific, the preferred candidate standards should, where possible, support and enable the delivery of care in any setting, and the viewing or recording of immunization data on different hardware devices.

UC-1 Patient or Delegate Retrieves Immunization History (Yellow Card)

A user, typically a parent with a school age child, retrieves a patient's immunization history form the Immunization Connect Ontario (ICON) online or mobile application.

• User enters a patient's Ontario Immunization ID and PIN to request proof of immunization (Yellow Card) from ICON. 
• ICON (and related services):
  • authenticates request, 
  • queries panorama to retrieve patient immunization history, and
  • displays yellow card to user to print or download.

UC-2 Patient or Delegate Records Immunization History

A user, typically a parent with a school age child, enters a patient's immunization history into the Immunization Connect Ontario (ICON) online or mobile application.

• User enters information into ICON:
  • Identifying information about self (submitter),
  • Identifying information about patient, and
  • Information about one or more immunizations.
• ICON (and related services):
  • authenticates request, 
  • stores information for validation by Public Health.
• Health care provider or Public Health reviews and validates information in ICON and submits information to Panorama.  (Alternate flow on UC-4?)

UC-3 Health Care Provider Retrieves Immunization History

A health care provider retrieves a patient's immunization history using a clinical viewer, EMR or mobile application.

• User logs in to application, looks up patient and requests immunization history. 
• Application (and related services):
  • authenticates user using ONEID
  • queries panorama to retrieve patient immunization history, and
  • displays immunization history.

UC-4 Health Care Provider Records Immunization Event(s)

A health care provider enters information about a new immunization event using a clinical viewer, EMR or mobile application.

• User logs in to application, looks up patient and enters information about one or more immunization events. 
• Application (and related services):
  • authenticates user using ONEID, and
  • stores information about immunization event in Panorama.

UC-5 Update Existing Immunization Record

A health care provider updates a patient's immunization history using a clinical viewer, EMR or mobile application.

• User logs in to application, looks up patient and immunization history, updates information about an immunization event. 
• Application (and related services):
  • authenticates user using ONEID, and
  • stores information about the updated immunization event in Panorama.

UC-6 View Immunization History (With Forecast)

Extends reports in UC-1 and UC-3 to include information about the patient's outstanding and upcoming immunizations.

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.