1 / 24

Agenda

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.

esben
Download Presentation

Agenda

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agenda • Project Overview • Project Background • What is the GCPR Framework • Project Schedule and Phases • Phases • Schedule • Functionality/Scope • Physical View • Key Components

  2. GCPR Program Vision • Improve public and individual health status by sharing clinical information

  3. 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

  4. Why a joint effort? • Presidential Executive Directive • Congressional interest/legislation • Parallel agency activities • Economic pressures • “It Makes sense”

  5. 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

  6. 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?

  7. 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

  8. 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

  9. Current Program Schedule PHASES / EVENTS / DEVELOPMENT & DEPLOYMENT I II III PHASES STAGE Stage 1 (Mar 00) Stage 2 (Apr - Oct 00) Stage 3 (Jan-Jun 01) Stage 4 (Jun-Sep 01) Stage 1 (Oct 01- Sep 02) Stage 2 (Oct 02 - Sep 03) SCHEDULE January 00 MILESTONES Proof of Concept Prototype Pilot Alpha Beta Phased Deployment NODES Development Node (0) Field Node (1) Alaska Alpha Sites SITES Albuquerque Bay Pines Chantilly Selected Beta Sites Pilot Test Protoype Acceptance Testing ACTIVITIES

  10. 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

  11. 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

  12. 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.

  13. 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

  14. 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

  15. 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

  16. 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)

  17. 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

  18. MPI Framework COAS Patient Records Master Patient Index Privacy Consent, Access Policies Agency System as Clients CHCS II, Vista, RPMS CORBA COAS PIDS Framework Framework Access Session,User,Security, etc Framework PIDS ID Person, Demographics JNDI LDAP Mediation LQS Clinical Terminology EMPI Observation Collector Enterprise Master Patient Index Cache Patient Records (ODBC, COAS) Framework COAS COAS SQL PIDS HL7 RPMS CHCS II VistA Heritage System Servers

  19. 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

  20. Questions/Discussion

More Related