An EHR migration can involve millions of structured data records.
Patient demographics, encounters, diagnoses, appointments, medications, and billing information all need to move into the destination system.
But after months of planning and database migration work, there can still be one significant repository left behind:
the documents.
Older healthcare applications may store formatted clinical and administrative documents separately from the main database.
If the application used HighEdit as its document technology, those files may exist as proprietary HED documents.
Before the legacy EHR is retired, these files need a migration strategy of their own.
The Database Is Not Always the Complete Patient Record
A legacy EHR may store document metadata in the database while keeping the actual formatted content on a file server.
For example:
Patient ID: 482713
Document ID: 2818371
Document Type: Clinical Letter
Created: 2013-11-04
File: 2818371.hed
A database export can successfully preserve the first four values while leaving the actual document behind.
Without 2818371.hed, the migrated record is incomplete.
This is why document repositories must be included in the EHR migration plan.
Why HED Files Are Easy to Miss
Users of the legacy system may never have seen the .hed extension.
They simply clicked a document inside the EHR and the application displayed it.
The file format was an implementation detail.
Migration teams may therefore discover HED files only after examining file servers or database references.
A repository may contain filenames such as:
00381726.hed
00381727.hed
00381728.hed
Without the legacy database, these filenames may provide very little information about the associated patient or document type.
Find the HED Repository Before Decommissioning the EHR
The best time to investigate the document architecture is while the original system still works.
Determine:
- Where HED files are stored
- Which database table references them
- How files are associated with patients
- Whether there are multiple repositories
- Whether files are organized by date
- Whether templates are stored with completed documents
- Which documents users still access regularly
This information can become much harder to reconstruct after the original EHR has been shut down.
Decide What the New System Needs
Historical documents typically fall into several categories.
Completed Patient Documents
These documents should normally remain viewable but do not need to be edited.
Examples include:
- Clinical letters
- Physician reports
- Referral documents
- Historical forms
- Patient correspondence
PDF or PDF/A is often appropriate for this content.
Active Templates
Templates may still be needed to create future documents.
Examples include:
- Physician letter templates
- Standard forms
- Administrative correspondence
- Reporting templates
These may be better converted into editable formats such as DOCX.
Documents for Data Extraction
Some migration projects need access to the text or other information contained in historical documents.
In these cases, document conversion can be combined with extraction and indexing workflows.
Convert Historical HED Files to PDF
For completed records, PDF provides a simple way to remove the dependency on HighEdit.
A converted PDF can be displayed by:
- The destination EHR
- A document management system
- An archive viewer
- A browser
- A patient portal
- A clinician portal
The organization no longer needs the original HighEdit software simply to render the historical document.
Consider PDF/A for Long-Term Records
Healthcare documents may need to remain accessible for long periods.
For archival scenarios, PDF/A can be considered as the target format.
The goal is to move important historical documentation away from a proprietary application format and into a format designed for durable document preservation.
The organization's own regulatory and records-management requirements should determine the appropriate archival format.
Maintain the Connection to the Patient
Conversion alone is not enough.
A perfect PDF is useless if nobody knows which patient it belongs to.
The migration should preserve metadata including:
- Patient ID
- Document ID
- Encounter ID
- Document type
- Document date
- Author
- Original filename
A migration mapping might look like:
Patient: 482713
Document: 2818371
Source: 2818371.hed
Destination: 2818371.pdf
Status: Success
This information can then be used when importing the file into the destination EHR.
Do Not Rename Everything Too Early
Numeric filenames may initially look inconvenient, but they may represent important database identifiers.
Before changing filenames, determine whether the existing identifier is used to establish the relationship between the file and the source database.
Keeping the identifier during conversion can simplify the migration:
2818371.hed
becomes:
2818371.pdf
The new EHR can assign another filename later if necessary.
Test Documents from Across the History of the System
A healthcare system used for fifteen years may have gone through multiple versions.
The oldest HED documents may therefore differ from the newest ones.
Build a test set that includes:
- Older documents
- Recent documents
- Different document types
- Different departments
- Different templates
- Documents with tables
- Documents with images
- Multi-page documents
This is much safer than validating only a handful of recent files.
Batch Conversion for Large Healthcare Archives
Legacy EHRs can contain enormous document repositories.
Manual conversion is not an option.
HEDBridge can be used as part of an automated batch migration workflow.
For example, a migration operator can convert nested HED folders to PDF and continue past individual failures:
HEDBrigde.exe /s:D:\LegacyEHR\HED /d:D:\Migration\PDF /f:pdf --recursive --continue-on-error
If the legacy application stores important metadata in the HED documents' ApplicationFields, extract it separately for the migration audit:
HEDBrigde.exe /s:D:\LegacyEHR\HED --extract-fields --recursive /d:D:\Migration\Audit
For every document, the process should ideally record:
Source file
Target file
Document ID
Conversion status
Error information
This allows the migration team to reconcile the converted archive with the source system.
Process Sensitive Documents Locally
Healthcare records can contain protected and confidential patient information.
Sending complete archives to arbitrary online conversion services introduces unnecessary risk and may conflict with organizational policies.
HEDBridge can be used locally so that document processing remains within the organization's controlled environment.
This also makes it easier to integrate conversion directly with migration scripts, databases, and local file repositories.
What If the New Application Uses TX Text Control?
Some projects replace the complete EHR.
Others modernize an existing healthcare application.
If HighEdit itself is being replaced, TX Text Control can provide a modern platform for document editing, generation, reporting, and processing.
HEDBridge can convert the existing HED repository while TX Text Control handles new document workflows.
This makes it possible to retire HighEdit without abandoning the documents created with it.
Keep the Original HED Archive Until Validation Is Complete
Do not immediately delete the legacy document repository after conversion.
Keep the original files available while:
- Conversion results are validated
- Documents are imported
- Patient mappings are verified
- Failed documents are investigated
- Users test historical document access
Once the migration has been accepted, the organization can apply its own retention policy to the original source files.
A Simple EHR Document Migration Checklist
Before retiring a HighEdit-based healthcare system, make sure you can answer these questions:
- Have all HED repositories been located?
- Do you know how HED files relate to patient records?
- Have historical documents and templates been separated?
- Has the target format been selected?
- Has a representative conversion sample been validated?
- Is every conversion logged?
- Can failed files be identified?
- Can the new EHR open the converted documents?
- Has the connection between each document and patient been preserved?
If the answer to any of these is no, the document portion of the migration may not be finished.
Don't Leave Part of the Patient Record Behind
A successful EHR migration is not simply a successful database import.
Patients may have years of important clinical information stored in documents generated by the previous system.
If those documents are HighEdit HED files, the organization needs a plan for preserving them before the legacy environment disappears.
HEDBridge converts HighEdit documents into modern formats such as PDF, DOCX, RTF, TXT, HTML, and TX Text Control compatible formats. If PDF/A is required, validate the generated PDF files with the approved archival tool after conversion.
That provides a path for moving historical documents into the new environment while preserving access to the information created by the old one.
When planning an EHR migration, treat the HED archive as part of the patient record from the beginning — not as something to investigate after the old system has already been switched off.