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

Referral requests remain manual and time consuming for both requester and performer. Associating the resulting reports and documents with the request, and notifying the requester, remain labor intensive.

There are several candidate message forms in HL7 that can be extended to describe requests. The various XD* profiles now cover the provision of documents in both directions. Report response message standards are less clear.

An HL7 message could convey the request to the performer. The screening activity to determine whether this request fits into the generic workflows or is one of the 20% that needs special processing will remain customized. The 80% that fit into IHE scheduled workflows can be forwarded into equipment complying with one of the IHE scheduled workflow profiles.

There is work underway in Germany and elsewhere to start this kind of messaging flow. There is strong interest from the professional societies.

This is of particular interest to the PCC committee, and will also affect Radiology, Cardiology, and other scheduled workflows.

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

There is work underway on this in Germany and other countries. There is support from professional societies. A potential issue will be coordinating the wide variety of support. At one extreme there are the small practitioner to small practitioner exchanges, in the middle is the small practitioner to large facility, and at the other extreme are referrals between large facilities.

7. Risks

The results reporting is much more variable and less well understood than the referral request.

The diversion of complex requests may be more difficult than expected, or may be much more than the 20% level.

The choice of technology level. Labs is proceeding using the HL7 v2.5 for workflow messages, and HL7 CDA for documents. This choice affects the ease of introduction into the field. The newer technologies have advantages, but may take longer to introduce. At this moment, this proposes to use an approach similar to Laboratory systems: Use HL v2.5 for workflow messages, and use XD* for exchange of documents. Unlike Labs, there is no need to constrain the documents used as part of this profile.

8. Open Issues

The following need planning committee decisions. They are not purely technical decisions. They need to consider installed equipment, etc.

Do we emphasize using the leading technology or speed of deployment? What are the technical considerations?

Do we do the results return profile on the same schedule as referral requests profile? They can be done independently as two phases.

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