Legacy EMR Migration
Migrating a clinic off a legacy EMR that had no supported export path, and finding serious security problems along the way.
Onboarding a clinic to Tempo meant moving their data out of an EMR that offered no supported export. I mapped the undocumented system by hand, scripted a validated extraction of roughly ten thousand patient records, prepared the data for predictive modeling under HIPAA de-identification, and, while mapping the platform, found eight critical security vulnerabilities that I documented for responsible disclosure.
Data Migration · Reverse Engineering · Security Disclosure · HIPAA · Data Engineering · Applied ML Prep
A Migration With No Supported Export Path
A clinic moving to Tempo needed years of demographics, scheduling, clinical documentation, and billing history brought over from their previous EMR. The vendor offered no export tooling and no documented API, so there was no standard way to get the data out in a structured, portable form.
That made the migration an engineering problem. It meant reconstructing the system's data model from the outside, extracting everything accurately, and handling protected health information carefully throughout.
Mapping an Undocumented System by Hand
With no documentation, I worked through the application manually, watching how each screen loaded its data to reconstruct the API surface and the storage conventions underneath it. I catalogued endpoints, request and response shapes, and the relationships between patients, cases, appointments, clinical notes, charges, and claims.
From those observations I built a master schema for the system, which became the map for both the extraction and, later, the security findings. There was no turnkey tool for any of this. It was methodical, iterative analysis, and it is the kind of problem I do my best work on.
Proving the Extraction Was Complete
I wrote custom Python to iterate across every patient and data domain and pull the records into structured files. Getting data out was only half the job. The harder part was proving the migration was complete.
So the pipeline validated itself as it ran. It reconciled record counts against the source, checked date ranges for silent gaps, and verified relationships across the patient, appointment, note, charge, and claim chain so foreign keys still lined up after extraction. Targeted spot-checks preceded sign-off.
Python · Manual API analysis · Schema reconstruction · Network/HAR inspection · Data validation · HIPAA de-identification · Feature analysis
The Migration Surfaced Serious Security Problems
While mapping the API by hand, I noticed the platform enforced access control only in the browser and trusted identifiers the client supplied. Pulling that thread revealed a consistent pattern of issues across the system. I reproduced each one to be certain it was real.
Security is not my specialty, and the stakes were high, so I was careful. I compiled a full vulnerability report and a HIPAA breach-notification analysis, and we submitted the findings directly to the vendor as a responsible disclosure. My role was the discovery, the reproduction, and the documentation that made a sound decision possible.
Broken tenant isolation
The server trusted a client-supplied account identifier with no ownership check, so one account could request another tenant’s data.
Frontend-only authorization
Access control was enforced in the browser. The underlying responses returned data the interface was only hiding.
Query injection exposure
User-controlled input reached query construction without parameterization, opening a path to the wider data store.
Credential exposure
Password hashes were present in routine API responses, well outside what any client needed.
Insecure direct object references
Individual records were reachable by incrementing or guessing identifiers, with no authorization on the object itself.
No access logging
Data access left no trail, which meant a breach could not be ruled out after the fact.
Findings are described in general terms only. The vendor is intentionally unnamed, and no patient data or vendor-identifying material appears anywhere in this case study.
Preparing the Data for Modeling, Safely
The recovered data was also the foundation for planned predictive features, such as appointment no-show risk and treatment-outcome prediction. I designed the data and feature strategy for that work mostly on paper, deciding what the datasets could actually support before any model was built.
That meant judging which fields were complete and consistent enough to model on, choosing realistic outcome variables, and turning semi-structured clinical evaluations into usable signal, all while keeping the data safe to work with.
- Scored field completeness and consistency to decide which fields could realistically support a model
- Weighed candidate outcome variables across goal mastery, treatment duration, and time-to-event framings
- Built extraction of standardized clinical test scores across roughly two dozen assessment instruments
- Designed a HIPAA de-identification approach built on identifier removal, score binning, and scrubbing of quantitative clinical detail
The modeling phase was scoped but not built once the engagement ended for funding reasons. The data foundation and de-identification approach were complete.
The Kind of Problem I Like Best
The broader migration into Tempo was a team effort, and the work described here, the system mapping, the extraction, the validation, and the security findings, was mine. It pulled together what I am strongest at. Working an undefined problem in unfamiliar territory, analyzing large and inconsistent datasets, following an anomaly until it explains itself, and handling sensitive data with care. The extracted records seeded the clinic's instance on the new platform.
Continue
About Emily