Critical Results - Detailed Proposal

1. Proposed Profile: Critical Results

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

Summary

Procedures such as diagnostic imaging or labs sometimes generate (unanticipated) critical results, e.g. a pneumothorax or serious contagion.

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

Producers need to be able to confirm that an appropriate physician has accessed/understood the relevant clinical information so they can stop working 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.

Presentations at SIIM 07 described parallel efforts by several hospitals to address this 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.

The two examples above are from Radiology. Other domains such as Lab, Pathology, Cardiology also have findings that are unanticipated and may need to be reacted to quickly, or properly flagged for later followup.

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

The American College of Radiology has made clear in its practice guidelines, however, 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), e.g. phone, fax, pager, SMS, email, public address system, EHR terminal, etc.

There are several elements to the problem:

Identify the appropriate person to contact with the critical result

• The admitting physician may be off-duty, the patient may have been transfered to a specialist,
  • Need Office Hours/On-Call/Personel schedule lookup & query for current attending physician
• SIIM implementations discussed having a list of all possible/likely people sorted by priority
• Some results should go to the surgeon, others should go to the family doctor

Identify methods to notify the selected person

• Need a way to identify potential contacts for a selected person (email addresses, pager #'s, etc)
• Selecting a method may depend on the type and urgency of the result and the state of the person being contacted
  • An office phone number or email might be a useful method for a family physician but not a doctor on rounds
  • An email might be a useful reminder to follow-up an unexpected lung nodule, but not to handle a pneumothorax
  • An alarm or PA announcement in ER might be useful for a pneumothorax but an inappropriate distraction for less urgent findings
• Multiple methods should be available and may be tried as fallbacks

Log attempts to notify

• For legal reasons it may be necessary to record that attempts were made to notify appropriate people
• Some notification methods may implicitly or explicitly generate a log, other methods would need a separate method for logging attempts

Convey the critical result details

• Again, multiple methods for conveying the results may be appropriate
• Some results may be simple enough to be conveyed in the notification itself
• Other results may require the result itself be conveyed separately (e.g. an image or full report would not fit in an SMS message)
  • In some cases the notification could carry a link, accession # or other convenient entry point to access the results

Log that the critical result was received

• For legal reasons it may be necessary to record that the critical result was received by an appropriate person
• It may be worth considering if receipt of all clinical results, not just critical ones, should be logged
• Some mechanisms, such as retrieval of a report, may already record receipt as an audit event
• Some mechanisms, such as a phone call, do not easily record the content conveyed and would require some other method, performed by the sender or receiver, to log receipt
• In general, an acknowledgement by the receiver is probably preferable to a log by the sender.
• Some guidelines require that the sender confirm and log that the receiver has understood the results
• The log details may also be useful data for quality monitoring and process improvement

Inform the Producer that the critical result was (or was not) received

• Pursuing notification and delivery of the critical results consumes the resources and attention of the result producer staff
• Notification and delivery will sometimes be an iterative process
  • If initial methods fail or people cannot be contacted, alternative methods and people will be tried
• Once receipt is confirmed, producer attention and resources can be turned elsewhere

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