1September, 2005 What IHE Delivers

Mike Schmidt, Carl Zeiss MeditecMike Schmidt, Carl Zeiss Meditec

IHE Eye Care WebinarIHE Eye Care WebinarRequirements for Modality VendorsRequirements for Modality Vendors

June 6-7, 2006June 6-7, 2006

2

Acquisition Modality RoleAcquisition Modality Role

The instrument shall support the acquisition modality role of the IHE Eye Care eye care workflow integration profile.

This allows the instrument to receive patient and order information from an information system,

to report on performed procedure steps, and to store exam data to a storage server.

3

Acquisition Modality RoleAcquisition Modality RoleDICOM ServicesDICOM Services

Modality Worklist Service

Modality Performed Procedure Step Service

Storage Service

Storage Commitment Service

4

Acquisition Modality RoleAcquisition Modality RoleSOP ClassesSOP Classes

OP: Ophthalmic Photography

US: Ultrasound

Encapsulated PDF

5

Acquisition Modality RoleAcquisition Modality RoleImage CompressionImage Compression

None

JPEG Baseline (Process 1) Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression

JPEG Lossless Non-Hierarchical (Process 14)

6

Image Display / Evidence Creator RolesImage Display / Evidence Creator Roles

The instrument shall support the image display and evidence creator roles of the

IHE Eye Care ophthalmic workflow integration profile.

This allows the instrument to retrieve exam data from a storage server, and to store evidence documents to the storage server. This supports post-processing typically available directly on the ophthalmic instrument.

7

Implicit Requirement:Implicit Requirement:Patient IdentityPatient Identity

The device shall determine the identity of the patient according to the Patient ID and Issuer of ID if these

are both provided in a worklist item. If a patient record with the same patient ID and issuer of ID already exists in the device’s local storage, other patient

record attributes of that local record shall be updated.

The Issuer of ID identifies the patient registration system, and will ensure the uniqueness of the Patient ID. This requirement allows instruments that maintain longitudinal data to update their patient demographics as changes or corrections are made at the patient registration system.

8

Implicit Requirement:Implicit Requirement:Patient Identity ReconciliationPatient Identity Reconciliation

The device shall allow a worklist item to be matched with a locally stored patient record

lacking the Issuer of ID. The local record shall be updated with the Issuer of ID and other attributes

from the worklist item. The match algorithm should use the patient name, date of birth, and ID. The device may require user confirmation.

This scenario arises from legacy longitudinal data, or from manual data entry of patient demographics on the device.

9

Implicit Requirement:Implicit Requirement:Protocol CodingProtocol Coding

The device shall support site configuration of protocol codes for the procedure steps supported by the device. The configuration mechanism shall allow all devices of the same type to be updated easily (without manual editing on each device).

Protocol codes are provided in a modality worklist item to identify the scheduled procedure step, and are specified in the performed

procedure step data. Although procedure steps are typically in 1-1 correspondence with a billable procedures, billing codes are not typically used as protocol codes. Instead site-specific, human-

readable codes are assigned, and the mapping of these back to billing codes is usually done by the EMR system as part of the charge

capture process.