Keywords
participatory design - data migration - electronic health record vendor transition
- end-user feedback - stakeholder feedback - physician engagement
Background and Significance
Background and Significance
Medical institutions are increasingly faced with the challenge of transitioning to
a new electronic health record (EHR) system as policies evolve, technologies advance,
and health networks merge.[1]
[2] A complexity that often arises during this transition is data migration.[2] Data migration describes the transfer of EHR data from the current system to a new
EHR.[3] This key step determines the clinical data content of the new EHR environment which
may ultimately influence subsequent institutional and clinical outcomes.[4]
[5]
[6] There is currently a paucity of data on the best approach for defining institutional
data migration based on the unique needs of clinical end-users. In this case study,
end-user feedback was obtained to develop the display of historical clinical data.
The amount of clinical data that can be migrated may be limited due to resource constraints.[7] For example, data from a proprietary EHR may not be transferrable in a form that
is compatible with the new EHR system. Conversions to ensure that data are fully accessible
in a new EHR system can be complex, costly, and may take weeks or months to complete.[7] Scripted data transfer has been shown to be effective and efficient but depends
on compatibility between systems, accurate master patient lists, and the ability to
accurately assign appropriate codes to the clinical data being migrated.[8]
Nonmigrated data is subsequently stored and is accessible via an archival legacy system.
Failing to precisely define the scope of clinical data for an EHR migration jeopardizes
the data integrity and clinical usefulness of the new environment.[9] Physicians may in turn spend additional time accessing the legacy archive to retrieve
data, a process that vendors may strive to advertise as “only a few extra clicks,”
but this may contribute to physician burnout.[10]
[11] Consequently, physicians may forgo archival data retrieval and simply elect to repeat
medical tests leading to health care waste in the form of redundant testing and reduced
patient safety.[12]
To define data migration on behalf of 20 ambulatory clinics, we developed a framework
based on participatory design (PD), a user-centered design approach that actively
engages end-users and stakeholders to design technological interfaces and systems.[13]
[14]
[15]
[16]
[17]
[18] Specifically, our framework involved an institutional committee consisting of key
stakeholders involved with the EHR transition. At this level, categories for data
migration were reviewed, lookback periods were established, and end-users were identified
to provide specialty-specific data migration feedback. PD is an approach that has
been used in healthcare to address the interorganizational nature of healthcare informatics,[19]
[20]
[21]
[22]
[23] resulting in improved system quality, higher levels of user adoption during implementation,
and decreased training needs.[24]
[25]
[26] Design based on end-user feedback has been shown to reduce end-user variations in
EHR use that often exists within practice settings using a common EHR.[27]
[28] Although PD emphasizes end-user feedback to influence functionality and design outcomes,
the goal of this study was to use PD to determine EHR content.
The aim of the data migration project was to elicit feedback from stakeholders to
compile a detailed list of laboratory and documentation data to be included for data
migration that reflected the unique needs of various specialties.[27]
[28] This consisted of individual laboratory types, documents, and other test results
with corresponding lookback periods used to quantify the amount of data to be transferred.
Other clinical domains, such as demographics, allergies, medications, past medical
history, and imaging reports, were not subject to data limitations and thus were not
included in end-user–focused provider feedback discussions. To our knowledge, there
are no publications to date that presents an approach to defining data migration using
PD in this setting. Here, we present an overview of our approach and recommend considerations
for similar institutions facing this task.
Methods
Setting
The study was conducted at a 602-bed urban tertiary care hospital with 20 ambulatory
clinics that are part of a larger health-network.
Committee and Key Stakeholders
After EHR vendor selection was established, a health-network governance committee
consisting of representation from executive and medical leadership, health information
technology, and vendor implementation specialists was appointed. This committee established
the broad categories of clinical domains to be included for data migration and determined
which would be subject to data limitations. Each hospital site then developed their
own institutional governance committee that would submit a proposal for data migration
and all requests would be combined to create a common EHR environment.
Our institution-specific EHR committee, which was overseen by the Chief Medical Information
Officer (CMIO), consisted of 10 key stakeholders from health EHR vendor specialists,
internal information technology (IT) specialists, executive management, physicians,
and advanced care providers ([Fig. 1]). Clinical department heads (chiefs of service) were also asked to participate in
this collaborative effort. Data migration discussions began 8 months prior to the
anticipated go-live date.
Fig. 1 Key-stakeholder groups involved in developing a data migration project. IT, information
and technology. NP, nurse practitioner; PA, physician assistant.
Defining the Scope of Data Migration
Specialty-specific feedback was elicited to define the scope of data migration for
documentation note types, laboratory values, and diagnostic test/procedure reports
([Table 1]). Physicians representing their respective ambulatory clinic were given the option
to review all laboratory types ordered and document types used in the past year. They
were then asked to indicate those suitable for data migration based on their perceived
usefulness within their specialty. All radiology reports would be included for data
migration. Radiographic images were not involved in data migration discussions, as
they were available via the independent picture archiving and communication system
(PACS).
Table 1
Inclusion and exclusion criteria of clinical data designated for data migration based
on specialty specific feedback
|
Laboratory
|
Imaging
|
Direct care documents
|
Scanned documents
|
|
Included
|
Any laboratory ordered at least once over the past year
|
All imaging reports
|
Physician documentation (phone calls, history and physical (H&P) notes, acute visits,
etc.)
Operative notes
|
Advanced directives
Consent to participate in research
External facility results (laboratories, imaging reports, stress testing, mammography,
etc.)
|
|
Excluded
|
Laboratory types not placed over the past one year
|
Radiology results[a]
|
Nonprovider documentation (i.e., nursing notes, pharmacy notes, social work, etc.)
|
Insurance forms
Patient questionnaires
Miscellaneous forms
Procedural consent forms
|
a Radiology images were not included as these are accessible via a separate picture
archiving and communication system (PACS) imaging system.
Classifying Laboratory Results
After committee review, three possible distinct “lookback” periods for lab values
were designated: (1) “3-years,” (2) “10 years,” or (3) “lifetime.” This was done to
ensure that the laboratory values migrated were relevant and contained enough data
points to have adequate clinical utility. The threshold of 3 years was based on the
clinical utility of trending commonly ordered values (i.e., prostate-specific antigen
[PSA], international normalized ratio [INR], iron studies, lipid values, etc.). Physicians
reported that this time frame likely provided enough historical data and additional
data beyond 3 years was not perceived to be beneficial. If physician stakeholders
indicated that a laboratory result should be included for data migration, they then
assigned it to one of the three look-back periods to indicate the amount of historical
data necessary ([Table 2]).
-
“Trended” laboratories were those that physicians usually compare with previous values
when making diagnostic decisions. Therefore, laboratories in this category would include
all values on file for patients over the past 3 years. Examples included but not limited
to hemoglobin A1c, PSA, and lipids.
-
“Last value” laboratories would be a single discrete laboratory result for particular
laboratory within the past 3 years. These refer to laboratories that are not generally
repeated within a 3-year period. Examples included but not limited to immunization
titers, Helicobacter pylori stool antigen, or heavy metal testing.
-
“Any value” are lifetime laboratories that are not routinely ordered with great frequency
but carry a high clinical significance. Examples include, but are not limited to interferon-gamma
tuberculosis (TB) testing, hemoglobin electrophoresis, hypercoagulable tests, and
genetic studies. These laboratories had no limit to the lookback period performed.
Table 2
Lookback period classifications for labs assigned to data migration
|
Laboratory category
|
Corresponding lookback period
|
Examples
|
|
Trended
|
Trend all values on record from past 3 years
|
CBC, lipid panel, A1c, PSA
|
|
Last value
|
Last value recorded over the past 3 years
|
MMR and varicella titers, Helicobacter
pylori stool antigen
|
|
Any value
|
Any value ever performed on record
|
Hemoglobin electrophoresis, ANA identification panel, interferon-gamma tuberculosis
|
Abbreviations: A1c, glycated hemoglobin; ANA, antinuclear antibody; CBC, complete
blood count; MMR,measles mumps and rubella; PSA, prostate specific antigen.
Provider Feedback Forms
A master list of all the unique laboratories ordered over the past year (n = 415), arranged by ordering frequency, was used as a template to obtain individual
provider feedback. Providers were asked to review the top 100 most commonly ordered
lab values (which accounted for 98% of all laboratories placed over the past year),
with the option to review the remaining 315 less frequently ordered lab values. The
aim of this approach was to maximize provider engagement by reducing the burden of
laboratories for them to review. This would ensure that the laboratories with the
largest amount of data to be migrated would be reviewed by all specialties interviewed.
Categorizing Documentation
Each clinic was asked to review their respective list of all the document types with
the corresponding frequency of use over the past year and select which items were
deemed necessary to be included for data migration.
Scanned Documents
Scanned documents posed a challenge for data migration and mapping as they contained
nondiscrete data. There were no institution-wide guidelines for scanning, and subsequently
each clinic had a unique approach to categorizing and labeling scanned documents.
The master list of scanned document types was manually reviewed. Any documents that
fell into one of the data-migration categories (i.e., laboratory values, procedures
results, provider documentation, and end-of life care forms) were included in the
final documentation list for data migration. Remaining scanned documents or “miscellaneous
scanned documents,” would remain in the legacy data archive.
Standardized Technical Presentation Points
Discussions were held with the committee and clinic leaders to elicit feedback and
address concerns. The following points were emphasized when presenting the concept
of data migration to physician key stakeholders:
-
All existing results, notes, and historical data would be accessible after the EHR
transition via an archival system.
-
The purpose of collecting their specialty-specific feedback was to identify clinically
relevant data that would be commonly used to deliver patient care. Having this particular
set of data migrated would ultimately save time and reduce the need for extra clicks
to access historical data.
-
Simply migrating everything into the new system was not feasible due to the large
amount of data which would require a lengthy and time-intensive conversion. This could
also potentially lead to having less-pertinent historical data that would make a new
user interface more challenging to adapt to.
Results
Overall, 90% (17 of 19) of key-stakeholder physicians agreed to take part. The feedback
compiled reflected a detailed list of clinically meaningful results that reflected
the needs of each medical specialty. Requests for types of laboratory values and associated
lookback periods varied based on specialty ([Fig. 5]). Requests ranged from 2 laboratory types from rehabilitation medicine, to as many
as 145 by immunology and infectious disease. Specialties that provided care on a long-term
basis with more frequent patient visits (family medicine, immunology and infectious
disease, and oncology) requested the most laboratory types (n > 87). Rehabilitation medicine, orthopaedic surgery, and bariatric specialties requested
fewer than 20 laboratory types. A total of 241 unique lab types were ultimately requested
for migration ([Supplementary Appendix A], available in the online version). Interestingly, there was often a discrepancy
regarding an ideal lookback period. When this occurred, the lookback period with the
most data was chosen. Requests for historical provider documentation for a given clinic
ranged from 3 note types to 43 with an average of 14 per clinic ([Supplementary Appendix B], available in the online version). Providers were generally enthusiastic about providing
feedback and 41% of providers (7/17) elected to review and provide feedback for all
lab values listed and not just the top 100. The most common questions received from
providers involved the appearance and accessibility of the legacy data archive and
the impact on their workflow if data was not migrated.
Fig. 5 Laboratory orders requested for data migration based on specialty.
Discussion
This paper presents an approach to define the data migration needs of numerous ambulatory
clinics using a PD-based method during the implementation of a new EHR system. By
involving physician end-users, the clinical data designated for migration more accurately
reflected their clinical needs. Physicians requested anywhere from 2 to 43 note types
and from 2 to 145 unique laboratory types. These variations in feedback underscore
the importance of tailoring data migration to end-users. This is in keeping with the
well-observed phenomenon that even when controlling for EHR and practice setting,
there exists a wide variation in individual physician practice patterns.[25]
[29]
Feedback from all stakeholders including information technology and vendor representatives
should be elicited early in the preimplementation planning phase. Data elements within
the original EHR that are eligible for migration such as laboratory values and document
types must be identified. The use of logical observation identifiers names and codes
(LOINC) standards may facilitate this. Data types that are subject to data migration
limitations should be defined based on end-user feedback to ensure clinically relevant
data are included for migration. Initial strategies to define data migration were
to take the top 100 most ordered laboratory types with 3-year lookback periods. While
this would likely transfer a large volume of clinically useful data, it would have
been suboptimal for certain specialties, such as oncology and infectious disease,
who identified several rarely ordered lab types as being critical to transfer to a
new EHR, such as genetic tests, electrophoresis, and, cytogenetics. Therefore, data
migration for specialties may require protocols to include additional laboratory types.
Common barriers to implementing PD include time constraints,[30] poor organizational support, and lack of physician understanding of the technical
aspects involved.[23]
[30]
[31]
[32] Our response rate (90%) for physician end-user participation which likely underscored
the strong endorsement and support from executive leadership, as well as accommodating
physicians' time and location for arranging meetings to obtain feedback. This project
was orchestrated by the CMIO. A clinical informaticist plays a critical role within
the health care setting by having the ability to understand and incorporate the unique
needs of a diverse set of end-users for EHR optimization. By understanding the potential
clinical implications of EHR functionality and design decisions, the clinical informaticist
has the unique skill sets to engage end-users and advocate for a system that optimizes
clinical outcomes.
Actively engaging end-users is only one part of PD which is based on several principles
including mutual learning between designers and users, exploring alternative design
visions, and simulation-based action.[33]
[34] Applying PD in the health care setting has been shown to enhance physician usability
and satisfaction[6]
[21]
[24]
[35]
[36] and improve patient care. PD has great potential to revolutionize health care but
it is still greatly underutilized.[37] Focusing on end-user feedback allowed our institution to successfully define its
unique data-migration needs for an upcoming EHR transition.
Limitations
Our study has several limitations. Each specialty was represented by only one clinical
end-user. Results would likely be more varied with a larger sample size within each
specialty. Another limitation was that, at the time of this project, we were unable
to show end-users what the legacy archive would look like. The most common question
that providers had was regarding the appearance and accessibility of the legacy data
archive. Gettinger and Csatari[2] described an unexpected and persistent reliance on legacy data to access administrative
documentation consistently even 1-year post-EMR transition. Future research evaluating
how accessing archival data impacts daily clinical practice patterns would be helpful.
Conclusion
PD describes a design approach based on feedback from all stakeholders. When transitioning
to a new EHR system, it may not be feasible to migrate all clinical data. Eliciting
physician end-user feedback to define data migration can be an effective approach
for health care institutions faced with this task. Clinical informaticists are well
suited to design and implement EHR optimization projects that integrate the needs
of clinical, executive, and technical stakeholders.
Clinical Relevance Statement
Clinical Relevance Statement
When transitioning between electronic health record systems, clinical institutions
may be faced with the task of defining the clinical data to be transferred. This paper
outlines our approach in developing a detailed list of clinical data elements for
data migration based on the unique needs of end-users. It may serve as a general framework
for other institutions faced with the task of defining data migration.
Multiple Choice Questions
Multiple Choice Questions
-
What is the benefit of using participatory design during an electronic health record
transition?
-
Reduced costs.
-
Provides rigorous guidelines for governance.
-
Allows for design based on end-user feedback from stakeholders.
-
It requires fewer resources to implement.
Correct Answer: The correct answer is option c. Participatory design describes a process of design
that attempts to actively engage end-users in the design process to ensure the final
product meets their needs and is usable.
-
Why is it important to consider the needs of clinical end-users when discussing data
migration for an electronic health record transition?
-
To ensure end-users have access to relevant clinical data.
-
To avoid relying on legacy databases to find clinical data on a routine basis.
-
To ensure that the new electronic health record environment is relevant to various
clinical specialties.
-
All of the above.
Correct Answer: The correct answer is option d. Clinical end-users demonstrate variability in how
they interact with an EHR system. To ensure that data migration results in an EHR
environment that is useful and promotes efficiency, data migration should reflect
the needs of clinical end-users.
