2014 Certification --- The RPMS Experience (to date)

2014 Certification and

Meaningful Use Stage 2---

IHS Resource and Patient Management System (RPMS) Experience

(to date)

Steve Thornton, MSIT, PMP, PMI-ACP, CUAChief Technology Officer (CTO)

Indian Health Service (IHS)September 4, 2014

Topics

• Background and overview• Certification testing and preparation• Lessons learned• Deployment planning and challenges• IHS Health Information Exchange (HIE) Status• Questions

2

BACKGROUND AND OVERVIEW

2014 Certification and Meaningful Use Stage 2

3

Indian Health ServiceMission, Goal, & Foundation

• The Mission, in partnership with American Indian and Alaska Native people, is to raise their physical, mental, social and spiritual health to the highest level.

• The Goal is to ensure that comprehensive, culturally acceptable personal and public health services are available and accessible to all American Indian and Alaska Native people.

• The Foundation is to uphold the federal government’s obligation to promote healthy American Indian and Alaska Native people, communities and cultures, and to honor and protect the inherent sovereign rights of Tribes.

4

A Quick Look at theIndian Health Service

• Provides a comprehensive health service delivery system for approximately 2.2 million American Indians and Alaska Natives.

• Serves members of 566 federally recognized Tribes.• FY 2014 budget is approximately $4.4 billion. • Indian Health Service total staff consists of about

15,630 employees, which includes approximately 2,590 nurses, 790 physicians, 660 pharmacists, 670 engineers/sanitarians, 330 physician assistants/nurse practitioners, and 290 dentists.

• Approximately 69% of IHS staff are American Indians and Alaska Natives.

5

Indian Health System Locations

6

Indian Health Care Systems

Hospitals Health Centers

Alaska Village Clinics

Health Stations

IHS 28 61 N/A 34Tribal 17 249 164 70

• The IHS also provides funding to 33 urban-centered organizations providing health care services at 57 sites across the nation.

7

Background• Resource and Patient Management System

– IHS health information solution since 1984.• RPMS EHR released in 2005

– In use at ~400 IHS, Tribal, Urban Indian health care facilities nationwide.

– Most – but not all – tribal sites use RPMS.– Adoption outside IHS in Hawaii and points west.

• 2011 and 2014 Certified Complete EHR for Ambulatory and Inpatient settings– To date over $117 million in MU incentive payments received by I/T/U

facilities using the RPMS EHR.• 2014 certification and deployment a current major priority of the

IHS Office of Information Technology– The other one is ICD-10 . . . .

8

MU2 Program Tracks

Certification Alpha and Beta Testing

Iterative Development

Training Policy Framework

Trust Frameworks

AgreementsDeployment and Onboarding of New Services

Attestation

9

CERTIFICATION TESTING AND PREPARATION


10

Certification StatusProduct Certificate # Certified Date Classification Practice Setting

Resource and Patient Management System Electronic Health Record, version RPMS Suite (BCER) v2.0

IG-2419-14-0020 August 22, 2014 Complete EHR Ambulatory

Resource and Patient Management System Electronic Health Record, version RPMS Suite (BCER) v2.0

IG-2419-14-0021 August 22, 2014 Complete EHR Inpatient

11

Certification and Test ScheduleSpring 2012 2014 Certification and Meaningful Use Proposed Rules released for commentAugust 2012 Final rule releasedJuly 1, 2013 Kick-off meeting with testerJuly 1 – August 22, 2013 Q/A period with primary tester to verify approach, assumptions, etc.October 1, 2013 2014 Reporting period began for Eligible HospitalsOctober 1 – 16, 2013 Government partial shutdownNovember 15, 2013 QMS and safety enhanced design documents submitted to testerJanuary 1, 2014 2014 Reporting period began for Eligible ProvidersJanuary 7 – 29, 2014 Round 1 testingMarch 5, 2014 Post test package submitted

(WCAG testing report, QMS, authorized representative form, privacy & security attestation, security audit, and sha.1 file)

May 30, 2014 Questions from certification body (round 1)July 22, 2014 Questions from certification body (round 2)August 19, 2014 Round 2 testingAugust 22, 2014 Notice of certification

• Total certification process – 1 year duration.• Test days – Planned 6; Actual 13.• Multiple iterations of Quality Management System, Safety Enhanced Design, and WCAG (accessibility) testing results. 12

Test Results Passed: 32/32 Functional Criteria Passed: 16/16 Inpatient Clinical Quality Measures Passed: 17/17 Ambulatory Clinical Quality Measures Passed: 23/23 Performance Measures Passed: Quality Reporting Document Architecture (QRDA) category 1 and

QRDA cat. 3 generation Accepted: Documentation of Quality Management System (QMS) used by

IHS in development of RPMS EHR and related applications; 31 page report. Accepted : For Safety-Enhanced Design (SED), IHS contracted with human

factors consultants and conducted usability analysis of the eight functions (both legacy and new development); 5 documents, 35-61 pages in length.

Accepted : Web Content Accessibility Guidelines (WCAG) report for patient-facing application (Personal Health Record).

13

LESSONS LEARNED


14

Schedule Challenges• Insufficient time between release of rule in August

2012 and deadlines for implementation and attestation • Under-estimated level of effort and schedule for Direct

trust framework on-boarding, training and adoption(still not done)

• Changes in requirements between proposed and final rules created risk and confusion for our projects

• Timing of release of NIST scripts and testing tools created challenges in preparation (preferred for test-driven development)

15

Requirements Challenges• Complex federal rule-making process and legal jargon

presented some challenges with requirements analysis and traceability.

• Cross-referencing among rules and between rules and secondary references proved difficult to follow for project teams and created ambiguity for certification testing (requirements scavenger hunt).

• One rule referenced an HL7 document that was not open –required HL7 membership to access.

• Certification does not necessarily equate to usability and does not guarantee provider or patient adoption.

• Additional requirements added through NIST test design (after final rule).

16

Requirements ChallengesClinical Quality Measures (CQM)

• CQM value set requirements – SNOMED CT only required for problem list (PL) and family history (FHx) but turned up in CQM numerous times.

• Derived from research and/or developed in non-EHR settings.• Requires data that is not normally collected in practice, or using

value sets not normally available.• Certification requires capture of ALL possible value sets rather than

vendor selecting value sets that would be used in the EHR.• Odd and conflicting use of different value sets for same concept in

different measures.• Stand-alone use of terms/codes that are intended as modifiers.• Use of terms for result instead of procedure (EKG).• High level of effort for overall analysis and development of CQM,

even with years of experience working in this area.

17

Standards Challenges• Evolving standards leveraged in rule-making –

CCDA was a draft standard at the time the rule was released.

• Other HL7 standards were still evolving as well.• Inconsistent standards application – NIST

requirements for 170.314(b)(6) and 170.314(f)(4) were different even though the test script requirements were the same.

• NIST would not work using HL7 standard for lab transmission – had to deviate from standard to pass NIST tests.

18

Testing Challenges• Significantly under-estimated the amount of time required for certification testing• Browser compatibility between NIST validator (worked with Chrome but not IE and

Firefox).• During pre-certification testing NIST tool generated random errors – one day

something would run clean; the next day it would not.• Some test scenarios made little clinical sense (“syndromic surveillance” in an ED).• Timing of NIST scripts led to revision in IHS requirements (after the final rule

released).• Changing NIST scripts led to requirements re-analysis and sometimes re-

development.• NIST scripts and tools more restrictive than rule.• CCDA validator not working until August 2013.• Test data issues: required to enter conflicting data for same patient; entry of old

patient data, forcing us to break/override system protections against back-dated entries; internal inconsistencies in test scripts; and using same patient for inpatient & outpatient testing led to data conflicts and rework.

• Must comply with both WCAG 2.0 and Section 508 as a federal agency.

19

Impacts in IHS• Scope, complexity and cost of 2014 Certification significantly exceeded

expectations and plans.• Many issues identified in testing had to be deferred to post ICD-10.• Like many others in the industry, most IHS and Tribal Hospitals using RPMS

are at risk of not receiving incentive payments for 2015 or are at risk for payment adjustments in 2017, due to the delayed release of the 2014 CEHRT and extensive deployment requirements.

• I/T/U sites will be leveraging the CMS Flexible Rule for 2014.– Providers scheduled to demonstrate Stage 2 of meaningful use in 2014 can:

• Demonstrate 2013 Definition of Stage 1 of meaningful use with 2011 Edition CEHRT or a combination of 2011 and 2014 Edition CEHRT;

• Demonstrate 2014 Definition of Stage 1 of meaningful use with 2014 Edition CEHRT; or• Demonstrate Stage 2 of meaningful use with 2014 Edition CEHRT.

• MU Certification schedule has impacted another (more) critical development project – ICD-10.

• Other innovative development and modernization projects, as well as hundreds of enhancement requests from users, have been deferred because of the Certification and ICD-10 priorities.

20

DEPLOYMENT PLANNING AND CHALLENGES


21

MU2 Program Tracks

Certification Alpha and Beta Testing

Iterative Development

Training Policy Framework

Trust Frameworks

AgreementsDeployment and Onboarding of New Services

Attestation

22

2014 CEHR Deployment

• Wrapping up testing at four beta sites; closing out all significant issues. Closely monitoring the triple constraint.

• Many lessons learned from beta testing to be applied in deployment.

• Target date for national release 9/15/2014.• Schedule is necessitating a rapid deployment

approach for RPMS and new services.• Advising sites to develop deployment risk

management plans, due to schedule constraints, resource availability, and complexity of upgrades.

23

Site Deployment ProcessSTEP 1: Training & Optimization

• Area Hosted Trainings

• Site Hosted Trainings

• Optimize Released Packages (BMW, RCIS, RAD, etc)

• Meet the Measure Training

• Office Hours

STEP 2: Complete Checklist

• Technical Checklist

• Clinical Pre-Deployment Checklist

• Office Hours

STEP 3: 2014 EHR Upgrade

• Post Deployment Checklist

• Office Hours

STEP 4: Optimization

• 2014 EHR optimization

• Troubleshooting

• Reminders

• TIU Note Titles

• Office Hours

STEP 5: New Services

• MPI

• CCDA

• Direct for Providers

• PHR

• Direct for Patients

*PRIOR to upgrade

*Week of Upgrade

*Day of Upgrade

*Week of Upgrade

*POST Upgrade

24

Deployment

Implement/Optimize currently released RPMS Applications (VI, Lab, Radiology, BMW…)

EHR MPI DIRECT for Providers

HIE

PHR

eHealth Exchange

DIRECT for Patients

CQM

25

Simplified Diagram of RPMS – eHealth Exchange Dataflow

eHealth Exchange

MPI

CCDA DocumentRepository

RPMS RPMSRPMS

HIE

PHR

I/T/U Enterprise Central Services

I/T/U Enterprise Local RPMS Databases

External HIE’s participating in eHealth Exchange

26

Policy Challenges• Multiple complex policy issues to resolve before

implementation of Stage 2 requirements can be started – additional requirements for Federal agencies

• IHS has customers in 35 states, which have variable laws concerning patient access to information, especially where minors are concerned.– In the near term will not enable access to patients under

18.– Longer term will enable filtering of sensitive information

keyed off of CCDA content.

27

Policy/Agreement Framework• Master Patient Index (MPI)

– MPI User Policy; MPI Policy for Data Access and Sharing

• Personal Health Record (PHR) Portal– Policy for Processing Patient Access to Personal Health Record; PHR Terms and Conditions; PHR

Audit Policy; HIPAA Un-Emancipated Minor Policy

• DIRECT– Policy for End User Access to the RPMS DIRECT Messaging System; Direct Administrator Policy;

Direct Terms and Conditions

• Health Information Exchange (HIE)– Policy for Access to the Health Information Exchange; Health Information Exchange (HIE)

System Security Audit Process Policy; HIE Terms and Conditions (Privacy, Terms, Disclaimers)

• National eHealth Exchange– Policy for Access to the Nationwide Health Information Network

• Legal Agreements– DURSA, Participant Agreement, BAA, ISA, End User Agreements

28

Direct Secure Messaging• IHS developed our own Direct solution using open source;

considered VLER Direct (DoD) but not available timely.• NIST scripts had more requirements with certain protocols that

were not in the rule.• Numerous technical, legal, and policy implications of standing up

our own HISP.• Federal security policy conflict with implementation requirements.• Considerable work remains about how the HISPs and HIEs will all

work together (esp. dual HISP/HIE).• EHNAC certification as a pre-requisite for onboarding to the ONC

granted trust bundle DirectTrust.• No national directory for identifying provider Direct addresses.

29

Deployment Risks and Issues

• Time of release and adoption relative to participation in Meaningful Use (extremely compressed schedule)

• Data sharing agreements and technical development necessary for full Indian Health System integration

• Alignment of deployment projects, training, and adoption

• Convergence of MU2 and ICD-10 requirements• Security and privacy • Extreme complexity• IHS unique challenges, risks, and issues

30

Other Concerns• Largest IT initiative ever undertaken by IHS.• Significantly increased O/M baseline.• New demand channel for services that didn’t exist before MU2.• Exposed internal process issues that need to be addressed.

– Reviewing ALL aspects of the SDLC and the underlying architecture.• Continued divergence between IHS and other VistA stakeholders’

priorities. How will open source address certification requirements in a timely way?

• Continued divergence in the architecture stack.• What to do about legacy technologies with the impending

retirement wave?• Thinking ahead to 2017 certification criteria and Meaningful Use

Stage 3 (rule targeted for release in 2015).

31

IHS HEALTH INFORMATION EXCHANGE (HIE) STATUS


32

eHealth Exchange Architecture

I/T/U Facility

I/T/U Facility

I/T/U Facility

33

National eHealth Exchange Status• Schedule

• Complete - Development of IHS’ HIE Connect components to integrate with the eHealth Exchange Connect Gateway.

• Complete - Testing of the integration between IHS and eHealthExchange.

• In Progress - Updated DURSA.• In Progress - Agreements between IHS and Healtheway.• Planned (within 90 days) - First Interoperability Testing with at

least one public sector and one private sector eHealth Exchange partner (received approval for extension from 8/20/2014 to 12/18/2014 from Healtheway Coordinating Committee).

• Planned (within 120 days) – Interoperable.• Planned (after 120 days) – Expand service; expand tribal on-

boarding.• Concerns with trust frameworks, security, privacy, and timelines

(some similar to Direct; some different).• Point-to-point inter-HIE exchange versus National eHealth Exchange.

34

QUESTIONS?

35

BACKUP SLIDES2014 Certification and Meaningful Use Stage 2

36

Test Results - PassedID Function Application

§170.314(a)(4) Vital signs, body mass index, and growth charts EHR

§170.314(a)(5) Problem list EHR

§170.314(a)(9) Electronic notes EHR

§170.314(a)(13) Family health history EHR

§170.314(a)(11) Smoking status EHR

§170.314(d)(4) Amendments EHR

§170.314(a)(12) Image results VI, EHR

§170.314(a)(3) *Demographics BMW (Reg)

* Designates an item that required some intervention or “tweaking” to pass** Designates an item that encountered difficulty requiring on-the-fly recoding or redesign of the testing approach to pass

37


§170.314(a)(2) Drug-drug, drug-allergy interactions checks EHR

§170.314(a)(16) Inpatient - electronic medication administration record BCMA

§170.314(a)(10) Drug formulary checks EHR

§170.314(a)(15) Patient-specific education resources EHR

§170.314(b)(3) Electronic prescribing eRx, EHR

§170.314(d)(2) **Auditable events and tamper-resistance BUSA

§170.314(d)(3) **Audit report(s) BUSA

§170.314(d)(7) End-user device encryption SEE, CREDANT2go, 7Zip

38


§170.314(f)(4) Inpatient - transmission of reportable laboratory tests and values/results

Lab

§170.314(b)(5)(A) Incorporate laboratory tests and values/results Lab

§170.314(a)(14) **Patient list creation iCare

§170.314(c)(1) Clinical quality measures – capture and export – Includes QRDA 1 and 3 for EP and EH

CQM

§170.314(c)(2) Clinical quality measures – import and calculateIncludes QRDA 1 and 3 for EP and EH

CQM

§170.314(b)(7) Data portability CCDA

§170.314(f)(2) **Transmission to immunization registries BYIM

§170.314(b)(6) **Electronic delivery of lab results for inpatients Lab

39


§170.314(f)(3) Transmission to public health agencies – syndromicsurveillance

RPMS

§170.314(b)(4) *Clinical information reconciliation EHR, VI

§170.314(b)(1) **Transitions of care - receive, display and incorporate transition of care/referral summaries

EHR, CCDA

§170.314(b)(2) **Transitions of care – create and transmit transition of care/referral summaries

EHR, CCDA

§170.314(e)(1) View, download, and transmit to 3rd party PHR

§170.314(e)(3) Ambulatory - secure messaging DIRECT

§170.314(e)(2) Ambulatory - clinical summary PHR

§170.314(a)(8) **Clinical decision support EHR, PXRM

40

2014 Certified RPMS Suite• Patient Care Component Reports (APCL v3.0

p29)• Performance Measures 2014 (APCM v1.0 p5)• Pharmacy Data Dictionary Changes (APSP v7.0

p1017)• ICD update (AUM v13.0 p4)• IHS Dictionaries (AUPN v99.1 p23)• Patient Education Dictionary Changes (AUT

v98.1 p26)• IHS VA Support files (AVA v93.2 p22)• Consolidated Clinical Document (BCCD v1.0)• Clinical Quality Measures (BCQM v1.0)• Immunization (BI v8.5 p5)• Vista Imaging/RAD MAG& HER (BMAG v1.0 p1)• Practice Management Component Framework

(BMW v2.5)• RPMS .NET Utilities (BMX v4.0 p3)• Personal Health Record (BPHR v2.1)

• EHR p13– ePrescribing Production (BEPR v2.0)– Pharmacy Data Mgmt. (APSP v7.0 p1017)– HL7/XML (BEPR v2.0)

• Components for EHR p13 (BGO v1.1 p13)

– GMRA v4.0 p1007– GMRA v4.0 p1008– GMRC v3.0 p1004

• Patient Care Component (BJPC v2.0 p10)

• BLV v8.5 p5• Referred Care (BMC v4.0 p8)• Clinical Reminders (PXRM v2.0, p1001,

p1002)• Text Integration Utilities (TIU v1.0

p1011, p1012)• VA Health Summaries (BHS v1.0 p8)• Patient Registration (AG v7.1 p11)• Patient Registration (AG v7.2 p3)

41

2014 Certified RPMS Suite (continued)

• Ensemble 2012.2.5• End User Encryption (Symantec

8.2, 7-zip, Credent 2-go 7.3)• Integrity (Winhasher)

• iCare Patient List (BQI v2.3 p3)• IHS Terminology Services (BSTS

v1.0)• IHS User Security Audit (BUSA v1.0)• Immunization Registry Interface

(BYIM v2.0 p4)• Adverse Reaction Dictionary

(GMRA v4.0 p1007)• Consult/Request Tracking (GMRC

v3.0 1004)• VA Vitals (GMRV v5.0 p1002)• Health Information Exchange (HIE

v1.0 p5)• Electronic Lab Results (LR v5.2

p1033)• Kernel RPC Broker (XWB v1.1 1018)

42

Documents

2014 Certification --- The RPMS Experience (to date)