Healthcare applications often remain in production for many years. During that time, they can accumulate enormous amounts of patient data, clinical documentation, correspondence, forms, and reports.
When such a system is eventually replaced, migration teams typically focus first on the database.
Patient demographics, appointments, diagnoses, encounters, billing information, and other structured records are exported and mapped into the new system.
But there is another important part of the migration that can easily be overlooked:
the documents.
Older healthcare applications may store formatted documents separately from the main database. In applications that used HighEdit as their document technology, these documents can exist as proprietary .hed files.
When the legacy application is decommissioned, those HED documents still need to remain accessible.
Healthcare Migrations Are More Than Database Migrations
A patient record is usually a combination of structured and unstructured information.
Structured information can include:
- Patient demographics
- Diagnoses
- Procedures
- Appointments
- Medications
- Billing information
- Encounter records
Unstructured or formatted information may include:
- Physician letters
- Clinical reports
- Patient correspondence
- Referral letters
- Administrative forms
- Billing documents
- Historical reports
In some legacy applications, these formatted documents were generated and stored using HighEdit.
The database may only contain a reference to the corresponding HED file.
For example:
Patient ID: 48291
Document ID: 887341
Document Type: Physician Letter
Document Date: 2012-04-17
File: 887341.hed
Migrating the database record without migrating 887341.hed would leave the historical document inaccessible.
What Is HighEdit?
HighEdit was a document editing and reporting technology that was integrated into enterprise applications, including healthcare software.
Applications could use HighEdit to create, display, and store formatted documents.
The resulting files often used the proprietary HED format.
As long as the original application was available, the format itself was usually invisible to end users. A physician or administrator simply opened a document through the application.
The underlying software knew where the HED file was stored and how to render it.
The challenge appears when the application is replaced.
Modern systems do not typically support the HighEdit HED format directly.
Why HED Files Matter During an EHR Migration
Healthcare organizations may retain patient information for many years.
Historical documents can therefore remain relevant long after the software that created them has been replaced.
A migration project must ensure that clinicians and authorized users can continue to access these documents.
If HED files remain in the legacy format, organizations may be forced to keep the old application available simply to view historical records.
This creates several problems:
- Legacy infrastructure must remain operational.
- Unsupported software may need to be maintained.
- Old databases must remain accessible.
- Specialized knowledge is still required.
- Security and maintenance become more difficult.
- The new EHR still depends indirectly on the previous system.
A document conversion project removes this dependency.
Convert Historical Documents to PDF
For most completed healthcare documents, PDF is a practical target format.
A finalized physician letter or historical clinical report usually does not need to remain editable. It primarily needs to remain readable.
Converting HED files to PDF provides a format that can be:
- Displayed in browsers
- Opened on modern desktops
- Stored in EHR systems
- Archived in document management systems
- Downloaded through patient or clinician portals
- Transferred between systems
This allows the organization to preserve the original document while eliminating the dependency on HighEdit.
Use PDF/A for Long-Term Archiving
When documents are intended for long-term retention, organizations may choose PDF/A.
PDF/A is specifically designed for document preservation and is commonly used in archive-oriented workflows.
This can be relevant for:
- Patient records
- Clinical documentation
- Legal healthcare records
- Billing records
- Compliance archives
- Historical correspondence
The exact archival requirements depend on the organization's policies and regulatory environment, but converting proprietary HED documents into an established archival format provides a much stronger long-term strategy than keeping them exclusively in the original format.
Some Healthcare Documents Still Need to Be Editable
Not every HED file is necessarily a completed patient document.
Legacy applications may also contain:
- Letter templates
- Report templates
- Form templates
- Standard correspondence
- Reusable document definitions
These files may still be needed after the migration.
In those cases, converting them to PDF would remove their editability.
A better target may be DOCX or a format that can continue to be processed by a modern document component such as TX Text Control.
This allows migration teams to distinguish between documents that should be archived and documents that should remain operational.
A Practical Migration Strategy
A healthcare HED migration can be divided into several phases.
1. Locate the Document Repository
Determine where HED files are stored.
They may exist in:
- File system directories
- Network shares
- Application-specific document folders
- Archive servers
- Backup repositories
Large installations may contain multiple repositories created over different generations of the application.
2. Understand the Database References
Determine how the legacy healthcare application links a database record to an HED file.
This relationship may involve:
- File names
- Numeric document IDs
- GUIDs
- Relative paths
- Absolute paths
- Database keys
This mapping is critical because the document itself may not contain enough information to identify the patient or encounter it belongs to.
3. Categorize the Documents
Determine which HED files are:
- Historical completed documents
- Active documents
- Templates
- Forms
- Obsolete documents
- Duplicates
Different categories can then be migrated using different target formats.
4. Select the Target Format
Typical choices include:
- PDF for general historical access
- PDF/A for long-term archiving
- DOCX for documents that should remain editable
- TX Text Control compatible formats for applications being modernized
5. Convert the Documents
Use a batch conversion process to convert the HED repository.
The HEDBridge console supports the unattended batch step directly:
HEDBrigde.exe /s:D:\LegacyApp\HED /d:D:\Migration\Converted /f:pdf,docx --recursive --continue-on-error
For a healthcare archive, extract ApplicationFields as a separate audit artifact when the source documents contain fields needed to reconnect documents to patient or encounter records:
HEDBrigde.exe /s:D:\LegacyApp\HED --extract-fields --recursive /d:D:\Migration\Audit
The process should preserve the identifiers required for the migration.
For example:
Source
887341.hed
887342.hed
887343.hed
could become:
Converted
887341.pdf
887342.pdf
887343.pdf
6. Reconnect the Documents to the Patient Record
The migration software can use the original document identifier to associate each converted PDF with the correct patient, encounter, or record in the destination system.
7. Validate the Results
Before decommissioning the legacy environment, verify that the converted documents can be opened from the new system and still represent the original content correctly.
Batch Processing Is Essential
Healthcare archives can become very large.
An organization that has generated documents for ten or twenty years may have hundreds of thousands or millions of HED files.
Manual conversion is not feasible.
A migration process therefore needs to support unattended batch conversion.
A typical process might record:
887341.hed -> 887341.pdf -> Success
887342.hed -> 887342.pdf -> Success
887343.hed -> Failed
887344.hed -> 887344.pdf -> Success
Failed files can then be investigated separately without interrupting the complete migration.
This makes the conversion process measurable and repeatable.
Keep the Migration Traceable
Healthcare migrations should be designed so that the origin of a document remains traceable.
Useful migration information can include:
- Original HED filename
- New PDF filename
- Original document ID
- Patient ID
- Encounter ID
- Document date
- Document type
- Conversion status
- Conversion timestamp
Maintaining this information makes it easier to verify that all documents were processed correctly.
It also simplifies troubleshooting if a document cannot be located later.
Test Different Generations of Documents
Long-running healthcare systems often contain documents created by different versions of the application.
Templates and formatting may have changed over time.
A representative test set should therefore include documents from:
- Different years
- Different departments
- Different document types
- Different templates
- Different software versions
Check the converted documents for:
- Text completeness
- Correct pagination
- Tables
- Headers and footers
- Images
- Fonts
- Special characters
- Line breaks
- Document dimensions
Testing only recent documents may not reveal issues present in much older parts of the archive.
Perform the Conversion On-Premises
Healthcare documents can contain sensitive patient information.
For many organizations, sending those files to a public online conversion service is not an acceptable migration strategy.
HEDBridge is designed for controlled conversion workflows where documents can be processed locally within the organization's infrastructure.
This allows healthcare organizations and migration partners to convert HED files without sending the underlying documents to an external cloud conversion service.
That can be especially important when the archive contains protected health information.
Modernizing the Application Instead of Replacing It
Not every project involves moving to a completely different EHR.
A healthcare software vendor may instead be modernizing an existing application that still uses HighEdit internally.
In this scenario, the migration includes two related tasks:
- Replace the HighEdit document technology in the application.
- Preserve or convert the existing HED document repository.
TX Text Control can be used as a modern document processing technology for applications that require editing, document generation, reporting, and conversion.
HEDBridge can handle the historical HighEdit documents while the application itself moves to the newer architecture.
HighEdit to TX Text Control in Healthcare Applications
A modernized healthcare application may need capabilities such as:
- Browser-based document editing
- DOCX processing
- PDF generation
- Reporting
- Mail merge
- Templates
- Server-side document generation
- Linux or container deployment
- Web application integration
TX Text Control provides these capabilities for modern application architectures.
For organizations and software vendors moving away from HighEdit, this creates a migration path where existing documents remain accessible while new documents are created using a current technology stack.
HEDBridge for Healthcare Migration Projects
HEDBridge is designed for legacy HighEdit document migrations.
It can convert existing HED files into modern formats including:
- DOCX
- RTF
- TXT
- HTML
- TX Text Control compatible formats
When PDF/A is required for retention, convert to PDF first and perform the organization's required PDF/A validation as a separate controlled step.
It can be used for individual documents or automated batch processing of large archives.
Because conversion can take place locally, HEDBridge can also be integrated into migration projects where healthcare information must remain within a controlled environment.
Do Not Decommission the Legacy System Too Early
One of the biggest migration risks is shutting down the old system before the document repository has been fully understood.
While the original application is still available, migration teams can verify:
- How documents are located
- Which database fields reference them
- How document types are categorized
- Which documents are still active
- Which files are templates
- Whether multiple repositories exist
- How historical documents appear to users
Once the system is gone, reconstructing those relationships can become much more difficult.
The HED archive should therefore be part of the migration plan from the beginning.
Preserve the Complete Patient Record
A successful healthcare migration does not end when the database has been imported.
The documents associated with those database records are part of the historical record as well.
If a legacy application contains HighEdit HED files, those documents should be identified, converted, validated, and connected to the corresponding records in the destination system.
For historical documents, PDF or PDF/A is often the right destination.
For documents that must remain editable, DOCX or TX Text Control compatible formats can provide a better migration path.
HEDBridge makes it possible to move these documents out of a discontinued proprietary format and into a modern document environment without losing access to years of historical healthcare information.