Critical Results - Detailed Proposal

1. Proposed Profile: Critical Results

• Proposal Editor: Kevin O'Donnell/Paul Nagy
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology/Cardiology/IT/Path?/Lab?

Summary

<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">

<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 few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">

<Summarize in a line or two market interest & available resources. E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking. Individuals from SFR are willing to participate in Profile development.">

<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

Typically a referring physician, suspecting a particular pathology, orders an imaging exam to confirm or rule it out or to provide more detail. Current report distribution mechanisms work reasonably well for communicating such results however gaps remain:

• Critical results such as findings that may imminently threaten the patients life (e.g. a pneumothorax) cannot wait for whenever the referring physician gets to the report but must need to be acted on quickly.

• Important incidental results such as findings that may threaten the patients life in the future (e.g. a suspicious lung mass in an exam for a cracked rib) should not be overlooked and must be properly followed up.

In an era of increasing pressures to interpret more images in less time, most radiologists are unable to spend the significant amounts of time needed to track down referring physicians and personally communicate findings.

However, the American College of Radiology has made clear in its practice guidelines that not only is such notification necessary, but that documented, verifiable records of such communication must be retained by the radiologist. Dozens of legal decisions have found radiologists responsible for damages in cases in which imaging results and reports were not communicated or in many cases in which such communications could not be verified.

Failure to communicate with referring physicians is believed to be responsible for significant numbers of adverse outcomes, and it is often implicated in liability claims.

There is currently no standard, integrated way to track receipt of clinical findings. The problem is compounded by the many different ways such findings can (and should) be communicated (particularly in urgent cases).

3. Key Use Case

A number of well attended presentations at SIIM 2007 emphasized the significance of this problem and presented desired behaviors. Systems should be able to use many different methods of notification to:

• alternative methods may be needed to reach the referring where they are
• the urgency of the finding dictates different communication channels
  • impending death within the hour warrants direct methods and alarms
  • a potentially fatal cancer requires different communication and followup

Address notification that critical results exist, access to those critical results, and auditing notification/receipt of notification/receipt of results

Clinical Findings Receipt Log

Whenever a system determines that clinical findings have been received by a designated recipient, it records that fact with a message in a log.

This could easily be an application of ATNA. The system might be a Report Reader that determines that the user has retrieved and accessed a report, it might be an email system that receives a receipt message from a users mail client, it might be an automated phone/pager system which receives an acknowledgement code from the recipient, it might be a human working a call list who confirms that the doctors office has received the result fax. The system and how it determines receipt is open. The log message should record the recipient, a reference to the results received, the date and time of receipt, the method of result delivery, the method of confirmation, who acknowledged receipt, and perhaps other details.

Clinical Findings Delivery: Reporting Workflow

In another sense, this problem points to a gap at the end of the Reporting Workflow. Delivery could be an additional step with an associated worklist and an actor to represent the system carrying out the delivery.

When a report is reviewed by the ordering physician the radiologist can have a worklist or notification that the results were received. A nurse could manage a worklist of all unreceived reports for a department with clinically significant findings to ensure the findings are delivered in a timely manner to impact medical management decisions. This would save the radiologists from playing phone tag with clinicians. Order fulfillment should be the state when the results are delivered to the ordering agent and not just when the results are available.

4. Standards & Systems

Paul Nagy and others have suggested that many of the relevant events already can be logged in the IHE ATNA audit log. Additional relevant events could easily be added. Note however, that the ATNA audit log is a security audit trail that collects security and privacy relevant events like login/ logout, system administration changes, access to personally identifiable health data. What is described here rather is a forensic log that records "good medical behavior". These two should not be confused pr mixed up.

If this profile added a query interface to the Audit Repository (e.g. so you could query for audit events involving the referring doc or their organization accessing the critical results in question. It would confirm that the necessary information has been communicated) it could be an excellent mechanism and would build on existing infrastructure.

PWP (Personel White Pages) could be used as a source of many contact details (email address, phone number, pager, cell phone, fax, office number, etc) to support the notification process.

Current attempts to implement such systems have found that access to On Call schedules are an important component since, for example, for an emergency patient, the original ordering physician is not the one to contact, but rather the doctor who took over the case when the original doc went home. For the biopsy followup, maybe the family doctor is a better contact.

5. Discussion

"Future work should address decreasing lost to follow-up results in computerized systems without placing additional burdens on providers." In general, computerized alerts have been shown to improve the communication of critical lab results in the inpatient setting, Singh said.

"We believe electronic alerting systems have a promising future in improving response to abnormal imaging results in the outpatient setting," he said

Summary

<Summarize in a few lines the existing problem . E.g. "It is difficult to monitor radiation dose for individual patients and almost impossible to assemble and compare such statistics for a site or a population.">

<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 few lines how the problem could be solved. E.g. "A Radiation Dose profile could require compliant radiating devices to produce such reports and could define transactions to actors that collect, analyze and present such information.">

<Summarize in a line or two market interest & available resources. E.g. "Euratom and ACR have published guidelines requiring/encouraging dose tracking. Individuals from SFR are willing to participate in Profile development.">

<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.">

5. Technical Approach

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>

Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>

Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>

Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

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

Need a champion for development.

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.>

This topic has been raised before in Radiology and was referred to IT Infrastructure, however there has been no progress there. Should we renew pressure on them, or consider drafting a profile ourselves for transfer later (as was done with ATNA in the first place)?

Need to identify where the clinical data is "attached". Is this profile purely notification/tracking with just references to clinical objects or is there some clinical details included?

9. Tech Cmte Evaluation

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