1 / 9

IHE Eye Care Webinar Requirements for Modality Vendors June 6-7, 2006

IHE Eye Care Webinar Requirements for Modality Vendors June 6-7, 2006. Mike Schmidt, Carl Zeiss Meditec. Acquisition Modality Role. The instrument shall support the acquisition modality role of the IHE Eye Care eye care workflow integration profile.

mwickstrom
Download Presentation

IHE Eye Care Webinar Requirements for Modality Vendors June 6-7, 2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IHE Eye Care WebinarRequirements for Modality VendorsJune 6-7, 2006 Mike Schmidt, Carl Zeiss Meditec

  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 RoleDICOM Services • Modality Worklist Service • Modality Performed Procedure Step Service • Storage Service • Storage Commitment Service

  4. Acquisition Modality RoleSOP Classes • OP: Ophthalmic Photography • US: Ultrasound • Encapsulated PDF

  5. Acquisition Modality RoleImage 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.

More Related