Own your data: a second PIMS you control

The most common reaction we hear from practices is some version of: "I love the idea, but changing my PIMS is a nightmare I'm not signing up for." That is reasonable. A PIMS migration is one of the riskiest things a clinic can do, and OpenVPM does not claim to remove that risk with an API key.

The current model: reviewed import, not live sync

OpenVPM currently supports a reviewed CSV import with a dry run for clients, patients, vaccination history, and visit notes. Appointments, invoices, attachments, and vendor-specific history require assisted scoping. There is no general connector that mirrors an incumbent PIMS continuously, and clinics should not plan around automatic synchronization or a zero-work cutover.

• Export selected source records to CSV and review the field mapping before importing.
• Run a dry run, resolve rejected rows, and validate totals before any real import.
• Scope appointments, invoices, attachments, and vendor-specific history with the OpenVPM team.
• Keep the incumbent system available according to your medical-record retention and cutover plan.

Where this goes

The near-term path is deliberately narrower: make supported imports reviewable and reversible, document unsupported record types, and expand only after real clinic validation. Vendor APIs may enable future connectors, but none should be marketed before they exist and have been tested against production exports.

Migration claims should be proven one record type at a time.

If you are evaluating OpenVPM, bring a representative export and a written list of the history your clinic must retain. We will distinguish what the current importer supports, what requires assisted work, and what is not available.