Why the Vist A Community Should Care About
Why the Vist. A Community Should Care About RPMS (and why we care about you. . . ) Howard Hays, MD, MSPH Chief Information Officer (acting) Indian Health Service Vist. A Expo September 11, 2012 11
Topics Background on RPMS Recently Released Enhancements Other Development in Process Personal Health Record E-Prescribing and Health Information Exchange SOA and the BMW Suite RPMS Certification for Meaningful Use ICD-10, SNOMED CT and Terminology Services OSEHRA, i. EHR, and the Future of RPMS 22
Background on RPMS 33
Resource & Patient Management System IHS Health Information Solution since 1984 RPMS is an integrated Public Health information system Composed of over 60 component applications/namespaces Patient and Population based clinical applications Patient and Population based practice management applications In use at approximately 400 facilities nationwide, including all Federal IHS facilities and most Tribal programs RPMS Electronic Health Record in use for ambulatory care at 331 facilities including 54 Alaska Village clinics 38 IHS/Tribal hospitals use RPMS EHR on inpatient 44
1984: IHS implemented the Patient Care Component (PCC) in the Vist. A framework – the systems have evolved together over the years RPMS is Vist. A at its core, sharing much of the same infrastructure and some clinical applications such as Radiology, Vist. A Imaging, and BCMA Many VA applications (Laboratory, Pharmacy) have been extensively modified to meet IHS requirements RPMS EHR uses CPRS code (and more) in a customizable, componentized user interface IHS has develop numerous applications independently of VA to address IHSspecific mission and business needs (child health, public/population health, revenue cycle) 55
On-the-fly Queries (QMAN, PGEN, VGEN) Componentized EHR (2011 Certified) Medication Management enhancements Immunization Tracking and Data Exchange Well Child functionality Women’s Health & Prenatal Care functionality i. Care Population Management HIV Management System Care Management Event Tracking Clinical Reporting System (Performance – GPRA) Revenue Cycle applications 66
New Enhancements and Work in Progress 77
EHR Releases in 2012 EHR v 1. 1 patch 9 – User Interface changes to support electronic prescribing deployment EHRv 1. 1 patch 10 – New Patient Goals component PXRM v 1. 5 patch 1008 – Updated set of national reminders TIU v 1. 0 patches 1008, 1009 – infrastructure upgrades to support CPRS 27 upgrade GMRA v 4. 0 patches 1003, 1004 – safety related fixes 88
EHR Development – 2012 -13 EHRv 1. 1 patch 11 – CPRS v 27 upgrade, new enhancements EHRv 1. 1 patch 12 – SNOMED CT based integrated problem list, ICD-10 compliance, CPRS 28, 29 upgrade Reminders v 2. 0 upgrade BJPN v 1. 0 - Prenatal issues and problem list component Group notes - SNOMED CT and ICD-10 compliant group entry application BEDD v 1. 0 – ED dashboard, second version also required for SNOMED CT and ICD-10 compliance TIU, GMRA, GMRC, GMTS, BHS – numerous to support SNOMED CT and ICD-10 changes Lexicon – infrastructure for ICD-10 changes in PCC 99
Patient Goals New Patient Goals component separate from Education topics Patient-driven documentation of any type of personal goal Documentation of goals, monitoring and follow-up Asthma Zones Numerous recent enhancements for documentation of asthma-related factors relevant to assessment of severity and control New function to document Red and Yellow zone instructions for creation of patient’s printable Asthma Action Plan Prenatal Issues and Problem List Pregnancy-specific problem list for current or all pregnancies SNOMED CT, mapped to ICD where possible Document Care Plan notes for any issue/problem, insert into note or Health Summary using TIU or HS objects Eyeglass Prescription Component Eyeglass Rx documented in PCC, displayed in Health Summary Printable Eyeglass Prescription 101
Patient Goals (EHR 1. 1 p 10) 111
Add will bring up a blank Add/Update Asthma Zones dialog. Update will bring up Add/Update Asthma Zones dialog with the most recent entry. Add/Update stores the new or changed Asthma Zones instructions 121
Prenatal Issues and Problem List 131
Prenatal Issues and Problem Care Plan Notes documentation 141
Eyeglass Prescription (EHR v 1. 1 p 11) 151
i. Care Enhancements Numerous enhancements to support Meaningful Use and IHS Improving Patient Care Initiative MU and IPC performance views for provider or aggregated across facility New panel creation tools Support for employee health More. . . 161
i. Care Meaningful Use Tab Provider Clinical Quality Display of provider Clinical Quality Measures. Filters can be set to focus in on specific measures Aggregate facility-level view available 171
i. Care: Allergy Panel Creation Certification requirement – create lists of patients with specific types of allergies 181
Know who needs followup and when it is due A CMET reminder is also generated 191
CMET Patient Record: Events Monitor status of current and past CMET events for a specific patient 202
RPMS Pharmacy GUI Initiated during ARRA, parked, resumed in 2012 Planned release late 2013 All outpatient prescription processing functions POV entry using SNOMED CT Future releases to include Inpatient functions and Reports GUI interface is in WPF 212
RPMS EHR Pharmacy GUI 222
Designed for sites without labs or technologists Allows staff to accession tests – validate specimen, associate with patient, document relevant factors (fasting, etc. ) Delete tests, reprint labels, print shipping manifests for reference lab Review order status Accessed by clinicians, nurses, etc. within EHR Currently beta, release early 2013 232
RPMS EHR Lab Accession GUI 242
Personal Health Record 252
262
272
282
292
303
313
Patients name, demographics Provider name and contact info Problem list, procedures Lab test results Allergy and medication lists Vital signs Smoking Care plan field including goals and instructions Any additional known care team members Secure messaging Access to clinical summaries – ambulatory encounters and discharge summaries 323
333
343
Electronicand Prescribing Health Information Exchange 353
E-Rx in RPMS is certified by Sure. Scripts for the following messages: NEWRX, STATUS, ERROR Messages under development: REFREQ, REFRES IHS acts as an aggregator for IHS and Tribal health programs using eprescribing to meet MU Live for 1 year on SS network Currently at 12 sites and 114 prescribers 199 sites in deployment queue. . . 363
IHS E-Prescribing Network 373
383
393
404
HIE in IHS is providing a number of centralized services for IHS and interested Tribal/Urban programs in support of HIE requirements (for MU and more) E-Prescribing Communicable Disease Reporting (CANES) C 32 (and other) document repository Currently on-boarding with Nw. HIN MPI and HIE deployment underway 414
Central MPI and C 32 servers Nightly C 32 upload (Albuquer que) HL 7 Ensemble MPI production HL 7 4242 RPMS Patient data Ensemble C 32 production Request C 32 EHR GUI
IHS/Nw. HIN Direct Architecture NHIN Direct Participant INTERNET XDR (via SOAP/TLS) XDM (via Secure Email) Policy Decision Point (PDP) Policy Information Point (PIP) HIEOS XDS. b Consent Registry Other Considerations: • IHE Health Provider Directory (HPD) • Document Sources could pull data from XDS. b and send via Direct NHIN Direct Document Source NHIN Direct Gateway HIEOS XDS. b Document Repository NHIN Direct Document Recipient HIEOS XDS. b Document Registry HIEOS XDS. b Consent Repository 4343
Service-Oriented Architecture and the BMW Practice Management Suite 444
Strategy to migrate away from legacy thick GUI clients with chatty RPC brokers Cache Classes & Objects, Web Services, and a MS Silverlight User Interface Multiple Deployment Options BMW namespace Initial versions of Registration & Scheduling in beta, pending release 3 PB Claims Editor late 2012 A/D/T in mid-2013 Other applications to follow Depending on performance/acceptance, migrate clinical applications (EHR, i. Care, etc. ) to BMW framework 454
Ensemble Productions Client Server Applications • Licensing overhead • Database overload • Connection per user / component • RPC non-standard text-based protocol • Business logic spread over client and database • Business logic repetition across client applications • Inconsistent user experience design • Login per client application • Client Installation and Maintenance per workstation C 32, EDR, MPI Ensemble Connectors Ensemble/Cache RPMS RPC Broker GUI Clients Registration GUI Scheduling GUI EHR GUI 464
Composite Application based on SOA • Reducing database overload via connection pooling • Reducing use of Ensemble connectors/ productions • Reusable business logic exposed via business services • One application – one login • Modular approach based on user roles • Consistent user experience design across modules • Integrated workflows across modules • Reducing workstation maintenance via webdelivered application • Standard SQL access to database that support data joins • Provides multiple deployment configurations Ensemble/Cache RPMS BMW Business Tier Data Access Layer Business Layer Service Layer Presentation Tier Composite Application Shell 474
Tools Technologies 484
Central Deployment The site’s RPMS/Ensemble database is physically located in the Area Office or HQ OIT or a Data center 494
Site Deployment The site’s RPMS/Ensemble database is physically located onsite and the site has an unreliable and/or low bandwidth connection to the IHS network (<4 T 1 lines = 6 Mbps) The site wants to completely own and manage the deployment and isolate it from IHS network (tribal/urban sites) Compact deployment combining RPMS & Application server possible but not preferred 505
BMW – Patient Registration Module Register New Patient 5151
BMW – Patient Registration Module Patient Profile 5252
BMW – Patient Registration Module Patient Appointments 5353
BMW – Scheduling Module Schedule Daily View 5454
BMW – Scheduling Module Schedule Appointment 5555
BMW – Scheduling Module Schedule Weekly View 5656
BMW – Scheduling Module Schedule Monthly View 5757
Certification & Meaningful Use, SNOMED CT, ICD-10, and Terminology Services 585
RPMS Certification and Meaningful Use IHS and Tribes bill CMS, so providers and hospitals eligible for MU incentives IHS modified RPMS to meet “ 2011 Certification” requirements, completed 04/2011 Certified for Ambulatory and Inpatient settings Over $29 million received to date by I/T/U Analysis & development underway for “ 2014 Certification” for Stage 2 MU IHS has been providing consultation to VA concerning certification requirements – former IHS employee now VA lead on MU 595
2014 Certification 606
2014 Certification 616
SNOMED CT® in Stage 1 vs. Stage 2 MU stage 1 MU stage 2 • SNOMED CT® used for event codes in Adverse Reaction Tracking • SNOMED CT® optional for CQM’s – allowed to map terms to local vocabularies • Extraordinary amount of work to map our local vocabularies to SNOMED CT • SNOMED CT® required for Problem List diagnoses • SNOMED CT® required* for Family History diagnoses • SNOMED CT® required for some CQMs • SNOMED CT® (and LOINC) required for cancer registries 626
Stage 1 CQM Mapping For Stage 1 MU, EHR developers were required to program all of the Clinical Quality Measures for EP and EH. Most of these were derived from expert sources such as the National Quality Forum (NQF) Measure logic for denominators, numerators, inclusions, exclusions - all provided, but most often in SNOMED terms, not ICD or CPT This required IHS to "reverse engineer" all of the logic to ICD-9, CPT, HCPCS, and RPMS-specific code sets - extremely labor-intensive For 2014 Certification, it will be MUCH easier to program CQM using the "native" logic, i. e. SNOMED CT® 636
RPMS EHR SNOMED CT® and the Integrated Problem List 646
Problem List Descriptions IHS (historically) Problem List – chronic problems only ONC/CMS description Problem List – problems for patient that have been documented POV – episodic problems, chronic problems addressed Problem List includes current and active at current encounter diagnoses (chronic, episodic, and problems requiring follow-up) Particularly with both SNOMED CT® required for “problems” and the institution of “care plan” we feel we need to shift how we utilize the Problem List to better align with the new requirements AND improve workflow in SNOMED CT®/ICD-10. 656
Integrated Problem List De-duplicated list of problems (based on unique SNOMED CT® Concept) Used for ALL problems addressed for patients – chronic, episodic, subacute Used by ALL clinicians who document care for patient Clinician uses only SNOMED CT® to document diagnoses/problems/indications Additional field of “Provider Text” will allow clinicians to add clarification No free text entries allowed, a SNOMED CT® must be entered POV’s for visit are selected from Problem List Care Planning documentation Ability to select multiple problems for POVs, update statuses, SNOMED, provider text and care plan en masse 666
Rationale for IPL Stage 2 Meaningful Use SNOMED CT® for problem list Care planning Clinical Quality Measures Stabilize the user interface in advance of ICD-10 changes to reduce impact on clinical users Improve clinical documentation of problems and encounter diagnoses Support interdisciplinary problem focused documentation 676
IPL Features - Change Status of Problems Nationally vetted and released Pick Lists -Clinical Indications for orders selected from Problem List -Care planning done from Problem List - 686
Mock-up: IPL Main Display 696
Mock-up: Add/Edit Problem 707
Mock-up: Update/Select Multiple POV The concept is to click “Select POV’s” and be offered a single dialog where multiple problems may be selected for use as POV and care plan data may documented as well as E&M to expedite documentation. 717
Care Planning Features Status: Requirements analysis and design 3 basic components: Goals – target outcome Plan of Care (Patient Instructions) – long term, chronic care issues Clinical Instructions – instructions related to office visit related to acute issues or shorter term management 727
Care Plan vs Clinical Instructions (From CMS) A care plan must include at a minimum the following components: • problem [field = problem] (the focus of the care plan), • goal [field = goal] (the target outcome) and • any instructions that the provider has given to the patient [field = Patient Instruction/Care Plan]. A goal is a defined target or measure to be achieved in the process of patient care (an expected outcome). By clinical instructions [field = Visit Instructions] we mean care instructions for the patient that are specific to the office visit. Although we recognize that these clinical instructions at times may be identical to the instructions included as part of the care plan, we also believe that care plans may include additional instructions that are meant to address long‑term or chronic care issues, whereas clinical instructions specific to the office visit may be related to acute patient care issues. Therefore we maintain these as separate items in the list of required elements below. 737
Care Planning Component 747
Care Planning Component 757
Problem List Migration Routine will utilize the IHTSDO released ICD-9 to SNOMED CT® reverse map and will populate SNOMED CT® where there is a 1: 1 match. ØWhen the user highlights and selects Edit, the Edit a Problem dialog will be presented to the user. ØIf the SNOMED CT® FIELD is empty then the user may search for a SNOMED CT® code and the ICD search will be grayed out OR may launch a pick list. ØAlternately, the user will be offered potential matches returned the IHTSDO released ICD-9 to SNOMED CT® reverse map after clicking “Get SCT” ØUser may also select “Get SCT” and ALL problems with no SNOMED CT® will return the reverse map results based on the ICD-9 for selection. Ø 767
Mock-up: Problem List Migration This would retrieve the problem entries that do not have a SNOMED term and return potential matches based on existing ICD code The concept is to provide a way to assist the user with problems that do not map automatically (with a 1: 1 from ICD to SNOMED CT). The system would retrieve the SNOMED terms that map to the ICD code and the user can select one or search for a new SNOMED CT term. 777
Benefits of SNOMED CT® interface stabilizes the user interface in advance of ICD-10, reducing impact on clinical users • Automatic mappings to ICD-10 codes will assign approximate ICD or uncoded diagnoses • SNOMED CT® is multidisciplinary so better supports documentation for disciplines other than medicine (such as nursing, pharmacy, etc) • Reduces ambiguity particularly for health information exchange • Potential for improved decision support tools using SNOMED CT • 787
Transition to ICD-10 797
ICD-10 Development 48 namespaces require modification > 750 taxonomies require mapping, validation, and testing File structure for ICD-10 negotiated with VA Application requirements “frozen” as of July 2012 Development underway Extensive integration & interface testing will be required. SNOMED CT at clinical user interfaces will reduce training requirement 808
ICD-10 Transition in a SNOMED-CT® Enabled EHR Clinicians document diagnoses and purposes of visits using clinical human readable language that the computer can read via the Integrated SNOMED CT® based Problem List SNOMED CT® preferred terms or synonyms along with provider text – The computer uses established maps to assign an ICD-10 code based on the SNOMED CT® preferred terms Coders review the ICD-10 code and visit documentation and refine the ICD-10 when necessary Clinicians document clinical care… coders code However… clinicians and coders will be co-dependent with the goal of improving documentation for ICD-10. 818
Tools for ICD-10 Transition Mappings used by problem list to ICD code: SNOMED CT® to ICD-9 -CM SNOMED CT® to ICD-10 -CM (rule-based) � First 2, 000 and viewer, trial version, Feb 2012 � Additional 15, 000 – June 2012 Mapping used to assist clinicians in problem list migration from ICD to SNOMED CT Frequently used ICD-9 -CM to SNOMED CT® � Released 5/15/12 828
Terminology Services in IHS New terminology sets – LOINC, SNOMED CT, ICD-10 – impose new requirements for terminology management Legacy approach with Fileman global patch releases may not be sustainable Centralized terminology services approach under consideration at IHS, using open source tools 838
Terminology Services Architecture BMXNet RPMS SERVER Terminology/Subset Management Functions MS. Net Client Applications (i. Care/Patient Reg GUI) SNOMED API: - Search Concepts - List Codeset Versions - Check Term in Subset - … CIA Broker Vue. Centric EHR Local SNOMED Terminology Store CTS 2 Web Services SOAP/REST Apelon DTS v 4 Terminology Service Storage of the terms, relationships, mappings, versioning info Telnet Client Greenscreen Applications Ensemble Integration Engine 848
Sample SNOMED Lookup - CHUI 858
Sample SNOMED Lookup – i. Care 868
Sample SNOMED Lookup - Web 878
OSEHRA, i. EHR, and the Future of RPMS 888
Difficult to maintain & support locally Challenging to host externally due to design and bandwidth Difficult to interface with commercial systems Reliance on VA proprietary capabilities that may not be supported Pharmacy applications Laboratory information system Vist. A Imaging and Vist. ARad Bar Code Medication Administration Lack of modules specific to special inpatient functions Surgery/OR management ICU Labor & Delivery Emergency Department* 898
More Challenges Rapid evolution of health information technology Variability in state laws/regulations Barriers to non-Federal participants in Federal central services (e. Rx, HIE, etc. ) Difficult for Tribal programs to contribute to development Uncertainty about outcome of VA-Do. D i. EHR effort 909
Mandated collaboration between VA and Do. D concerning a common health information solution for military and veterans Standardized service-oriented architecture permitting integration of numerous business-oriented applications, both proprietary and open source Carefully managed development, numerous contracts, releases over several years IHS participates in limited fashion, has made some contributions & demonstrations (i. Care) Final product remains unclear – will it be suitable or affordable for IHS and Tribal health programs? 919
IHS, OSEHRA and the Vist. A Community IHS is not yet an organizational member of OSEHRA HHS attorneys researching options & discussing with OSEHRA IHS will nonetheless contribute all released RPMS code to OSEHRA either directly or via Source. Forge Contribution of pre-release code has not been discussed Closer collaboration desirable for all parties Development/testing/certification of additional web services Services to support adoption of third party applications Niche application development Mobile UI development Forum for Tribal entities to participate in and contribute to RPMS development Evolution of O/S modules compatible with i. EHR architecture 929
Discussion 939
- Slides: 93