Go-live

Bringing the chart across

What your old EMR has to export, how the import behaves, and why the first run never writes anything.

7 min · Implementation team, Administrators · lesson v1

This lesson is for whoever is running the migration, not for practice staff. There is no import screen in the EMR — the importer is a command the implementation team runs, which means the practice's job is to get the export right.

What to ask the outgoing vendor for

  1. A directory with three things in it:

    export/
      patients.csv            demographics — mrn,last,first,dob,sex[,language]
      ccda/<mrn>.xml          one C-CDA CCD per patient
      documents/<mrn>/<file>  optional per-patient documents

    patients.csv is the canonical patient list. The C-CDA files are matched to it by MRN, and documents likewise.

Ask for this in writing, early, and ask for a sample of ten patients before the full extract. Vendors vary enormously in what they call a C-CDA, and finding out in the go-live week is expensive.

How the import behaves

Three properties worth understanding, because they shape how you plan the cutover:

Dry-run by default. The importer parses, reconciles and prints per-entity counts without writing anything. Persisting requires an explicit --commit. So the safe sequence is: run, read the counts, compare against the old system's own totals, then commit.

Idempotent. Re-running a committed bundle writes nothing new — every entity comes back matched. Migrations get re-run by tired people at unsociable hours; the design assumes that.

Governed like everything else. It writes through the same audited, versioned, tenant-isolated repositories the application uses. An imported record is not a special second-class row — it carries the same audit trail as one typed today.

What to expect on the other side

Set expectations with the practice before the cutover, not after:

  • Structured clinical data — problems, medications, allergies, results — comes across from the C-CDA
  • Demographics come from the CSV
  • Documents are counted, and stored where object storage is wired
  • Anything your old vendor did not put in the export does not exist. Scanned paper, free-text notes in proprietary formats, and internal flags usually do not survive

A sensible cutover shape

  1. Sample export of ten patients → dry run → read counts with the practice
  2. Full export → dry run → reconcile totals against the old system
  3. Commit, in a quiet window
  4. Spot-check twenty charts by hand, chosen by the practice, not by you
  5. Keep the old system readable for a defined period — nobody regrets this

What usually goes wrong

Committing on the first run. The dry run exists so a mismatch is a conversation rather than a cleanup.

Trusting totals nobody checked. The counts mean nothing unless someone compares them to the old system.

Discovering the export format in go-live week. Ask for the sample first.

Assuming the notes came across. Confirm what your vendor actually included, in writing.

Check yourself

No score, no account — just make sure you can answer these before you move on.

  1. The first import run reports counts but the practice sees no patients. Did it fail?

    Show the answer

    No — it did exactly what it should. The importer is dry-run by default: it parses, reconciles and prints per-entity counts without writing. You read the counts, satisfy yourself they match the old system, and only then run it again with --commit.

  2. Somebody runs the same committed bundle a second time by mistake. What happens?

    Show the answer

    Nothing new is written. The import is idempotent — every entity comes back matched. That is deliberate: migrations get re-run at 2am by tired people, and a duplicate chart is far worse than a wasted command.

  3. Which file decides who exists?

    Show the answer

    patients.csv — it is the canonical patient list, with columns mrn,last,first,dob,sex[,language]. The C-CDA files are matched to it by MRN, so a C-CDA for an MRN not in the CSV has nothing to attach to.