Difference between revisions of "Critical Results - Detailed Proposal"

From IHE Wiki
Jump to navigation Jump to search
Line 9: Line 9:
  
 
===Summary===
 
===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.">''
+
Physicians need to recieve appropriate notification of critical results generated by procedures such as diagnostic imaging.  
  
''<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.">''
+
Producers of such results (such as radiologists) need flexible methods of identifying, locating and contacting a responsible caregiver.
  
''<Summarize in a few lines how the problem could be solvedE.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.">''
+
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 themThey also need a legal record of having attempted and achieved contact.
  
''<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.">''
+
Many of these things are difficult and poorly done today, and patient care suffers.  
  
''<Summarize in a line or two why IHE would be a good venue to solve the problemE.g. "The main challenges are dealing with the chicken-and-egg problem and avoiding inconsistent implementations.">''
+
Profiles such as PWP, IAN, ATNA, etc are potentially part of the solutionMany existing general purpose communication and notification methods could also be used.
 +
 
 +
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.
  
  
Line 59: Line 63:
 
==4. Standards & Systems==
 
==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.
+
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.
 
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.
Line 66: Line 70:
  
 
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.
 
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==
 
==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.>''
+
See some approach details in the Use Case and Standards sections above.
 
 
''<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===
 
===Existing actors===
Line 104: Line 85:
  
 
===New transactions (standards used)===
 
===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===
 
===Impact on existing integration profiles===
Line 110: Line 91:
  
 
===New integration profiles needed===
 
===New integration profiles needed===
''<Indicate what new profile(s) might need to be created.>''
+
Propose one new profile addressing locating people, notification and audit.
  
 
===Breakdown of tasks that need to be accomplished===
 
===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.>''
+
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
 +
 
 +
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
  
 
==6. Support & Resources==
 
==6. Support & 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.>''  
 +
 +
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.
 +
 +
[http://www.siimweb.org/index.cfm?id=2630 SIIM Presentations]
  
 
Need a champion for development.
 
Need a champion for development.
 +
 +
"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
 +
  
 
==7. Risks==
 
==7. Risks==
Line 129: Line 135:
  
 
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?
 
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==
 
==9. Tech Cmte Evaluation==
  
 
<The technical committee will use this area to record details of the effort estimation, etc.>
 
<The technical committee will use this area to record details of the effort estimation, etc.>

Revision as of 00:32, 15 September 2007


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.

Profiles such as PWP, IAN, ATNA, etc are potentially part of the solution. Many existing general purpose communication and notification methods could also be used.

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.

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.

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

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

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)

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

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

6. Support & Resources

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

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

Need a champion for development.

"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


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?

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

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