Difference between revisions of "Eye Care Workflow"
(New page: Eye Care Workflow Integration Profile The Eye Care Workflow Integration Profile (EYE CARE) describes mechanisms to manage and distribute the workflow within the eye clinic across the seve...) |
m (→Summary) |
||
| (13 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | The '''Eye Care Workflow Integration Profile (EYE CARE)''' describes mechanisms to manage and distribute the workflow within the eye clinic across the several types of equipment in a synchronized manner. | |
| − | |||
| − | The Eye Care Workflow Integration Profile (EYE CARE) describes mechanisms to manage and distribute the workflow within the eye clinic across the several types of equipment in a synchronized manner. | ||
| Line 7: | Line 5: | ||
==Summary== | ==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. | + | 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. |
| − | + | [[Image:workflow_small.jpg]] | |
| − | + | ==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. It also provides the ability for the acquisition devices (such as diagnostic imaging, measuring, test equipment) to identify the actual procedure(s) that were performed. This enables further workflow steps such as automated billing for the procedure. | |
==Details== | ==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 performed modality procedure step service to send a complete message to either the ordering system or storage server, depending on the configuration. This message contains a lot of key information such as the performed procedure step’s protocol code (i.e. what procedure was actually performed on the patient) that later may be used for charge processing (the protocol code is mapped to a billing code). 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. This enables the ability to charge for the “actual” performed procedure automatically (if the Charge Posting Integration Profile is supported). | ||
==Systems Affected== | ==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:''' | '''Actors & Transactions:''' | ||
| − | + | [[Image:Workflow transaction copy.jpg]] | |
==Specification== | ==Specification== | ||
'''Profile Status:''' [[Comments| Final Text]] | '''Profile Status:''' [[Comments| Final Text]] | ||
| − | |||
'''Documents:''' | '''Documents:''' | ||
| − | + | :*[[:Media:Copy_ihe_eyecare_tf_yr3_vol1_Final_Text.pdf| Year 3 - Volume 1: Final Text (Version 3.6)]] | |
| − | + | :*[[:Media:Ihe_eyecare_tf_yr3_vol2_Final_Text.pdf| Year 3 - Volume 2: Final Text (Version 3.6)]] | |
| − | |||
| − | :* [ | ||
| − | :* [ | ||
| − | : | ||
'''Underlying Standards:''' | '''Underlying Standards:''' | ||
| − | |||
:* [http://dicom.nema.org DICOM] | :* [http://dicom.nema.org DICOM] | ||
:* [http://www.hl7.org HL7] | :* [http://www.hl7.org HL7] | ||
| − | |||
| − | |||
==See Also== | ==See Also== | ||
| − | + | http://one.aao.org/CE/PracticeGuidelines/Information_Technology.aspx | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 11:21, 12 July 2012
The Eye Care Workflow Integration Profile (EYE CARE) describes mechanisms to manage and distribute the workflow within the eye clinic across the several types of equipment in a synchronized manner.
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. It also provides the ability for the acquisition devices (such as diagnostic imaging, measuring, test equipment) to identify the actual procedure(s) that were performed. This enables further workflow steps such as automated billing for the procedure.
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 performed modality procedure step service to send a complete message to either the ordering system or storage server, depending on the configuration. This message contains a lot of key information such as the performed procedure step’s protocol code (i.e. what procedure was actually performed on the patient) that later may be used for charge processing (the protocol code is mapped to a billing code). 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. This enables the ability to charge for the “actual” performed procedure automatically (if the Charge Posting Integration Profile is supported).
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: Final Text
Documents:
Underlying Standards:
See Also
http://one.aao.org/CE/PracticeGuidelines/Information_Technology.aspx