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 IIIIII PrototypePilotProof of Concept Alaska Alpha Sites BetaAlphaPhased Deployment Stage 4 (Jun-Sep 01) Stage 3 (Jan-Jun 01) Stage 2 (Apr - Oct 00) Stage 1 (Mar 00) January 00 Stage 1 (Oct 01- Sep 02) Stage 2 (Oct 02 - Sep 03) Pilot Test Albuquerque Bay Pines Chantilly Development Node (0)Field Node (1) Protoype Acceptance Testing Selected Beta Sites

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.

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

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

EMPI Enterprise Master Patient Index Framework PIDS ID Person, Demographics Mediation Clinical Terminology Observation Collector (ODBC, COAS) Heritage System Servers Framework LQS Agency System as Clients CHCS II, Vista, RPMS SQLCOAS JNDI VistA CHCS II RPMS Framework COAS Patient Records Framework Access Session,User,Security, etc Privacy Consent, Access Policies Cache Patient Records HL7 MPI Master Patient Index PIDS CORBACOAS 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