Difference between revisions of "Detailed Proposal"

From IHE Wiki
Jump to navigation Jump to search
Line 29: Line 29:
  
 
==5. Technical Approach==
 
==5. Technical Approach==
''<This section can be very short but include as much detail as you likeThe Technical Committee will flesh it out when doing the effort estimation.>''
+
<p> The technical approach to RPE takes RFD as a point of departure.   
  
''<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.>''
+
The actors of RPE take their name and some notion of their roles from RFD:
 +
* Protocol Executor resembles Form Filler, the EHR-based actor that receive the task instruction and executes it
 +
* Protocol Manager resembles Forms Manager
 +
* Protocol Recorder resembles the Forms Receiver
  
''<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.>''
+
Transactions map to RFD's transactions:
 
 
 
 
===Existing actors===
 
''<Indicate what existing actors could be used or might be affected by the profile.>''
 
 
 
===New actors===
 
''<List possible new actors>''
 
 
 
 
 
===Existing transactions===
 
''<Indicate how existing transactions might be used or might need to be extended.>''
 
 
 
===New transactions (standards used)===
 
''<Describe possible new transactions (indicating what standards would likely be used for each.  Transaction diagrams are very helpful here.  Feel free to go into as much detail as seems useful.>''
 
 
 
 
 
===Impact on existing integration profiles===
 
''<Indicate how existing profiles might need to be modified.>''
 
 
 
===New integration profiles needed===
 
''<Indicate what new profile(s) might need to be created.>''
 
 
 
 
 
===Breakdown of tasks that need to be accomplished===
 
''<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>''
 
  
 
==6. Support & Resources==
 
==6. Support & Resources==

Revision as of 09:40, 18 November 2008

1. Proposed Profile: Retrieve Protocol for Execution

  • Proposal Editor: Landen Bain, CDISC
  • Profile Editor: Diane Wold, Glaxo Smith Klein; Peter Villiers, SAS
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Quality, Research, and Public Health

Summary

The ITI profile Retrieve Form for Data-capture, along with its complementary content profile Clinical Research Data-capture, set a path towards integrating the site-based workflow of a clinical trial into the task manager of an electronic health record.

CDISC's Protocol Representation team intends to develop a standard document, derived from the BRIDG, a RIM-linked data model. This protocol representation includes a Trial Design Model a standard structure for representing the planned sequence of events and the treatment plan of a trial. This planned sequence of events includes many tasks that could be executed in an EHR. The 'schedule of activities' section of the trial design includes clinical trial activities such as interventions (e.g., administering drug, surgery) and study administrative activities (e.g,. obtaining informed consent, distributing clinical trial material & diaries, randomization) as well as assessments. The time is ripe to insert these executable workflow tasks into the EHR for execution within the site's normal way of doing business.

2. The Problem

Research protocols are complex instruction sets that guide the conduct of trials. A subset of the protocol pertains to the activities of the healthcare provider site that participates in the trial. This instruction set specifies the data to be captured, tests to be ordered, inclusion and exclusion criteria for subjects, number and type of visits, etc. These instructions currently reside in hard copy binders which provide guidance for study coordinators at research sites. What is desired is a way to insert protocol instructions into an EHR for automatic completion.

3. Key Use Case: Investigational New Drug Clinical Trial

The setting for the clinical trial use case is a physicians’ practice where patient care is delivered side-by-side with clinical research. The site, Holbin Medical Group, is a multi-site physician practice, employing over 100 physicians in a variety of specialties. Holbin’s CEO encourages the physicians to participate as site investigators for pharmaceutical-sponsored clinical trials; Holbin provides support for clinical research activities in the form of a Research Department of twelve dedicated study coordinators, mostly RNs, along with clerical and data-entry support personnel. Holbin Medical Group uses an Electronic Health Record (EHR) and a number of sponsor-provided Electronic Data Capture (EDC) systems for documenting clinical trial activities. (For our purposes, an EHR is any application which is the primary site for documenting patient care, and retrieving patient care information. Thus we include in our span of interest many systems installed today that are not quite EHRs in the strictest sense, but which would still benefit from this approach.)

Holbin’s involvement in a clinical study begins when the Research Department receives a request for proposal from a study sponsor. A Study Coordinator, Patricia Zone, RN, evaluates the RFP for business viability and clinical appropriateness, and provides the requested documentation back to the sponsor. After being selected as a site for the trial, identified as #1234, and providing the required regulatory documentation to the sponsor, the physician identified as the Principal Investigator and other study personnel receive protocol-specific training from the sponsor. During the trial set-up period, Patricia ensures that the appropriate system security is in place for this protocol, recruits patients to participate as subjects according to inclusion and exclusion criteria described in the study protocol, schedules patient visits, manages data capture and data entry, and performs all the attendant financial tasks.

Patricia contacts Corey Jones, a patient at Holbin, about participating in the trial, and Corey agrees to participate as a subject. Patricia registers Corey in the EHR as a subject in trial #1234, using the EHR’s patient index. She schedules Corey’s study visits using the EHR scheduling module, and flags the visits as pertaining to the trial #1234. After the set-up stage, the site initiates clinical trial care and trial-specific documentation. The use case continues with current state and desired state scenarios, which describe data capture utilizing EDC technology during a patient clinical trial visit before and after the RFD implementation.

4. Standards & Systems

  • Standard Protocol
  • RFD
  • Business Processing Management standards (OASIS)

5. Technical Approach

The technical approach to RPE takes RFD as a point of departure. The actors of RPE take their name and some notion of their roles from RFD:

  • Protocol Executor resembles Form Filler, the EHR-based actor that receive the task instruction and executes it
  • Protocol Manager resembles Forms Manager
  • Protocol Recorder resembles the Forms Receiver

Transactions map to RFD's transactions:

6. Support & Resources

  • RFD scenario teams: Pfizer, Lilly, Novartis, Genzyme, et al.
  • Lisa Chatterjee, DIFZ, chair of CDISC’s Protocol Representation team
  • Diane Wold, GSK, chair of CDISC’s Trial Design team
  • Peter Villiers, SAS, developer of ODM extensions to express Schedule of Activities


7. Risks

<List technical or political risks that could impede successfully fielding 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.>

<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>