In re-reading the thread from this weekend, I realize that I addressed 3 different aspects of this, but didn't segregate the issues very clearly.
The first is the actual merging of two (or more practices). It requires database tools, attention to detail, and either detailed knowledge of the data model, or the ability to analyze the tables and application to derive the data model. Some relationships will be trivial to determine, e.g. patientID in the patient table and in the encounter table
Many existing systems were built before referential integrity was maintained by the DBMS, so their PK-FK relationships are not explicit - rather they are maintained within the code.
David - you mentioned 4D, I wonder if you bumped into Omnis5 or Omnis7 back in the day. My first commercial projects outside of minis and mainframes came doing client-server projects for launch vehicles.
The second aspect is compiling patient data from multiple practices to aid treatment ala RECs, IPAs, or ACOs. Identity reconciliation uses approaches like James mentioned or similar. My experience is that, depending on data quality and time domain you get 90-95% with machine matching. The rest has to be done by hand; yeah humans!
The third point is the logistics of moving patient data from one provider/practice to another. Here we are actively working with Updox to provide the secure messaging platform, while we work on mobile apps, systems, and integration to make this a quick and easy digital process. Part of the 'fun' is each lab, imaging lab, or third party has their own system, politics, and interface or lack thereof. We are making progress towards the day when a provider can open up their app and message another provider while tagging the patient, and view/order/check status of labs/imaging without having to get to a computer.
