Conway Regional Health System Replaced Automize With Files.com Automations for Clinical Data Exchange

Conway Regional Health System is a not-for-profit regional health system based in Conway, Arkansas, with an acute-care hospital and associated clinics serving a seven-county area in central Arkansas.
A regional health system does not do all of its clinical work inside its own walls. Conway Regional sends medical test orders to outside clinical partners and takes patient results back in, and those results have to land in MEDITECH, the electronic health record where its physicians read them. Every one of those exchanges moves protected health information between the hospital and systems it does not control, under HIPAA, and nearly all of it has to run with no one watching.
Conway Regional retired Automize and rebuilt its scheduled file-movement jobs as native Files.com Automations, consolidating transfer and automation on one event-driven platform.
One Clinical Pipeline, Split Across Two Products
Inside the hospital, a Mirth Interface Engine generates the clinical traffic. HL7 test orders come off the engine, get routed to folder destinations, and go out to external servers owned by clinical vendors. Results come back the other way over SFTP, principally from a pathology group in Little Rock, and are consumed into MEDITECH. This is the step between a physician ordering a test and the result appearing in the patient's chart.
The machinery behind that step used to be split. File transfer was one product. The logic that drove it was another: Automize, a third-party workflow-automation tool, ran the scheduled jobs that picked clinical files up, routed them, backed them up, and deleted them afterward.
Every exchange with a clinical vendor lived in two systems at once: the transfer configuration in one, the scheduled job that moved the files in another. Any change to a vendor workflow meant touching both, and the IS team had two products to keep configured and watched for a workload that feeds the patient chart.
The arrangement persisted because these are not workflows a team swaps casually. They carry live clinical traffic under a HIPAA business associate agreement, and anything that replaced the scheduler had to reproduce the behavior of its jobs faithfully: pickup, routing to multiple destinations, backup, and deletion, without interrupting the results flowing into MEDITECH.
The requirements followed from the shape of the problem. The fix had to run the automation where the files already live, so each workflow exists in one place. It had to trigger on the file itself rather than a clock, so a result moves when it arrives. It had to reach vendor-owned SFTP servers directly. And it had to carry the compliance obligations that come with PHI. Files.com met those requirements.
Rebuilding the Scheduled Jobs as Files.com Automations
On Files.com, the platform that moves Conway Regional's clinical files is also the thing that decides when and where they move.
SFTP remained the primary transport in both directions. Files.com Remote Server connections linked vendor-owned SFTP endpoints, while a Files.com Agent connected systems inside the hospital's network to the platform.
The scheduled jobs became Files.com Automations with file-action triggers. When the Mirth engine writes an order file, an Automation picks it up and routes it out, to multiple destinations where the workflow calls for it. When a result arrives from the pathology group, the platform delivers it where MEDITECH consumes it, writes a backup copy, and deletes the source.
What used to run on a schedule now runs on the file: nothing waits for the next job to come around. Every run retries automatically on failure and lands in the Automations log with its outcome.
The PHI exchange runs under Files.com's HIPAA BAA with SOC 2 Type 2 attestation behind it, on a site with insecure ciphers disabled.
One Platform to Run Instead of Two
The change produced a practical contrast:
- Automize is retired. The file-movement jobs it carried run natively as Files.com Automations, so the IS team maintains one system for the transfers and the automation behind them, not two.
- The exchange is event-driven. Orders and results move when the file action fires rather than when a scheduled job next runs.
- The large majority of Conway Regional's traffic on the platform is fully automated PHI exchange with its clinical vendors. Orders leave the Mirth engine, results land where MEDITECH picks them up, and no one touches a file in between.
- Connecting another clinical vendor is a Remote Server connection and an Automation on the same platform, not a new set of jobs in a separate scheduling product.
Automation by Removing a Tool, Not Adding One
Conway Regional did not automate its clinical data exchange by bolting another tool onto its file transfer; it removed one.
Related Customer Stories
Health & Life Sciences
Nestlé Health Science Moves 10 TB of Regulated Acquisition Data in One Month with Files.com
A repeatable SFTP staging and verification workflow keeps multi-terabyte GxP data moving without waiting six months to a year for internal infrastructure.
Read story →
Health & Life Sciences
Abcam Retired Its Self-Hosted FTP Servers With Files.com at MuleSoft’s Transfer Edge
A UK-locked landing zone now handles machine traffic from FTP-only counterparties while MuleSoft continues to orchestrate the integrations behind it.
Read story →
Health & Life Sciences
Everly Health Solutions Configures 40 Health Plan SFTP Connections in Files.com, Not Custom Code
Files.com Remote Servers and automations now move regulated clinical reports from AWS to payer-owned endpoints while operations staff handle routine delivery.
Read story →