Difference between revisions of "Critical Results - Detailed Proposal"

From IHE Wiki
Jump to navigation Jump to search
 
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
  
==1. Proposed Profile: Critical Results==
+
==1. Proposed Profile: Critical & Important Results==
  
 
* Proposal Editor: Kevin O'Donnell/Paul Nagy
 
* Proposal Editor: Kevin O'Donnell/Paul Nagy
* Profile Editor:
+
* Profile Editor:  
* Date:    N/A (Wiki keeps history)
 
* Version: N/A (Wiki keeps history)
 
 
* Domain: IT/PCC - (Radiology/Cardiology/Path/Lab)
 
* Domain: IT/PCC - (Radiology/Cardiology/Path/Lab)
  
 
===Summary===
 
===Summary===
Procedures such as diagnostic imaging or labs sometimes generate (unanticipated) critical results, e.g. a pneumothorax or serious contagion.
+
Procedures such as diagnostic imaging or labs regularly 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 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.
Line 21: Line 19:
  
 
This is a clear example of a number of different systems needing to communicate, share information and coordinate with each other.
 
This is a clear example of a number of different systems needing to communicate, share information and coordinate with each other.
 +
 +
[http://www.auntminnie.com/index.asp?Sec=sup&Sub=ris&Pag=dis&ItemId=82463&wf=2716&d=1 A recent article] reconfirms the need for a solution and integration difficulties being experienced.
 +
 +
Associations with personel whitepages, and continuity of care should be clear.
  
 
==2. The Problem==
 
==2. The Problem==
Line 42: Line 44:
 
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 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:
+
 
 +
==3. Key Use Case==
 +
 
 +
When a "critical result" is identified by the producer of the result, a number of steps should take place:
  
 
'''Identify the appropriate person to contact with the critical result'''
 
'''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,  
+
* The admitting physician and/or the physician who ordered the exam 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
 
** 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
 
* SIIM implementations discussed having a list of all possible/likely people sorted by priority
Line 70: Line 75:
 
'''Log that the critical result was received'''
 
'''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
 
* 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
+
* It may be worth considering if receipt of ''all'' clinical results, not just critical ones, should be logged.  Current guidelines recommend logging receipt of critical results.  Logging receipt of routine reports is not common practice.
 
* Some mechanisms, such as retrieval of a report, may already record receipt as an audit event  
 
* 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
 
* 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
Line 83: Line 88:
 
* Once receipt is confirmed, producer attention and resources can be turned elsewhere
 
* 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:
+
A number of well attended presentations at SIIM 2007 emphasized the significance of this problem and presented additional desired behaviors.  Systems should be able to use many different methods of notification:
 
* alternative methods may be needed to reach the referring where they are
 
* alternative methods may be needed to reach the referring where they are
* the urgency of the finding dictates different communication channels
+
* the urgency of the finding dictates different communication channels and timeframes for follow-up
 
** impending death within the hour warrants direct methods and alarms
 
** impending death within the hour warrants direct methods and alarms
 
** a potentially fatal cancer requires different communication and followup
 
** a potentially fatal cancer requires different communication and followup
 +
* Mechanisms should support the variety of timeframes, urgencies and contact methods
  
Address notification that critical results exist, access to those critical results, and auditing notification/receipt of notification/receipt of results.
+
If a notification or result delivery fails or does not result in an acknowledgement:
 +
* need notification of timeout of confirmation
 +
* need an escalation strategy for notification
  
<<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 thatMight need an escalation strategy for contact, might also want to consider the whole followup chain>>
+
Consider the whole follow-up chainWhat actions should happen downstream (clinical treatment, followup diagnostics, etc.) and how should they be linked to the original finding?
 
 
===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===
 
===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.
 
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.
 
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.
+
==4. Standards and Systems==
 +
Systems involved could include reporting systems, departmental information systems, hospital and office communication systems, etc.
  
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.
+
The following standards have some overlap with the activities described in the problem section and may (or may not) be appropriate solutions.  
  
<<Could also log "understand" messages sent from recipient>>
+
PWP (Personnel White Pages) provides a way to look up some contact details (email address, phone number, pager, cell phone, fax, office number, etc) for some relevant staff.
  
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.
+
ATNA (Audit Trail and Node Authentication) provides a way to log events.  The current security application includes recording which doctor accessed which clinical data for which patient at what time.
  
 
DSG (Digital Signatures) might be useful if it is decided that strong tamperproof signatures (e.g. attesting receipt/understanding) are needed.
 
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.
+
XDS (Cross Enterprise Document Sharing) has a suite of profiles for conveying clinical results.
 +
 
 +
VOIP (Voice Over IP) and SMS provide methods to connect to phones from a computer.
 +
 
 +
There are likely other general purpose standards that may be useful too.
  
 
==5. Technical Approach==
 
==5. Technical Approach==
See some approach details in the Use Case and Standards sections above.
+
The following are just some ideas on a possible technical approach.
 +
 
 +
Digital communications are most amenable to triggering and auditing from systems.  Phone-based communications are ubiquitous and convenient so it would be difficult (inadvisable?) to prohibit their use, but we would need to consider whether they should be profiled since auditing would require supplemental mechanisms. 
 +
 
 +
===New integration profiles needed===
 +
Propose one new profile addressing locating people, notification and audit.
 +
 
 +
===Breakdown of tasks that need to be accomplished===
 +
 
 +
'''Identify the appropriate person to contact with the critical result'''
 +
* Some people will be listed in the order itself
 +
* Consider an extension of PWP or an Appointment/Scheduling Profile to determine who is on-call and/or currently responsible for the patient
 +
* Recognize that it might be appropriate to notify several people on the list
 +
 
 +
'''Identify methods to notify the selected person'''
 +
* Consider PWP to get URIs (points of contact) for selected people
 +
* May need an extension to span multiple organizations (the hospital, the clinic, the family physician)
 +
* Consider profiling additional communication channels
 +
 
 +
'''Log attempts to notify'''
 +
* Some notification methods may implicitly or explicitly generate a log, other methods would need a separate method for logging attempts
 +
* Consider logging messages to an audit repository
 +
 
 +
'''Convey the critical result details'''
 +
* List the likely types of results that would likely need to be communicated
 +
** Consider which could be communicated in the notification itself and which would need to be conveyed separately
 +
* List the many likely people who would be recipients
 +
* Inventory existing deliver methods, look for gaps
  
<<Note that we would address the electronic communications. Wouldn't address phones, but can't prohibit their use>
+
'''Log that the critical result was received'''
 +
* If the results are accessed from a system participating in the ATNA Profile, there would be a message in the audit log indicating when the recipient accessed the specific result document (e.g. in ATNA a Report Reader would send a log message with a physician retrieves and views any report)
 +
* It is an open issue whether it would be appropriate to use a privacy audit log for these purposes, whether a parallel receipt log should be generated (likely using the same transactions), or whether an audit log is the appropriate way to manage receipt at all
 +
* Assuming an audit log was used, it would be useful to have a query interface on the Audit Repository
 +
** The result producer could query for who had accessed the specific result to determine if appropriate people had received the result
 +
** If the initial critical finding was logged, a monitoring system could check for things that have "fallen through the cracks"
 +
** Quality systems could measure times to contact, or notification attempts
 +
* Additional data access log messages should be generated by other actors, e.g.:
 +
** an email system that receives a receipt message from a users mail client
 +
** an automated phone/pager system which receives an acknowledgement code from the recipient
 +
** a human working a call list who confirms that the doctors office has received the result fax
 +
* An additional audit message could be added which records that a recipient acknowledged understanding the result.
 +
* Past audit logs might be called up as part of legal proceedings
 +
* 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.
 +
 
 +
'''Inform the Producer that the critical result was (or was not) received'''
 +
* The producer system could query the audit repository
 +
* Alternatively a notification message of receipt could be sent to the producer system.
  
 
===Existing actors===
 
===Existing actors===
Line 145: Line 191:
  
 
===Impact on existing integration profiles===
 
===Impact on existing integration profiles===
''<Indicate how existing profiles might need to be modified.>''
+
Might need to extend PWP, ATNA or other profiles if used to support this new one.
  
===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==
+
==6. Support and Resources==
 
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''  
 
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''  
  
Line 180: Line 204:
 
[http://www.siimweb.org/index.cfm?id=2630 SIIM Presentations]
 
[http://www.siimweb.org/index.cfm?id=2630 SIIM Presentations]
  
 +
 +
A group of radiologists in the UK have [http://www.pacsgroup.org.uk/forum/messages/2/48026.html?1259184637 discussed use case and implementation details for critical results reporting].  (Note: a V10 of the document attached to the thread is available.)
 +
 +
 +
[http://www.diagnosticimaging.com/conference-reports/rsna2008/article/113619/1356061?cid=DIMAG-RSNA-120408 RSNA 2008 - Critical results findings: Prototype system tells you whom to call]
  
 
"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.  
 
"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
 
"We believe electronic alerting systems have a promising future in improving response to abnormal imaging results in the outpatient setting," he said
 +
  
 
[http://www.diagnosticimaging.com/cardiovascular/news/showArticle.jhtml?articleID=201800695&cid=CARDIO-news-monthly-091807 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.
 
[http://www.diagnosticimaging.com/cardiovascular/news/showArticle.jhtml?articleID=201800695&cid=CARDIO-news-monthly-091807 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.
 +
 +
 +
A study by Dr. Amy Musk from the VA Maryland Medical Center in Baltimore reported on rates of followup to abnormal findings in radiology reports.  [http://www.auntminnie.com/index.asp?Sec=sup&Sub=pac&Pag=dis&ItemId=79038&wf=2235 Aunt Minnie Article]
 +
 +
 +
[http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=61280 A 1998 Brigham and Womens Study in JAMIA] identified difficulty communicating critical results directly to the responsible caregiver as an important problem, quantified the problem and proposed some elements of the solution.  [http://www.auntminnie.com/index.asp?Sec=sup&Sub=ris&Pag=dis&ItemId=86080 Recent Brigham results were reported at SIIM 2009]
  
 
==7. Risks==
 
==7. Risks==
Line 191: Line 227:
  
 
* 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.
 
* 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.
 +
 +
* Many of the hospitals most interested in this topic (who would be the best IHE partners) have moved ahead in 2007, 08, 09 and implemented in-house solutions and may be less interested in working on an associated standards effort.
  
 
==8. Open Issues==
 
==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.>''
 
''<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.>''
 +
 +
Should this be dealt with as part of a cross-domain reporting profile?  These activities could be woven into the result delivery part of a reporting profile, however, it is unlikely a comprehensive cross-domain reporting profile will be completed in the near future so it might be better for this profile to start by assuming the existence of a finding/report and define the extraordinary delivery methods as described above, and leave routine delivery for a reporting 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)?
 
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)?
Line 200: Line 240:
  
 
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.
 
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==
 
==9. Tech Cmte Evaluation==
  
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):  
 
Effort Evaluation (as a % of Tech Cmte Bandwidth):  
:* 25% ...
+
:* In light of the cross-domain requirements and the likely use of IT profiles, the Radiology Technical Cmte felt it lacked the necessary expertise to perform the work efficiently and produce a sufficiently robust profile.
  
 
Responses to Issues:
 
Responses to Issues:
: ''See italics in Risk and Open Issue sections''
+
:
  
 
Candidate Editor:
 
Candidate Editor:
 
: TBA
 
: TBA
 +
 +
 +
[[IT Infrastructure Technical Committee]]
 +
 +
[[Radiology Technical Committee]]

Latest revision as of 13:43, 3 May 2012


1. Proposed Profile: Critical & Important Results

  • Proposal Editor: Kevin O'Donnell/Paul Nagy
  • Profile Editor:
  • Domain: IT/PCC - (Radiology/Cardiology/Path/Lab)

Summary

Procedures such as diagnostic imaging or labs regularly 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.

A recent article reconfirms the need for a solution and integration difficulties being experienced.

Associations with personel whitepages, and continuity of care should be clear.

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.


3. Key Use Case

When a "critical result" is identified by the producer of the result, a number of steps should take place:

Identify the appropriate person to contact with the critical result

  • The admitting physician and/or the physician who ordered the exam 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. Current guidelines recommend logging receipt of critical results. Logging receipt of routine reports is not common practice.
  • 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


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

  • alternative methods may be needed to reach the referring where they are
  • the urgency of the finding dictates different communication channels and timeframes for follow-up
    • impending death within the hour warrants direct methods and alarms
    • a potentially fatal cancer requires different communication and followup
  • Mechanisms should support the variety of timeframes, urgencies and contact methods

If a notification or result delivery fails or does not result in an acknowledgement:

  • need notification of timeout of confirmation
  • need an escalation strategy for notification

Consider the whole follow-up chain. What actions should happen downstream (clinical treatment, followup diagnostics, etc.) and how should they be linked to the original finding?

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 and Systems

Systems involved could include reporting systems, departmental information systems, hospital and office communication systems, etc.

The following standards have some overlap with the activities described in the problem section and may (or may not) be appropriate solutions.

PWP (Personnel White Pages) provides a way to look up some contact details (email address, phone number, pager, cell phone, fax, office number, etc) for some relevant staff.

ATNA (Audit Trail and Node Authentication) provides a way to log events. The current security application includes recording which doctor accessed which clinical data for which patient at what time.

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

XDS (Cross Enterprise Document Sharing) has a suite of profiles for conveying clinical results.

VOIP (Voice Over IP) and SMS provide methods to connect to phones from a computer.

There are likely other general purpose standards that may be useful too.

5. Technical Approach

The following are just some ideas on a possible technical approach.

Digital communications are most amenable to triggering and auditing from systems. Phone-based communications are ubiquitous and convenient so it would be difficult (inadvisable?) to prohibit their use, but we would need to consider whether they should be profiled since auditing would require supplemental mechanisms.

New integration profiles needed

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

Breakdown of tasks that need to be accomplished

Identify the appropriate person to contact with the critical result

  • Some people will be listed in the order itself
  • Consider an extension of PWP or an Appointment/Scheduling Profile to determine who is on-call and/or currently responsible for the patient
  • Recognize that it might be appropriate to notify several people on the list

Identify methods to notify the selected person

  • Consider PWP to get URIs (points of contact) for selected people
  • May need an extension to span multiple organizations (the hospital, the clinic, the family physician)
  • Consider profiling additional communication channels

Log attempts to notify

  • Some notification methods may implicitly or explicitly generate a log, other methods would need a separate method for logging attempts
  • Consider logging messages to an audit repository

Convey the critical result details

  • List the likely types of results that would likely need to be communicated
    • Consider which could be communicated in the notification itself and which would need to be conveyed separately
  • List the many likely people who would be recipients
  • Inventory existing deliver methods, look for gaps

Log that the critical result was received

  • If the results are accessed from a system participating in the ATNA Profile, there would be a message in the audit log indicating when the recipient accessed the specific result document (e.g. in ATNA a Report Reader would send a log message with a physician retrieves and views any report)
  • It is an open issue whether it would be appropriate to use a privacy audit log for these purposes, whether a parallel receipt log should be generated (likely using the same transactions), or whether an audit log is the appropriate way to manage receipt at all
  • Assuming an audit log was used, it would be useful to have a query interface on the Audit Repository
    • The result producer could query for who had accessed the specific result to determine if appropriate people had received the result
    • If the initial critical finding was logged, a monitoring system could check for things that have "fallen through the cracks"
    • Quality systems could measure times to contact, or notification attempts
  • Additional data access log messages should be generated by other actors, e.g.:
    • an email system that receives a receipt message from a users mail client
    • an automated phone/pager system which receives an acknowledgement code from the recipient
    • a human working a call list who confirms that the doctors office has received the result fax
  • An additional audit message could be added which records that a recipient acknowledged understanding the result.
  • Past audit logs might be called up as part of legal proceedings
  • 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.

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

  • The producer system could query the audit repository
  • Alternatively a notification message of receipt could be sent to the producer system.

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

New transactions (standards used)

Impact on existing integration profiles

Might need to extend PWP, ATNA or other profiles if used to support this new one.


6. Support and 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


A group of radiologists in the UK have discussed use case and implementation details for critical results reporting. (Note: a V10 of the document attached to the thread is available.)


RSNA 2008 - Critical results findings: Prototype system tells you whom to call

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


A study by Dr. Amy Musk from the VA Maryland Medical Center in Baltimore reported on rates of followup to abnormal findings in radiology reports. Aunt Minnie Article


A 1998 Brigham and Womens Study in JAMIA identified difficulty communicating critical results directly to the responsible caregiver as an important problem, quantified the problem and proposed some elements of the solution. Recent Brigham results were reported at SIIM 2009

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.
  • Many of the hospitals most interested in this topic (who would be the best IHE partners) have moved ahead in 2007, 08, 09 and implemented in-house solutions and may be less interested in working on an associated standards effort.

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

Should this be dealt with as part of a cross-domain reporting profile? These activities could be woven into the result delivery part of a reporting profile, however, it is unlikely a comprehensive cross-domain reporting profile will be completed in the near future so it might be better for this profile to start by assuming the existence of a finding/report and define the extraordinary delivery methods as described above, and leave routine delivery for a reporting 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):

  • In light of the cross-domain requirements and the likely use of IT profiles, the Radiology Technical Cmte felt it lacked the necessary expertise to perform the work efficiently and produce a sufficiently robust profile.

Responses to Issues:

Candidate Editor:

TBA


IT Infrastructure Technical Committee

Radiology Technical Committee