Referral Request

1. Proposed Profile: Referral Request

Proposal Editor: Robert Horn
Profile Editor: TBD
Date: N/A (Wiki keeps history)
Version: N/A (Wiki keeps history)
Domain: IT Infrastructure

Summary

<Demonstrate in a line or two that the key integration features are available in existing standards. E.g. "DICOM has an SR format for radiation dose events and a protocol for exchanging them.">

<Summarize in a line or two why IHE would be a good venue to solve the problem. E.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">

2. The Problem

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. The various XDS alternatives already address conveying the patient records between enterprises, so a mechanism is needed to convey the dynamic workflow information.

The present system depends upon letters, faxes, telephone calls, and documents to convey the referral request. About 20% of referrals require conversations or other interactions between the various clinicians. The combination of simple request and patient medical record is insufficient. The goal is to significantly improve the 80% where the simple request is adequate without interfering with the 20% where more interactions are needed. The 20% can have some data entry and associated errors eliminated, but will continue to need the direct clinician interactions and will not fit into a well defined preset workflow.

3. Key Use Case

Referral

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. If this is one of the 20% that require further interactions, it is diverted into the more complex processing. This profile does not attempt to specify that processing. It only eliminates some of the need to perform data entry to re-enter patient information.

Significant variations in this use case are:

Referring sites that use intermittent network connections. They presently use XDM or XDR for the transmitting their documents. More study is needed to decide whether a direct connection can be established for transmission of these small requests, or whether a intermittent connection approach must be supported.

The backup documents and patient records may be sent directly to next healthcare site, or they might be sent to a repository. The referral request needs to have a means to accommodate all combinations.

Referring sites might be permanently connected and utilize XDS for documents, with the referring site providing the repository.

Results

The results of a referral need to be returned to the referring physician. This relationships between requests and results can become quite complex. For example, if the referral is one of the 20% that required further conversations the results are not predictable from the referral information. There are also reporting complexities that arise during regular referrals. The proposal for a profile for Notification of Critical Results deals with one aspect of this. It manages the need to confirm that the patient has been informed of medically significant results, and the need to alert the referring physician when critical (abnormal) situations were detected. (In Radiology criticial results measurements have shown that emergent and urgent critical findings are handled well, but significant non-urgent unexpected findings are a problem. E.g., X-ray of broken bone detects a small cancer.)

The referring site might be on an intermittent connection. The results might be delivered to a repository (XDS), or they might be delivered by email (XDM).

Multiple Profiles

There are possible several related profiles to be created. The differences in connectivity can lead to significant technical issues and usability issues. The most common configurations are:

Both parties are permanently connected with local EHR systems. In this case direct immediate notification is practical. The notifications can go between EHR systems automatically. This is common in hospital to hospital situations.

The referring site is intermittently connected, while the performing site is permanently connected. This is a common physician's office to hospital situation. This makes referral easier because the physician can always establish a connection when necessary. The return of results cannot depend on the physician' system being available for connection.

Neither site is permanently connected. This is a physician to physician communication. This poses the greatest communications problems since neither side can establish a connection when needed.

Another tradeoff to be considered is the extent to which these profiles push the state of the art. There are new technologies that require upgrades to physician equipment to be useful. There are older less capable technologies that can be retrofitted. The planning committee needs to consider whether to emphasize the ability to implement rapidly with existing equipment or have more capability but a slower rollout.

4. Standards & Systems

The HL7 standard has Patient Transfer of Care and various order related messages. One of these is expected to be suitable for this purpose. The technical committee can determine whether any extensions will be needed.

5. Technical Approach

There are probably three pairs of related profiles. One dimension is the three major classes of connectivity. It is likely that there will be transaction differences between these three classes, and XDS has set the tradition of using different profiles for differences at this level. This might become three sets of options if there are significant protocol commonalities. The other is separation between conveying the referral request from the requester to the performer, and the conveying of results from the performer to the referrer. The two must coordinate identifying information, but are otherwise likely to use different protocol details.

Existing actors

This profile will not directly include any existing actors, but it depends upon the use of existing profiles and actors for closely related functions:

Transmission of documents will be done using one of the existing profiles: XDS.a, XDS.b, XDR, XDM. The existing actors: XDS Repository, XDS Registry, XDS Source, and XDS Consumer are all needed.

The existing profiles for scheduled workflows (in Radiology, Cardiology, Radiation Therapy, Ophthalmology, etc.) are the final destination for many of the referral requests. The transactions between the Referral Screening Actor and the many order management actors are not specified in this profile. They are specified in the other profiles.

New actors

Referral Request Sender – This actor sends the referral request. It is typically part of an application supporting a physician.

Referral Request Screener – This actor receives the referral request and separates the 20% that must be diverted from the more automated path from the 80% that are routine. It performs all the necessary internal tasks to convert the referral request (which is often incomplete or highly summarized) into the detailed form needed internally.

Referral Results Notification Sender – This actor send the return notifications. The document results are sent using one of the existing XD* profiles.

Referral Results Notification Receiver – This actor receives the notifications. It is typically part of an application that supports a physician.

Existing transactions

see above

New transactions (standards used)

Send Referral Request

Send Results Notification

Impact on existing integration profiles

There are no expected direct impacts. There is the impact of interactions between this profile and existing profiles for document exchange and scheduled workflows.

New integration profiles needed

There are at least two profiles needed. This might be three pairs of profile, with individual profiles reflecting different technologies for different connectivity.

Referral Request
Referral Results

The 20% diversion and the changes that can occur during treatment mean that the request handling and results handling might be performed by completely different systems. It is also useful to be able to handle at least requests, even if results reporting is not automated. Having two profiles simplifies explaining this. If the connectivity variations result in significant technology or implementation differences, it is probably easier to explain this to users by using different profiles than by having complex optionality tables. This is how XD* has handled these issues, so it will be consistent with XD*.

Breakdown of tasks that need to be accomplished

These use cases need to be detailed with timelines, especially to clarify the many race conditions that are possible.

The diversion of the 20% that get diverted into special handling needs to be clarified. These are requests that are effectively leaving the IHE domain, but some of the information in the requests needs to be conveyed consistently to the scheduled work that is eventually ordered. We have not previously tried to say something like this.

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

<List technical or political risks that will need to be considered to successfully field the profile.>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA

<Delete this Category Templates line since your specific Profile Proposal page is no longer a template.>