Switch from iMedDoc: What Moves Across and How Long It Takes

The migration myth: why 'just move the data' is the wrong frame

The conventional wisdom about switching practice management systems goes something like this: export your data, import it somewhere else, spend a weekend on it, and you're done. That framing is wrong, and believing it is the single most common reason migrations stall, go over budget, or get abandoned three months in. The real constraint is never the data export. It's the gap between what a system exports and what a new system can actually consume in a clinically useful form.

This matters particularly for consultants who have used iMedDoc for several years. iMedDoc is a well-established Irish clinical correspondence and practice management platform with a substantial installed base, especially among hospital-based consultants and their secretaries. Its document-centric architecture means that the accumulated value in the system lives not in structured database rows but in letters, reports, correspondence threads, and dictation-linked documents. That distinction changes everything about how you plan a migration.

The question to ask is not "can I export my data?" Almost certainly you can. The question is: "In what form does it come out, and what does it look like inside a receiving system on day one?" Answering the second question honestly is what separates a migration that goes well from one that leaves your medical secretary manually reformatting documents for six weeks after go-live.

There is a secondary myth worth naming: that migration is the vendor's problem. Target vendors, including Ask Brigid, will assist with structured data import. But iMedDoc's export capabilities, the shape of your own data, and decisions about what to carry forward versus archive are yours to own. No vendor can make those choices for you.

---

▶ Watch on YouTube

What iMedDoc actually exports and what format it comes in

iMedDoc can export patient demographic records, appointment history, and clinical correspondence documents. The document output is typically in a combination of formats: Word (.docx), PDF, or RTF, depending on how letters were originally created in the system. Structured data such as patient lists and appointment logs can usually be extracted as CSV or Excel files. What you will not get is a single clean, schema-mapped database dump that any receiving system can interpret without configuration work.

A urology consultant running a busy flexible cystoscopy list at Blackrock Clinic or UPMC Whitfield might have several thousand patient records in iMedDoc, each with a correspondence folder containing outpatient letters, referral acknowledgements, discharge summaries, and results letters going back years. Those documents exist as files. They are not structured clinical data in any interoperable sense. The patient's name and date of birth are in the filename or the document header, not in a field a receiving system can query.

iMedDoc does support HL7 and has integrations with hospital PAS (Patient Administration Systems) in some configurations, but those integrations are typically hospital-side infrastructure, not something a consultant's private room inherits as a portable export capability. If you are running iMedDoc as a standalone room system rather than through a hospital integration, your export options are more limited.

What you can typically extract from iMedDoc:

• Patient demographic list (name, DOB, address, contact, GP) as a structured spreadsheet
• Appointment history logs
• Clinical correspondence as individual document files (Word, PDF, or RTF)
• Insurance and billing reference data, if captured in the system
• Template files (letter templates, referral templates)

What you will not get as a clean structured export:

• Clinical summaries or problem lists in a coded format (SNOMED, ICD-10)
• Medication histories in a structured, importable schema
• Linked document-to-appointment relationships in a format a new system can reconstruct automatically
• Audit trails in a portable format

This is not a criticism specific to iMedDoc. Most document-centric practice management systems from the same generation share this architecture. The point is to set accurate expectations before you start.

---

Which data categories transfer cleanly and which need manual work

Patient demographics transfer cleanly in almost every migration, provided the source data is reasonably tidy. Appointment history transfers acceptably, though it usually becomes read-only historical data rather than live records in the new system. Clinical correspondence documents can be bulk-imported as file attachments, preserving the document itself but losing any structured metadata unless you add it. Everything else, from billing linkages to templated pathways, requires configuration rather than migration.

The table below is based on what we have seen across migrations from iMedDoc to newer platforms. "Clean" means the data transfers in a usable form with minimal manual intervention. "Needs work" means human review, reformatting, or re-entry is required. "Archive only" means you keep it accessible but do not attempt to make it live in the new system.

Data category	Transfer outcome	Notes
Patient demographics	Clean	CSV/Excel import; deduplicate before export
Appointment history	Clean (read-only)	Historical record; not live scheduling data
Clinical correspondence (letters, reports)	Archive or partial	Files import as attachments; metadata linking is manual
Referral letters sent/received	Archive or partial	Same as correspondence; HealthLink history stays with HealthLink
Insurance/billing reference data	Needs work	VHI, Laya, Irish Life scheme codes need remapping to new system
Letter and document templates	Needs work	Logic and formatting must be rebuilt; content can be reused
Dictation audio files	Archive only	Not portable to a new dictation workflow
Coded clinical data (diagnoses, procedures)	Rarely available	Usually does not exist as structured data in iMedDoc room setups

The category that catches most consultants off guard is letter templates. You may have spent years refining a prostate cancer follow-up letter, a post-TRUS biopsy results template, or a bladder cancer surveillance letter. That content is salvageable. The iMedDoc template logic, merge fields, and formatting will not port directly to a new system. Someone has to rebuild the template structure in the receiving platform, populating it with your existing text. It is an hour of work per template, not an afternoon for the entire library, but it is still work that needs to be scheduled.

Billing data warrants a separate comment. iMedDoc captures insurer reference information, but the mapping between iMedDoc's scheme codes and the billing logic of a new system is never automatic. VHI, Laya Healthcare, Irish Life Health, and Aviva all have procedure code sets that need to be correctly mapped in the new platform before you send your first claim. Getting this wrong in the first week after go-live is how practices lose money they never recover. Audit this mapping before you go live, not after.

---

How long a realistic iMedDoc migration takes, stage by stage

A straightforward migration from iMedDoc, for a solo consultant or a small two-to-three-consultant room, realistically takes six to ten weeks from the decision to switch to a stable live environment. That assumes no significant data quality problems in the source system, that template rebuilding is scoped in advance, and that your medical secretary has protected time to contribute. Rushing it to four weeks is possible but creates risk at the billing and template stages specifically.

The stages below reflect what a reasonably well-run migration looks like. The timeline assumes you are switching to a cloud-based platform with a structured onboarding process rather than installing new on-premise software.

1. Scoping and data audit (weeks 1–2). Before exporting anything, run a data quality check on your iMedDoc patient list. Duplicate records, incomplete demographics, and inconsistent insurer coding are common. The time you spend cleaning the source data is paid back several times over during import. Agree with your target vendor exactly which data categories they can receive in structured form and which will be treated as document archives.
2. Export and structured data import (weeks 2–3). Export patient demographics and appointment history. Your target vendor should provide an import template with field mapping. This stage is largely technical and, if the data is clean, takes one to three days of actual work with a few days of elapsed time for vendor processing.
3. Document archiving (weeks 3–4). Bulk-export clinical correspondence from iMedDoc and agree a folder or archive structure with your target platform. You are not making these documents live and queryable; you are making them findable when a patient attends. For a consultant with five or more years of correspondence, this is a non-trivial volume. A realistic estimate for a busy urology practice is several thousand documents. Bulk upload is usually automated, but someone has to verify the archive is complete and accessible before you decommission iMedDoc.
4. Template rebuilding (weeks 3–5, running in parallel). Identify your top twenty most-used letter templates and rebuild them in the new system first. Everything else can be rebuilt on demand after go-live. Do not try to port your entire template library before go-live; scope it to the documents you send every week.
5. Insurance scheme mapping and billing configuration (weeks 4–6). Map your procedure codes and insurer scheme identifiers. Test with at least one complete billing run in a sandbox environment before going live. If you work across multiple hospital sites under different insurer agreements, this stage is more complex and needs proportionally more time.
6. Staff training and parallel running (weeks 5–8). Your medical secretary or practice manager needs structured time with the new system before you ask them to manage a live clinic on it. Two to three weeks of parallel running, where you continue to run iMedDoc for outgoing correspondence while new patient data flows into the target system, is the standard approach. It creates some administrative duplication but significantly reduces the risk of a disrupted clinic.
7. Go-live and iMedDoc wind-down (weeks 8–10). Hard cutover: new consultations and correspondence run entirely on the new platform. iMedDoc access is kept open for archive reference, typically for three to six months, before the subscription is cancelled. Confirm your iMedDoc contract notice period before you start the migration clock.

One factor that shortens this timeline significantly: how many sites you practice from. A consultant operating from a single private room at one hospital will move faster than one managing clinic lists across, say, the Beacon Hospital and Bons Secours Cork simultaneously, with separate iMedDoc configurations at each. Multi-site migrations need their own checklist at the scoping stage.

---

What to sort before you trigger the switch

The decisions you make in the two to four weeks before formally initiating a migration determine most of what goes right or wrong. Confirming your iMedDoc contract exit terms, agreeing on a parallel-running period, and getting your patient demographic data into exportable shape are the three highest-value actions. Everything else follows from having those three things settled.

Check your iMedDoc contract terms. iMedDoc is provided through Clanwilliam Health (formerly Lanas). Confirm the notice period required to end your subscription and whether there are any data retrieval obligations or timelines in the contract. GDPR obligations mean you are entitled to your patient data in a portable format under Article 20 of the General Data Protection Regulation; see guidance at dataprotection.ie. In practice, iMedDoc will facilitate a data export, but having the contractual timeline confirmed before you start the process matters.

Audit your patient list. Run a de-duplication check. Identify patients with incomplete demographic records. Check that insurance scheme references are populated consistently. A patient list with 3,000 records and 200 duplicates will create problems on the other side of the import; better to resolve them now.

Inventory your templates. List every letter template, referral template, consent form, and report template in iMedDoc. Mark each one as "rebuild before go-live", "rebuild on demand", or "retire". You almost certainly have templates in there that nobody has used in three years. Do not migrate dead weight.

Confirm your HealthLink setup. If you send or receive referrals via HealthLink, your HealthLink credentials and message routing are separate from iMedDoc. Confirm with your target vendor that HealthLink integration is configured and tested before go-live. HealthLink outage during transition is one of the more disruptive things that can happen in a busy consultant room.

Brief your medical secretary early. This is the step that gets deferred longest and causes the most friction. Your secretary will have her own mental model of how the current system works. Change that model before she is managing a live clinic on new software, not during it. Involve her in the template inventory and the billing code mapping stages specifically. She will spot errors you will not.

Decide what you are archiving versus migrating. This is a clinical governance decision. Old correspondence is patient data. You cannot delete it because you have changed platform. The standard approach is to keep iMedDoc access live for a defined period (often six months) as a read-only archive, then export a full document archive to secure encrypted storage before decommissioning. Your obligations under the Medical Council's Guide to Professional Conduct and Ethics include maintaining access to clinical records for the required retention period, regardless of what system they live in.

For a urology consultant who has been on iMedDoc for a number of years, the single most valuable thing you can do before switching is to talk to a colleague who has already made a similar move. The peer experience will tell you what the vendor documentation will not: which edge cases surfaced after go-live, whether the billing mapping took longer than expected, and whether the parallel-running period felt long enough. The iMedDoc alternative Ireland 2026 overview and the full Irish practice management software comparison on this blog are reasonable starting points for understanding the current platform options before you commit to a direction.

When you are ready to evaluate a specific target platform, Ask Brigid (formerly MedProAI) offers a structured onboarding process for consultants switching from iMedDoc, including data import support for patient demographics and document archiving, with a 48-hour setup and the option to run a parallel period before full cutover. The platform is EU-hosted on AWS Dublin and GDPR-compliant, with native multi-insurer billing for VHI, Laya, Irish Life Health, and Aviva. More detail on the urology-specific workflow configuration is at medproai.com/for-urologists.

Pull your current patient list from iMedDoc today and run a basic duplicate check. That single action, which takes an hour, will tell you more about the real complexity of your migration than any vendor conversation will. Once you know the shape of your data, everything else can be planned around it.

Ask Brigid offers a 7-day free trial for Irish practices, no credit card required, with 48-hour setup. Start at auth.medproai.com.

Frequently asked questions about switch from imeddoc

What data can I export from iMedDoc when switching systems?

iMedDoc typically allows export of patient demographics, appointment records and billing history in structured formats. Clinical letter content can be exported as documents, but template logic and custom macros are generally not portable and must be recreated in the new platform.

How long does an iMedDoc migration take for an Irish private practice?

Practices report that the data import stage itself can complete within a few working days once a clean export is prepared. The full transition, including staff training and workflow setup, commonly takes several weeks depending on practice size.

Will my patients need to do anything when I switch away from iMedDoc?

For most migrations, patients notice nothing during the data transfer itself. If your new platform includes a patient-facing app such as Meet Brigid, patients are invited to create their own account and can choose to link it to your clinic and share specific categories of their information with you.