GE Centricity and MEDITECH to Epic EHR Transition
Join us for a complimentary webinar as present the decisions that are important to consider when performing a clinical data migration from the point-of-view of: the healthcare organization program manager, the clinical analyst, and the technical implementation team. Our expert panel will survey data migration considerations, best practices and lessons learned from the project. The webcast will present a unique client perspective, offering insight into considerations surrounding staffing, clinical mapping, legacy application support and validation & testing.
8. Galen Roles:
• Legacy System Data Extract and Evaluation
• Clinical Data Mapping
• Configuration
• Testing and Validation
• Data Import and Issue Resolution
• GE Centricity and MEDITECH to Epic EHR
Migration
⁃ Legacy Systems
⁃ MEDITECH 6.0 Inpatient EHR 6.07
⁃ MEDITECH/LSS Ambulatory EHR 6.08
⁃ GE Centricity Ambulatory EMR 9.8
⁃ Target System: Epic 2014
⁃ CCD Extract & Import
⁃ Active Allergies
⁃ Active Medications
⁃ Active Problems & Problem History
Key Metrics
Immunizations270K
Allergies360K
Medications650K
Problems600K
139K Patients
Migrated
200+ Providers
Migrated
SSM Integrated Health Technologies
25. Timeline by Month
December January February March April May & June
Note Gap
Loads
Data Mapping
Client Side Data Mapping
Validation
Large Scale Testing
Round 1
Small Scale
Testing
Round 1
REL Refresh
MEDITECH
MPI PRD
LOAD (12/7-
12/29)
GE MPI
PRD
LOAD
(1/12-2/8)
MEDITECH
MPI GAP
LOAD (3/25-
4/1)
MEDITECH
MPI GAP
LOAD (5/1-5/2)
GE MPI
PRD
LOAD
(4/28-
4/29)
Go-Live Prep
Note PRD
Load
Support
Big Bang
Go-LiveCCDs are
loaded into
PRD &
Abstraction
Starts
Full Scale Testing
Round 1
Client Side Workflow Testing
and Validation
REL Refresh
CCD Gap
Loads
GE MPI
PRD
LOAD
(5/3-5/4)
SSM Health: Legacy System to Epic Conversion Timeline
[Julie]
Best in KLAS – HIT Implementation Staffing and Support
Clinical workflow and operations experts
Average Staff HIT Experience: 12 Years
Our company culture - Strive for success, you get the entire Galen team behind every project
Cross-section of clinical and non-clinical healthcare application expertise
2.0MM Hours Healthcare Experience
280 Customers served in the last 2 years
Boutique, healthcare-focused services & solutions company
For over a decade, Galen has built a solid reputation of providing high-quality, expert level IT consulting services to health systems, hospitals and physician practices.
The foundation of our growth and success can be attributed to our people. It’s what we care about as a company that makes us unique.
[Julie]
Our Value Proposition:
We transform data into actionable, profitable information
Provide world-class Technical & Professional Services to healthcare organizations that interoperate, aggregate, convert, harvest and optimize clinical patient information within their multi-vendor systems portfolio including Practice Management, Electronic Health Record & Health Information Exchange.
Deliver a suite of fully-integrated Products that enhance, automate, and simplify the access and use of clinical patient data within those systems to improve cost-efficiency and quality outcomes.
[Julie]
[Sandy]
Consider all inbound data feed options – like re-purposing an inbound point of care lab interface to import lab results.
Consider how the bulk import of results and data will affect downstream systems (portal notifications, provider tasking, etc.)
Don’t underestimate the importance or time required for mapping. In addition to nomenclature and code mapping – there are the nuances between systems (i.e. format required, blanks, comments, units of measure, etc.)
Have a dedicated clinical and technical team and don’t lose momentum.
[Justin] Incorporate HL7? project overview; significant legacy systems needed to be brought forward into Epic; CCD Extract & Import – put in history
[Sandy]
Facilitated discussions with physicians, hospital administration and clinic leaders regarding data elements for migration and amount of data to migrate.
Coordinated IT technical plans with System IT leaders and local IT staff.
Completed data mappings and coordinated System IT resources for data loads.
Completed necessary paperwork and project request forms (internal change control process).
Validated data loads, CCDs, and data reconciliation process.
To determine appropriate mappings based on clinical input.
Determine appropriate/desired workflows for physicians end-users (e.g. No Known Allergies Workflow, Unmapped Allergy Reaction Workflow – is it preferred to map allergy reactions as ‘unknown’ or should these reactions be left unmapped so that providers may easily ascertain and add the appropriate reaction the next time the patient is seen?
Provided demos for physicians – helped to involve physicians and create buy-in
[Sandy]
We considered hiring temp help (clinical students) to manually abstract the data from source to target system.
We evaluated the tradeoffs and talked through options.
The med & nursing students didn’t know systems – that was a major factor
Another was the potential for human error and lack of audit trail that comes with manual data abstraction. The systems are constantly changing, and as such the fidelity of the data could come into question.
Cost benefit analysis shaped the scope (different elements)
Going into any new data migration we provide the client an assessment of the capabilities of our migration engine, GalenETL. In a few minutes we will discuss the impact of the assessment with the scoping decisions made by SSM, but first we’ll briefly discuss the capabilities coming into each data migration. Each client is unique in their approach to migrating data and we provide a menu-like approach to choosing which clinical data elements will need to be brought over.
The decision all starts with the legacy EHR, that we call the source system, and how the data is stored. Is the data discrete, is it combined into scanned images, is it spread across multiple tables, etc. The data is further sub-divided by the preference in which the target EHR, also called the target system, needs the data to be delivered in order to load it for clinical use. This ranges from HL7 messages, Continuity of Care Documents (CCDs), flat files, or scanned images. Now to get the data from source to target we insert the GalenETL data migration engine into middle to act as the transformation engine to support your needs.
As you can see in this graphic, we utilize healthcare standards, such as HL7 or CCDs, or any other formats for that matter, to deliver a wide variety of data elements to support your data migration. This isn’t an all-inclusive list, but a great example to highlight the functionality that we can provide for your source system data. If you don’t have access to the entire source system database we can also extract clinical data from standardized data sets, such as HL7 or CCD to perform similar workflow, but we always prefer to work with the source system data when available.
We were just talking about what we can migrate, now we are going to review and discuss how SSM applied our capabilities to reflect their budget and data needs based on an assessment we performed with them to determine the cost
[Kavon & Taylor] Framework for scoping, assessing conversion
Multiple ways to filter the data
Decide what data types will be converted
Immunizations, allergies, medications, results, problems, documents, vitals, images
Not every data type may be present in the source system
If organization has no inbound results interface then there may not be results to extract
Different ways to filter clinical data depending on need
Clearly define what fields will be converted
Can help to display where fields render in the target system
All fields might not be available to convert
Can depend on workflow
Graphically show how different clinical items are manifested.
Show all the clinical items (with icons) for those grouped under HL7 and those grouped under CCD, etc. – See example on following slide
Highlight what SSM decided to do – how they manifested or how they were migrated. Animate?
You have an opportunity for all of this stuff – but these are the ones SSM chose for these reasons. Scanned images – chose not to pursue because they knew they would have that in PACs
Physicians didn’t think that historical vital signs would be beneficial
How much history for these data elements do we want to bring over? Previous 2 years for notes. Refining the patient population. Only bring over patients that have been active or seen within the last 2 years
Want to be consistent in terms of decision in the amount of information (avoid situation where one element has 2 years; another has 3 years) going to be 2 years unless you have a reason why it should be shorter or longer.
Why?
Sometimes adding a large amount of data
Very difficult to change once data has been loaded
Way the data is stored in the source system does not always play nice with how the target system accepts it
Way the source system records medication refills may be different from how the target system records them
Often need to think long term and about the global context in the organization
Mapping highly utilized medication in source system to rarely used medication in target system may not be a good idea
Data access, extraction and evaluation are the initial steps to any data migration project at Galen. In this phase we want to confirm access to your clinical data so that we can start extracting it into our GalenETL data migration engine for evaluation and comparison with your source system’s UI.
There are several challenges we continually face during the access, extraction and evaluation phase that we help our clients mitigate through planning, discussion, and execution.
Which system do we want to use as the source of truth (LLS vs MT) since there could be overlap. In Acute/Ambulatory shared or integrated environments, such as what we encountered at SSM. We need to determine the origins of the migrated data. For example, in a shared platform with multiple data sets, data entry from one platform can migrate over through existing stored procedures so that the data can appear in both acute and ambulatory user interfaces. However, our goal is to determine which of the two system that data originated so we can capture the data from where it was initially entered into the EMR so we can modify our extracts to select from the correct location.
When we start developing our data extracts and reviewing the results, we can run into issues that can be identified without impacting the project timeline and deliverables. We can triage the issues to apply fixes or features to reduce or eliminate the issues prior to the loading of the data. Sometimes these issues take weeks or months to resolve, but we identify them upfront and continue to provide updates on when the client can expect to see the data delivered for testing purposes.
Examples, previous experiences, leverage our experience (Julia’s speil)
Perhaps the most critical component of this phase is getting access to the data. Timely access to the data helps ensure the project stays on schedule and that our consultants can begin the extraction process of the data into our GalenETL platform. From within the GalenETL platform we can start to evaluate the data along with our conversion analysts counterpart and determine how the extracted data aligns with the EMR or data source from which it is being extracted. We
[Taylor] – Have Sandy chime in
One of the most critical parts of a data migration is how quickly and effectively the data migration team can gain access to the source data and application.
Source data access entails the ability to query and extract data from the system that is being migrated and typically means that we have direct access to a copy or production data of the relational database system (SQL, Oracle, MySQL, etc). Source application access typically refers to read only rights that allow us to confirm that the data we are extracting aligns with the data that the end users are seeing. This helps us prepare for later testing rounds.
The remaining parts of a project depend on this timely access. Delays in access may require the timelines to be shifted or require additional effort than what was originally scoped.
Access
There are several approaches to access that we’ve seen be successful:
Onsite kickoff that focuses on project and access prior to departure – we’ve had several projects start in this fashion and
Ensure that access/security team is part of the project discussion during scoping phase
Upon signing, focus on access requirements immediately
Understand and communicate what access requirements are needed for data migration project
[Kavon]
Focus on percentages – effort needed for items that are not codified; Exact spelling matches drive the low match rate
When importing data, Epic matches allergies based on the RxNorm codification. When Epic cannot match allergies based on RxNorm, it still has the ability to match allergies based on exact spelling. Despite the low percentage of allergies in MEDITECH and GE Centricity with associated RxNorm codes, a large percentage of allergies are still expected to be matched based on spelling. The percentages in these columns represent a worst case scenario.
When importing data, Epic matches problems based on ICD-9, ICD-10, and SNOMED codes. Due to the high percentage match with these standardized codifications, a minimal amount of effort will be required to manually abstract unmapped problems during reconciliation workflows.
When importing, data, Epic matches Medications based on the RxNorm and NDC codifications. Due to the high percentage match with these standardized codifications a minimal amount of effort will be required to manually abstract unmapped medications during reconciliation workflows.
Discuss importance of codifications when migrating data to Epic.
[Kavon]
Standardization – e.g. codification
Strategy = mapping validation. Galen first pass, Client/Clinician second pass
Medications – Dose, Route, Unit, Frequency; Search for equivalence in target system. A lot of times there are not exact equivalents or may be some uncertainty mapping; As such – pharmacy resources needed for med mapping; clinical resources needed for allergy mapping
Kavon to elaborate NKA use case consideration for Epic: workflow – how does the client use? NKA can be sent in and reconcilable; Any patient who has that field populated would then appear to have allergies; Same thing goes for unmapped reactions
This just scratches the surface for mapping considerations – we wanted to provide some specific examples; with more clinical items in scope outside of just PAMI, there are even more mapping decisions
[Kavon]
Less effort for client end users when you can map discretely – ease of reconciliation.
Volume stats are important. Physicians wanted everything – they gave them a lot. Communicate enormity of the information they were able to bring over.
Physician buy-in to the process once they see how it works
The mapping counts for Allergy Reactions are lower in GE Centricity than for MEDITECH due to the large number of free text Allergy Reactions documented in this legacy system that do not have discrete matches in Epic.
The mapping counts for Medication Dose Units and Route appear lower due to how the data needed to be extracted from GE Centricity. To map Dose Units and Route discretely, complete medication instructions were extracted from GE Centricity and Dose Unit, Route, and Frequency were mapped when appropriate. If a medication instruction did not contain a Dose Unit or Route (e.g. Take 1 Daily), no Dose Unit or route could be mapped. Thus, there were simply a large number of medication instructions where mapping certain elements was not appropriate.
Manual process completed by Galen.
End-users will not have to manually manipulate data prior to reconciling/adding it to the patient’s Epic chart. Higher percentage of mapped elements results in less time required to add this clinical information into the target system. Compare this with manual abstraction, and the time saved is even more apparent.
[Kavon]
Gap loads specific to SSM to talk through
Timeline was a major challenge
Visually represent clinical validation; rounds of testing (subsets of data) – at patient-level.
Ensure only data that is in-scope is pulled.
Full-scale – essentially a dry-run.
Benchmark duration of production load;
identify exceptions that would need to be addressed before production
Reconcile CCD;
adding medication; trying to reduce as many hard-stop as necessary;
Validation Methodology Overview: While Galen's validation methodology consists of several phases of testing (Unit, Small Scale, Large Scale, and Full Scale) that culminates in a total of at least 270 patients and 270 instances of each in-scope clinical element being tested, we also deploy other testing methodologies to ensure the appropriate and safe migration of data. One of the methodologies not captured in the validation tracking above is focused testing.
Focused Testing: Throughout the validation process, Galen performs data testing where specific scenarios that could cause or result in issues are identified and tested. Examples of focused testing include testing multiple examples of every mapped allergy reaction, medication dose/dose unit, route, and frequency. Similarly, other scenarios include:
•Testing patients that have matched vs. unmatched allergies/problems/medications
•Testing patients that have mapped and unmapped allergy reactions
•Testing patients that have an allergy with more than one mapped allergy reaction
•Testing patients that have no documented allergies, medications, or problems
Gap Testing: Generally during a migration there is a need to perform more than one data load into the target system. Subsequent data loads are referred to as gap loads. The goal of a gap load is to capture in-scope clinical elements that have either been updated, changed, or removed from the legacy system since the initial data load. To accomodate gap loads, Galen also performs gap testing. During gap testing, Galen validates that any changes that have occurred in the legacy system are reflected appropriately in subsequent data loads into the target system. Some gap testing scenarios include:
•Testing to ensure that removed allergies, medications, and problems no longer show on subsequent CCDs
•Testing to ensure that updated allergies, medications, and problems show on subsequent CCDs and replace the previous version of the allergy, medication, or problem that was updated
•Testing to ensure that allergies, medications, and problems that have not been updated, but that are included in subsequent CCDs do not duplicate in the target system
•Testing to ensure that previously reconciled allergies, medications, and problems do not duplicate in Epic and cannot be reconciled again
[Kavon]
Challenges
Communication for data loads
Timeline
Abstraction Go-Live 2 months
Epic Go-Live 4 months
[Taylor]
The final phase of a data migration project is the process of populating the full data set of production ready data, loading it into the target system, and subsequent loads of gap data between the initial production load, Go Live date, and the date when the source system is turned into Read only and no more updates have occurred.
We’d like to discuss three challenges that we face during this process that can be reduced through thoughtful planning, a sound technical approach, and strong project management.
MPI (master patient index) loads can be performed by the client or by Galen, but contain the demographics that are not only brought over into Epic, but are used to match migrated clinical data against. This data set is the primary record used to establish that patient in the target system and becomes more complex given the following scenarios that we encountered with this project and many others:
Multiple systems that could contain the same patient
Initial and gap MPI Load schedules for multiple systems as they continue to change/evolve
Extraction vs abstraction timeline – these two timelines hold key project plan considerations as they pertain to hard timelines/deadlines we need to meet in order to keep the project on schedule. Extraction timelines are associated with the time that it takes us to pull the data from the source system and transform the data into data format requested by the client or target system. Abstraction timelines are generally provided by the client but focus on the time it will take their team to reconcile the loaded data in target system’s user interface.
All of these lead to the higher subject of timing and the multiple components that go into the planning to ensure that the data is in place when the client expects it to be.
[Taylor]
[Taylor]
Data Extraction
Delivery and Loading
Validation
Go-Live Expectations
[Kavon]
Major milestones – audience can get a sense for the timeline they should budget for
Initial extraction go-live in feb. Very tight timeline. Didn’t get to start testing until sometime in January
***These dates assume that Taylor is able to gain access at the beginning of next week (12/7/15)***
12/7/15-12/11/15: Taylor to create and handoff CCD Mapping Workbooks to professional services team.
This could also be done in piecemeal fashion as Taylor completes the mapping workbooks for each data element rather than waiting for all workbooks to be finished to begin mapping.
12/14/15-12/18/15: Professional Services team to complete CCD Mapping (Allergies and Medications)
12/21/15-12/23/15: Taylor to create three CCDs with all discrete mapping included (e.g. route, frequency, dose, dose units)
12/21/15-12/23/15: Taylor to extract three complete CCDs
Steps 4 & 5 to be completed concomitantly
12/28/15-1/5/16: Create Notes Mapping workbook
12/28/15-1/5/16: Create Encounters Mapping workbook
Steps 5 & 6 to be completed concomitantly
1/6/16-1/8/16: Professional Services team to complete notes and encounters mapping
1/11/16-1/15/16: Taylor to extract and load 5 notes and linked encounters.
1/18/16-2/4/16: Small Scale Testing
2/8/16-2/25/16: Large Scale Testing
2/29/16-3/24/16: Full Scale Testing (Galen company trip 3/16-3/19)
3/28/16-4/15/16: Go-Live Prep
4/18/16-4/29/16: Production Load
[Sandy]
[Sandy]
Abstraction process = Epic practice
Migrated data reduced the amount of time spent abstracting for not only clinic visits but also patients who were currently in-house at the time of “Go Live.” This was an unexpected benefit.
Ensure that the MPI and visit loads are complete, up-to-date, and clean.
Begin the data migration process early! Some activities took longer than anticipated
Get agreement on elements to migrate versus abstract as well as the approach for migration (CCD, HL7).
Physician champions:
Experts for data elements and data mapping
Strong working knowledge of the reconciliation process in the new EHR
Champion the data migration effort with other providers and physicians
Have operational and IT subject matter experts available for data mapping. Experts need to be proficient with “old” EHR and have a good working knowledge of “new” EHR
Ensure that the data migration and abstraction strategies work hand in hand.
A1 – Providers familiarity with the EHR played a part.
They wanted everything, but it was important to show them that everything has a price tag.
We delved into filtering and ultimately came up with 2 years of data.
We had to weigh every category of data and get buy-in from providers on the approach.
I would say it does take time to get folks on the same page: “What I would like to have” vs. “What I really need.
This underscored the importance of the work on the front end: scoping of data via assessment?
A2 – Yes, but I wish we had more time so there weren’t multiple loads of problem history.
A3 – A big benefit was going live with the data migration at the same time for the go-live of the hospital.
Lots of patients already had demographics, meds – specifically clinic patients who were hospital patients.
Also reconciliation of the data allowed our staff to become gain familiarity with Epic – how to look up certain pieces of info. Physicians became more familiar through the reconciliation process
Downside was weird stuff that existed in source record – namely data variability and integrity issues.
How old the information was made it more challenging.
[Sandy]
Community Support
Knowledge center with whitepapers, playbooks, guides.
Our contribution to move healthcare IT forward
Freely sharing our unique perspectives, our knowledge and our experience
Over 622 blog posts
Over 213 complimentary webinars delivered
Visit our knowledge center - galenhealthcare.com/knowledge-center/
Visit our wiki – wiki.galenhealthcare.com
Visit our Blog – blog.galenhealthcare.com
