Home Forums Merging practices

If two separate practices using AC wish to merge, is it possible to merge their AC records seamlessly? Would synch work in this setting?

I do not think I would try sync with two different Tax IDs, etc. You would really need some good backups. Personally, I would let AC do it. I think it would be easier to do it directly through SQL, although I don't know that.

You cannot just sync. I had 2 databases and have tried. It will not work. Of course I did this on copies on backup machines. Now they are separate licenses and it would be even more difficult.

I agree that you probably need to go through SQL. That should require a discussion with AC since they have the passwords for the database.

I never discussed with AC what that would entail to merge the databases.

Going through SQL would be the way to go. It takes a few hours of work, but once done you would have two practices merged under a new tax ID.

You would still need to keep the original copies of the original databases for those wonderful auditing moments we all know and love.

JamesNT

I will second James, and add that the folks to do this would be AC staff.

Having written all kinds of special tools for DB manipulation, to effectively accomplish a merge/de-dupe/PK-FK unique check requires a detailed knowledge of the data model, as well as PK-FK relationships, esp. if the relationships are code enforced rather than DB enforced.

There are whole books written about how to do these things; this is not nearly as simple as it might appear.

Yes, I can imagine some of the issues. It is at least important to know it can be done in theory.

The next question from there is, if such a method can be written, why not create such a method to selectively merge a record from another AC practice? The CCR is a feeble and shriveled thing of no value, but if my surgeon uses AC, how wonderful it would be to merge my records on a patient fully and silently with his, and vice-versatile after surgery? That would, in fact, be such a huge advantage that I would be strongly biased towards using consultants who also use AC, other things being equal, which would be a significant marketing tool.

The databases I write are based on 4D SQL, and writing a method to export, and deduplicare is within even my unsophisticated ability. This seems like such a huge advantage that I am really very puzzled why it has not been a basic part of the program. What am I missing here? The tower of Babel that we face with the current EHR landscape is crippling.

David, my guess is that the architecture began as practice centric, so the concept of a 'grandparent' row/instance that dictates "which practice records are which" is probably not part of the existing model.

This came up in a conversation with a large IPA, because they wanted to standardize on [another lame EHR], and acknowledged that they would still have to spend ~ 1 Mil to have a custom repository made so that they could compile all of the data from the different providers. What cracked me up is that their well-paid consultants has ruled out AC because there wasn't an easy way to extract data.

As a business we have contemplated offering a datawarehouse and/or datamart to serve as the consolidating repository for a IPA, REC, or similar entity. I would be glad to offer it with AC as the baseline EHR, but AC will need to complete their baseline CCD implementation before that would be possible.

Because these projects require serious talent to pull off effectively, it would require some initial funding as well as the possibility to re-use/re-sell the use of the platform in the future - as many open-source projects, the first one in production with an open interface would quickly become the default.

All possible, but it means lining up several different pieces that we don't have control of, so we watch and wait.

Indy, I don't get this. Surely each patient has sone unique ID or record number to which all fields in associated tables are linked, allowing one to search for everything with "unique ID= 4376$a"; then it seems you'd just sort by date, line them up table by table, and push "go".

And, don't get me started on the CCD; what I have seen so far is demographic data, problem list and medications. I can get that on my own; what I need is the result of the cardiac cath or the surgeon' evaluation of belly pain.

Maybe I have not given my Regional Extention Center a full hearing, but the last I checked they were feeling all smug and self-satisfied that we could share medication lists. They now have an agreement with AC, and I will speak with them soon to see if they understand yet what is needed.

For those wandering by, David and I are now officially off into the weeds of DB theory and practice.

The challenge isn't for extracting the data from an individual practice, but in compiling it from multiple practices in a valid and useable fashion.

The first architectural concern is functional ownership of data. If we have a fictional patient Peter Parker, you see Peter for chest pain, and determine that he has cracked ribs. He has something weird going on with his skin, so you refer him to a dermatologist. We have a single patient, but he is seen in two practices, and they both [understandably] want to "own" their own data. Thus we have to have the "grandparent" or archetype requirement to determine ownership of individual rows/instances/records.

{I'll note that I am mixing object, relational, and physical terminology - that is both to make the conversation as approachable as possible, and I find it helpful to consider the different contexts in parallel}

The next challenge comes in the "ownership" of the patient data for Peter Parker. Functionally the pre-cursor challenge is determining that Peter Parker is known elsewhere as Pete Parker, but not Peater Parker. Of course, corporations and insurance companies long ago determined that using the national ID that the federal government swore would never be used as a federal identifier was how they would track people. That would answer the issue of knowing that Peter & Pete are the same guy, but which one is right? What do you change it in the datawarehouse, or change his demographics - say his home got demolished in a little dust-up, and does the demographics update flow back to individual practices?

So, we are into data concurrency, and who/how/when is "shared" data updated. The easiest is that you store it all with separate ownership, and give users the ability to read it all and come to their own conclusions in a read-only format.

Once these logistical issues are sorted, then the last major question is how does data get into the repository - does a subscribing practice update every day? What is the format of the data - JSON or XML ala CCD or otherwise? What is transport mechanism? web services, manual https, server to server connection with JSON?

So again, very do-able, but as you observed with your REC - most folks haven't begun to do this in any meaningful fashion.

I'm purposely not even addressing the patient's rights [or lack thereof] to have any control over their personal data. Separate subject.

I do love reading Indy's posts. You can literally feel the young 21-year-old-engineer in him ready to break out of its shell to create something grand, like maybe our first colony on Mars, with only a pocket knife and Q-tip at his disposal.

If I may take Indy's well detailed explanation and narrow its scope a bit and perhaps simplify it for those who may not be into relational theory or finite state automata that much...

Our goal is to be able to easily merge two practices. This is yet another example of a process that sounds simple but isn't.

Consider two patient tables from two different practices. Both tables will have fields for patient ID, last name, first name, city, state, zip, and so forth.

Let's look at the problems we have already. First, we have a situation where one patient is seen in both practices. Merging these two tables together will create a duplicate patient. The second issue is that the second practice already has a patient duplicate problem where one or more patients have been entered multiple times. Perhaps the staff at the second practice is less competent or the second practice has had more employee turn-over - pick your poison. It is also quite possible one patient is duplicated in one database and is seen by both practices which means after merging that one patient would be in the final database any number of times. One approach to solve duplication would be to look at the patient first name, last name, and birthdate to see if any of the new entries have all three in common. This would be, at best 90% accurate as one assume both practices have done a good job of entering this information correction, and we must consider the possibility that there are four James Summerlins in North Carolina and two of us have the same birthdate.


Furthermore, notice that different patients in the two databases could share like unique ID's. Each database would have a patient 11, 12, 13, and so forth and these patients would be different poeple. The new merge would need to create a whole new unique ID for each patient whilst maintaining the previous unique ID in an "old ID" field, if you will.

After merging 30,000 demos together, one can see where in some cases this would become a real mess, possibly. And then what happens if a third practice wants to merge x amount of time later?

The last question is an economics one: For all the labor it would take to solve these issues and make this feature effective, how many people would actually use it? This is where the economic principle of opportunity cost comes in. Does AC spend time and money developing a feature that is used maybe once or twice a year, or does AC spend time developing a feature that may be used by everyone several times a year?

JamesNT

Ok I see the merge issue. However, I'd settle for this, for the moment:

I see Peter for a weird skin rash, and want to refer him to dermatology. I want derm to know he is taking cephawhapazone HP to combat a bad case of Semliki forest virus. So, I do the usual; dictate a letter, and attach relevant chart notes. HOWEVER, instead of turning these into PDF files that get stuck in imported items, I am aware that my consultant, being the consummate provider that she is, also uses AC. So, I push the "export record to Amazing Charts button" in my AC version 8.

This great version of AC now brings up a list of encounters, imported items and demographics for Peter. I select what I want to send, and push "send."

This then goes in an HL-7 format to the regional center, and the consultant is notified it is there, just like a Quest lab. She clicks "import".

Just like with quest, if demographics match, my records are imported; but with my encounter becoming another encounter in her records. If demographics don't match, then there is an alert and an opportunity to match the record or create a new file.

Why not arrange that?

David,

Good post and good idea. Unfortuately, given the oversight of the government to actually do something positive like "meaningful merge," there are very few physicians using AC (we probably have the greatest AC users to patient population in Brewer than any other area) and even less chance that your consultant would be on the same page as you.

I don't knopw. With so many online data repositories in the cloud, Drop Box just to name one, there has to be ways to do this. Hell, Logician Internet (the ASP cousin to Logician and still one of the best EMRs ever and produced the best note ever) did this better than ever. Of course, Medscape came long and, just like anything it touches, ruined it. God, look what Medscape did to eMedicine. Just awful.

I love reading Indy, Sandeep and James's posts. Talk about information overload (a good thing, not a criticism). I can barely stay with them.

I think merging two practices would be difficult, but I think it could be done. Patient ID's as James points out, would be the toughest. But, just like deciding whether to send a patient to urology or nephrology, you would have to decide whether to consult with AC or SQL. There is no doubt you would need a SQL expert who has a copy of AC (can be done) who could then merge them using a lot of scripts and planning. My guess is patients 1001 through 2001 in Office 2 could be instantly changed to 2002 through 3002.

Of course, you have to take into consideration the next database tuner and make sure everything is set up perfectly. But, I wouldn't give up until you tried it. But, you need a SQL Server expert with at least 10 Microsoft MVPs and certifications behind their name. What I have found with my SQL consultant is, after he looks at the situation, he is able to say one of two things. Yes, Bert, that can be done. Or, no Bert, there is no way to do that. It's that simple.

Thanks to all for the great responses. I am continually frustrated every time I have to import or scan in some PDF file, and fume over the missed opportunity. I also have planned on going electronic as part of the exit plan for retirement, but having to export or print one record at a time is only a marginal improvement over Xeroxing paper. I still have to figure out who is going to do that, and don't want it to be me.

Funny, I was just thinking of exit strategies today. I suppose you could either:

1) Wait to the end
2) Burn each day's patient's records to CDs
3) Start burning now.

I have heard but never seen that there are companies that will manage all of your records for a fee. Or, you could live in Maine and just throw them all away.

Do you have room in your basement? It would just be me, my wife, a 13 (going on 20) year old and two dogs.......

I could hold probably 50,000 records or more. Of course, burn them to CD and make that 500,000. Put them on those tiny CDs and, wow.

Why did those tiny CDs and DVDs never take off anyway?

Bert,

They didn't take off because their bigger cousins held more data. The same reason Blue-Ray won over HDDVD. HDDVD had more features, but Blue-Ray had more storage.

Size matters.

JamesNT

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.

Two other thoughts:

<>In merging data we typically alter the database to add a new key field where we copy in the rows previous PK, and then go through a process of re-keying much like a locksmith does. This is where the data model is critical, because the new data is going to have different keys.

<>Exit strategy - does this mean that if you are retiring your patient records have to be sent out or otherwise maintained so that they are available to patients?

Yes, that is correct. How long varies by state, but is typically several years. That and malpractice "tail" insurance, to cover events that happened but have not been discovered yet, are two major potential expenses for a retiree.

And, Indy... You come up with a seamless way of integrating records from different practices, and you will have done far, far more than the government to make the EHE truly useful,,

As we used to say, 'I can neither confirm nor deny' that we are helping practices move to a hosted model, but it would be an obvious offering to allow a retiring provider to host their data for X years @ $Y per year + $Z per records request. My question is how you would evaluate a records request as being valid beside the patient themselves? I'm guessing this is something that you folks have down.


I have talked with some folks about teaming up to offer the back-end repository with AC as the baseline EHR to RECs, ACOs, IPAs etc. We have the means to do it [including making it accessible to providers via mobile systems], but someone is going to have to find the opportunity - we have plenty to do without chasing bureaucracies.

While my experience is not extensive, everyone I have encountered in the vendor/government 'we must amass data per patient' are in it for greed and/or power. What I haven't heard from *anyone* is how they are helping providers help patients.

No surprise there. Setting up datawarehouses is expensive. And having that type of data on hand is like finding the world's largest diamond. No one is going to spend all that money without going nuts over having that kind of access.

JamesNT

I hae done this merging way back when AC was V3 or V4 when it just moved to sql from access. My wife's practice was merging with another nephrologists practice and both were using AC. I did the quick and dirty combining of tables with patient infomartion. I remember i had to do some manipulation with the patientID's and thire respective notes are.

AC has become more complicated and I am sure there was way too many ref, but then for the right price I can bring back my coding skills

Maybe I should start a business being a caretaker for AC EMR files to serve the retiring doctors. It would be simple enough to make sure a release was on file and then release the info.

Of course finding a younger doc to take over your practice might be the most beneficial. I would probably write all the patients and ask them to return a ROI if they would like their records and come by and pick them up. You could probably get 90% delivered in a short time.