technology models for building health information infrastructure ii
DESCRIPTION
Technology Models for Building Health Information Infrastructure II. Mike Epplen VP Product Management Quovadx Inc. [email protected]. Agenda. Health Information Access Challenge Care Data Exchange Technology Model Additional Models for Success Summary: Key Enablers. - PowerPoint PPT PresentationTRANSCRIPT
Technology Models for Building Health Information
Infrastructure IIMike Epplen
VP Product ManagementQuovadx Inc.
2
Agenda
• Health Information Access Challenge
• Care Data Exchange Technology Model
• Additional Models for Success• Summary: Key Enablers
3
The Healthcare Information Access Challenge
• Healthcare is a personal and local phenomenon– Patient information is found across
the community• Personal – over the counter medicines• Hospital Care Delivery• Physician Care Delivery• Government• Private Insurers – Medical
Management
4
The Healthcare Information Access Challenge
• Systems supporting Healthcare information are diverse– Best of Breed - Multiple Vendors service different
areas– Best of Suite - Single Vendors acquire and
migrate platforms– Standards allow different interpretations of the
same content – medical terminology and transaction standards
– Process for person identification vary from site to site and source to source
• Information Use is affected by processes which are unique and ever changing– Government regulations– Improvements in clinical guidelines– Information Access patterns
5
Core Services For Resolution• Data Integration by Message Broker Technology• Identity Correlation Service – correlates patient
identities across medical region (MPI)• Information Locator Service – registers location of
clinical data for a correlated patient• Access Control Service – supports HIPAA compliance,
user defined security rules, role based access, logs access events/reasons
• Clinician Portal – gives clinicians ability to access results, customize patient lists, perform searches, message– Laboratory results– Radiology reports and images– Clinical Notes– Eligibility and other Admin/Health Plan data– Medication History
• Accessible to End Users via Browser
6
One Model: Care Data Exchange
• The Santa Barbara Medical Community
• Community Vision and Design• Architecture• Lessons Learned
7
Santa Barbara Medical Community – Early RHIO
* Estimated** Planned ParticipationSource:Santa Barbara County Medical Society; Dep’t of Finance, Santa Barbara County
County profile• Population: ~500,000• Major Cities
– Santa Barbara– Santa Maria– Lompoc
• Per capita income: $28,698• 5 major hospitals• ~1,000 physicians• 72 retail pharmacies• Total SB health care spending:
approximately $1.1 Billion*
Santa Maria• Population: 72,900• 184 physicians, 21% of physicians in SBCMS• 1 major hospital• 14 pharmacies• Major CDE participants: MidCoast IPA, Quest,
Marian Medical Center
Santa Barbara• Population: 92,800• 693 physicians• 53% of physicians in SBCMS• 3 hospital Cottage Health System• 32 pharmacies• Major CDE participants: Santa Barbara Regional Health
Authority, Sansum-Santa Barbara Medical Found. Clinic, Santa Barbara Public Health Dept. Cottage Health System
Lompoc• Population: 43,300• 75 physicians• 21% of physicians in SBCMS• 1 major hospitals• 7 pharmacies• Major CDE participants: Lompoc Valley Community
Health Organization, Lompoc Hospital
• Santa Maria
• Lompoc
• Santa
Barbara
Active CDE participation**• Major hospitals
5 of 5
• Physicians
~325 of 1000
• Retail pharmacies
~60 of 72
• Payors
1 of 8
8
CDE - From Vision to Design…
Vision Design• Infrastructure promoting collaboration
within a medical community• Secure utility enabling physicians, health
care organizations and consumers to access clinical information within and across enterprises
• Data provider organizations to retain control over their data while permitting access to authorized users
• Fast and inexpensive deployment• Designed for:
– Clinicians: Results reporting and communication – Clinician extenders: Support clinician data
gathering– Consumers: Personal data management
• Non-proprietary utility
• Secure utility accepting multiple standards
• No “central” clinical data repository; Peer-to-peer architecture
• Affordable
• Requires minimal technical infrastructure from the end user
• Major Funding by CHCF
9
Care Data Exchange Solution• Technology
– SSL, SOAP, XML, HL7, Server Certificates• Data Access
– Clinical Data Repositories• Federated• Location Independent
– Direct to Source/API• Total Solution in “IHE Speak”
– Data Collection– Data Registry– Data Repository– Data Consumer/Record Distributor– Identity Service
10
Quovadx Care Data Exchange Model
AnalyticsTrusted Third
Party Authority
De-identified Data
Identified Data Surveillance
Reporting
ReportingData
AggregationsComponent
Cu
rre
nt
De
plo
ym
en
t
Physician
Patient
Data Users
• Clinical records access• Browser-based• Retrieve records from
anywhere in system• Document consent
process
• Personal information
• Browser-based
• Clinical information access reports
• Personal Health Information
Clinics & Services
Hospitals
Payors
Data Providers
• Rad. Studies• Lab. Results
• Patient Demographic
• Rx Data• Radiology
Studies• Lab Studies
• Demographics• Eligibility
Platfo
rmFirew
all
QVDXInfrastruct.
Information Location Service (ILS)• Links to Patient clinical records in
participants’ systems • No clinical records stored at CDE
central site• Demographic data of all Patients in
system
Access Control Service (ACS)• Controls login• Monitors and records access
requests• Enables access only to allowed
data
Identity Correlation Service (ICS)• Correlates Patient identities from
different sources• Intelligently matches similar records
(e.g., similar names, SSN’s, addresses)
CDE Infrastructure
11
CDE Components
• CDE Portal – Originally targeted at ‘viewing’ results
• Data Integration• Identity Correlation Service (ICS)
– Federated
• Information Locator Service (ILS)• Clinical Data Repositories (CDRs)
– Federated
• CIA (Data Collection/Processing) Service
12
CDE Portal
• Built on BEA Weblogic Portal Server• Provides primary user interface for
all CDE functionality• Integrates with ICS and ILS to
perform patient and results searches• Provides user authentication,
authorization and manages person/results access privileges
13
Data Integration
• SBCCDE Originally employed “classic” integration– Predominately HL7 stream– Somewhat customized interfaces– Limited data standardization
• Predominately a Federated CDR model• Move to intelligent message brokering• Data Management – filters, edits,
logging
14
Identity Correlation System• Defines a “Person” from disparate
demographic information from participating systems
• Provides two basic services: demographic queries and addition of new identities to the database
• Uses fuzzy logic and Neural Network technology to determine which identities make up a single Person
• “Federates” Enterprise MPI functionality with persistent but “silent” regional MPI
15
Information Locator System
• Distributed network of nodes that determine if results are available for a person
• Central service communicating with remote nodes (uses server certificate based authentication)
• SOAP over https between ILS nodes• Adapter implementation allows for
communicating with different data sources• Creates Person Result List and URL’s
Dynamically (Registry “on the fly”)
16
Clinical Data Repository
• Maintains actual patient results (Radiology, Lab, Clinical Notes, Admin, Pharma)
• An ILS serves each CDR to query for results• CDRs responsible for responding to requests
from UI to display results• Multiple CDR formats
– CareScience format when data is pushed from organizations to a staged repository
– Organizational format (Direct to Source) via adapter
• CDR locations – Hosted in CareScience Data Center – Hosted by participating organization
17
Clinical Data Repository
Direct to Source CDR• Datasource owned and operated by
remote facility• ILS node installed remotely, usually
on Apache Tomcat• Different datasource connectivities:
SQL, XML, HL7
18
Lessons Learned• Provider desktop is low tech, heterogeneous, office setting not
attuned to new roles• Intelligent and flexible integration and message brokering
required– HL7 isn’t “standard”– Multiplicity of sources, endpoints and uses
• Identity Correlation remains a challenge – data completeness a challenge
• Flexibility of data model is desirable• Provider rights/access control is non-trivial in the real world
Industry/Society does not know how to operationalize “consumer control”
• Exchange operations takes a real entity– Identity Management– User Management– Policy and PR Management– Data Management and Netops– High expectations re Availability, Accuracy, Completeness of data
19
Florida Department of Health
• Overview– Individual program areas & counties
collected individual data – Aggregate data was needed at the
state and federal level – (e.g., immunization history, CDC smallpox reporting)
– Duplicate data entry produced: • unreliable information• waste of limited resources
20
Technology Model
• Data Integration Services: HL7 & ANSI X12 based integration
• Information Location Services: Delivered flexible solutions through federated data storage
21
Florida Department of Health
• Local Impact– Connected to all 67 Florida Counties– Lab Data accessibility improvements
• from 10 days to 24 – 48 hours for disease surveillance programs
– Alerts associated with lab results• saving actual lives through information
immediately reaching county case workers– Reduced duplicate data entry
• freeing employees to do other important things– For sexually transmitted diseases:
• More rapid intervention resulted in approximately $850,000 in 1st year savings alone…
22
Florida Department of Health
• Federal Impact– Used existing report system and met CDC reporting
requirement• saved time to market• reduced training• provided single point of data entry
– First state to electronically load data to CDC’s PVS– Gave CDC and all stakeholders immediate view of
smallpox vaccination progress via Web application
23
Canadian RHIO: Capital Health
• Capitol Health Authority Overview– A Canadian “Connected Community”
servicing more than 1.6 million Alberta residents with an integrated Electronic Health Record
– Consolidated 14 silos of clinical information
– Utilized HL7 and XML as enabling standards
24
Technology Model
• Data Integration Services: HL7 & XML
• Identity Correlation Services: EMPI for matching of Patient data across 14 silos; multiple data owners.
• Information Location Services: Delivered flexible solutions through centralized CDR
25
Canadian RHIO: Capital Health
• Capitol Health Authority– Enterprise wide rollout of the
electronic health record (April 2004)– 2,300+ authorized users of the secure
portal– Accessing information from 5+ million
medical records– 80,000+ screens of information
viewed by clinical professionals in the first 3 months…
26
Summary• Regardless of the Clinical Portal & Data Model
chosen- healthcare environments today require a architecture founded on:– Data Integration Services/Message Broker Service:
• Integrating a myriad of disparate applications from across vendors and within a vendor’s family of products
• Intelligently manage data translation, standardization, routing
– Identity Correlation Services:• Identifying and linking the correct patient across the
community– Record Location Services:
• Delivering flexible solutions through management of your business processes and architectural environment
– Access Control Services:• Providing secure access – implementing local policy