September, 2005What IHE Delivers 1 Mike Schmidt, Carl Zeiss Meditec IHE Eye Care Webinar Requirements for Modality Vendors June 6-7, 2006

2 Acquisition 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 Role DICOM Services Modality Worklist Service Modality Performed Procedure Step Service Storage Service Storage Commitment Service

4 Acquisition Modality Role SOP Classes OP: Ophthalmic Photography US: Ultrasound Encapsulated PDF

5 Acquisition Modality Role Image 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 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: Patient 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: Patient 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: Protocol 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.