EMR Patient Data Interoperability Between 3 Locations

Posted on December 28, 2009 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Another interesting story from EMRUpdate talking about how one EMR vendor, Medtuity EMR, took 3 locations and tied their EMRs together. However, they didn’t just do one centralized database accessed from each location. Instead, they essentially built patient data interoperability between the 3 locations. Check it out:

We just linked 3 sites in October. The docs described what they wanted, including the speed of a separate SQL Server in each facility. They also had a billing office (as the center or hub). They previously used a single server with Remote Desktop as the means of communicating with a central server. They were not entirely happy with that arrangement and so wanted to embark on a SQL Server in each facility. Additionally, they did not want all encounters synched to all facilities daily. Instead, the 3 offices synch to the billing office once daily. Pt demographics get synched from that hub outward to all offices daily just in case a pt should visit another office.

So the underlying theme was speed– each office has its own server; pt encounters originating there are stored there + at the billing office, but pt demographics are synched to the hub and from there back to all 3 facilities. It’s all automated. If a pt visits a different facility than the original, the demographics are already at that alternate site and so the additional encounters can be synch with a button press to insure contemporaneous info.

What they did not want is to have all encounters stored at each site because there is not enough cross visiting among docs to warrant it, but they did want to be able to transfer encounters quickly when the need arose.

Certainly, this problem is much easier since all 3 locations used the same EMR software. However, it seems like there’s something that can be learned from this story in regards to broader interoperability of EMR software.