According to a recent report by KLAS, 34% of eClinicalWorks customers are prepping to switch EHR vendors. As provisions of the settlement and the signed Corporate Integrity Agreement, eCW is required to offer de-migration options to their customers:

The Data Transfer Option requires eCW to assist current customers with migrating to other EHR companies, without penalties or service charges for breaking contracts.

“Data Transfer Option for Existing Customers: Consistent with requirements and limitations in this section, eCW shall timely transfer the Existing Customer’s data without penalties or service charges (including, without limitation, any break fee or termination fee) other than contractual amounts still owed in connection with goods or services already provided (“the Data Transfer Option”).”

The nature of data structure and storage within the eClinicalWorks database is non-traditional and complex. In general, these complexities are due to the following two reasons:

• Most of the data is stored at an encounter level and duplicated at each encounter rather than stored at a patient level and simply referenced at each encounter.
• The application allows for nearly any type of data to be entered as unstructured data.

We’ve assembled our lessons learned in migrating clients from eClinicalWorks to other EHR platforms. For a full analysis, download a de-identified sample eClinicalWorks database assessment we provided for one of our clients or view a case study describing how we assisted St. Joseph Health System  with their eCW to Allscripts Touchworks EHR migration.

Global Challenges

• Data stored at encounter level instead of patient-level.
• Duplicate data at each encounter instead of reference at the patient level for each encounter.
• Free text allowed for virtually every type of entry rather than dictionary lookup.
• Very little usage of dictionaries or standardization with codification.
• De-duplication/listing distinct is a large task.

Medications

• Difficulty in distinguishing past meds versus active meds.
• Dosage and formulation stored as separate data elements instead of being encapsulated in medication name.

Problems

• Past Medical History: Stored as a single delimited string at each encounter.
• Social History: Recorded as a question and answer within the note.

Document/Note

• Notes stored as XML and need to be converted to RTF.
• HTML converted to an RTF using an XSL style sheet.
• The XML of the note not locked until the providers lock the encounter.

Allergies

• Replicated at each visit.
• Reactions recorded as unstructured data.

Results

• Separate extracts could be required for in-house and interfaced results.

Images

• Free-text, custom names permitted for document types.

Vitals

• Can be entered as free-text without constraints.

Progress Notes

• Stored as encrypted XML.
• Associated stylesheet.
• Output to PDF, HTML, XML.

View additional resources to help you tackle eClinicalWorks data extract, clinical data migration (data conversions) and archival:

• HSCIO Webinar: Exploring Healthcare Data Archival Strategies
• HSCIO Webinar EHR Transitions: Legacy Support and Staff Augmentation
• EMR Data Archival Strategy Whitepaper
• EMR Replacement, Migration & Archival Resources
• Tackling Transition Blog Series
• Expert Panel: Seamless EHR Transition Through Data Migration