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