Guides & Checklists
Practical guides you can use before you talk to anyone
Working checklists from real projects — migration, integration and modernization. Use them as they are. If you would like a formatted copy or a walkthrough, ask.
OpenEMR Data Migration Checklist
What to assess, map, validate and reconcile before, during and after an OpenEMR migration — so go-live does not surface surprises.
Open the checklist InteroperabilityHealthcare Integration Planning Guide
The questions to answer before building an interface between an EMR and a lab, pharmacy, payer or patient app.
Open the checklist ModernizationLegacy Modernization Checklist
How to decide what to modernize, what to integrate around, and what to leave alone — before committing to a rewrite.
Open the checklistOpenEMR
OpenEMR Data Migration Checklist
What to assess, map, validate and reconcile before, during and after an OpenEMR migration — so go-live does not surface surprises.
Before you export anything
- Inventory every source system holding patient, clinical, billing or document data.
- Agree what counts as a valid patient record, and how duplicates are identified and merged.
- Decide which historical data must stay directly accessible in OpenEMR vs archived.
- Confirm code systems in use (ICD, CPT/HCPCS, LOINC, RxNorm, SNOMED) and how they map.
- Identify data owned by external systems (labs, pharmacy, clearinghouse) that should stay there.
Data domains to map explicitly
- Patient demographics, identifiers and merge history
- Encounters, problems, diagnoses, allergies, medications and immunizations
- Documents and scanned files, with dates and authorship preserved
- Appointments and schedules, including recurring and cancelled
- Insurance, guarantor and eligibility data
- Charges, claims, payments, adjustments and outstanding balances
- Provider, facility and user records, and their relationships
Validation and reconciliation
- Row counts per domain: source vs staged vs loaded, with documented differences.
- Financial reconciliation: total charges, payments and AR balance to the cent.
- Referential checks: no orphaned encounters, documents or claims.
- Spot-check a stratified sample of real charts against the source, clinician-reviewed.
- A written exception log — every record that did not migrate cleanly and why.
Cutover and after
- A rehearsed cutover runbook with a defined rollback point.
- A read-only copy of the source system available during stabilization.
- Post-migration verification against the reconciliation baseline.
- A support window with the migration team on call, not just the help desk.
Insights, monthly
Practical writing on AI, healthcare interoperability, integration and enterprise engineering. No noise.
We use your email only to send Insights. Unsubscribe anytime.
Interoperability
Healthcare Integration Planning Guide
The questions to answer before building an interface between an EMR and a lab, pharmacy, payer or patient app.
Scope and standards
- Which direction does data flow, and which system is the source of truth for each field?
- HL7 v2, FHIR R4, X12, or a proprietary API — and who owns the specification?
- Real-time, near-real-time or batch, and what latency the workflow actually needs.
- Volume today and at peak, and what happens when the downstream system is unavailable.
Mapping and safety
- Field-level mapping held as versioned configuration, not tribal knowledge.
- Code set translation (units, result codes, order codes) and how unmapped values are handled.
- Patient and provider identity matching rules, and the fallback when matching fails.
- What a message that fails validation does — reject, quarantine, alert whom.
Operations
- Monitoring that treats a stalled interface as a patient-safety issue, not an IT ticket.
- Reprocessing and replay for messages missed during an outage.
- A test environment with representative data and a way to test against the real downstream system.
- Documented ownership for the interface once it is live.
Insights, monthly
Practical writing on AI, healthcare interoperability, integration and enterprise engineering. No noise.
We use your email only to send Insights. Unsubscribe anytime.
Modernization
Legacy Modernization Checklist
How to decide what to modernize, what to integrate around, and what to leave alone — before committing to a rewrite.
Understand what you have
- Map the business capabilities the system supports, not just its screens.
- Identify which parts change often and which have been stable for years.
- Find the integrations in and out, and which ones are undocumented.
- Locate the data the rest of the business depends on this system for.
Decide the approach per capability
- Keep and wrap: stable, low-change capabilities get an API, not a rewrite.
- Rebuild: high-change, high-value capabilities where the current form blocks the business.
- Retire: capabilities no longer used, or better served elsewhere.
- Sequence rebuilds so each one delivers something usable and has a fallback.
De-risk the transition
- An API layer over the legacy system so new work does not depend on its internals.
- The strangler-fig pattern: route traffic capability by capability, reversibly.
- A data migration plan with validation and reconciliation, not a one-off export.
- Automated tests around current behaviour before you change it.
Insights, monthly
Practical writing on AI, healthcare interoperability, integration and enterprise engineering. No noise.
We use your email only to send Insights. Unsubscribe anytime.
Next step
Working on a migration, integration or modernization?
Tell us where you are. We will help you work out what to validate, what to reconcile, and what not to promise.