Free Hospital EMR and EHR 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 Hospital EMR and EHR for FREE!

McKesson and Infor Go-To-Market Partnership – What Happens Now?

Posted on January 9, 2017 I Written By

For the past twenty years, I have been working with healthcare organizations to implement technologies and improve business processes. During that time, I have had the opportunity to lead major transformation initiatives including implementation of EHR and ERP systems as well as design and build of shared service centers. I have worked with many of the largest healthcare providers in the United States as well as many academic and children’s hospitals. In this blog, I will be discussing my experiences and ideas and encourage everyone to share your own as well in the comments.

A couple weeks ago, McKesson and Infor announced a partnership that will have McKesson EIS (Enterprise Information Solutions) offering Infor Cloudsuite as their cloud-based ERP (Enterprise Resource Planning) solution for human resources, supply chain, and financials. What does each party have to gain from this partnership and what does this mean for existing customers of McKesson ERP solutions?

Infor continues to be the dominant player in the ERP space for healthcare providers. Its healthcare applications, previously known as Lawson (and probably always known as Lawson to many of us), have the largest market share with the majority of larger hospitals and healthcare systems. Its closest competitor in the past, Peoplesoft, is now owned by Oracle which is focused on developing and promoting its Fusion product and has released the final version of the Peoplesoft product. Workday, the cloud-only solution that is publicly traded and making significant strives in many industries, has won deals in human resources and financials implementations but lacks a supply chain solution, critical to any integrated ERP deployment. SAP, the largest ERP provider in the world, has a strong presence in healthcare manufacturers but does not provide a supply chain solution well suited for the unique needs of healthcare providers, and therefore has a very small market share.

McKesson, once a strong player in this space, has faded over the years in ERP as they have with EHR solutions. The majority of the McKesson ERP customer base, using the products commonly referred to as Pathways, have been long-time legacy customers. Pathways has not been kept up with modern ERP needs, and it has been many years since I have seen a hospital consider Pathways as a potential solution, but rather it is typically the solution being replaced.

Infor has invested significantly in creating a cloud-based solution, referred to as CloudSuite. However, the existing healthcare customer base typically has an on-premise installation and therefore cloud adoption has been focused on new customers as well as those that are specifically looking to transition away from on-premise. McKesson has not had a cloud offering, therefore it would make sense for them to partner with someone to offer it as an alternative to Pathways.

Infor will gain access to the Mckesson customer base, many of whom are likely considering leaving Pathways for other solutions anyway. In addition, Infor will be able to provide Mckesson’s Strategic Sourcing solution for their customers.

However, it is unclear what that means for Pathways. While McKesson press releases state that CloudSuite is an alternative to Pathways, one has to wonder why Infor would want to expose their solution to someone who is actively selling a competitive solution, and why McKesson would continue to invest in Pathways when it has access to a much more mature and robust solution as a go-forward path for its Pathways customers.

Therefore while it is likely that McKesson will keep Pathways supported and up-to-date with regulatory improvements for the time being, it seems very unlikely that they would continue to enhance it – and inevitable that it will eventually be sunset in favor of transitioning those customers to Infor Cloudsuite. If history is indeed an appropriate predictor of the future, consider that McKesson announced its BetterHealth 2020 plan – in which they announced a focus on Paragon as their EHR but continued support of the older Horizon EHR product. Shortly after that they went back on that commitment and announced they would sunset Horizon in 2018.

Meaningful Use has led to a focus of resources on Electronic Health Records implementations which have led many customers to hold onto their older ERP solutions past their useful life. I suspect that the next two years will see a re-focus to ERP solutions with customers with more modern solutions focusing on upgrades and new feature deployment while customers with older solutions making a change.

Those customers who stayed on Horizon for too long are currently in a rush to implement replacements before the March 2018 sunset date.Customers on Pathways products should likely start the conversation now about their long-term ERP plans and consider if they want to get ahead of any sunset announcement.

If you’d like to receive future posts by Brian in your inbox, you can subscribe to future Healthcare Optimization Scene posts here. Be sure to also read the archive of previous Healthcare Optimization Scene posts.

Clinical System Replacement & Decommissioning: Migrate or Archive? – Tackling EHR & EMR Transition Series

Posted on September 21, 2016 I Written By

clinical-system-complexity
(See Full Healthcare Data Archival Infographic)

A Maturing Healthcare IT Landscape
If 2010 was the year of EMR implementations and optimization driven by initiatives like Meaningful Use, the ARRA, and Obamacare, then 2015 might be known as the year that clinical application retirement became a prevalent topic for many mature healthcare organizations.

Application retirement is nothing new. Large organizations both inside and outside of healthcare have had application retirement strategies in place (typically doled out by expensive consulting companies with fancy matrices, methodologies, and graphs in tow) for a decade or more. Anytime an organization outlives a large IT system (or, in many cases, that system’s vendor), retirement becomes a pressing need. In the case of healthcare, the two largest driving factors forcing clinical application retirement are the consolidation of organizations into large integrated care delivery networks, and replacement of existing electronic healthcare record systems due to poor usability or inadequate functionality.

Migration and Archival – Not Migration Versus Archival
One question that often comes up early on in the process of clinical application retirement is whether it’s necessary at all if the data in these systems is also being migrated into a new EMR. Conversely, the question of whether the cost of a migration is worth it if the archival solution being considered supports some sort of continuity of care solution like seamless single sign on from the new EMR. In most cases, it turns out that the ideal approach is migration and archival.

Just Migrate?
The process of EMR data migration almost always results in some fairly fundamental alteration of the legacy EMR data. The data models used by different EMRs are typically quite different, and it’s not a matter of export/import. Instead, it’s a true ETL process – extract, transform, load.

The shape of the data is changed. Sometimes data types undergo conversions, such as a number to a string, which if done poorly can result in loss of precision. Data sets, such as order codes, result codes, diagnosis categories, note types, and various other types of dictionaries are mapped from the values in the legacy EMR to the values used by the new EMR. Fields that have no apparent corollary in the new EMR are often just dropped entirely. It’s frequently not possible to know for sure what the data actually looked like in the legacy system once this process is complete and the legacy system is actually retired.
legacy-ehr-archive
Not only that, but from a clinical perspective, it’s probably not useful to take 15 years of legacy data and load that directly into your new EMR. Most organizations opt for something more likely to be relevant, while still remaining safe; perhaps 3 to 5 years of data. While the state and federal requirements for archival are clear on how long you need to preserve data (from 6 years to forever, depending on a variety of factors), they aren’t nice enough to say that the data you need to preserve is limited to what’s usually currently clinically relevant. In other words, that 10-year-old test result is still, technically, part of the legal medical record.
legal-medical-record-and-continuity-of-care
Some EMR vendors will even outright limit the mechanisms for data import to something like a CCD (clinical continuity document) import, which inherently limits the scope and quantity of available data that can be preserved.

Just Archive?
Ok. You give up. Obviously a migration isn’t going to cover us, and if the archive has everything we need legally and clinically, let’s skip that time consuming and expensive migration and just archive. Well, you can do that, but just archiving means that your organization is abandoning millions of dollars of hard won documentation and all the automation and analytics that goes with that.

An EMR is a lot more than a place to store clinical documentation. Virtually all modern EMRs have substantial functionality surrounding clinical decision support, health maintenance planning, and quality reporting. They also often are crucial source of data for analytics suites that are the pillars of population health management. In short, not migrating this data means you should have just stuck with paper charts until your latest and greatest EMR was available.

It’s certainly possible to bring over data in a manual, piece meal fashion as patients are seen or based on some other reasonably predicable event whose workflow can be augmented. This will, eventually, patch up the gaps in data that not performing a migration results in. If your organization is willing to suffer the significant, but probably short to medium term repercussions of temporarily losing this data in your EMR and related operational data repositories, then migration might not be necessary.

Not All Archives Are Created Equal
Inside the world of data archival, there are nearly as many different types of archives as there are vendors. Many of the existing archival solutions that have gained popularity with large healthcare organizations are ones that are also frequently utilized by other sectors and often claim to be able to “archive anything”. This can be very appealing, as an organization going through a merger will often retire dozens or even hundreds of systems, some clinical, but most only tangentially related to the delivery of care. HR systems, general ledger financial systems, inventory management, time tracking, and CRMs are just a few of the systems that might also be slated for the chopping block. The idea of retiring all of these into a single logical archiving is very appealing, but this approach can be a dangerous one. The needs of healthcare are not necessarily the same as the needs of other sectors.

Some factors that make healthcare different include:

  • The highly complex data models used by electronic healthcare record systems.
  • The common need for specialized user interfaces to properly visualize the data.
  • The continuing need for clinicians to seamlessly access the archived data with minimal workflow interruption.
  • The incredible variety of source systems that are in need of archival.
  • The lack of data format standards to make it easy to determine what needs to be archived.
  • The need for HIPPA and HITECH compliance (think encryption and auditing).
  • The massive size of the data to be archived, the need to constantly add new sources of data to an existing archive as the organization expands.
  • The frequent need to rapidly produce specific subsets of archived data during an eDiscovery proceeding or other legal compliance scenarios.

Summary:

  • There must be a clear distinction made between “migrated” or “converted” data and archived data, as the drivers and considerations for each are different. Retiring a legacy application and housing the data in an archival solution has markedly different requirements than migrating data from an existing clinical application to another.
  • Retiring legacy systems typically do not necessitate changing the “shape” of the data to fit a particular model. A data archival solution facilitates legacy system retirement, providing a storage solution for clinical data archival in compliance with state and federal regulations for protected health information (PHI).
  • With EMR migration, data typically needs to be mapped and translated to facilitate proper import into the target system. This is critical for the clinical impact and workflow integration required to support a discrete clinical data migration.

Download the full archival whitepaper to evaluate available EMR data migration & EMR data archival options and processes critical to EMR replacement and legacy system decommissioning.

About Robert Downey
Robert is Vice President, Product Development, at Galen Healthcare Solutions. He has nearly 10 years of healthcare IT experience and over 20 years in Software Engineering. Robert is responsible for design and development of Galen’s products and supporting technology, including the VitalCenter Online Archival solution. He is an expert in healthcare IT and software development, as well as cloud based solutions delivery. Connect with Robert on LinkedIn.

About Galen Healthcare Solutions
Galen Healthcare Solutions is an award-winning, #1 in KLAS healthcare IT technical & professional services and solutions company providing high-skilled, cross-platform expertise and proud sponsor of the Tackling EHR & EMR Transition Series. For over a decade, Galen has partnered with more than 300 specialty practices, hospitals, health information exchanges, health systems and integrated delivery networks to provide high-quality, expert level IT consulting services including strategy, optimization, data migration, project management, and interoperability. Galen also delivers a suite of fully integrated products that enhance, automate, and simplify the access and use of clinical patient data within those systems to improve cost-efficiency and quality outcomes. For more information, visit www.galenhealthcare.com. Connect with us on Twitter, Facebook and LinkedIn.

Software Selection Done Right Part 2: Presenting a Vision through an RFI

Posted on August 22, 2016 I Written By

For the past twenty years, I have been working with healthcare organizations to implement technologies and improve business processes. During that time, I have had the opportunity to lead major transformation initiatives including implementation of EHR and ERP systems as well as design and build of shared service centers. I have worked with many of the largest healthcare providers in the United States as well as many academic and children’s hospitals. In this blog, I will be discussing my experiences and ideas and encourage everyone to share your own as well in the comments.

Be sure to check out part 1 in the series.

The primary driving document of a software selection is often the RFI or RFP, the invitation to vendors to participate in the process.. In future articles in this series, we will discuss the process of software selection and obtaining buy-in from stakeholders after the RFI has been received. For this week, we will focus on that centerpiece document, the RFI. This document sets the stage for the process, creating the tone and establishing the way that the hospital will work with the vendor during the selection.

However, far too often creating this document becomes the focus of the process rather then the actual selection. Creating an RFI should not be a large effort and done properly, can be one of the easier steps, allowing the journey to begin much faster.

The purpose of an RFI should not be to provide a laundry list of needs and wants to the software vendors. An RFI that includes pages of checklists of features can take a considerable effort to create and an even more considerable effort for the vendor, and actually adds little value. When it comes to mature software solutions, such as ERP and EHR solutions, it is very likely that the vendor understands your needs better than you do. They demonstrate software to hospitals every day, and have numerous customers who have been through the same changes and challenges that you have.

Several years ago I was working alongside an ERP software sales team and joined a meeting in which a potential customer had allowed them to present their solutions following completion of an extensive, laundry list style RFI. During the discussion the potential customer’s CIO was present and was looking through the response to the RFI carefully, with a frown on his face.

Then he looked up and asked a question. “I am reviewing your response to our RFI”, he said, “and I see that you answered no to many of the items in our requirements. Why should we choose you over another vendor who met more of those needs.” The salesperson from the ERP team was not only a seasoned salesperson, but also well versed in the business processes of ERP and was well prepared with an answer that I often reference to this day.

“Do you know what a Japanese auction is?”, he asked the CIO. “Actually”, he continued, “does anyone here know what a Japanese auction is?.” Everyone looked confused, but no one spoke.

“I don’t, but why would you ask that?” inquired the CIO.

“Because it is a requirement of the software in your RFP”, the salesperson responded, “and one of the examples where we said no”. He then went on to explain what a Japanese auction was to the hospital team, and asked if they would ever use that functionality. They all agreed that they would never have a use for it. In closing the salesperson asked what consulting firm wrote the RFI for them and if they were advised that they needed to include it, or if the consultant simply forgot to remove it from the template they were using.

This story highlights that the software vendor is well aware of the features and functionality that a hospital would typically use, and does not need a list of those features. It also demonstrates that paying a third party to develop an RFP does not always lead to a more effective document – and in some cases leads to a less effective document.

Rather than a laundry list of features, an RFP should tell a story. The story of who you are, where you are now, and where you want to go. It should explain the vision and objectives of your project, the organization’s current challenges, and your future vision for the hospital with the new software. The RFP should invite the vendor to participate and present how they will help you to achieve those goals. Each vendor can then present why their solution is the best to get you to your desired destination.

Specific features and functions are much less of a key difference between software solutions today. Feature lists have actually led many vendors to write and acquire software for the purpose of being able to check boxes in an RFP rather than reacting to actual customer needs or with the intent of producing a quality product. It is increasingly unlikely that a “smoking gun” will be found with a specific absolutely necessary feature existing in one vendor option but not the other. Rather, it is the design and the quality of the solution that is important, as well as confidence in the vendor and their ability to partner with you effectively and capability to deliver on their promises.

Indeed there is more to an RFP – and in a future article we will discuss how to define the rules of the road of the selection process and to make sure those rules are reflected in the RFP and that the vendors and staff follow those rules. However, the core content of an RFP is expressing that vision to your potential software partners.

Therefore rather than spending months of creating lists of checkboxes of features that you may or may not need, just tell your story. Explain the vision of where you want to go and invite the potential solution providers to explain to you how they will help you to achieve that vision. The result will not only be a significantly faster selection process, but also a better relationship with your vendor partners during the selection and beyond.

If you’d like to receive future posts by Brian in your inbox, you can subscribe to future Healthcare Optimization Scene posts here. Be sure to also read the archive of previous Healthcare Optimization Scene posts.

Does Green Mean Go? The Importance of Transparency in Status Reporting

Posted on February 19, 2016 I Written By

For the past twenty years, I have been working with healthcare organizations to implement technologies and improve business processes. During that time, I have had the opportunity to lead major transformation initiatives including implementation of EHR and ERP systems as well as design and build of shared service centers. I have worked with many of the largest healthcare providers in the United States as well as many academic and children’s hospitals. In this blog, I will be discussing my experiences and ideas and encourage everyone to share your own as well in the comments.

A common method of reporting project status is to use the familiar traffic light system, with a status of green, yellow and red. This method of reporting, in theory, makes it easy to determine whether a project is on track and allows the reader to glance quickly at a status report and determine whether there is any cause for concern that requires their attention.

A status of green simply suggests that no such action is necessary, and that the reader has no required actions. A status of yellow or red may require some discussion or resolution. In concept, this system makes sense and allows a project sponsor, who is likely involved in multiple projects and has limited time for each, to quickly determine which projects require their attention.

In reality, this system results in a false sense of security regarding the status of a project and often covers up issues that require attention until they inevitably become serious, at which point the result is most often a project delay, an increase in budget, or more often than not, both.

No project is perfect
The reality is that any project that will result in real change in your organization — including software implementations, cost savings initiatives, and organizational changes — will have problems. It is not the existence of problems that will make or break the success of a project; it is how these problems are addressed. Addressing a problem properly almost always requires early identification and action. Too often, the status reporting system delays the identification of problems, causing them to fester and build to the point at which they can no longer be easily repaired.

The politics of project status
Status reports are inevitably a very political process as the project manager must gather information from the leads or key members of the project team who are completing sets of tasks. In some cases, the project manager is an employee who is overseeing a combination of internal and external resources to complete a project. Quite often, the reverse is true, where the project manager is an external resource who is managing a combination of internal and external resources.

Regardless, the motivations of project managers are in conflict. They want to ensure that they report issues early enough that they can be addressed, but have to balance multiple political realities.  A project manager must be careful not to burn bridges and gain the trust of the team members. Changing a status report to yellow will increase the pressure on team members and potentially make them look bad to their management. Those team members may resent the project manager for the action and be reluctant to share information with him or her in the future.

Therefore, a project manager will often hide the truth, buying the team time to address the issue on its own before escalating the issue by properly reporting the actual status of the project. The result is that often the status that appears on a report is a matter of negotiation between the project manager and the respective team members.

This issue can be even more significant when the project manager is an external contractor managing a project that includes resources from the same company. The project manager in this case has a split loyalty. The first is to the project, and the second is to the employer. To protect the employer, project managers might be reluctant to report a status that will indicate a delay or issue caused by their team, resulting in overly optimistic status reports that hide the project realities.

This is further complicated by the reality that status, particularly status with a green-yellow-red option, is highly subjective. One might interpret a red status as one that is halting the project, but a problem could have serious implications down the line even if it is not halting the project today. A green status could be interpreted as one in which the project remains on track even if there are issues.

Properly reporting status
How does a project sponsor ensure that the true status of a project is reported?

First, there needs to be an acceptance that the status of a complex project cannot be simplified into the equivalent of a system that is designed to let us know whether it’s safe to proceed through a traffic light. Sponsors must be prepared to take the time to fully read through reports and understand the events and issues that have occurred and be prepared to ask questions to challenge the project manager and team leads about the urgency of any issues to see if they require sponsor involvement.

Second, project managers and team members need to be informed that the expectation is that all issues, challenges, and risks will be raised in status reports and status meetings without any fear of repercussions from project sponsors or project team members. These issues should be included in status reports, even if resolved before the report is created, to create visibility into any challenge the project has to overcome. The discussion about issues in status meetings should be open and honest, with proposed solutions provided by team members. Often issues can be resolved timely with the proper allocation of resources, expedited decision making, or simply through discussion.

Finally, the motivations of the project manager must be considered and factored into discussions. In many cases it may be preferable to have the project manager be an internal resource or an external resource that is not from the same company as your implementation or software partner. In cases where they are the same, extra attentiveness to the status and issues presented should be considered to ensure that the reports are being prepared without bias.

While the green-yellow-red method may allow for efficient review of status reporting, it can lead to missing the important details of the actual status that are vital to the success of the project. Proper communication can ensure that red lights change to yellow, and yellow to green, ensuring that the project will not face a true stopping point at a critical point, leading to costly delays.

If you’d like to receive future posts by Brian in your inbox, you can subscribe to future Healthcare Optimization Scene posts here.

Introduction to Healthcare Optimization Scene

Posted on February 17, 2016 I Written By

For the past twenty years, I have been working with healthcare organizations to implement technologies and improve business processes. During that time, I have had the opportunity to lead major transformation initiatives including implementation of EHR and ERP systems as well as design and build of shared service centers. I have worked with many of the largest healthcare providers in the United States as well as many academic and children’s hospitals. In this blog, I will be discussing my experiences and ideas and encourage everyone to share your own as well in the comments.

Editor’s Note: We want to offer a warm welcome to the latest blogger to join the Healthcare Scene family, Brian G. Rosenberg. Brian will be writing our new series we’re calling the Healthcare Optimization Scene. Brian has an incredible background and experience with ERP and EHR in healthcare and will be able to bring some really unique and in the trenches perspectives on how to get the most out of your EHR and ERP investments. We’re so excited to have Brian join us and we think you’ll be glad too.

Welcome to Healthcare Optimization Scene, the newest member of the Health Scene blog network.

Healthcare IT projects are often about much more then replacing software.  They often represent significant transformations in business operations and alter the role of people and processes within the hospitals.   The ability of an organization to understand and manage these changes as well as ultimately to embrace them is often as important, if not more important, then the actual capabilities of the software solutions being implemented.   Change Management and Project Management of significant software projects, primarily as it relates to EHR and ERP projects, will be one of our key topics of discussion in this blog series.

One of the most common mistakes in implementation of these software solutions is the expectation is that the date of go-live for a major new software initiative is the end of the project.   The reality is that the go-live is the middle of the project, the end of the implementation phase and the beginning of the on-going optimization phase. Without optimization, the true value of the software is never achieved and the slow but steady breakdown of the standardization and benefits of the software begins.  Another topic for this blog series will be to discuss how to create a culture of continual improvement in the use of software within your healthcare organization with the goal of fully realizing the reasons the solution was implemented.

I have been working for nearly twenty years in leading software implementation and optimization projects for healthcare providers for both EMR/EHR and ERP projects.  I will be sharing with you my ideas about how to lead successful implementations as well as techniques to optimize the use of software within your organizations.  In addition, I will be sharing articles and industry news that relates to these topics.  Here are just a few examples of the subjects that you can expect to see discussed on Healthcare Optimization Scene:

  • Software selection
  • Implementation Strategy
  • Change Management and Communication Planning
  • Project Management
  • Metrics and Key Performance Indicators
  • Driving value out of EHR and ERP solutions
  • Business Process Improvement
  • Why projects succeed – and why projects fail (as well as defining what succeeding or failing means)

I encourage you to share your ideas for the type of content you would like to see covered in this forum.  Please share your ideas and comments on the articles and ideas presented.  The more the readers share their ideas, the more valuable the forum will be for everyone.

Be sure to connect with me on LinkedIn as well.

If you’d like to receive future posts by Brian in your inbox, you can subscribe to future Healthcare Optimization Scene posts here.