Dec 28th, 2008 by Ben Guest Blog: A case study in two very different approaches to EMR
A few days ago Dr. Robert Rowley, Chief Medical Officer at Practice Fusion, posted a comment on my entry about NextGen renaming their product from EHR to EMR. I asked Dr. Rowley if he would be interested in writing a guest blog comparing Practice Fusion’s business model to that being utilized by NextGen. He provided this interesting analysis from the other side of the EMR universe:
__________________________________________________________________
NextGen vs Practice Fusion: a case study in two very different approaches to EMR
The EMR/EHR space has seen divergent approaches to medical records software development – NextGen is an example of one approach, and PracticeFusion is an example of a fundamentally different approach. Rather than seeing them as “a spectrum” of approaches, it might be more appropriate to consider them as different generations of product: EMR 1.0 vs. EMR 2.0
Interoperability and the weakness of locally installed programs
Traditionally, EMR systems (such as NextGen and other established participants in the space) have been developed as client/server systems which are intended to be installed locally in a physician’s practice and be the electronic equivalent of the previously-paper chart rack. The business model for the EMR vendor is to sell the software to the physician, by any of a number of methods (purchase, lease, third-party partial subsidies, etc). To the practice, the encumbrance is not only the software license purchase, but also the need to have a local hardware server system and IT support to run the product, as well as upgrade the product as new releases are published. This becomes a very expensive proposition (to large and small practices alike) and constitutes the primary barrier to EMR adoption seen in the market so far.
Even setting the cost barrier aside, there remains a fundamental weakness in this method of software deployment. Medical care is carried out in networks, or communities of physicians – primary care, specialists, ancillary services, imaging centers, laboratories, hospitals, etc. Sharing clinically relevant information between each of these locations has been challenging. Every connection (assuming they are able to import and export data in a standardized fashion) must be established in a point-to-point way. No unified patient identifier exists between them, so that pieces of a patient’s record exists in the different systems, and (at best) require the deliberate uploading and downloading of information when shared information is needed. Most of the time, this is nothing better than simply faxing print-outs of a patients record, and hoping the receiving party gets the data in time. Busy and chaotic settings, such as emergency rooms, will easily lose the uploaded or faxed data, do the best they can with the information at hand, and maybe (or maybe not) will reply to the private MD in some non-standardized way.
With these “EMR 1.0” systems, where clinical data is fragmented among local installs that may or may not communicate with each other very well, there is no intrinsic method in place today to aggregate these records without each practitioner exporting them manually. And even if one goes through the exercise, where does the master record reside? To date, the industry has tried to solve this through RHIOs and other initiatives, and most have failed catastrophically – CalRHIO is an example where hundreds of millions of dollars in funding have been expended with no real progress.
The rise of EMR 2.0
Can the dilemma of interoperability be solved? Absolutely, but only with emerging web-service based architectures that are natively designed to share data and manage large communities. Only with hosted – not with locally-installed – systems can there be a shared chart among all participants – the “one patient, one chart” concept. With web-based design, the issue of version control goes away – as new features are added, everyone reaps the benefit immediately. Implementation of advanced features that are needed in order to move health care forward, such as wellness prompting and disease management prompting, or real-time links with professional reference data that allow decision support at the point of care – these can be added to emerging web-based EMRs rather easily. With widespread physician adoption, patient portals can be easily created to result in PHRs pre-populated with one’s physicians’ EMR data (from all different sources).
In addition to removing the need for complex and expensive local hardware and IT support needs, EMR 2.0 systems can be deployed using novel business models. Beyond the in-office efficiencies and improvements enjoyed by physicians themselves, some of the biggest benefits from EMR use have been reaped by payors and others – one can certainly make the argument that those who benefit most by EMR efficiencies should be the ones who pay for them. Practice Fusion’s free EMR is an emerging product built on this vision, and has a business model where in-product targeted ads pay for the service. The ads can be traditional vendor ads (pharmaceuticals, devices, billing and transcription services, etc), or can be “counter-detailing” ads, where insurers or local medical groups or IPAs can display their preferred treatment methods for the condition-at-hand.
The future of EMRs, and in health care overall, is in this “EMR 2.0” direction – and, unless they change their fundamental basis, older technologies such as NextGen will simply become dinosaurs that will fall by the wayside. The technology is available, and the standards are in place – the market simply needs to deliver a solution that is priced right, truly web-based and easily adoptable.








December 28th, 2008 at 6:54 pm
While I agree that web services are 100% the way to go and that the whole deployment/architecture of NextGen to me does seem a bit archaic. I don’t think you explained how having it be web based would solve the one patient, one chart problem. This problem is going to exist as long as everyone chooses a different EMR/EHR. There is no way to make it so that the hospital that chooses Epic, my Neurologist on NextGen, and my PCP on Practice Fusion all have access to the same information about me. Which I think is what people complain the most about in health care and isn’t going to get solved anytime soon. It just means my PCP might have easier upgrades and a more inexpensive EMR. For a small private practice, it’s a great solution.
However I live in the Bay Area and here’s what I know about what’s happening in my area. Mills Peninsula Medical Group, Muir Medical Group, Hill Physician, Santa Clara County, and Valley Care have all purchased NextGen and are in some phase of implementation. MPMG has already chosen to do Enterprise Chart so if I go to any of their providers on NextGen that are primary care or specialists, they’ll have access to my chart. This happens at Brown & Toland in San Francisco with AllScripts also. Now if any groups decide to do NextGen CHS with each other, there’s a pretty good chance that whether I go to a provider anywhere around the bay area they’ll have access to the important pieces of my chart. That sounds more like the “one patient, one chart” type concept to me.
Also, could you expand on what type of interoperability Practice Fusion offers? Device integration? HL7?
Do you do all the hosting for the provider? Do they have access to the back end of the database for reporting purposes?
December 29th, 2008 at 12:09 am
[...] by NextGen. He provided this interesting analysis from the other side of the EMR universe.” Article Ben Quirk, Implementing EMRs, 28 December [...]
December 30th, 2008 at 3:36 pm
I appreciate Laura’s comments. The issue of interoperability is one where the desired outcome is for everyone with appropriate permissions be able to see a unified health record on a given patient. This is a much more difficult and expensive process when the patient data is disaggregated into multiple local installs – even if practices are using the same tools (like NextGen), or are using tools that can “talk” to each other (some of the other scenarios described), sharing data is still point-to-point. Sort of like walkie-talkies rather than cell phones – our challenge is to build the infrastructure that will allow widespread interoperability. The Practice Fusion model is based on global data hosting. Everyone (with proper permissions) using the Practice Fusion system (and it is free, and only requires a web browser) can share patient information with each other. The default is shared chart records, rather than separate records in each physician’s office that need a deliberate uploading step in order to share.
Interoperability between the EMR and other devices or services (e.g. labs) takes place via web services (preferred) or via HL7-formatted files. Reporting to practices is already built into the product, and is evolving – currently, patient lists and disease registries for any given diagnosis are available. Practice Fusion is a young product, emergent in the market, and is rapidly evolving to include the features needed for it to be the preferred solution for everyone.
December 30th, 2008 at 6:58 pm
Dr. Rowley, I always run into HIPAA concerns when working on projects where PHI will be shared amongst multiple practices. The practices usually end up signing BAAs and putting together strict auditing and p&ps to catch inappropriate use.
How has Practice Fusion overcome these concerns? Are all charts open to all users?
December 31st, 2008 at 11:17 pm
Bob-
Do you have the patient’s sign documents that providers hand out to patient’s? How is this covered? I understand how enterprise how enterprise chart is covered under medical groups but this astounds me. I’m extremely interested.
Also, what about confidential information. Drug addiction, HIV results, behavioral health type info, etc.?
You have me totally intrigued!
January 2nd, 2009 at 5:23 pm
Practice Fusion’s approach to “which charts are visible to which practices” is done through a sophisticated system of permissions, since the databases are hosted, as described above. Without getting into too much detail here, these are some of the general principles:
1. each chart has a specified “owner” – these are your own charts, created by you.
2. an “owner” can grant access to a specified practice to see a specific chart
3. the patient list of charts available to you is (a) your “own” patients, and (b) those patients who have been referred to you
4. each entry type in a chart (chart note, lab data point, or scanned document) can be given different security levels – such as behavioral health, HIV results, chemical dependency information. When granting “guest” permission to another provider, one can specify which elements are viewable.
Chart sharing in this way follows general PHI rules, just like in paper – general patient permission allows one practitioner to share chart notes with another practitioner when making a referral (usually faxing information), so that the referral has something to go on. If the patient only wants specific information communicated, the referring physician can refer and grant access on a chart note-by-chart note basis. A practitioner can only see one’s “own” charts, plus those elements of a referred chart specifically granted by a referring source.
Laura and Ben, if you are interested in a more detailed discussion on this topic, I would invite you to meet in order to discuss this in more depth. Chart sharing in a shared e-environment is not a trivial matter, and really is at the heart of the huge potential of “EMR 2.0”
January 2nd, 2009 at 10:42 pm
Dr. Rowley, my hat off to you. It sounds like Practice Fusion has accomplished the holy grail of data sharing between users of the same application.
January 3rd, 2009 at 11:43 pm
Dr. Rowley-
I hadn’t really imagined this when you first said something but now that you explained it in more detail, i’m thoroughly impressed. It sounds awesome! I can’t wait for our dinner in a couple of weeks!
January 6th, 2009 at 2:10 am
SAAS Versus Client Server in EHR…
I was invited to join in on a discussion that Ben over at tempdev started with the CEO of Practice Fusion, Dr. Robert Rowley. The guest post by Dr. Rowley essentially began to highlight some advantages of the Practice Fusion SAAS model versus the clie…