Difference between revisions of "Scheduled Workflow"
Line 47: | Line 47: | ||
'''Actors & Transactions:''' | '''Actors & Transactions:''' | ||
− | + | [[Image:Swf-actor-transaction.JPG]] | |
==Specification== | ==Specification== |
Revision as of 14:11, 10 March 2008
Scheduled Workflow (SWF) integrates ordering, scheduling, imaging acquisition, storage and viewing for Radiology exams.
Summary
Scheduled Workflow establishes a seamless flow of information that supports efficient patient care workflow in a typical imaging encounter. It specifies transactions that maintain the consistency of patient information from registration through ordering, scheduling, imaging acquisition, storage and viewing. This consistency is also the foundation for subsequent workflow steps, such as reporting.
![Ihe rad swf ip.jpg](/uploads/1/18/Ihe_rad_swf_ip.jpg)
Benefits
<List the key benefits the profile provides (e.g. error reduction, increased throughput) and how they come about (e.g. SWF reduces patient errors due to mistyped demographics at the modality by transfering demographics electronically from the Order Filler).>
- Reduce Errors and Enhance Patient Care
- Prevents manual data entry errors at the modality console by downloading patient and study information from the RIS in the MWL
- Prevents delays in patient care by transmitting images and completion status notification electronically and by reducing number of manual steps
- Reduces missing or irrelevant priors—modality stores studies with accurate, detailed patient demographics and procedure descriptions downloaded from the RIS, allowing accurate location and retrieval
- Improve Throughput
- Saves manual data entry time by using Worklists to download patient demographics and study details
- Saves time wasted manually confirming image transfer to the PACS—modality automatically confirms PACS receipt of images
- Prevents time wasted manually fixing demographics for emergency or John Doe studies—the PACS updates the studies to the modality based on patient demographics feeds from the RIS
- Reduce Deployment Cost/Time
- Prevents custom interface specification time and expense—IHE TF provides a detailed specification for a powerful interface, supported and tested by many vendors
- Prevents custom interface implementation time and expense—many IHE Integration Profiles are already supported by many vendor products
- Reduces interface compliance testing time and expense—many implementation variations have been refined in systems tested at IHE Connectathons
- Reduces intersystem testing time and expense—many combinations of systems have already been directly tested together at IHE Connectathons
- Reduces custom interface maintenance time and expense by maintaining a single interface (IHE) instead of multiple custom interfaces
Details
<Editors NOTE: Raw material extracted from the User Handbook. Some additonal massaging is still needed.>
The SWF and PIR Profiles ensure that patient demographics and order and procedural information are correct and consistent. They allow images to be available for review in a timely fashion. Modality operators use the MWL to query and retrieve the relevant patient demographics and scheduled procedure information from the RIS. Patient name changes should not be made on the modality. The RIS is the primary information source and is capable of managing name updates, as long as the modality does not introduce additional unexpected changes. To ensure the most timely and correct patient information, the Worklist should be re-queried just before starting a new exam in case patient or order details have changed. The modality operator should verify that the right patient is selected for each examination.
In unscheduled cases (e.g., emergency patients), patient names and identification (ID) numbers may be unknown. As these are required to commence the procedure, they will need to be selected from a predefined list of temporary patient and names and IDs and entered at the modality. In such unscheduled cases, the AN, a key identifier for the imaging order, must be left blank. Later, when the correct patient ID, name and Accession Number are known, the RIS and the PACS will reconcile the image information with the correct values.
Systems Affected
Systems involved in this profile are:
- Enterprise-wide information systems that manage patient registration and services ordering (i.e., admit-discharge-transfer (ADT)/registration system and hospital information system (HIS ))
- Radiology departmental information systems that manage department scheduling (i.e., radiology information system (RIS))
- Radiology image management/archiving (i.e., picture archiving and communication system (PACS))
- Acquisition modalities
Actors & Transactions:
Specification
Profile Status: Final Text
Documents: IHE Radiology Technical Framework:
- Vol. 1 - Section 3 documents the profile
- Vol. 2 - Sections 4.1 to 4.8, 4.10 to 4.14, 4.16, 4.18, and 4.20 to 4.21, document specific transactions. Appendices A, B and D provide additional requirements and suggestions on mapping information to ensure consistent flow of information throughout the department.
- Vol. 3 - Sections 4.42, and 4.48 to 4.49 document specific transactions.
Underlying Standards:
See Also
<The following sections can be left out if there is nothing to point to. This is just to show where such information can go.>
Related Profiles
<List profiles this one depends on, profiles that depend on this one, profiles that are synergistic with this one>
Consumer Information
The Profile FAQ Template answers typical questions about what the Profile does. <Replace the link with a link to the actual FAQ page for the Profile>
The Scheduled Workflow FAQ answers typical questions about what the Profile does.
The Profile Purchasing Template describes considerations when purchasing equipment to deploy this Profile. <Replace the link with a link to the actual Purchasing page for the Profile>
The Profile Purchasing Template describes considerations when purchasing equipment to deploy this Profile.
Implementer Information
The Profile Implementation Template provides additional information about implementing this Profile in software. <Replace the link with a link to the actual Implementation page for the Profile>
<< Incorrect example>>: The Cross-Enterprise Document Sharing Implementation provides additional information about implementing this Profile (well XDS actually) in software.
Reference Articles
<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis) >
This page is based on the Profile Template