Use Case for Medical Product Safety Surveillance Using ... Slipstream... · use case, but the data...

Accenture 2006. All Rights Reserved.

Use Case for

Medical Product Safety Surveillance

Using Electronic Health Records

Version Number: FINAL

Version Date: November 22, 2006

Developed by: NHIN Slipstream Project *

* Contributing companies: Accenture, AstraZeneca, Bristol-Myers Squibb, Pfizer, and Wyeth

Slipstream Medical Product Safety Surveillance Version Number: FINAL

Use Case Document Version Date: November 22, 2006

Accenture 2006. All Rights Reserved. of 40

TABLE OF CONTENTS

Scope: ................................................................................................................................................... 4

Intent of this Use Case: ...................................................................................................................... 5

Data Element Requirements: ............................................................................................................. 6

Executive Summary: .......................................................................................................................... 7

Stakeholders:......................................................................................................................................... 9

Preconditions:...................................................................................................................................... 10

Obstacles:............................................................................................................................................ 14

Post-conditions: ................................................................................................................................... 16

Perspectives & Scenarios: ................................................................................................................... 19

Scenario 1: EHR-enabled Adverse Medical Product Reaction Reporting (ICSR)............................. 20

Scenario 2: Signal Detection of Medical Product Reactions ............................................................ 25

Scenario 3: Epidemiology & Exploratory Studies Using Longitudinal Data Analysis ........................ 28

Value Propositions:.............................................................................................................................. 30

Value Propositions Matrix:................................................................................................................ 30

Value Proposition Definitions and Key Metrics ................................................................................. 32

Glossary of Terms ............................................................................................................................... 38




TABLE OF FIGURES

Figure 1 – Stakeholders for Safety Surveillance Use Case .................................................................... 9

Figure 2 – Preconditions for Safety Surveillance Use Case ................................................................. 10

Figure 3 – Obstacles to Safety Surveillance Use Case ........................................................................ 14

Figure 4 – Post-Conditions for Safety Surveillance Use Case.............................................................. 16

Figure 5 – EHR-enabled Adverse Event Reporting .............................................................................. 20

Figure 6 – Centralized Process for ADR Investigation & Individual Case Safety Reports (ICSRs) ....... 21

Figure 7 – Stakeholder Perspectives: EHR-enabled Adverse Reaction Reporting (ICSR) .................. 24

Figure 8 – Signal Detection of Medical Product Reactions................................................................... 25

Figure 9 – Stakeholder Perspectives: Signal Detection of Medical Product Reactions........................ 27

Figure 10 – Epidemiology & Exploratory Studies Using Longitudinal Data Analysis............................. 28

Figure 11 – Stakeholder Perspectives: Epidemiology & Exploratory Studies Using Longitudinal Data Analysis ............................................................................................................................................... 29

Figure 12 – Value Proposition Matrix by Stakeholder and Use Case Scenario .................................... 31

Figure 13 – Glossary of Terms............................................................................................................. 38




Scope:

This use case defines the stakeholders, preconditions, obstacles, post-conditions, and detailed perspectives and scenarios involved with post-approval safety surveillance of pharmaceuticals and medical products. This use case aims to identify how specific elements of patient health information used in the context of care can be shared with pharmaceutical and medical product companies and regulators to support product safety surveillance. The use case is focused on the exchange of data from clinical sources to pharmaceutical and medical product companies and regulators and on how the data are employed by these groups in the execution of their missions.

Specifically, this use case will describe the process by which health information exchanges and electronic health records (EHRs) will enable pharmaceutical / medical product companies and regulators to better monitor and protect the safety of consumers using approved products through access to broader and deeper sets of patient health data. The use case scenarios will explain how enabling companies with access to higher quality patient information in larger quantities will enable more effective and efficient reporting of adverse events, better epidemiological study, and enhanced signal detection of health trends related to the use of medical products. These enhancements to product safety monitoring will benefit all stakeholders, including patients, physicians, other healthcare professionals, regulatory agencies, and medical product companies.

The scope of this use case will include the following:

� Evaluation of how electronic health records and patient data available via health information exchanges (HIEs) can be used to improve current processes and capabilities for the following post-marketing medical product safety surveillance activities:

o Reporting and evaluating individual adverse events (ICSRs)

o Detecting patterns of medical product effects, also referred to as signal detection

o Longitudinal data analysis related to the safety of medical products, including epidemiological studies

� Identification of data sources and data elements necessary to conduct the processes included in the scope of this use case. Data sources include hospital and ambulatory care systems, clinical data in payer systems, clinical trial data systems, pharmacy systems, laboratory systems, and other ancillary care data systems. Data elements include patient demographics, diagnostic data, chief complaints, triage data, laboratory orders and results, procedure data, prescription data, and physician orders.

� Determine which organizations and stakeholders should receive and manage patient data to support the processes and outputs defined in this use case.

� This use case will focus only on post-marketing safety and surveillance of product reactions reported by patients, physicians, and other healthcare professionals outside of clinical trials. This type of reporting is commonly referred to today as “spontaneous” reporting. This use case will not include safety surveillance of product reactions occurring during clinical trials.

� Wherever possible, existing data, workflows, and systems will be leveraged to minimize the barriers to participation in data sharing.




� This use case will consider the policies and processes related to medical product safety within the United States and in other countries around the world. Regulators around the world require the reporting of adverse product reactions, so we will assume a global view of safety issues. Initial implementations or pilot projects will likely focus on the United States.

� The use case will focus on a longer term vision of how health information networks can enable changes to medical product safety surveillance processes and technology. The details of this long term vision can be used to identify near, mid, and long term actions and proof of concept projects that can be conducted.

The scope of this use case will exclude the following:

� This use case will not include safety surveillance of medical product reactions occurring during clinical trials. It will only focus on “spontaneous” reporting outside of clinical trials.

� The specific requirements and design of signal detection algorithms will not be detailed in this use case, but the data elements necessary for signal detection and the way in which signal detection algorithms will be used to enable the use case will be included in scope.

� Definition and evaluation of the processes used to determine whether or not an adverse medical product reaction falls within the label statements will not be in scope.

� Identification of medication errors is not included in the scope of this use case.

Intent of this Use Case:

This use case document is meant to provoke thought and conversation about how electronic health records (EHRs) and emerging health information exchanges (HIEs) will enable improvement in medical product safety and surveillance. This document captures the thoughts and discussions of the Slipstream participants through a series of work group meetings, in which we aimed to describe future capabilities that could be built to improve the monitoring of product safety.

This document is a starting point for evaluating future projects and does not intend to prescribe the way that future capabilities will be built or that policy and regulation will change over time. Please consider the many challenges to the use of EHR data for product safety surveillance, which are listed in the preconditions and obstacles sections, as you read the use case scenarios.

We hope that this document generates discussion and debate of how medical product safety surveillance can be included in the analysis, design, and implementation of national health information technology initiatives in the United States.




Data Element Requirements:

Authorized users involved in direct patient care will be able to see patient identity data in the patient’s health record, according to the agreed privacy, security, and data access policies used in electronic medical record systems. Patient health data will be anonymized or pseudonymized prior to transmission from these source systems to third parties not directly involved in patient treatment so that it can serve secondary uses, such as medical product safety surveillance. Once data is pseudonymized, a randomized data linker may provide authorized entities the ability to re-identify the patient through the data provider. This should serve to protect the privacy and security of patient health information while allowing follow up investigation about specific adverse events or product reaction signals through the data provider.

Several types of data elements will be required to report adverse events, conduct epidemiologic studies, and continually execute signal detection algorithms. To obtain the full value of this use case, all data elements must be stored and transmitted using emerging standards, as defined by the Healthcare Information Technology Standards Panel (HITSP) and international standards bodies.

The general categories of data elements required to support the processes defined in this use case are:

1. Patient Demographics

2. Patient Health History Data

a. Allergies

b. Family History

c. Personal Health History (e.g. smoking, alcohol, bereavement, etc)

3. Clinical Practice Data

a. Visits

b. Diagnoses

4. Observation Data

a. Simple observations (height, weight, etc)

b. Laboratory results

5. Procedure Data

6. Pharmacy Data

a. Prescription Order

b. Dispense

c. Administration




7. Medical Product Exposure Data

8. Indication of Death & Cause of Death

9. Teratogenicity

Executive Summary:

The Medical Product Safety Surveillance use case includes three scenarios that improve the ability of stakeholders to better ensure the safety of medical products using electronic health records. Each scenario is described briefly below. The full details of the scenarios are located in the Scenarios & Perspectives section of this document.

EHR-enabled Adverse Medical Product Reaction Reporting (ICSR):

This scenario describes a process by which electronic health records (EHRs) exchanged through the Nationwide Health Information Network (NHIN) or other health information exchanges (HIEs) can enable better and easier reporting of suspected adverse reactions to medical products by healthcare professionals and patients.

When healthcare professionals with access to a patient’s electronic record report product reactions, a subset of information about the patient will automatically be populated in the adverse reaction form. The healthcare professional will enter additional information specific to the reaction and the suspected product(s). The reaction report will then be sent to an adverse reaction reporting service provider, who will accumulate all reported product reactions.

A similar process will be used to include electronic patient health information from the NHIN when adverse reactions are reported by a patient or his/her proxy, as long as the patient’s identity is provided along with the report. If the patient’s identity is not reported, no information will be retrieved from the NHIN, so it will need to be provided by the reporting party as in today’s reporting process.

Once adverse reaction reports are received by the service provider, the marketing authorization holder (MAH) for the product and the appropriate regulatory agencies will be notified of the report. The MAH will carry out any necessary investigation. All updates to the adverse reaction report will be made directly in one centralized system, which will facilitate workflow and visibility of the reaction report between the MAH and regulators. Regulators will review each report after the MAH completes its investigation and will either mark the report complete or ask the MAH for more information.




Signal Detection of Medical Product Reactions:

This scenario describes a signal detection capability that runs algorithms against electronic health records that are exchanged through the NHIN or other HIE. These algorithms will pick up signals of medical product reactions based on all patient information available via the HIE.

When signals are detected, the relevant product MAHs and the regulatory agency will be notified. The detected signal will also be recorded in a product knowledge base that makes available information about medical products and their safety. This knowledge base will allow stakeholders to see the status of a signal as it is investigated by the MAH and regulatory agency and will show the findings of all investigations when they are available.

The relevant MAHs will investigate the detected signal to determine its medical and statistical significance. They will update the record of the signal with their findings and report these findings to the regulatory agency using workflow capabilities within one central system for signal detection. Regulators will review each report after the MAH completes its investigation and will either mark the report complete or ask the MAH for more investigation.

Once results are available and reviewed by the regulatory agency, they will be added to the product knowledge base. Healthcare providers will be notified of any signal detection findings that may negatively impact patient safety.

Epidemiology & Exploratory Studies Using Longitudinal Data Analysis:

This scenario describes the use of longitudinal patient health data to improve the ability to conduct epidemiology and exploratory medical product safety studies. Researchers will be able to develop data analysis plans to carry out exploratory studies on anonymized patient health information available through health information networks (HIEs). Results from these queries and algorithms will be available to the researcher in a centralized system, which will then allow the researcher to share their findings, along with the data analysis plan and data set used for the study, with other stakeholders. This centralized system will allow all researchers to have access to the same patient health information when executing exploratory medical product safety studies or epidemiological research.




Stakeholders:

The following list of stakeholders and their definitions are for discussion purposes within the context of the use case.

Figure 1 – Stakeholders for Safety Surveillance Use Case

Stakeholder Working Definition

Patient

Members of the public who require healthcare services from ambulatory and emergency department environments, specifically those using medical products. If the patient is not capable of decision-making, a patient proxy may substitute for the patient in the use case processes.

Physician The treating physician(s) with direct patient interface in the delivery of care and prescribing of medical products.

Other Healthcare Professionals

Other healthcare providers with direct patient interface in the delivery of care and prescribing and dispensing of pharmaceuticals, including but not limited to nurses, clinical supervisors, and pharmacists.

Medical Product Company

Companies that discover, develop, manufacture, and market medical products.

Regulatory Agency Agencies, such as the Food & Drug Administration (FDA), that regulate the marketplace for medical products and aim to protect the health and safety of the consuming public.

Health Data Service Provider

A company or organization that collects, manages, and distributes patient and/or medical product information. This category may include government payer organizations, non-government payer organizations, integrated delivery networks, data aggregators, or other organizations that supply, collect, or process health data.

Safety Researchers

Researchers that conduct epidemiology and other types of data analysis to look for medical product safety patterns and investigate hypotheses about medical product reactions. Note: Policy decisions will determine who has access to patient health data and the capabilities described in this use case.

Healthcare Delivery Organization

Organizations, such as hospitals and physician practices, which manage the delivery of patient care.




Preconditions:

Preconditions are the conditions that must be in place before the start of the use case. This includes, but is not limited to, the state of a stakeholder, data that must be available somewhere, or an action that must have occurred. This section also includes triggers for the initiation of the use case and discussions of important assumptions made about the use case during its development. A variety of preconditions are necessary for this use case, including:

Figure 2 – Preconditions for Safety Surveillance Use Case

# Precondition Description Categories* Scen.

1: ICSR

Scen. 2: Signal Detect.

Scen. 3: Data

Analysis

1 Established network and policy infrastructures to enable secure, consistent, appropriate, reliable, and accurate information exchange.

� Data Exchange � � �

2

A consistent, agreed approach to anonymize and pseudonymize, including the following elements:

� list of patient data that must be removed to anonymized or pseudonymize

� ability to connect all data related to a patient or event to limit or prevent duplicates

� re-linking pseudonymized data by going back to the data provider

� Data Content

� Privacy � � �

3 Systems must be able to exchange components of patient health data in a way that links all data from one patient together to make up the health record.

� Identity Correlation

� Record Location

� � �

4

Healthcare facilities’ (i.e., hospitals, clinics, laboratories, physician practices, and ancillary clinical facilities) ability to electronically collect, process, and transmit pertinent health data in a secure fashion using existing data exchange and vocabulary standards.

� Data Content

� Security

� Data Translation

� � �

5

Consistent international regulations and policies regarding data privacy, transport, and ownership. Competing, conflicting, and/or confusing regulations have made previous technology and process improvements difficult to implement. (e.g. EMEA electronic reporting)

� Policy Alignment � � �

6

Agreement about who can use identified, anonymized, and pseudonymized patient health information, under what circumstances they can use it, for what purpose they can use it, and whether or not patient consent is required for data use.

� Data Usage

� Privacy � � �





1: ICSR


Scen. 3: Data

Analysis

7

Physicians and healthcare professionals must be trained and must always enter necessary data to support research and adverse event reporting in a structured, standardized format.

� Data Content � � �

8 Agreement to organization that will build and maintain the safety surveillance services.


9

Policy must be in place to designate who owns and is able to sell or authorize the sale of patient health data. Contractual terms and conditions must be agreed and well-defined to support the establishment of contracts to obtain patient health data from its owners/suppliers. Policies must consider both identified and anonymized data and indicate under what conditions patient consent is necessary to sell patient data.


10

All health information source systems must be connected to health information networks that can share the data necessary to make up the longitudinal health record of a patient.

� Data Content

� Data Exchange

� � �

11

EMR systems must be configured to allow healthcare professionals (HCP) to capture information about and report suspected adverse medical product reactions.

� Data Content

� Data Exchange

�

12

Agreement from the pharmaceutical and medical product industries and regulators on the processes and technology for a central system to collect, investigate, and report individual suspected adverse medical product reactions.

� Policy Alignment �

13

Definition of the minimum data set required for healthcare professionals or patients to report adverse events. This data set may differ from what is captured in today’s AE reporting forms.

� Data Content �

14

Agreement about authorization and role-based access rights to view and update adverse medical product reaction information at various points in the investigation and reporting process.

� Data Access

� Policy Alignment

� �





1: ICSR


Scen. 3: Data

Analysis

15

Agreement on where adverse medical product reaction information resides, the process to update this information, and whether it will be appended to a patient’s longitudinal record or will update a “living” patient record.

� Record Location


� �

16 Agreement about who can re-link patient health data for the purpose of investigating a suspected adverse medical product reaction.

� Data Usage

� Privacy � �

17

Agreement from the medical products industries and regulators on the processes and responsibilities for signal detection using a central shared system and electronic patient health data.


18

Agreement about who has permission and responsibility to create and maintain the algorithms used for signal detection of product reactions and outcomes.


19 Agreement about who governs and reviews the algorithms used to detect signals of product reaction and outcomes.


20 Development of new regulatory policies to govern signal detection of product reactions and outcomes.


21

Agreements about who will maintain, govern, and have access to a product knowledge base that will contain information about all detected product signals, including findings from MAH investigations.


22

Data from all provider systems, payer systems, laboratory systems, and other electronic data source systems that contribute patient data must be accessible in a manner that supports data analytics using algorithms and queries.

� Record Location

� Data Storage

� �

23 Agreements about who has access to conduct signal detection and exploratory studies using aggregated electronic health information.

� Data Usage


� �

24

Agreement about whether and/or how a consumer’s choice to restrict access to some or all of his/her electronic health information will be applied to anonymized and pseudonymized data.

� Data Content

� Privacy � �





1: ICSR


Scen. 3: Data

Analysis

25

Policies and agreements must be in place to govern access to patient health data, such that data available to one organization is available to equivalent organizations under the same terms and conditions.

� Data Access


� �

26

Determination of the standards that will be used to identify and credential researchers that wish conduct exploratory studies using electronic patient health information.

� Data Access

� Credentials �

* Categories are based on those used by the National Committee on Vital and Health Statistics (NCVHS) and the Office of the National Coordinator for Healthcare Information Technology (ONC) to evaluate requirements for the NHIN.




Obstacles:

In general, the absence of the prerequisites described in the previous section presents obstacles to implementation of the use case. Additional obstacles include an unwillingness to participate in activities due to perceived security and privacy concerns or to the lack of perceived value. These obstacles could affect several groups including:

1. Consumers / Patients: Must be adequately educated about the value of electronic health information and the security safeguards that are in place to protect their privacy and confidentiality.

2. Health facilities: Some health facilities may lack resources to implement the technology to collect, process, and transmit the necessary health information electronically.

3. Physicians & Healthcare Professionals: Must be adequately educated about the uses of electronic health data and the value derived from data entry that impacts their workflow. Without this education and understanding of the value of medical product safety surveillance, these professionals may not enter all data necessary to support this use case.

Additional obstacles include:

Figure 3 – Obstacles to Safety Surveillance Use Case

# Obstacle Description Categories* Scen.

1: ICSR


Scen. 3: Data

Analysis

1 Limited use of electronic medical record systems (EMRs) by physicians in small practices, who still rely primarily on paper records.


2

Inability of clinicians, laboratories, or healthcare delivery organizations to transform electronic data, using accepted standards, into filtered, normalized, and anonymized or pseudonymized form to enable data exchange. These organizations may require assistance with these capabilities to implement projects in the near- and mid-term.

� Data Content

� Data Translation

� � �

3

Limited access to connectivity capabilities for clinicians’, laboratories’, or healthcare delivery organizations’ systems to securely share data across the Internet. This is more likely to be an obstacle for small physician practices than for larger, integrated healthcare delivery systems. The ability for trial sponsors to aid these organizations in system implementation is limited by Stark and anti-kickback legislation.

� Data Exchange


� � �

4

Incomplete data within local EMR systems. Key elements necessary for medical product safety surveillance may not be available in the near- to mid-term.





# Obstacle Description Categories* Scen.

1: ICSR


Scen. 3: Data

Analysis

5

Unwillingness of healthcare delivery organizations to provide data management, including review of patient information to identify missing data elements necessary for medical product safety surveillance, manually enter data, and scan or manually enter historical information. This includes possible resistance of healthcare professionals to take on additional data entry that may affect their current workflow.


6

Unwillingness of current patient health information owners to share their electronic patient health information outside of their organization. This could be driven by fear of liability, the desire to sell the data, or the lack of perceived value in sharing the data.


7

Limitations on the ability of pharmaceutical companies to access identified, anonymized, and pseudonymized patient health information. These limitations may mean that a third party organization or government agency (e.g. FDA) will be required to collect, manage, and distribute adverse medical product reaction reports, aggregated patient health information, and maintain the central, shared systems described in this use case.

� Data Usage


� � �

8

Patient health information, including pharmacy information, will not be able to definitively indicate whether the patient actually took a medication, unless it was administered in an inpatient setting. Outpatient information will only indicate that the prescription was written and filled.


9

Unwillingness of physicians to change their current data capture practices and workflow to report suspected adverse medical product reactions and capture the necessary information about these events in an EMR system. This reluctance could be caused by fear of liability because the doctor prescribed the medical product that is believed to have caused the adverse event.

� Data Content �

10

If regulators determine that the systems used by healthcare professionals to electronically collect and report adverse event information fall within GxP or Part 11 requirements, the necessary validation efforts for the healthcare professionals’ systems would be an obstacle to implementation.





Post-conditions:

Post-conditions are the conditions that will be a result or output of the use case. This includes, but is not limited to, the state of a stakeholder upon conclusion of the use case, data that was created or is available at the conclusion of the use case, and actions that may serve as pre-conditions for other use cases. The post-conditions for this use case include:

Figure 4 – Post-Conditions for Safety Surveillance Use Case

# Post-Condition Description Categories* Scen.

1: ICSR


Scen. 3: Data

Analysis

1

Data sources will be able to electronically collect and exchange the data elements necessary for the medical product safety surveillance processes defined in this use case.


2

Data provided will support the privacy and security of patient health information, and also be responsive to requirements for re-linking the patient’s identity by authorized parties.

� Privacy

� Security � � �

3

Medical product marketing authorization holders (MAHs) and regulatory agencies will no longer need to maintain separate databases and systems for individual adverse reaction reporting, detection of patterns of medical product effects, and epidemiology and data analysis.

� Data Access

� Data Content

� � �

4

Medical product MAHs will not need to conduct as much additional investigation of adverse reactions, because more complete, higher quality adverse medical product reaction data will be collected electronically by healthcare professionals via EMR systems.

� Data Content

� Data Quality � �

5

Physicians will no longer need to complete paper forms or electronic forms through a website to report suspected adverse medical product reactions to marketing authorization holders (MAHs) and regulatory authorities, because they will be able to report them using their EMR systems with some data automatically populated from the patient’s electronic record. Ideally, this will lead to higher data quality and more frequent voluntary reporting of suspected adverse medical product reactions.

� Data Exchange

� Data Quality �





1: ICSR


Scen. 3: Data

Analysis

6

The number of duplicate records for suspected adverse medical product reactions will decrease, because the NHIN will be able to uniquely identify patients and link all pieces of their health record together to create the longitudinal patient record. Note: this only applies to electronic reports and those that identify the patient in a way that supports linkage to the patient’s electronic records.

� Identity Correlation �

7

Signal detection algorithms will be continuously executed against electronic patient health information to automatically identify patterns of product reactions and outcomes.

� Data Analytics �

8 Patterns detected by signal detection algorithms will be included in a product knowledge base, along with findings from investigations carried out by the MAH.


9

Product MAHs will be able to review patient records that have been flagged as part of a significant medical product reaction signal. They will evaluate detected signals to determine their statistical and clinical significance. This may include running additional studies to help evaluate the signal.

� Data Analytics

� Data Access �

10 MAHs will create reports of their investigations of significant signals in a central system.


11

Regulatory agencies will be able to access medical product reaction signal reports and the related patient records to review the findings of the MAH. Workflow capabilities will facilitate the review process and interactions between the MAH and the regulatory agency.

� Data Access

� Data Analytics

�

12

Medical product MAHs, regulatory authorities, and other researchers will be able to create, save, and execute epidemiological and other types of medical product safety surveillance studies using the same centralized, anonymized patient health data set and data model.

� Data Access

� Data Analytics

�

13

All stakeholders that conduct research on anonymized, electronic patient health data will be able to publish and share the results of their studies with other stakeholders using a shared system.






1: ICSR


Scen. 3: Data

Analysis

14

Stakeholders will be able to save snapshots of data at the time when their data analysis was executed. Stakeholders can share these data snapshots along with their findings. Additional data analysis can then be executed against the snapshots.

� Data Access

� Data Analytics

�

15

A larger sample size of electronic patient health information will be available for data analysis and studies, which will lead to higher power statistical analyses compared to the data available for these studies today.

� Data Access

� Data Analytics

�

* Categories are based on those used by the National Committee on Vital and Health Statistics (NCVHS) and the Office of the National Coordinator for Healthcare Information Technology (ONC) to evaluate requirements for the NHIN.




Perspectives & Scenarios:

Each scenario will be represented using visual diagrams that depict a combination of all events used in the scenario flow, an outline that defines each step of the scenario in greater detail, and a visual diagram that shows the steps in the process from the perspective of each stakeholder group.

The list of scenarios for evaluation in this use case is:

1. EHR-enabled Adverse Medical Product Reaction Reporting (ICSR)

2. Signal Detection of Medical Product Reactions

3. Epidemiology & Exploratory Studies Using Longitudinal Data Analysis

Each of these scenarios will be evaluated considering the reporting practices for medical product safety events in the US and other countries around the world. Preliminary efforts will focus on US medical product safety surveillance.




Scenario 1: EHR-enabled Adverse Medical Product Reaction Reporting (ICSR)

The first diagram below represents the process of using longitudinal, electronic patient health records to better enable healthcare professionals to report adverse events that they believe to be related to use of a medical product. The second diagram shows the process by which product marketing authorization holders (MAHs) and regulatory agencies interact through a centralized system to process Individual Case Safety Reports (ICSRs). The sections below the diagrams describe the sequence of events in more detail. The final diagram in this section shows the process from the perspective of each stakeholder group.

Figure 5 – EHR-enabled Adverse Event Reporting

Suspected ADR

Information

Entered in EMR

or Online AE

Form

Suspected ADR Data Sent to

Aggregator

Patient

Adverse Event

Occurs

Patient & Event

Data Collected for Suspected

ADR

Patient Suspects

Reaction &

Reports

HCP Has

Access to

NHIN

Record for

Patient?

No

Yes

Suspected ADR

Reported To or Discovered by

MAH

ADR

Suspected by

Healthcare

Professional

(HCP)?

ADR

Suspected

and

Reported by

Patient?

See ADR

Investigation

& ICSR

Diagram

NHIN Populates Patient Health

Information in ADR Record

ADR Information Entered in Paper

/ Electronic Form or Via Phone

Yes

Yes

No

ADR

Reported to

or

Discovered

by MAH?

AE Not

Reported

No

Yes

No




Figure 6 – Centralized Process for ADR Investigation & Individual Case Safety Reports (ICSRs)

MAH Marks ICSR

Complete

Regulator Reviews ICSR

& Investigation Results

MAH Investigates

Event

MAH Updates

ICSR

ADR Investigation

& ICSR

Complete

Is ICSR

Sufficient?

Yes

No

Regulator Marks ICSR Complete

Notification to Marketing

Authorization Holder (MAH) & Regulators

FromEHR-enabled

AE Reporting

Process Flow:

1. Patient Receives/Uses Medical Product and Experiences an Adverse Event

2. Medical Product Reaction Suspected & Reported:

a. Healthcare Professional (HCP) with Access to NHIN Record for Patient:

1. Physician or other HCP suspects that an adverse medical event was caused by a medical product. This determination may be made at the point of care or at a later time through review of the patient’s record or any other interaction with the patient.

2. HCP enters information specific to the suspected product reaction in an adverse reaction report form. This form may be presented in an EMR system or through an online, NHIN-connected service. The key advantage is that the patient’s identity can be connected to the reported information so that it can be incorporated into the patient’s longitudinal record, duplicate records can be decreased, and follow-up investigation can indicate the identity of the patient to the reporting HCP.

3. Additional patient health information required to report the suspected product reaction (e.g. medication history, lab data, diagnoses) is retrieved from one or more sources through the NHIN and entered into the reaction report form.




4. Information collected about the suspected product reaction and the relevant components of the patient’s health record are sent to the data aggregator as part of the report form.

b. Healthcare Professional (HCP) without Access to NHIN Record for Patient:

1. Physician or other HCP suspects that an adverse medical event was caused by a medical product. This determination may be made at the point of care or at a later time through review of the patient’s record or any other interaction with the patient.

2. HCP enters information related to the suspected product reaction and the patient’s health in a paper or electronic report form or collects the information in preparation to report the event via phone to the data aggregator.

3. Electronic and paper forms are sent to the data aggregator or the HCP calls the data aggregator to report the event. If the necessary identifying information about the patient is supplied, the data aggregator may be able to connect to the NHIN and link the event report to the patient’s health record. This will allow additional health information from the patient’s longitudinal record to be added to the report form, enable decreased duplication of event reports, and make follow up investigation about the event easier for the MAH and the reporting HCP.

c. Patient Suspects and Reports Reaction:

1. The patient or a proxy for the patient suspects that an adverse medical event was caused by a medical product. The patient or proxy reports the event directly to the data aggregator instead of a HCP.

2. The patient or proxy collects the information related to the suspected product reaction and the patient’s health in preparation to report the event.

3. The patient or proxy enters the collected information in a paper or electronic report form or calls the data aggregator to report the event via phone.

4. Electronic and paper forms are sent to the data aggregator or the HCP calls the data aggregator to report the event. If the necessary identifying information about the patient is supplied, the data aggregator may be able to connect to the NHIN and link the event to the patient’s health record. This will allow additional health information from the patient’s longitudinal record to be added to the event report, enable decreased duplication of event reports, and make follow up investigation about the event easier for the MAH and the reporting HCP.

d. Reported to or Discovered by the Marketing Authorization Holder (MAH)

1. A suspected product reaction is reported directly to a marketing authorization holder (MAH) by a patient, HCP, or other entity. Alternatively, the MAH discovers a suspected product reaction through literature or some other means.




2. The MAH collects the information related to the suspected product reaction and the patient’s health in preparation to report the event.

3. The MAH enters the collected information in a paper or electronic report form or calls the data aggregator to report the event via phone.

4. Electronic and paper forms are sent to the data aggregator or the HCP calls the data aggregator to report the event. If the necessary identifying information about the patient is supplied, the data aggregator may be able to connect to the NHIN and link the event report to the patient’s health record. This will allow additional health information from the patient’s longitudinal record to be added to the event report, enable decreased duplication of event reports, and make follow up investigation about the event easier for the MAH and the reporting HCP.

3. MAHs & Regulators are Notified of Suspected Reactions

a. Two models are feasible to inform regulators and marketing authorization holders (MAHs) of new suspected adverse reactions that have been reported. One model “pushes” alerts of new reports to the necessary parties and the other puts ownership on system users to “pull” information by logging into the system to check for new reports.

1. The “push” model uses the aggregator system to send alerts to the regulators and the MAHs of the products suspected of having caused an adverse reaction. This alert will contain information necessary to identify the event when the receiving party logs into the aggregator reporting system.

2. The “pull” model requires the MAH of the product to log into the aggregator reporting system to check for new events that they must investigate. This model also requires regulators to check the system for newly reported events of interest and completed Individual Case Safety Reports (ICSRs).

4. MAH Investigates Suspected Adverse Reaction

a. The MAH views the event report and analyzes the data received for the suspected adverse reaction.

b. The MAH conducts necessary follow up with the reporting physician / healthcare professional or the reporting patient for more information about the event.

c. The MAH updates the ICSR in the aggregator system with additional information from its investigation, including whether the reaction falls within labeled statements.

d. When all investigation and updates to the ICSR are complete, the MAH flags the ICSR complete and ready for review by regulators.

5. Regulators Review Adverse Reaction Report

a. The regulators review the completed investigation and all information in the ICSR completed by the MAH.




b. If the regulators feel that the investigation by the MAH is insufficient, they request additional information which reopens the case investigation.

c. If the regulators agree that the ICSR is complete and sufficient, they update the status of the ICSR to complete.

Stakeholder Perspectives:

Figure 7 – Stakeholder Perspectives: EHR-enabled Adverse Reaction Reporting (ICSR)

Patient or Proxy RegulatorPhysician /

Provider / HCPData Aggregator

1. Use Product and

Experience Event

5. Review Case

Report

5a. Review Case

Report

5b. If Incomplete,

Request Additional

Investigation

2a. Suspected by

HCP with NHIN

Access

2a.1. Suspect

Reaction Related to

Product

2a.2. Report Reaction

via EMR or NHIN

Service

3. MAH/Regulator

Notification

3a.1. Notifications

Pushed by Aggregator

3a.2. MAH/Regulator

Check for New

Reaction Reports

EHR-enabled Adverse Reaction Reporting

Marketing

Authorization Holder

4. Investigate Event

4a. Analyze Event

Report

4b. Conduct Follow-up

2b. Suspected by

HCP without NHIN

Access

2c. Patient Suspects

Reaction & Reports

2c.1. Suspect

Reaction Caused by

Product

2c.2. Collect Event

Information

4c. Update Case

Report

4d. Flag Case Report

for Regulator Review

5c. If Complete, Mark

Case Report

Complete

2d. Reported to or

Discovered by MAH

2b.1. Suspect

Reaction Related to

Product

2b.2. Collect & Enter

Event Information in

Paper or Electronic

Form

2b.3. Provide Event

Information / Form to

Data Aggregator

2c.3. Enter Event

Information in Paper

or Electronic Form

2c.4. Provide Event

Information to Data

Aggregator

2d.1. Learns of

Suspected Reaction

2d.2. Collect Event

Information

2d.3. Enter Event

Information in Paper

or Electronic Form

2d.4. Provide Event

Information to Data

Aggregator




Scenario 2: Signal Detection of Medical Product Reactions

The following diagram represents the process of using anonymized or pseudonymized electronic patient health data to detect signals related to the safety of medical products. The section below the diagram describes the sequence of events in more detail. The final diagram in this section shows the process from the perspective of each stakeholder group.

Figure 8 – Signal Detection of Medical Product Reactions

Product

MAHs &

Regulators Notified of

Signal

Signal

Detection Complete

Patient Medical

Outcomes Occur

Signal Detection

Algorithms are Constantly

Executed On

Patient Records

No Action

Required

Yes

No

MAH Marks Signal

Investigation

Complete

Regulators

Review Signal Report

MAH Investigates

Signal

MAH

Updates

Signal Record

Is the

Report Sufficient?

No

Yes

Signal

Detected?

Results Included in

Product

Knowledge

Base

Physicians Are Notified

of Signal Results

Product

Knowledge Base

Updated with Signal Info

Process Flow:

1. Patient Outcomes are Recorded

a. Patients experience medical events and are treated by physicians.

b. Patient outcomes are recorded in electronic medical records. Electronic health records are then available via the NHIN and/or other health information exchanges.




2. Signal Detection Algorithms are Executed

a. Algorithms are continuously executed against electronic patient health records to detect patterns of medical product reactions and outcomes. These patterns include unreported adverse events and reactions, as well as other positive and negative patterns of product effects.

3. Notification of Detected Signal

a. If the algorithms detect a signal, the regulatory agencies and relevant product Marketing Authorization Holders (MAHs) are notified of the detected signal.

b. Once the MAH and regulators are alerted of the signal, an entry will be made in the product knowledge base to indicate the presence of the signal and the status of investigation by the MAH and regulators. The product knowledge base will make information available about medical products and their safety. It will allow stakeholders to see the status of a safety signal as it is investigated by the MAH and regulatory agency and will show the findings of all investigations when they are available.

4. MAH Investigates Medical Product Reaction Signal

a. The MAH views the electronic health information about the patients identified as part of the signal in order to determine the medical and statistical significance of the signal.

b. The MAH conducts any necessary follow up with the physicians that treated the patients to acquire more information about the events, reactions, or outcomes.

c. If necessary, the MAH may decide to conduct additional studies (e.g. PK/PD, genetics, Pharmacoepidemiology, etc.) to evaluate the signal.

d. The MAH updates the signal investigation record, including whether the reaction falls within labeled statements.

e. When all investigation is complete and the signal record updated, the MAH marks the signal investigation record for review by the regulator.

5. Regulator Reviews Signal Report

a. The regulator reviews the completed report of the detected signal, including all information gathered during the investigation.

b. If the regulator feels that the investigation by the MAH is insufficient, it requests additional information and reopens the investigation.

c. If the regulator agrees that the signal report is complete and agrees with the findings, it marks the report as Complete.

6. Notification of Signal Report Findings

a. After the regulator has approved the signal report, the findings and all relevant data are included in the product knowledge base, so that the physicians, patients, and the public are provided full disclosure of the safety of medical products.




b. If the results of the signal investigation show that patients are at risk from using the medical product, physicians and healthcare providers will be notified of the new product safety information.


Figure 9 – Stakeholder Perspectives: Signal Detection of Medical Product Reactions

Patient RegulatorPhysician /

Provider / HCP

Signal Detection

Service

1. Patient Outcomes5. Review Signal

Report

5a. Review Signal

Report

5b. If Incomplete, Request Additional

Investigation

1. Patient Outcomes

1b. Treat Patient &

Record in EMR

2. Algorithms

Executed

2a. Algorithms

Continuously Executed

Signal Detection of Product Reactions

Marketing

Authorization Holder

4. Investigate Signal

4a. Analyze Records

& Determine Signal

Significance

4b. Conduct Follow-up

1a. Experience

Medical Event

4d. Update Signal Investigation Record

4e. Mark Signal

Record for Regulator

Review

5c. If Complete, Mark

Signal Report as Complete

3. Notification of

Detected Signal

3a. Notify MAH &

Regulators

3b. Update Product

Knowledge Base with

Signal Information

4c. Conduct Additional

Studies (if necessary)

6. Notification of Signal Findings

6a. Update Product

Knowledge Base with

Signal Findings

6b. Notify Physicians of Significant Signal

Results




Scenario 3: Epidemiology & Exploratory Studies Using Longitudinal Data Analysis

The following diagram represents the process of using anonymized electronic patient health data to understand the epidemiologic patterns of diseases, patient outcomes, and other significant insights about the safety of medical products and population health. The sections below the diagram describe the sequence of events in more detail. The final diagram in this section shows the process from the perspective of each stakeholder group.

Figure 10 – Epidemiology & Exploratory Studies Using Longitudinal Data Analysis

Create Data

Analysis Plan

Alert of Output

Sent to

Researcher

Share Data

Set, Methods,

& Conclusion

Execute Data

Analysis

Researcher

Initiates

Exploratory

Study

Researcher

Analyzes Results

& Draws

Conclusion

Desire to

Share

Results?

No

Yes

Refine

Analysis

Plan?

Abandon

Exploratory

Study

No

Yes

Process Flow:

1. Exploratory Study is Developed and Translated into a Data Analysis Plan

a. Researchers from medical products companies, regulatory agencies, academia, and other researchers develop exploratory studies for which they wish to use anonymized, electronic patient health data.

b. These researchers create data analysis plans for their research studies based on the available anonymized, electronic patient health information.

2. Data Analyses are Executed

a. Data analyses (in the form of queries or algorithms) are executed against the anonymized patient health data at a specified frequency to produce the designed output.




b. A notification of the data analysis output is automatically sent to the researcher, who can then login to see results.

3. Data Analysis Outputs are Analyzed & Shared

a. The researcher reviews the output of the data analysis and determines whether to share the results.

b. If the creator of the exploratory study does not want to share the results, s/he can revise the data analysis plan and have it re-executed or abandon the testing for this study.

c. If the creator of the exploratory study finds significant results and wants to share them, s/he can choose to share the data set, conclusions, and analysis plan with other stakeholders, including other researchers, regulatory agencies, and marketing authorization holders (MAHs). The data set can be shared using a snapshot of the data at the time the data analysis was conducted, and the analysis plan can be shared for use in additional studies. When results are shared in a snapshot data set, others can execute their own data analysis against the snapshot of data to conduct alternative studies.


Figure 11 – Stakeholder Perspectives: Epidemiology & Exploratory Studies Using Longitudinal Data Analysis

Researcher Data Analysis Service

1. Exploratory Study

Initiated

1a. Initiate Exploratory Study

1b. Study Translated

into Data Analysis

Plan

2. Analysis Plan Executed

2a. Analysis Plan is

Executed

2b. Notification of

Results Sent to Researcher

Epidemiology & Exploratory Studies Using

Longitudinal Data Analysis

3. Analyze & Report

Results

3a. Review Data Analysis Results

3b. If Do Not Want to Share Results, Revise

Analysis Plan

3c. Ability to Share Results & Data Set




Value Propositions:

This section will outline the value propositions related to the three scenarios identified in this use case. Each way in which the use case provides value to one or more stakeholder group(s) is outlined in this section along with a description of how the new processes and technology from these scenarios will enhance today’s capabilities for medical product safety surveillance. Key metrics will be identified to help quantify the value derived by the stakeholders.

The scope of this section will include:

� Explanation of the benefits and value created for each stakeholder group by each scenario described in the Safety Surveillance use case document.

� Key metrics that may be useful in quantifying the value of the use case.

� Some assumptions and challenges that may limit the value obtained by stakeholders.

The scope of this section will exclude:

� Quantification of the key metrics for each benefit to stakeholders.

� Recommendations for business models by which various stakeholders can contribute to the development and implementation of the scenarios described by this use case.

� Identification of proof of concept projects to demonstrate the value of the use case scenarios or how to overcome the preconditions and obstacles to achieve the value of the scenarios.

Value Propositions Matrix:

The table on the following page shows each of the value propositions, which stakeholders receive value, and which use case scenarios are involved in creating the value.

The value propositions are shown in the second column. The remaining columns to the right show whether each stakeholder group receives the stated value. Each cell will contain numbers that indicate which of the three use case scenarios provide the mechanisms that deliver the value to each stakeholder group.




Figure 12 – Value Proposition Matrix by Stakeholder and Use Case Scenario

Stakeholders Receiving Value

# Value Proposition Patients / Public

Physicians Other

Healthcare Professionals

Product MAHs

Regulatory Agencies

Safety Researchers

Payers

1 Ability to Conduct More Powerful Product Safety Analysis

1, 2, 3 1, 2, 3 2, 3 2, 3

2 Improved Response to and Reduced Impact of Product Safety Risks

1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3

3 Increased Ease for Healthcare Providers to Report AEs

1 1 1 1

4 Reduced Effort For AE Follow Up Investigation

1, 2 1, 2 1, 2 1, 2

5 Reduced Cost of Product Safety Surveillance

1, 2, 3 1, 2, 3 1, 2, 3

6 Improved Perception of Medical Products Industries

1, 2, 3 1, 2, 3

7 Reduced Cost of Medical Care Due to Adverse Product Reactions

1, 2, 3 1, 2, 3

8 Improved Ability to Detect Patterns of Unreported Adverse Events

2, 3 2, 3 2, 3 2, 3 2, 3 2, 3 2, 3

9 Proactive Feedback to the Standards of Care

1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3




Value Proposition Definitions and Key Metrics

The following subsections describe the potential value that can be provided to each stakeholder group through the three scenarios defined in this use case. Each subsection provides a description of the value proposition that explains how it improves on the current processes and systems used for medical product safety surveillance. It then lists one or more key metrics that can be used to quantify the value of the scenarios in this use case and compare them to today’s safety surveillance metrics.

1. Ability to Conduct More Powerful Product Safety Analysis:

Access to longitudinal, electronic patient health information through a Nationwide Health Information Network (NHIN) will provide the opportunity for improved product safety analysis, due to:

� Longitudinal patient health information from all sources in electronic format.

� Larger sample size of patient data through NHIN.

� Improved data quality, because data will come directly from EMR systems & will use accepted standards for terminology and transmission.

� Better understanding of denominator data (i.e. how many consumers use a product) for product safety analyses.

These enhancements to patient safety data will allow safety researchers to conduct more powerful statistical analyses, draw better conclusions, and make more complete assessments of product safety. The improved confidence and power of safety analyses conducted using these capabilities will lead to safer medical products.

The key metrics that may be useful in quantifying the value to stakeholders are:

� Time spent to draw safety analysis conclusions today versus when NHIN capability is available.

2. Improved Response to and Reduced Impact of Product Safety Risks:

The increased frequency and quality of adverse event reports and the ability to conduct product safety analyses on detailed population health information will allow faster, more targeted response to product safety risks. Improving the speed of response and the detailed understanding of safety concerns will reduce the negative impact of the safety risk on the population of consumers using the product. This will lead to many benefits, including:

� Earlier Awareness of Product Safety Risks:

i. More frequent voluntary AE reporting with higher quality data will allow companies to detect patterns of adverse events earlier.




ii. Active surveillance of product safety through signal detection using near real-time longitudinal population health record data will allow earlier detection of patterns of drug effects. This will allow MAHs to respond to safety risks more quickly.

2. Targeted Response to Product Safety Risk:

i. Longitudinal population EHR data will allow safety researchers to better understand the risks caused by products, especially when genomic data is more prevalent. Researchers may be able to determine subpopulations that are at higher or lower risk of a particular adverse event, whereas today they may think that all consumers are at high risk.

ii. This better understanding of the risk profile for various populations may allow the product’s use to be restricted only in high-risk populations, instead of removing a product from market entirely that may still have been valuable for lower-risk populations.

iii. Product use information in EHRs may enable products to be withdrawn from high-risk populations more efficiently.

� Reduce Financial Impact of Safety Risk for MAH:

i. MAHs may be able to change product labels to indicate populations at high-risk for an adverse event, instead of removing a product from market entirely as they might today. This reduces the financial impact of safety risks for MAHs while keeping a product on the market that is valuable for lower-risk consumers.

ii. Faster removal of products from the market and faster product label updates with safety warnings for newly identified high-risk populations should reduce liability for MAHs.

The key metrics that may be useful in quantifying the improved response and reduced impact of safety risks are:

� Compare the number of people affected by previous medical product safety risks and the percentage which had occurred when the product was withdrawn from the market. Estimate the percentage improvement that would be possible with the capabilities in this use case.

� Estimate the financial impact of faster awareness of and responses to previous medical product safety risks.

� Determine the time spent making label changes and informing HCPs of the new safety information. Estimate the impact of increased ability to notify impacted providers/patients using the capabilities in this use case.




3. Increased Ease for Healthcare Providers to Report AEs:

Today, healthcare providers (HCPs) that want to report adverse events have to complete a manual form or fill out an electronic form from scratch with information related to themselves, the patient, the products the patient uses, and the event that took place. Enabling electronic health records to automatically populate healthcare provider, patient, and medical product information in an adverse event report form makes the healthcare provider’s task of reporting adverse events much easier.

Ideally, making the AE reporting process easier for HCPs should promote increased voluntary AE reporting. Furthermore, using structured electronic health record data should increase the data quality and reduce the amount of data that may be missing from many of today’s AE reports.

The key metrics that may be useful in quantifying the value of easier AE reporting are:

� The percentage of adverse events that are voluntarily reported in the US.

� The amount of time that HCPs spend for each adverse event report.

� The number or percentage of HCPs that do not report adverse events today, because the process is too burdensome.

� Determine what would be an acceptable amount of time to spend for an AE report, such that a HCP would increase his or her frequency of reporting AEs.

4. Reduced Effort For AE Follow Up Investigation:

Many adverse event reports today are submitted without all of the information needed by the MAH to evaluate the event. Furthermore, many of today’s AE reports are submitted without a code by which the reporter will remember which patient experienced the event. In these situations, it is very difficult for the MAH to conduct the necessary follow up investigation of the event with the reporting HCP.

Enabling EHRs to automatically populate information in AE report forms should improve the data quality and completeness of AE reports. Furthermore, supplying an opaque patient identifier for the patient referenced in the report may better enable the reporting HCP to identify the patient when the MAH contacts the HCP for follow up investigation. Both of these improvements will reduce the effort necessary for both the MAH and the reporting HCP during adverse event follow up investigation.

The key metrics that may be useful in quantifying the reduced effort for follow up investigation are:

� Average hours of effort to follow up on AE reports. Consider time from the MAH and the reporting HCP.

� Average number of follow-up investigations due to poor data quality that are necessary per reported adverse event.




� Percentage of adverse events that are reported with missing data or poor data quality.

� Percentage of adverse event reports that come from a HCP and contain some form of patient identifier.

5. Reduced Cost of Product Safety Surveillance:

In today’s regulatory and product safety environment, each MAH and the regulatory agency maintains its own information systems to receive, manage, and respond to adverse event reports. This use case describes a centralized system that would allow all MAHs and the regulatory agency to use the same system to receive and process adverse event reports and conduct signal detection investigation.

This would allow the medical products industry to remove this duplicate infrastructure by using one centralized system with workflow capabilities. The EHR-enabled adverse event reporting and signal detection using population EHR data would also potentially minimize the cost of conducting Phase IV clinical trials, which could possibly be done using proactive surveillance with EHR data in real-time.

Depending on the cost to access the new, centralized capabilities, organizations could potentially save money by using these centralized systems to conduct AE processing and proactive Phase IV type product surveillance. It is also important to consider that there may be increased costs of risk assessment and management with this approach, because additional resource could be required to evaluate increased volume of product safety signals.

The key metrics that may be useful in quantifying the cost reduction are:

� Average spend of MAHs & regulators on product safety systems per year.

� Average spend of MAHs on Phase IV safety-oriented clinical trials per year.

� Average number and cost of resources to evaluate product safety signals.

6. Improved Perception of Medical Products Industries:

In the past few years there has been a lot of media attention related to medical product safety. Several product safety problems have led to negative impressions of the medical products industries’ and regulators’ efforts related to product safety. The capabilities described in this use case could allow more active safety surveillance through EHR-enabled adverse event reporting and signal detection capabilities that increase the transparency of product safety efforts.

These enhanced product safety systems and processes would hopefully increase the public’s perceptions of medical product safety due to added transparency of detected adverse events and safety signals and the new speed and specificity in the ways MAHs react to detected safety risks. All of these things would also increase the public’s perception of the regulatory agency’s safety monitoring processes.




The key metrics that may be useful in quantifying the improved public perception are:

� Percentage of people surveyed that feel that medical product industry and regulatory efforts to ensure product safety are sufficient.

7. Reduced Cost of Medical Care Related to Adverse Product Reactions:

The improved safety surveillance capabilities in this use case enable faster response to and reduced impact of detected product safety risks. This should, in turn, lead to reduced overall medical costs related to treating adverse product reactions, because safety risks will be detected earlier and understood in more detail. Product usage by patients that are at high risk of the detected adverse product reactions can be detected and instructed to stop using the product before they experience an adverse medical event, which avoids the cost of treating the prevented event.

The key metrics that may be useful in quantifying the reduced medical costs related to adverse product reactions are:

� Average cost of treating a particular adverse event that could be prevented by earlier detection and better response.

� Estimated number of these particular adverse events that could have been prevented with earlier detection and better response.

8. Improved Ability to Detect Patterns of Unreported Adverse Events:

The signal detection and longitudinal data analysis scenarios described in this use case will allow safety researchers to detect patterns of adverse events that seem related to a particular product, even if these adverse events were not reported by HCPs or patients. Not all adverse events will be reported to MAHs and regulators, because HCPs may not realize that the event is a reaction related to the use of a particular medical product.

Today, signal detection is mainly conducted against reported AEs, which only contains the small percentage of adverse events that are reported. Even when researchers today use broader data sets purchased from insurance companies and healthcare providers, the databases do not make up longitudinal electronic records that tie all information about a patient together. Executing signal detection algorithms and conducting analysis of longitudinal EHR data across a large population will allow researchers to find patterns they may not observe today, analyze them in more detail, and determine the true nature of the safety risk.




The key metrics that may be useful in quantifying the improved detection of patterns of unreported adverse events are:

�

9. Proactive Feedback to the Standards of Care:

When product safety information is available from EHRs for large populations in real time, safety researchers will be able to better evaluate the nature of safety risks for various subpopulations. The inclusion of genomics data electronically in EHRs will enable researchers to derive even more insight of product safety and will enable more personalized evaluations of the standards of care for various conditions.

When safety researchers are able to determine that certain subpopulations are at higher risk than others, they can help educate physicians, patients, and the public of these risks to inform decisions of which product is right for each patient. It may even be possible to provide product safety information tailored to an individual based on his/her EHR. This will lead to better overall product safety by providing proactive feedback to the standards of care for conditions based on better understanding of product safety risks.

The key metrics that may be useful in quantifying the value of proactive feedback to the standards of care are:

�




Glossary of Terms

The following table provides definitions for terms that are used throughout this use case document.

Figure 13 – Glossary of Terms

Term Working Definition

Anonymized Data Data that has been rendered non-attributable to a specific individual by removing identifying information.

Pseudonymized Data

Data that has been manipulated so that real-world identifiers for the specific individual have been removed, and an alternative identifier added. Such identifier may, or may not, be used consistently across multiple data sets. Such identifier may, or may not, be reversible to permit the identification of the patient.

Marketing Authorization Holder (MAH)

Company responsible for the marketing of a medical product. This company is also responsible for regulatory commitments related to post-marketing product safety.

Individual Case Safety Report (ICSR)

A report that describes an adverse experience(s) for a patient or clinical trial subject. Individual case safety reports of domestic adverse experiences for marketed human drug and biological products, except vaccines, must be submitted to the FDA on FDA Form 3500A; a Vaccine Adverse Event Reporting System (VAERS) form must be used for adverse experiences associated with the use of vaccines.

Teratogenicity The capability of producing fetal malformation. In terms of product safety, this term relates to the effects on a child when a mother uses a medical product during pregnancy.

Spontaneous Reporting

The reporting of adverse events that are believed to be related to an approved, marketed medical product. This does not include adverse events that occur during pre-approval clinical trials. This reporting may be mandatory or voluntary, depending on country regulations.

Epidemiology The branch of medicine that deals with the study of the causes, distribution, and control of disease in populations.





Pharmacoepidemiology

The science concerned with the benefit and risk of medical products used in populations and the analysis of the outcomes of medical product therapies. Pharmacoepidemiologic data come from both clinical trials and epidemiological studies with emphasis on methods for the detection and evaluation of medical product-related adverse effects, assessment of risk vs. benefit ratios in medical product therapy, patterns of medical product utilization, the cost-effectiveness of specific medical products, methodology of post-marketing surveillance, and the relation between pharmacoepidemiology and the formulation and interpretation of regulatory guidelines.

Electronic Health Record (EHR)

All electronic information related to the health of one patient/consumer that exists. This information may be located in many different source systems in different organizations and geographies.

Electronic Medical Record (EMR)

All electronic information related to the health of one patient/consumer that exists within the systems of one organization/entity. This information may reside in more than one system, but those systems must all reside within one organization.

Personal Health Record (PHR)

Electronic health information that a patient/consumer has collected from one or more sources for the purpose of understanding his/her health status and sharing it with his/her physician(s).

Nationwide Health Information Network (NHIN)

A nationwide health information network is not a single entity, but a system of systems. It is envisioned that such a network would provide for the secure exchange of health information for many uses, in multiple ways, and by a number of different health information network providers. A nationwide health information network can also address needs relative to security services, privacy protections, and methods to identify (or de-identify) individuals who are the subject of the health information exchanged.

Health information exchanges (HIEs)

Networks that have been established to exchange health information among several healthcare organizations.

Interoperability The ability to exchange and use information (usually in a large heterogeneous network made up of several local networks).

Longitudinal health record

The accumulation of all health-related information about an individual from many clinical encounters over a long period of time. This information may be contained in many different healthcare provider locations.





Product knowledge base

The product knowledge base describes a possible future capability that could make information about medical products and their safety available to healthcare stakeholders and the public. It could allow stakeholders to see the status of a medical product safety signal as it is investigated by the MAH and regulatory agency and could show the findings of all adverse medical product reaction investigations when they are complete and reviewed by the regulatory agency.

Use Case for Medical Product Safety Surveillance Using ... Slipstream... · use case, but the data...

Documents

Transcript of Use Case for Medical Product Safety Surveillance Using ... Slipstream... · use case, but the data...