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

Physicians need to recieve appropriate notification of critical results generated by procedures such as diagnostic imaging.

Producers of such results (such as radiologists) need flexible methods of identifying, locating and contacting a responsible caregiver.

Producers need to be able to confirm that an appropriate physician has accessed/understood the relevant clinical information so they can stop trying to contact them. They also need a legal record of having attempted and achieved contact.

Many of these things are difficult and poorly done today, and patient care suffers.

Some high profile presentations at SIIM described the parallel attempts of several hospitals to address what they feel is a significant patient care and legal issue.

This is a clear example of a number of different systems needing to communicate, share information and coordinate with each other.

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.

Other domains such as Lab, Pathology, Cardiology will have similar situations.

• Often findings in Lab results are unanticipated and may need to be reacted to quickly, or properly flagged for later followup.

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

There are several issues to be addressed:

• Receipt
• Acknowledgement
• Understanding

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.

<<The profile mechanisms should support the variety of timeframes/urgencies of followup. Need notification of timeout of confirmation. Might not be the radiologist who follows up on that. Might need an escalation strategy for contact, might also want to consider the whole followup chain>>

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.

<<Skip reference to solution technology>>

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.

<<Normally receipt of routine reports is not logged and not required to be. Should consider if everything should be "tracked" and not just critical results.>>

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.

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.

<<Could also log "understand" messages sent from recipient>>

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.

DSG (Digital Signatures) might be useful if it is decided that strong tamperproof signatures (e.g. attesting receipt/understanding) are needed.

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

See some approach details in the Use Case and Standards sections above.

<<Note that we would address the electronic communications. Wouldn't address phones, but can't prohibit their use>

Existing actors

• Report Creator
• <PWP Actors>
• <ATNA Actors>

New actors

<List possible new actors>

<<Add some relevant to the use cases>>

Existing transactions

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

Impact on existing integration profiles

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

New integration profiles needed

Propose one new profile addressing locating people, notification and audit.

Breakdown of tasks that need to be accomplished

Address Locating Appropriate Recievers of the Results

• Need OnCall/Personel schedule lookup to figure out who
  • Maybe an extension of PWP, or Appointment/Scheduling Profile
• Use PWP to get "URIs" (points of contacts for the person)

Address Contacting/Notifying them of the Critical Results

• Should take advantage of many modes of notification
• Should try to provide links or convenient entry points to access the results
• do we need a link/pointer to the results, or do we include the critical findings (Open Issue)

Address providing the critical results

• Use existing delivery mechanisms
• Include audit trail entries.

Address confirming contact/delivery/reciept of the results

• Include a query interface on the audit trail
• Used by the application that confirms receipt to the Radiologist
• Used by the receipt doing forensic retrieval for legal or process improvement reasons
• Flag for failure.

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.

Brigham & Womens Hospital (Ramin Khorasani), University of Maryland (Paul Nagy), and University of Chicago (Paul Chang) have all worked on systems to address this problem.

SIIM Presentations

"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

A study by University of Maryland researchers has found that CT angiography exams performed after coronary artery bypass surgery can help physicians identify unsuspected, clinically relevant cardiac and noncardiac conditions. Physicians detected ventricular pseudoaneurysms, perfusion deficit, or intracardiac thrombi in 24 patients (9.3%). Thirty-four patients (13.1%) showed noncardiac findings, such as pulmonary emboli, lung cancer, or pneumonia. Fifty-one (19.7%) showed at least one unrelated, potentially significant finding during the immediate postoperative period.

7. Risks

• As with topics like digital signatures, etc., this profile would address records which will eventually be called into legal liability proceedings, and would need to be appropriately robust.

• Ideally the mechanisms should be common with similar needs in a variety of domains. Without involvement of the different domains involved it might fail to meet all needs.

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?

Note that although ATNA specifies general audit trail mechanisms, they were originally designed with Security and Privacy use cases in mind and the current set of audit events reflect this. This proposal focuses on addressing "Good Medical Behavior" use cases. There may be some overlap in the needed audit events, but there might be additional events or details needed. Also it is possible there could be a conflict between the requirements of the use cases. An important issue is whether it would be advisable to "piggyback" this application on existing ATNA servers, or whether a new server should be created with independent messaging. If a new server is created, can it re-use the existing ATNA technical specification or would we prefer to define a new one.

9. Tech Cmte Evaluation

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

• 25% ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA