Basic Eye Care Workflow

Summary

Advanced Eye Care Workflow and Basic Eye Care Workflow address three workflow scenarios: stand-alone eye care clinics, large eye care groups, and hospital-based eye care departments. The difference between these two profiles is that Basic Eye Care Workflow does not include the Performed Procedure Step Manager.

In Eye Care, patients present with a variety of symptoms and complaints, which may or may not result in the need for diagnostic imaging and testing. Some types of imaging and testing may be performed routinely, before patients are seen by a physician. Other types of imaging and testing may be performed only after a physician has determined the need for them while examining the patient. Thus orders may be placed either for a specific procedure, or for a “generic eye care procedure.” This requirement of flexibility is paramount.

Benefits

In even the best eye care practices, there is currently potential for error and inefficiency because of the multitude of players in a practice. Under the most optimized of non-IHE practices, this information would flow from the PMS to the EHR and potentially to each device/equipment as a result of a specific custom interface written. In the case where the information isn’t available automatically, patient information is re-entered by hand by the technician into the device or application that is going to be used to help diagnose the patient.

These issues are addressed in the Eye Care Workflow Integration Profile, which establishes the continuity and integrity of basic patient and procedure data in the context of an eye care clinic and/or an integrated hospital workflow scenario. This profile deals specifically with consistent handling of patient identifiers and demographic data. This includes when the procedure(s) have been ordered prior to performing the acquisition in addition to the scenario when a “generic eye care order” has been placed. It also specifies the scheduling and coordination of procedure data to a wide variety of diagnostic imaging and testing equipment, and its reliable storage in an image management system from where it is available to support subsequent workflow steps, such as reporting.

Details

The patient has been registered in an ADT/Patient Registration actor, a specific order has been placed, and a procedure step has been scheduled. The technician uses the Acquisition Modality to query for a worklist. This may be either a patient query (using parameters to identify the patient uniquely), or a broad query (for all procedure steps scheduled for the modality). The modalities use the DICOM modality worklist service to query the Order Filler, which responds with a worklist. This is displayed on the modality, and the technician selects the appropriate worklist item. The technician performs the acquisition based upon the requested procedure code identified in the worklist, or the technician may have determined the requested procedure code was incorrect, and therefore selects a different procedure code for acquiring the information (i.e. the technician determined the “specific” procedure was incorrect). The modality uses the DICOM performed procedure step service to send a start message to either the ordering system or storage server depending on the configuration. The modality may use the DICOM query / retrieve service to retrieve longitudinal data to display to the technician prior to the acquisition, or to display to the physician after the acquisition (for implicit post-processing involving longitudinal data). The technician performs an acquisition for the patient. When the technician selects to save the acquisition, the modality uses the DICOM storage service to store the acquisition data to the storage server. Additional acquisitions may occur as part of the performed procedure step, each resulting in a DICOM storage command. The technician selects a user interface (UI) mechanism on the modality to indicate the end of the procedure step. The modality uses the DICOM storage commitment service to request that the storage server take responsibility for persistent storage of the previously stored acquisition data. The storage server responds asynchronously to acknowledge the storage commitment; this may be almost immediate, or it may be after the storage server has transferred the acquisition data to secondary media. After receiving a positive storage commitment response, the modality may clear the acquisition data from its disk.

In summary, this example allows for specific detailed procedures to be requested in the order. It supports the scenario that the technician performs what was specified (i.e. no changes) or determines that the order was incorrect and performs another procedure. If what was performed is not what was ordered, the order is corrected on the instrument and sent back to the department ordering system.

Systems Affected

• Practice Management System or Enterprise-wide information systems that manage patient registration and services ordering (i.e., admit-discharge-transfer (ADT)/registration system and hospital information system (HIS))
• Electronic Medical Record System or Departmental information systems that manage department scheduling
• Acquisition modalities (e.g., fundus cameras, ultrasound machines, ophthalmic tomography devices, slit-lamp biomicroscopes)
• Image management/archiving (i.e., picture archiving and communication system (PACS))

Actors & Transactions:

Specification

Profile Status: Trial Implementation Version

Documents:

• Year 3 - Volume 1: Final Text (Version 3.6)
• Year 3 - Volume 2: Final Text (Version 3.6)

Underlying Standards:

• DICOM
• HL7

See Also

http://one.aao.org/CE/PracticeGuidelines/Information_Technology.aspx