Upload
lamthuy
View
218
Download
0
Embed Size (px)
Citation preview
Real World Evidence: Research Driving Better Device Design
James E. Tcheng, MD - Duke
JaWanna L. Henry, MPH - ONC
Colleen Skau, PhD - AUGS
Terrie Reed, MS - FDA
1
Is Healthcare Changing for the Better …
Envisioned Reality EHR “Meaningful Use” EHR meaningless burden Usability and productivity Death by clicking Patient engagement AVS drivel
Effective clinical care CDS trivial pursuit Population health Resource consumption focus Bending healthcare cost curve Cost control and penalties Better provider work life NOT!
Torrent of real-world data Puddles of document exchange Big (clinical) data analytics Small transactions data Leveraged RCTs via registries 20th century paradigms
3
If you don’t know where you are going, chances are you will end up somewhere else.
Yogi Berra
If you don’t know where you are going, any road will take you there.
Lewis Carroll
Is Healthcare Changing for the Better …
What Should the Common Denominator Be?
Clinical documentation Registry reporting Quality and performance Supply chain Device safety, surveillance Clinical research RWD RWE (aka Real World Evidence) Computational constructs: CDS, AI, machine learning, etc.
Critical Step
Usage DFT Pt data Accession # UDI (DI + PI) Serial, lot # Expiration Procedure data
Pyxis
Procedure
Stations
BD CCE Care
Coordination
Engine
Lumedx Procedure
Documentation
Epic
Radiant EHR
SAP Replenishment JIT Ordering
SAP Item Master Orders ORM Pt data Accession, case # Procedure data Items data (ASCII)
Inventory replenishment data
What Does UDI Enable?
• Standardized device description procedure report – no more MD recall, transcription errors
• Inventory management (e.g., lower PAR levels, JIT supply chain)
• Device use attribution (e.g., waste, failure to deploy)
• Consignment device management
• UDI to the EHR (exported to the UDI device table)
• Device explants (e.g., CIED) – closing the loop
• Administrative reporting (e.g., device usage reports)
• Adverse event reporting (e.g., FDA MedWatch)
How Important is it to Identify an Implant?
Consumers: Decisions Within Days
Value of Device Lifecycle and Evaluation
Benefits of MDEpiNet for Patients, Clinicians, Industry,
Regulatory Agencies
Better product
• Better devices, faster to bedside for patients
• Improved pre-/post-market balance
Increased information
• Information on device risk/benefit
• Comparative effectiveness, cost-effectiveness
• Historical data (modeling; performance goals and criteria)
• Best practice guidelines
• Increased data sets for greater accuracy
Greater efficiency
• Interoperable collection and exchange of electronic health data
• Reduced regulatory burden
• Leveraging existing data for device evaluation
Registry Assessment of Peripheral Interventional Devices (RAPID)
• MDEpiNet RAPID project is designed to advance the foundational elements of the approach for the evaluation of medical devices used to treat and manage peripheral artery disease.
• RAPID is an archetype of the total product lifecycle (TPLC) ecosystem.
• It is one of a series of projects initiated to advance and demonstrate the interoperable flow of data across electronic health information systems.
• Is a key demonstration project of the approach of the National Evaluation System for Health Technology (NEST).
Why RAPID?
Current Challenge = Heterogeneity
• Devices (balloons, DCBs, stents, atherectomy, others)
• Patient and disease characteristics (severity, location, extent)
• Provider specialties (cardiology, vascular surgery, IR)
• Treatment options (permutations TNTC)
= Uncertainty!
• E.g. paclitaxel
Basic Principles for Success
• Developing uniform, core clinical concepts of harmonized definitions specific
to a particular area (= vocabulary)
• Defining relevant questions (e.g., is paclitaxel)
• Establishing quality by design principles to ensure data quality and ability of
registry to withstand audit (i.e., regulatory uses of data)
• Successfully addressing any relevant informed consent issues
• Sustainability
FDA
Coordinated
Registry
Networks
• Orthopedics (joint replacement) - ICOR
• Vascular intervention – VISION (RAPID)
• Cardiovascular disease – CDCRN (TAVR, etc.)
• CIEDs – EP PASSION
• Prostate ablation – SPARED
• Robotics
• Women’s Health Technology
• Hernia repair
• Neurology (stroke intervention) – DAISI
• Breast implants – NBIR
• GI (bariatric devices) – CATNIP
• TMJ
• Venous infusion catheters – VANGUARD
FDA Coordinated Registry Networks • Orthopedics (joint replacement) - ICOR
• Vascular intervention – VISION (RAPID)
• Cardiovascular disease – CDCRN (TAVR, etc.)
• CIEDs – EP PASSION
• Prostate ablation – SPARED
• Robotics
• Women’s Health Technology
• Hernia repair
• Neurology (stroke intervention) – DAISI
• Breast implants – NBIR
• GI (bariatric devices) – CATNIP
• TMJ
• Venous infusion catheters – VANGUARD
Evaluate maturity of Registries 1. patient engagement 2. capture UDI 3. data quality 4. efficiency 5. Governance 6. sustainability and 7. fitness for use Use (FHIR) profiles (produced
aligned with US Core Data for Interoperability (USCDI) requirements
Structured Capture UDI-DI and UDI-PI - ALL Device Systems
• Link to GUDID and capture in:
Adverse Event Reporting Systems
and Recall Systems
and Materials Management Systems
and Registries
And Reimbursement Systems
And…
• In Progress:
– HL7 FHIR Device Profile
– HL7 CCDA Implementation Guides
– HL7 WHT CRN Profile
Capture UDI DI + PI in HL7 US Core Data for Interoperability
Use the UDI to improve device data
Vascular Quality Initiative
22
Uterine Fibroids
Working Group
Pelvic Floor Disorders
Working Group
Sterilization/LARC
Working Group
Core Activities •Overall Project Coordination
•Develop data sharing framework, CRN metadata, analysis
•Data source quality and reliability analysis
•Develop linkage platform across datasets
•Develop sustainability plan
•Analyze priority CRN research questions
Core Leadership: FDA | ONC | NLM | AHRQ | MDEpiNet
Cross-Functional Activities
Clinical Working Groups | Informatics Working Group
• Harmonize and standardize minimal core datasets (with clinical groups), leveraging unique device identification (UDI) and
GUDID
• Develop HL7 FHIR Profiles and structured data capture methods to extract core datasets captured in routine care for use in the
CRN
• Conduct feasibility pilots to evaluate the ability of the CRN to address clinical questions
Multi-stakeholder Clinical Groups: Identify Core Datasets for each clinical area
CRN Project Overview
CRN Pilot Overview
Purpose
-Test the CRN capabilities mapped to specific actors and interactions of the technical specifications of the CRN IG in a test environment, production environment (e.g. clinical or provider setting) and/or manufacturing setting.
-The pilot site will also test the underlying standards and common clinical data sets, that are being developed as part of the CRN project for collecting and sharing women’s health data.
23
CRN Pilot Overview
24
Actors Capabilities
CRN Instrument and Metadata Repository 1. Ability to publish a CRN instrument.
External CRN Data Collection System
2. Ability to retrieve the instrument, render the instrument and collect the necessary data.
3. Ability to retrieve, render and autopopulate the CRN instrument and collect additional data.
4. Ability to retrieve, and render the CRN instrument and collect data and transform data into FHIR Resources.
Women’s Health Registry
5. Ability to receive CRN instrument and collected data.
6. Ability to receive CRN instrument, collected data and other FHIR Resources.
AUGS Pilot Overview
• The American Urogynecologic Society represents more than 1,900 members dedicated to treating female pelvic floor disorders including incontinence and pelvic organ prolapse – Members include surgeons, advance practice providers and trainees at various levels
• AQUIRE (AUGS Quality Improvement Registry) serves as a quality reporting tool
with benchmarking and outcome tracking
• Project team includes: – Charles Rardin, MD, MDEpiNet Physician Lead
• Serves as the volunteer lead for the WHT CRN – Colleen Skau, PhD, Research and Quality Programs Manager
• Serves as the staff point person for the WHT CRN – Michelle Zinnert, CEO
• Provides oversight and strategic support
25
AUGS Pilot Overview
26
# Capability Milestones Success Metrics
1 Ability to publish a CRN instrument
1. Standup a FHIR server. 2. Populate the server with the various CRN
instruments. 3. Implement the various search parameters.
Ability to publish a CRN instrument using FHIR APIs.
Ability to publish the different types of CRN instruments (Basic, Populatable, Extractable, Adaptive).
2 Ability to retrieve the instrument, render the instrument and collect the necessary data.
1. Implement a FHIR client. 2. Render the Questionnaire Resource. 3. Collect data. 4. Validate collected data with GUDID database. 5. Validate collected data with Terminology Server. 6. Create QuestionnaireResponse. 7. Post the QuestionnaireResponse to a registry.
Ability to retrieve and render a Basic CRN instrument.
Ability to collect data manually for a Basic CRN instrument.
Ability to post the collected data to a registry.
AUGS Pilot Overview AUGS Pilot
– The AUGS pilot utilized a SMART on FHIR Capable App to store data collection instruments; collect patient data based on the previously-defined data elements (pelvic organ prolapse surgery data elements); add data more easily to existing records; and, validate the collected data with AccessGUDID database.
– Data from the AccessGUDID database and its APIs are used to populate fields in the CRN Instrument being used for data collection (specifically the Device Lookup API and Parse UDI API). *The APIs to be used for accessing the GUDID can be found at GUDID Database APIs
27
AUGS Pilot Overview
• AQUIRE currently collects UDI as part of the Stress Urinary Incontinence Surgery Module
– Two methods of entry: manual or using a mobile app to scan the
barcode
– Based on UDI (and lot number if available), registry calls remaining data from AccessGUDID
28
AUGS Pilot Overview
29
AUGS Pilot Overview
30
AUGS Pilot Overview
• Working with ONC to stand up a FHIR server and FHIR app
• Clinical team finalizing the data elements for terminology in preparation for storing in the instrument repository – Instruments will be called by FHIR server: so far instruments include Basic
and Populatable but not Extractive
• AQUIRE module will be formalized as a point of data entry for providers
• AQUIRE calls information from AccessGUDID based on UDI – New module will continue this functionality
• AQUIRE sends patients questionnaires to provide feedback
31
AUGS Pilot Overview
32
• “Mobile” interface of the FHIR app • Scanning function not operational yet
• Remaining information is called from AccessGUDID using the Device Lookup API and Parse UDI API
• Manufacture Date and Serial Number are not printed on most products
• Data elements also include adverse events and intraoperative complications—how can we connect UDI information to adverse events/complications?
• Device malfunctions as well as other issues
AUGS Pilot Overview
• Issues with collection/use of UDI
– Manual collection is difficult and time-consuming
• Providers don’t always have easy access to the packaging with the UDI on it!
• Solution: collect with a barcode scanning app
– Lack of a unique identifier: the most specific information is lot number
33
AUGS Pilot Overview
• Future plans: how do we facilitate collection of UDI? – Is UDI captured in a standard way in EHRs?
– Prioritize capture of UDI in a way that make it accessible to clinicians/data entry
• Next task: how do we use UDI for more than adverse event reporting?
34