Difference between revisions of "Referral Orders"
Line 16: | Line 16: | ||
==3. Key Use Case== | ==3. Key Use Case== | ||
− | A doctor at chalet clinic sends a patient to larger hospital with a referral request for procedure X. Chalet clinic is only intermittently connected, so they use XDM to send the relevant medical records to larger hospital. They also use the Referral request to convey the procedure X request. Some time earlier, chalet clinic established a referral relationship with larger hospital. As part of this relationship they maintain the current referral procedure codes, and have established the other medical relationships regarding acceptance of referrals. | + | A doctor at chalet clinic sends a patient to larger hospital with a referral request for procedure X. Chalet clinic is only intermittently connected, so they use [[Cross-enterprise Document Media Interchange|XDM]] to send the relevant medical records to larger hospital. They also use the Referral request to convey the procedure X request. Some time earlier, chalet clinic established a referral relationship with larger hospital. As part of this relationship they maintain the current referral procedure codes, and have established the other medical relationships regarding acceptance of referrals. |
The request arrives at larger clinic and is processed to the referrals staff. They check the entry, work out scheduling, assignment of local doctor, etc. These internal tasks are not profiled by IHE. The incoming referral is used to automatically fill as much of the relevant information as is reasonable, e.g., patient name, and thus assist the other tasks such as assignment of doctor and scheduling. | The request arrives at larger clinic and is processed to the referrals staff. They check the entry, work out scheduling, assignment of local doctor, etc. These internal tasks are not profiled by IHE. The incoming referral is used to automatically fill as much of the relevant information as is reasonable, e.g., patient name, and thus assist the other tasks such as assignment of doctor and scheduling. | ||
There can be similar use cases between more closely integrated organizations with full time connectivity, coordinated order entry systems, etc. In these cases the incoming request may be a much more complete request, and may be sufficiently complete that it can be processed fully automatically. | There can be similar use cases between more closely integrated organizations with full time connectivity, coordinated order entry systems, etc. In these cases the incoming request may be a much more complete request, and may be sufficiently complete that it can be processed fully automatically. | ||
− | |||
==4. Standards & Systems== | ==4. Standards & Systems== |
Revision as of 03:05, 15 September 2008
1. Proposed Workitem: Referral Orders
- Proposal Editor: Rob Horn
- Editor: Rob Horn
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: IT Infrastructure
2. The Problem
The various XDS alternatives address conveying the patient records between enterprises. There is not a way to convey the referral request in a form suitable for automatic processing. Internally within the organization various profiles deal with Scheduled Workflows and unscheduled workflows. These are not directly suitable for cross enterprise referrals.
3. Key Use Case
A doctor at chalet clinic sends a patient to larger hospital with a referral request for procedure X. Chalet clinic is only intermittently connected, so they use XDM to send the relevant medical records to larger hospital. They also use the Referral request to convey the procedure X request. Some time earlier, chalet clinic established a referral relationship with larger hospital. As part of this relationship they maintain the current referral procedure codes, and have established the other medical relationships regarding acceptance of referrals.
The request arrives at larger clinic and is processed to the referrals staff. They check the entry, work out scheduling, assignment of local doctor, etc. These internal tasks are not profiled by IHE. The incoming referral is used to automatically fill as much of the relevant information as is reasonable, e.g., patient name, and thus assist the other tasks such as assignment of doctor and scheduling.
There can be similar use cases between more closely integrated organizations with full time connectivity, coordinated order entry systems, etc. In these cases the incoming request may be a much more complete request, and may be sufficiently complete that it can be processed fully automatically.
4. Standards & Systems
Existing relevant profiles include: XDS/R/M for exchange of medical records; Radiology, Cardiology, PCC, and other disciplines for the definition of record formats; Scheduled Workflow profiles from Radiology, cardiology, etc. The various Scheduled Workflow profiles do not provide this facility themselves. They will be the consumers of the finished orders that result from the processing of the referral request.
HL7 Order management. This may need some adaptation to reflect the incomplete nature of the referral request, but since HL7 Orders are the input into the scheduled workflows, they are the natural starting point for defining a referral request.
5. Discussion
This is the natural completion of the present IHE profiles for exchanging medical records and for managing internal scheduled workflows. It is related to the appointment proposal, but deals just with exchanging the referral request.
This does not address the complex issues that arise if there needs to be negotiation and amendment of the request. Those generally involve the clinical staff and are a poor choice for standardization. This is one reason to keep an active actor with human involvement between the receipt of the request and the dispatching of orders into the scheduled workflows. The requests and the scheduled workflow orders can be reasonably standardized if the people running this system deal with the complex problem requests.
This is related to the proposal for introducing scheduling support for the Image enabled office.
There will be a strong desire to help automate the scheduling activities with patients. This poses serious problems. First, although there are standards for exchange of calendar and schedule information, these are not well supported by industry. Second, there is strong industry opposition to open exchange and coordination of schedules. The dominant products and servers are all proprietary systems. IHE does not have the clout to change this. Third, there are very difficult and complex privacy issues to be managed around scheduling. People are highly conflicted between wanting easy ready access to scheduling information, and not wanting the nature of their appointments or illness disclosed. Fourth, this almost always involves human negotiations back and forth around priorities, conflicts, and availability. These are relatively easy to handle in specific contexts but very hard to handle generically. (E.g., broken bones, cardiac exams, and tooth cleaning are very different scheduling problems.)