Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and HIPAA for FREE!!

EMR Integration Paying Dividends For All Types of Healthcare Practitioners

Posted on July 17, 2018 I Written By

The following is a guest blog post from the team at Fullscript, a proud sponsor of Healthcare Scene. Follow and engage with them on Twitter: @FullscriptHQ

It would not be a stretch to say that EMRs have been both a blessing and curse for healthcare practitioners. There is no doubt that EMRs have improved the safety of care and the mountain of data that has been collected is now powering the renaissance of Artificial Intelligence in healthcare. However, EMRs have also increased the workload on clinicians which in turn has negatively impacted the overall patient experience and has contributed to burnout. It would not be a stretch to say that EMRs have been both a blessing and curse for healthcare practitioners. There is no doubt that EMRs have improved the safety of care and the mountain of data that has been collected is now powering the renaissance of Artificial Intelligence in healthcare. However, EMRs have also increased the workload on clinicians which in turn has negatively impacted the overall patient experience and has contributed to burnout.

To help practitioners, HealthIT vendors need to ensure their products can be:

  • Tightly integrated with EMRs so that data can be shared easily
  • Seamlessly incorporated into existing workflows
  • Tuned to fit the specific needs of the practice

Fullscript, an online e-prescribing platform helps integrative medical practitioners dispense supplements without the need for physical inventory. This saves valuable office space and improves the overall safety of practices. The company offers over 20,000 professional-grade supplements. Key to the company’s success has been the integration of their platform with existing EMRs coupled with their user-friendly workflow features.

Dr. J. E. Williams, a highly respected integrative medicine clinician who treats and revitalizes patients across a spectrum of illness, implemented Fullscript in order to provide his patients with a streamlined experience and to improve the performance of his practice.

Prior to Fullscript, Dr. Williams, used a non-integrated e-prescribing system. That system was difficult to use and his patients frequently complained at how confusing it was. The result was that patients were not filling their scripts and were not following the prescribed regimen. After switching to Fullscript, Dr. Williams could seamlessly e-prescribe what his patients need, directly from within his EMR. In addition, the easy-to-use nature of the system has made it less confusing for patients. The net result is that Dr. Williams has experienced 100% patient compliance by using Fullscript through his EMR.

“I can write a recommendation when a patient is in front of me, or immediately afterwards. ​Patients want to see their recommendation in their inbox right away, and that’s what Fullscript provides. My patients love it.” – Dr. J.E. Williams

Dr Williams is on a mission to bridge complementary as well as alternative therapies with evidence-based clinical science. Although some would see this as controversial, Dr. Williams firmly believes that there is growing evidence of improved patient outcomes when melding ancient wisdom with modern science. The ultimate goal is to use the most efficient therapies with the least side effects for patients.

The success of Dr Williams demonstrates the power of tight integration with EMRs for all types of clinicians. Gone are the days when clinicians had to tolerate clunky stand-alone systems. Today, they can and should expect their HealthIT partners to provide systems that seamlessly integrate with their existing applications.

Fullscript embraces this vision and has worked with over a thousand practitioners just like Dr Williams to provide the ability to e-prescribe nutraceuticals in as little as 4 weeks.

To learn more about Fullscript’s EMR integration or to read more about Dr. Williams, click here.

“I Don’t Want to Be Portal’d” – The Need for Untethered Patient Portals

Posted on March 23, 2018 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.

Always great when people who work in healthcare IT bumped into it in their own personal lives. That’s what makes this tweet from Steven Posnak so interesting:

For those not familiar with Steven Posnak, he’s the Director of the Office of Standards and Technology at ONC. He’s very familiar with these challenges on a policy level and now he’s gotten a first hand look on a personal level. I think most patients understand the idea of being portal’d.

One great thing about Steven Posnak’s tweet was that it inspired Arien Malec to share this tweetstorm about the need for an untethered patient portal:

This is some great analysis of why we have tethered portals today. I don’t see EHR vendors ever fully committing to an untethered portal and public API for all portal functions. Can you see it happening? I can’t. The future of healthcare portals is tethered portals, until we leapfrog way past it.

Epic and other EHR vendors caught in dilemmas by APIs (Part 2 of 2)

Posted on March 16, 2017 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The first section of this article reported some news about Epic’s Orchard, a new attempt to provide an “app store” for health care. In this section we look over the role of APIs as seen by EHR vendors such as Epic.

The Roles of EHRs

Dr. Travis Good, with whom I spoke for this article, pointed out that EHRs glom together two distinct functions: a canonical, trusted store for patient data and an interface that becomes a key part of the clinician workflow. They are being challenged in both these areas, for different reasons.

As a data store, EHRs satisfied user needs for many years. The records organized the data for billing, treatment, and compliance with regulations. If there were problems with the data, they stemmed not from the EHRs but from how they were used. We should not blame the EHR if the doctor upcoded clinical information in order to charge more, or if coding was too primitive to represent the complexity of patient illness. But clinicians and regulators are now demanding functions that EHRs are fumbling at fulfillling:

  • More and more regulatory requirements, which intelligent software would calculate on its own from data already in the record, but which most EHRs require the physician to fill out manually

  • Patient-generated data, which may be entered by the patient manually or taken from devices

  • Data in streamlined formats for large-scale data analysis, for which institutions are licensing new forms of databases

Therefore, while the EHR still stores critical data, it is not the sole source of truth and is having to leave its borders porous in order to work with other data sources.

The EHR’s second function, as an interface that becomes part of the clinicians’ hourly workflow, has never been fulfilled well. EHRs are the most hated software among their users. And that’s why users are calling on them to provide APIs that permit third-party developers to compete at the interface level.

So if I were to write a section titled “The Future of Current EHRs” it could conceivably be followed by a blank page. But EHRs do move forward, albeit slowly. They must learn to be open systems.

With this perspective, Orchard looks like doubling down on an obsolete strategy. The limitations and terms of service give the impression that Epic wants to remain a one-stop shopping service for customers. But if Epic adopted the SMART approach, with more tolerance for failure and options for customers, it would start to reap the benefits promised by FHIR and foster health care innovation.

Will Personal Health Information Exchanges (PHIE) Lead the Consumer Medical Record Revolution and Bridge the Gap Between PHRs and EHRs? (Part 2 of 2)

Posted on August 5, 2015 I Written By

The following is a guest blog post by Cora Alisuag, RN, MN, MA, CFP, President & CEO, CORAnet Solutions, Inc.
Cora Alisuag, CEO, CORAnet Solutions
Be sure to check out part 1 in this series where we talked about the movement towards an empowered patient who controls their health record.

Lack of Interoperability Continues to Hamper Patient Record Access

However, it has been six years since the HITECH Act passed, yet most Americans seeking medical care are still unable to obtain their full medical records for a variety of reasons. Some hospitals will simply not release them or proprietary EHR system vendors not allowing hospitals, let alone patients, direct access.

This capability also comes at a critical time as enormous obstacles hamper the ability of people to obtain their medical records. This is documented in the ONC’s “2015 Report to Congress on Health Information Blocking” which concludes that it is apparent that some health care providers and health IT developers are knowingly interfering with the exchange of health information in ways that limit its availability and use to improve health and health care.

This situation is only going to worsen as the Centers for Medicaid and Medicare (CMS) is considering a change to the EHR meaningful use rule that requires five percent of patients must view or download or transmit their health data to only one patient; not one percent, one patient.

Blue Button Not Gaining traction

In the meantime, other PHR technology has been introduced, but has not gained popularity including forays from Microsoft and Google. The ONC and other government organizations’ initiative to adopt and use the Blue Button platform for exchanging healthcare data between clinicians equipped with electronic health-record systems and patients with mobile computing devices is stalled, according to a recent survey by the not-for-profit Workgroup for Electronic Data Interchange (WEDI).

WEDI questioned 274 providers, health plans, HIT vendors and claims clearinghouses in the Second Annual Survey of Industry Awareness of Blue Button, conducted late in 2014. Only eight percent of respondents noted that their organizations actually used Blue Button, down from 15% of survey respondents in 2013.

PHRs Largely Unpopular

PHRs joined the lexicon of medical terminology several years ago as a convenience way for consumers to have copies of their medical records. It was largely born out of EHR’s lack of interoperability and access. However, as far back as 2009, a Health Affairs article detailed the major factors behind the slow adoption of PHRs. The article reviewed some of the reasons and includes cost, access, interoperability, security concerns, and data ownership.

Because health records which include clinical data, laboratory results and medical images do not flow freely among multiple organizations due to lack on EHR interoperability, PHRs do not automatically receive data. This means that the data must often be entered manually by consumers—a time-consuming and error-prone process. For most consumers, this lack of safe and reliable automation makes it problematic to maintain a PHR, and a PHR that is not up-to-date likely will not be used. Unlike PHIEs, the API-EHR connectivity connection is the missing link in PHRs.

However, the authors of the Health Affairs article offered a challenge. They described a gap between today’s personal health records (PHRs) and what patients say they want and need from this electronic tool for managing their health information. They noted that until that gap is bridged, it is unlikely that PHRs would be widely adopted, but noted that in the future; when these concerns are addressed, and health data is portable and understandable in content and format, PHRs will likely prove to be invaluable.

“While we all agree that lack of interoperability continues to stymie patient health record access and PHRs might not be the ultimate solution, but if a PHIE can bridge the gap by accessing EHR data through an open API while offering the security and convenience of a PHR. I believe PHIEs offer a solution that should satisfy the spontaneity of millennials’ and more frequent use of middle-aged and elderly users,” says Tiffany Casper, RNC, CNM, MSN and President of EMR Consultants which helps medical organizations transition to EMR systems.

About Cora Alisuag
Cora Alisuag is the CEO of CORAnet Solutions, Inc., a health information technology company. She is the inventor of CORAnet technology, the software engine that drives CORAnet’s Personal Health Information Exchange (PHIE), allowing patients’ mobile device access to their complete medical records. She is also an MN, MA, CFP and healthcare industry speaker and serial medical entrepreneur.

EHR Partner Programs

Posted on May 22, 2015 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.

Amazing Charts just announced a new EHR partner program. This isn’t something that’s particularly new for EHR vendors. They all have lots of partners. Some have formalized them into a program like athenahealth has done with their More Disruption Please (MDP) program. Others are much more quiet about the partners they work with and how they work with them.

What’s clear to me in the EHR industry is that an EHR vendor won’t be able to do everything. There are some that like to try (See Epic), but even the largest EHR vendor isn’t going to be able to provide all the services that are needed by a healthcare organization. This is true for ambulatory and hospitals.

Since an EHR vendor won’t be able to do everything, it makes a lot of sense for an EHR vendor to have some sort of partners program. The challenge for an EHR vendor is that a partner program comes with two major expectations. First, the partner has a high quality integration with the EHR software. Second, that the partner is something that the EHR vendor has vetted.

The first challenge is mostly a challenge because most EHR vendors aren’t great at integrating with outside companies. This is a major culture shift for many EHR vendors and it will take time for them to get up to speed on these types of integrations. Plus, these integrations do take some time and investment on the part of the EHR vendor. When there’s time and investment involved, the EHR vendor starts to be much more selective about which companies they want to be working with long term. They don’t want to spend their time and money integrating with a company which none of its users will actually use.

The second challenge is that EHR users assume that an EHR partner is one that’s been vetted by the EHR vendor. Even if the EHR vendor puts all sorts of disclaimers on their partner page, the EHR vendor is still associated with their partners. The written disclaimers might help you avoid legal issues, but working with shady partners can do a lot of damage to your reputation and credibility in the marketplace. I actually think this is probably the biggest reason that EHR vendors have been reluctant to implement partner programs.

I think over time we’ll see the first problem solved as EHR vendors work to standardize their APIs for partner companies. As those APIs become more mature, we’ll see much deeper EHR integrations and the costs to an EHR vendor will drop dramatically when it comes to new partner integrations.

The second problem is much harder to solve. My best suggestion for EHR vendors is to create a platform which allows your users to help you vet potential partners. Not only can they participate in the vetting process, but it can also help you know which partners would be useful to your users. Is there anything more valuable than user driven partnerships? It also puts you in a good position with potential partners if you already have users interested in the integration.

However, an EHR vendor shouldn’t just leave potential partnership requests to their users. Many of their users don’t know of all the potential partner companies. Users are so busy dealing with their day jobs that they often don’t know of all the potential companies that could benefit their practice or hospital. Certainly you should accept user input on potential partnerships, but an EHR vendor should also seed the potential partner feedback platform with a list of potential partners as well. The mix of an EHR vendor created list together with user generated partner lists is much more powerful than one or the other.

We’re just at the beginning of companies partnering and integrating with EHR vendors. I expect that over the next 5 years an EHR vendor will be defined as much by the organizations it chooses to partner with as the features and functions it chooses to develop itself.

How Do We Achieve Continuous Healthcare Interoperability?

Posted on February 2, 2015 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.

Today I had a really interesting chat about healthcare interoperability with Mario Hyland, Founder of AEGIS. I’m looking at a number of ways that Mario and I can work together to move healthcare interoperability forward. We’ll probably start with a video hangout with Mario and then expand from there.

Until then, I was struck by something Mario said in our conversation: “Healthcare interoperability is not a point in time. You can be interoperable today and then not be tomorrow.

This really resonated with me and no doubt resonates with doctors and hospitals who have an interface with some other medical organization. You know how easy it is for your interface to break. It’s never intentional, but these software are so large and complex that someone will make a change and not realize the impact that change will have across all your connections. As I wrote on Hospital EMR and EHR, API’s are Hard!

Currently we don’t even have a bunch of complex APIs with hundreds of companies connecting to the EHR. We’re lucky if an EHR has a lab interface, ePrescribing, maybe a radiology interface, and maybe a connection to a local hospital. Now imagine the issues that crop up when you’re connecting to hundreds of companies and systems. Mario was right when he told me, “Healthcare thinks we’re dealing with the complex challenges of healthcare interoperability. Healthcare doesn’t know the interoperability challenges that still wait for them and they’re so much more complex than what we’re dealing with today.”

I don’t want to say this as discouragement, but it should encourage us to be really thoughtful about how we handle healthcare interoperability so it can scale up. The title of this post asks a tough question that isn’t being solved by our current one time approach to certification. How do we achieve continuous healthcare interoperability that won’t break on the next upgrade cycle?

I asked Mario why the current EHR certification process hasn’t been able to solve this problem and he said that current EHR certification is more of a one time visual inspection of interoperability. Unfortunately it doesn’t include a single testing platform that really tests an EHR against a specific interoperability standard, let alone ongoing tests to make sure that any changes to the EHR don’t affect future interoperability.

I’ve long chewed on why it is that we can have a “standard” for interoperability, but unfortunately that doesn’t mean that EHR systems can actually interoperate. I’ve heard people tell me that there are flavors of the standard and each organization has a different flavor. I’ve seen this, but what I’ve found is that there are different interpretations of the same standard. When you dig into the details of any standard, you can see how it’s easy for an organization to interpret a standard multiple ways.

In my post API’s are Hard, the article that is linked talks about the written promise and the behavioral promise of an API. The same thing applies to a healthcare interoperability standard. There’s the documented standard (written promise), and then there’s the way the EHR implements the standard (behavioral promise).

In the API world, one company creates the API and so you have one behavioral promise to those who use it. Even with one company, tracking the behavioral promise can be a challenge. In the EHR world, each EHR vendor has implemented interoperability according to their own interpretation of the standard and so there are 300+ behavioral promises that have to be tracked and considered. One from each company and heaven help us if and when a company changes that behavioral promise. It’s impossible to keep up with and explains one reason why healthcare intoperability isn’t a reality today.

What’s the solution? One solution is to create a set of standard test scripts that can be tested against by any EHR vendor on an ongoing basis. This way any EHR vendor can test the interoperability functionality of their application throughout their development cycle. Ideally these test scripts would be offered in an open source manner which would allow multiple contributors to continue to provide feedback and improve the test scripts as errors in the test scripts are found. Yes, it’s just the nature of any standard and testing of that standard that exceptions and errors will be found that need to be addressed and improved.

I mentioned that I was really interested in diving in deeper to healthcare interoperability. I still have a lot more deeper to go, but consider this the first toe dip into the healthcare interoperability waters. I really want to see this problem solved.

Are Client Server EHR Holding Back Healthcare?

Posted on December 19, 2014 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.

The number one topic of debate on this blog has definitely been Client Server EHR versus SaaS EHR. There are staunch parties on both sides of this aisle. No doubt both sides have a case to make and we’ll see both in healthcare for a long time to come. Although, I think that long term the SaaS EHR will win out.

As I was thinking about this recently, I realized that while client server EHR can do everything a SaaS EHR can do, it definitely makes a lot of things much harder to accomplish.

It’s much harder to create an API that connects to 2000 client server EHR installs.

It’s much harder to make 2000 client server EHR installs interoperable.

It’s much harder to evaluate data across 2000 client server EHR installs.

I’m sure I could keep going with this list, but you get the point. Even though something is possible, it doesn’t mean that they’re actually going to do it. In fact, if it’s hard to do, then it takes extreme pressure for them to do it.

All of this has me begging the question of whether client server installs are holding back the EHR industry. Up until now, many of the things I mention above haven’t been that important. Going forward I think that all three of the things I mention above are going to be very important.

The good thing is that I see many client server EHR moving to some kind of hosted EHR solution. That solves some of the problems mentioned above. At least if it’s a hosted EHR solution, they can control the environment and more easily implement things like API access and interoperability. That’s much harder in the client server world where if you have 2000 EHR installs, you have 2000 unique setups.

Of course, as soon as a large SaaS EHR has a massive breach, healthcare will go running after the client server EHR. The battle lines are drawn and each side knows each other very well. Although, I think the SaaS EHR have the high ground right now. We’ll see how that continues over time. Client server EHR have done an amazing job battling.

What a Real Open EHR API Should Accomplish

Posted on June 17, 2013 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.

There’s been a lot of talk in the EHR world about APIs and most of the time they talk about it as an open API. The problem is that there’s been a lot of talk about EHR APIs and not a lot of action. Having an open API is more than just giving a couple people access to some really small subset of your EHR. We need truly open EHR APIs that are more than just a nice press release.

A successful EHR API requires two core elements: Access to EHR Data and a User Base.

The first element is the obvious one and the one that everyone focuses on. An API needs to have access to the data in the EHR. This includes accessing that data for display in an outside application. Plus, it requires that an EHR accept data from an outside application. EHR APIs seem to fall short on both of these areas. Most only give you access to some really small portion of the EHR data. Even fewer let you write any sort of data to the EHR.

If you don’t give an outside application the ability to access the EHR data and write data to the EHR, there are very few applications you can build on top of it. Is it any wonder that the third party EHR developer community isn’t doing more things with EHR software? If they had these two things, EHR vendors would be amazed at what they’d build. I love Jonathan Bush’s idea of “every surface area” of athenahealth being available in an API. If he achieves this vision, third party developers will flock to that EHR and enhance it in ways that would have never been possible for athenahealth to do on their own.

The second piece is just as important to an API. EHR API developers need to get access to your existing EHR user base. This doesn’t mean you have to give them a list of all your clients. It does mean you need to feature the work of these third party developers to your existing user base. This can be in your application, in an email list, at your user conference, etc.

Think about the message you’re sending to your developer community and your existing user base when you do this. The developer community wants to build even more functionality into your product. Your EHR users get more value out of your EHR application thanks to the development efforts of an outside party. Plus, ambitious EHR users can even create their own functionality using the EHR API.

I can’t wait for the day that EHR vendors fully embrace the idea of a third party EHR API. There are so many outside companies that would benefit from an EHR API, but the EHR vendor will benefit just as much. Plus, the real winners will be the EHR users and patients who get the functionality they’ve been wanting from their EHR that the EHR vendor couldn’t deliver.

Submit and Vote on BlueButton Ideas

Posted on June 12, 2013 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.

At Health Datapalooza, Health Tech Hatch announced the Blue Button CoDesign Challenge. Certainly we’ve seen hundreds of challenges come out over the past couple years, but this challenge is a bit different.

Most challenges provide a prize for some goal and then teams of people get together to create a product or service that helps achieve that goal. In the BlueButton CoDesign Challenge they’re starting by asking patients the question, “Build me a Blue Button-enabled tool that….” So far 74 ideas have been submitted as answers to that question. Hundreds of comments have been added on each idea and thousands have voted on which idea has the most potential.

I do have some concern with how they’re doing the voting. I think it’s a mistake to display how many votes each idea has, because then it skews people’s future vote. The same goes for listing the top ideas on the home page. That encourages the casual visitor to just vote on the top ideas which gives the top ideas an unfair advantage. Plus, if someone like me tweets out my idea and gets my followers to vote for me, then I automatically skew to the top page. In fact, this voting reminds me a bit of the upper right quadrant syndrome that Jonathan Bush talked about at TEDMED.

Of course, there are always issues when you deal with voting. However, I love the idea of getting the patient crowd involved in sharing their ideas of how to make healthcare better. For example, e-Patient Dave offered this great idea on managing the pills you take. He’s right that all of the data is there, so why hasn’t someone built it? The answer is likely that it’s not the focus of the people that have the data. This is why EHR APIs are so important.

Just reading through the list of ideas is quite inspiring. I’ll be interested to see which ideas win and if any developers jump on board to build those ideas. The problem with most people is that they’d rather build their own ideas than someone else’s.

Rip & Replace EHR, 3rd Party EHR Connections, and EHR Advice from a Physician

Posted on December 23, 2012 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.


It’s not good for morale, finances, or patient care. Although, it might be better than being stuck with an EHR that is worse for morale, finances and patient care. It’s not an easy decision to switch EHR, but sometimes it’s necessary. Although, this is an almost impossible decision for a hospital. See this post about the “Wrong EHR” conundrum.


I’m not sure how much of this twitter thread will embed. If it doesn’t, then here’s a link to see the full thread. I hope that we can continue to raise the call for more open systems and access to EHR by third party software! Which EHR will set themselves apart in this regard?


Great advice for every doctor when it comes to EMR. It’s a hard shift for many, but I expect Dr. Noah won’t have any issues with this advice.