The OneSource Initiative: An Approach to Structured Sourcing of Key Clinical Data (for personalized care)
1. THE ONESOURCE INITIATIVE: AN APPROACH
TO STRUCTURED SOURCING OF KEY
CLINICAL DATA (FOR PERSONALIZED CARE)
Michael Hogarth, MD, FACP, FACMI
Professor, Internal Medicine
Professor and Vice Chair, Dept. of Pathology and Laboratory Medicine
http://www.hogarth.org
mahogarth@ucdavis.edu
2. Tailoring Care to Biology, Patient Preference,
and Clinical Performance
Personalized Medicine is the art of . . . .
3. Two Similar People Are Not . . .
Veronica
Age 51, 1 cm tumor
Screen detected
Works for Walmart
Post menopausal
Grade 1 ER+ tumor
No family history
Kim
Age 51, 1 cm tumor
Found on self exam
Self employed consultant
Recently divorced, single
mom
BRCA carrier
Pre menopausal
Grade 3 triple negative
tumor
Positive nodes
4. Key Elements to Provision Personalized Care
• Learning Healthcare Systems
– Systems that can evaluate care and continue to improve it
• Ability to adapt care based on data
– Personal level
– Systems level
• Precision Medicine:
– understand the disease and the host’s biology;
• To be more “precise” on disease and host response (precision
medicine!)
6. But… Sourcing clinical data has not changed with EHR use
- we continue to be burdened by “manually abstracting data”
6
“Where is that ER/PR Result?”
“Where is that outside MRI?”
“Did the path show invasion?”
”Where is that MammaPrint report?” post-EHR
1907 – ~today
(pre-EHR)
“Where is that ER/PR Result?”
“Where is that outside MRI?”
“Did the path show invasion?”
”Where is that MammaPrint report?”
8. Peeking inside a HIMSS Stage-7 EHR’s data
75% of records
have unknown race?
Nobody is older than 85?
(1) Only have dx for pts. admitted after
1984?
(2) Someone is pre-admitted for 2020....
35 million procedures are “unknown” type?
We have a procedure for someone
To be admitted 12 years from now
Only 659,000 records have a diagnosis
(UCDHS repository profiling 2014)
11. We need better data –
but can we do it?
Survey of 845 primary care providers
“48min loss of free time per clinic day per
physician”
information finding
takes time because
notes are bloated
and “new” or “key”
data is hard to find...
I don’t have time, so
I will cut & paste...
12. The EHR “clinical documentation conundrum”
o The Electronic Documentation Conundrum – “I have met the
enemy and it is I...”
• We EHR-using physicians generate large, verbose, narrative notes that
include auto-inserted unnecessary text (lab values, Rad reports) leading
to very poor readability
(the “note bloat” phenomenon)
• We physicians spend significant time foraging for key pieces of data in
our “bloated notes” which negatively impacts clinical care and physician
productivity
o The extent of productivity loss in US practices implementing EHRs
• A survey of 9 family practice physicians at 1 academic medical center.
Providers had 2+ years of experience with an EHRs
average 46 min of free time list per clinic day per physician
• Survey of 410 Internists (JAMA 2014- McDonald)
average of 42 min loss of free time per clinic day per physician
(1) http://www.redwoodmednet.org/projects/events/20130725/rwmn_20130725_mcdonald_v2.pdf
(2) McDonald, McDonald. Arch Intern Med. 2012. Feb 13;172(3):285-7
16. INSPIRE’s Vision
“Improve the acquisition and
exchange of patient data in high
impact conditions in order to support
care coordination, practice
improvement, and longitudinal
disease registries”
17. INSPIRE Approach to Data Capture
Providers fill out “electronic forms”
(templates) at key points of care
Ask providers to enter structured data
for key data elements only
Data is used for structured
sharing/exchange
(caCCD, CAP eCC, CDC-CDA)
18. A breast cancer “e-checklist”
(xml form/template rendered by system)
19. The idea is not new….
The CAP Electronic checklists XML Specification (eCC XML) c2013
20. Data Element Selection for Checklist
Clinical Data
Critical
Clinical
Data
Clinical Trial
Data
ASCO
Data
• Clinical Dataset captured on all
patients
• Identify subset that is critical
for decision making, reporting
– Elements vetted by over 50
clinicians across the UC
Medical System for clinical
and research importance
– Re-vetted by 50 clinicians for
functionality, adoption and
workflow
• Compare against Community
Data Standards
– ASCO, CAP, Cancer Registry,
NCI CTEP Common Data
Elements (for Clinical Trials)
21. INSPIRE Demonstration Project OneSource
‘capturing and exchanging key clinical data for care coordination in high impact conditions’
EHR
SDC
XML
Dynamic Form for Data Capture
(XML-driven and questionnaire like
with skip/branch, etc…. Rendered *within* EHR)
EHR 1
EHR 2
State Central
Cancer Registry
Community
HIE
Repository
ASCO/HL7
BTPS
ASCO/HL7
BTPS
ASCO/HL7
BTPS
ASCO/HL7
BTPS
23. Key Components of the
OneSource Framework
1) A data element core set for high impact
condition
2) OneSource forms delivered to EHR as
Structured Data Capture XML (SDC-XML)
3) OneSource form is loaded and rendered by
the primary system (EHR, CTMS, mobile, etc..)
4) OneSource forms can be co-authored by
clinicians on a single shared form viewable in
the primary system
23
27. OneSource: What are we really talking about?
• Fundamentally changing the documentation style
and data sourcing in EHRs!!
– Value based payment models will provide an
opportunity to think differently about
documentation
– Value-based documentation vs. volume-based
documentation
• “Clinical Data Checklists”
– A co-authored structured data documentation “tab”
in the EHR record
28. Will OneSource “clinical data checklists” just
cause more clinician angst?
• No, because OneSource forms have shared
authorship, which will decrease documentation time
• No, because OneSource data forms put key data in
one place in the chart – making it EASIER to find!
• No, because the clinical checklist has real value to
the clinician
– The effort is rewarded if clinicians document this way for
all patients with high impact conditions
– OneSource for “key data” – makes it EASIER to provide
good care
29. ONC SDC and IHE RFD –
“Remote Structured Forms”
RFD
SDC Additions
CRD DSC BFDR …
ONCSDC
Athena
core data
elements
30.
31. OneSource I-SPY2 Pilot – QoL ePatient; Clinical Data Checklist,
Structured Pathologist forms, Structured Radiologist form
Patient
Data
Checklist
Library
Store
Select
Pre-populate
Load
Submit
Archive
Import
32. The relevance of OneSource
in Clinical Trials
• ~25% of the cost of an investigational drug
phase III clinical trial is in the *verification* of
source data against what is being recorded in
the CRF and reported to FDA
• FDA eSource guidance allows data to be
directly submitted from EHR into a “eCRF”
with appropriate audit trail/controls
33. Clinical Trial Costs Breakdown
Operational costs of a trial are 80% of the cost of a
trial
30% of operational costs are source verification
In a $100M Phase III trial – source verification = $24M
34. OneSource and FDA eSource
FDA– “source data should be attributable, legible,
contemporaneous, original, and accurate (ALCOA)”
When using CRFs, best practice is for a first pass data
entry followed by a second pass or verification step by
an independent operator
FDA eSource guidance – Final Guidance, Jan 29, 2014
To encourage direct transmission of data from EHR record
to the eCRF
To encourage eCRFs vs. “paper”
If one sources data according to eSource guidance, source
verification/validation is not required
35.
36. Our Quest for High Quality Structured Data Does
not End with the EHR
• EHRs are an authoritative source of clinical care data
• BUT, EHRs are NOT the only source of the needed patient
data, now and even more so in the future
• A single source of truth is constructed from multiple
authoritative data sources:
Data
Source A
Data
Source D
Data
Source C
Data
Source B
VIEW
OF THE
TRUTH
37. Patient as a Source of Data -- Engaging Patients
Implementing Electronic Patient Reported Data (ePRI)
Athena Breast Health Network Screening Cohort
- 5 UC med centers, Sanford
- To date: 90,000+ questionnaires of women undergoing screening mammograms
- Automated risk models as a web service
- Composite 15yr risk of breast cancer provided to PCP
- Risk report fully integrated with EHR record
- High-risk referred to genetic counseling
38. 38
100,000 women
① Screening/Prev:
- ePRI
- breast cancer risk
② Dx/Rx/Survivorship
- EHR data, ePRI
- structured data
- comparative eff
- clin trials matching
One Longitudinal and Four Point-in-Time Schemas
The OneSource System lets a user complete a checklist containing a patient’s health history. The checklist data are represented in five domain models: SDC, HQS, FHIR, ODM and TRANSCEND.
The FHIR data model stores longitudinal health histories. In contrast, the other four schemas only support point-in-time data. The data flow from checklist selection to submission follows:
Structured Data Capture Schema (SDC)
The Office of the National Coordinator SDC standard specifies how forms can be exchanged between systems. SDC specifies both how forms are exchanged and the information in each exchange.
OneSource conforms to the IHE SDC schema and supports the following SDC Actors:
Form Filler completes a form for a particular patient
Form Processor provides an empty form and collects a completed form
Form Archiver archives a completed form
Health Questionnaire System Schema (HQS)
The Athena Breast Health Network collects patient questionnaires for breast cancer prevention and treatment. Athena HQS employs its own schema to represent the questions, answer choices and skip logic in each questionnaire. An Athena component named the Q-Engine (“Questionnaire Engine”) determines the question sequence from the skip logic.
The OneSource Form Filler leverages the Athena Q-Engine technology to render its checklists. Each checklist is translated from the SDC schema to the HQS schema. Completed checklists are translated from the HQS schema back to the SDC schema.
HL7 Fast Healthcare Interoperability Resources Schema (FHIR)
The HL7 FHIR data model represents longitudinal patient health history in a set of context-aware resources.
The OneSource Form Processor persists patient histories using the FHIR data model. Each new checklist pre-populates previously answered questions from the FHIR model. The pre-populated checklist is transformed into the SDC schema. Later, the completed checklist is translated from the SDC schema back to the FHIR model and persisted in the OneSource Form Processor.
The FHIR data model in the OneSource Form Processor is represented by a set of Salesforce custom objects. These FHIR custom objects are provided by the Salesforce Health Cloud app.
CDISC Operational Data Model Schema (ODM)
The CDISC ODM standard specifies how a clinical research Case Report Form (CRF) is exchanged between Electronic Data Capture (EDC) systems.
The OneSource Form Archiver persists each completed checklist as an immutable document. Checklists that represent clinical research are translated from the SDC schema into the ODM schema. ODM data elements are annotated with variable names from the Clinical Data Acquisition Standards Harmonization (CDASH) standard. Each therapeutic area has its own set of CDASH variable names.
I-SPY 2 TRANSCEND Schema
The TRANSCEND EDC system collects health information of participants in the I-SPY 2 clinical trial. This information is persisted in Salesforce relational custom objects that represent CRFs.
The TRANSCEND EDC system will populate its CRFs from OneSource checklists. TRANSCEND transforms each completed checklist sent by the OneSource Form Archiver from the ODM schema to the TRANSCEND schema. It then stores the checklist data into TRANSCEND CRF custom objects.