View
216
Download
0
Category
Preview:
Citation preview
Project Overview Government Computer-based
Patient Record
24 September 2000Presented by
MAJ Philip Dederer, MS, RHIA
Agenda
• Project Overview•Project Background•What is the GCPR Framework•Project Schedule and Phases
•Phases•Schedule •Functionality/Scope•Physical View
• Key Components
GCPR Program Vision
• Improve public and individual health status by sharing clinical information
Framework Goals & Objectives
• The GCPR Framework Project was conceived to establish the standards and technical infrastructure required to provide secure access to electronic clinical information on a shared patient population. The framework will consist of a suite of software and hardware tool sets and services designed to– Create a secure technical environment for sharing sensitive
information– Develop a patient-focused information technology architecture– Create common information and terminology models to ensure
interoperability between disparate systems– Adopt and adhere to standards where they exist and to advance
the development and establishment of standards where they are absent
– Leverage existing agency and inter-agency systems and workgroup investments
Why a joint effort?
• Presidential Executive Directive
• Congressional interest/legislation
• Parallel agency activities
• Economic pressures
• “It Makes sense”
What are the problems?
• Medical Treatment Facilities are heritage stovepipes
• Medical information gathered during deployment is lost
• Government patients receive healthcare from a variety of sources that don’t interchange information
• Patient information is not transferred when a patient’s status changes
– Active Duty, Reserves, Retirement
What is GCPR Framework?
• The “CPR” in GCPR is misleading
• It is not a CPRS, CDR, EIS or Clinical Application• Although it can enable exchange between such systems
• It is a component-based infrastructure for the secure information interchange between disparate systems
• Information Interchange Infrastructure• What’s that mean?
What is GCPR Framework? (Cont.)
• Information• Currently clinical information and patient demographics• Architecture is information independent
• Interchange• Not a data repository (temporary cache)• Virtual record assembler
• Infrastructure• Middleware and the platforms to run the middleware• Common Services for the enterprise• Non-application specific
Framework Project Phasing
• GCPR Framework Program Initiated in 1998
• SOO (RFP) Release to D/SIDDOMS Primes May 1998
• Litton/PRC Award August 1998
• Phase I development work began April 1999
• Prototype Completed March 2000
• Phase II (stage 1 and 2) - Pilot development and test began April 1, 2000
• Phase II (stage 3 and 4) alpha & beta testing (FY 2001)
• Phase III Multi year deployment
Current Program Schedule
PHASES
NODES
MILESTONES
SCHEDULE
STAGE
SITES
ACTIVITIES
PHASES / EVENTS / DEVELOPMENT & DEPLOYMENT
I II III
Prototype PilotProof of Concept
Alaska Alpha Sites
BetaAlpha Phased Deployment
Stage 4
(Jun-Sep 01)
Stage 3
(Jan-Jun 01)
Stage 2
(Apr - Oct 00)
Stage 1
(Mar 00)January 00Stage 1
(Oct 01- Sep 02)
Stage 2
(Oct 02 - Sep 03)
Pilot Test
AlbuquerqueBay PinesChantilly
Development Node (0) Field Node (1)
ProtoypeAcceptanceTesting
Selected Beta Sites
Possible GCPRGlobal Deployment
Node Backbone
= G C P R N ode
= N ode S upport Te lcom m C onnection
McLean, VADMC, San Diego
Honolulu, HI
Anchorage, AK
Seattle, W A New England/New York Area
Great Britain
MediterraneanArea
Pacific Rim Area
Phase I Results
• Prototype Acceptance Test Validated Architecture and Core Technology
• Current level of Functionality - Prototype – MPI Interoperability & Dynamic Updates
– Demographic Data Retrieval
– Lab Results Exchange
– Terminology Mediation - Multiple output contexts
– Security
– Wide-area secure communications
• Stood up and refined processes
Pilot Planning
• Pilot is a functional release• Pilot Testing Scheduled for January 2001• Test Environment (Bay Pines, Albuquerque,
Chantilly)• Pilot software baseline will be used to start Alpha
Test– Demographics
– Outpatient Pharmacy
– Labs
Draft Scope Statement for Pilot
The scope of Pilot will be to conduct a rigorous, robust test of a deployable information interchange infrastructure that supports identified common reference models, framework infrastructure middleware, data management, security and internal/external interfaces. At the same time it is essential to demonstrate the accurate secure movement of clinical data to the user, through more complete clinical area functionality, i.e. the completion of specific laboratory functions and simple outpatient medications.
GCPRDevelopmentFacilityM cLean, VA(Node 0)
VA HDB TestbedBay Pines, FL
DoD/USI HDBTestbedChantilly, VA
IHS HDB TestbedAlbuquerque, NM
GCPR Pilot Deployment
Alpha Test
• ‘Current’ target May 2001• Agency Requirements
– Site selection– Technical support– Functional support– CHCS II, VISTA, RPMS interface schemes
• (live system/test partition/mirror)• CHCS II installed at Alaska Sites
– Test scenario agreed to, security issues resolved– LAN/WAN interface– MPI and database population– Code sets current
GCPR Node 0McLean, VA
GCPR Node 1Anchorage, AK = P ilo t S upport N e tw ork
= A lpha S upport N e tw ork
= A lpha S upport N e tw ork O p tion
= In te rN ode N e tw ork
= G C P R N ode
=H eritage D B
CLIM S (CG)Kodiak
RPRM SANM C
Anchorage
VISTA VAM CAnchorage
CHCS II DM CSan Diego
CHCS II DM CDenver
IHSAlbuquerque
VA Bay Pines
DoD Chantilly
GCPR Alpha PhaseProposed Connections
Key Components
• Common Information Models
• Common Terminology Models
• Federated Master Patient Index (MPI)
• Security Services
• Public Key Infrastructure (PKI)
• Cache Services
• Virtual Database
• Mediation Services
• Interface Engines
• Telecommunications
• Trigger Events
• Query Capabilities
• Open System & COTS Based
• Web-based Technologies & Internet Backbone
• Object Oriented Solutions
Security
• Protects patient and provider rights• Provider access controlled by “Role”• Public Key Infrastructure (PKI) compliant• Meets legislative, regulatory, policy standards • Encrypted transactions• Adaptable to individual agency business rules
Security: Role Based Access
• Role Determines What is Displayed– Primary Care Manager has full access
– Other providers have support access as required to perform their clinical role
– Administrative personnel have limited access when required
• Data not permanently stored in GCPR Framework– Retrieved if authorized (from heritage system)
– Data kept for limited period in cache (business rule defined)
Overall Privacy Architecture
• Two regions in the Framework– User Region: Only data displayable to the
requesting user will exist here.– Trusted Region: All data sent to the
Framework will be here
• Domain Access controls passage of data from Trusted Region to the user Region
• RAD is the basis of the consent checking
EMPIEnterprise Master Patient Index
Framework PIDS
ID Person, Demographics
MediationClinical Terminology
Observation Collector(ODBC, COAS)
Heritage System Servers
Framework
Framework
LQS
Agency System as Clients CHCS II, Vista, RPMS
SQLCOAS COAS
JNDI
VistACHCS II RPMS
Framework COAS
Patient Records
Framework Access
Session,User,Security, etc
PrivacyConsent, Access Policies
CachePatient Records
HL7
MPIMaster Patient Index
PIDS
PIDSCORBA COAS
LDAP
Lessons Learned
• Meetings multiply at a rate twice that of rabbits
• Pizza is more enjoyable when eaten less than 4 times a week
• Software developers and bananas ripen after 48 hours in a warm room
• Time exists so everything doesn’t happen at once
• Everything seems to happen at once anyway
• Getting two OO Guru’s to agree is only slightly harder than communicating with the dead
• The difference between theory and practice is much smaller in theory than it is in practice
Questions/Discussion
Recommended