270 likes | 415 Views
Technology Models for Building Health Information Infrastructure II. Mike Epplen VP Product Management Quovadx Inc. Mike.epplen@quovadx.com. Agenda . Health Information Access Challenge Care Data Exchange Technology Model Additional Models for Success Summary: Key Enablers.
E N D
Technology Models for Building Health Information Infrastructure II Mike Epplen VP Product Management Quovadx Inc. Mike.epplen@quovadx.com
Agenda • Health Information Access Challenge • Care Data Exchange Technology Model • Additional Models for Success • Summary: Key Enablers
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
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
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
One Model: Care Data Exchange • The Santa Barbara Medical Community • Community Vision and Design • Architecture • Lessons Learned
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 Barbara Medical Community – Early RHIO 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 Active CDE participation** • Major hospitals 5 of 5 • Physicians ~325 of 1000 • Retail pharmacies ~60 of 72 • Payors 1 of 8 • Santa Maria • Lompoc • Santa Barbara 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 * Estimated ** Planned Participation Source: Santa Barbara County Medical Society; Dep’t of Finance, Santa Barbara County
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 CDE - From Vision to Design… Design Vision • 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
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
CDE Infrastructure Data Providers Data Users Hospitals Physician Access Control Service (ACS) • Controls login • Monitors and records access requests • Enables access only to allowed data QVDX Infrastruct. • Clinical records access • Browser-based • Retrieve records from anywhere in system • Document consent process • Patient Demographic • Rx Data • Radiology Studies • Lab Studies Identity Correlation Service (ICS) • Correlates Patient identities from different sources • Intelligently matches similar records (e.g., similar names, SSN’s, addresses) Payors Patient Platform 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 • Demographics • Eligibility • Personal information • Browser-based • Clinical information access reports • Personal Health Information Firewall Clinics & Services • Rad. Studies • Lab. Results Analytics Identified Data Surveillance Trusted Third Party Authority Data Aggregations Component Reporting De-identified Data Reporting Quovadx Care Data Exchange Model Current Deployment
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
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
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
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
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”)
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
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
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
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
Technology Model • Data Integration Services: HL7 & ANSI X12 based integration • Information Location Services: Delivered flexible solutions through federated data storage
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…
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
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
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
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…
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
Thank You! Questions or Comments Mike Epplen Mike.epplen@quovadx.com 513-253-7249