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!

mHealth Apps May Create Next-Gen Interoperability Problems

Posted on November 20, 2015 I Written By

Anne Zieger is veteran healthcare editor and analyst with 25 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. She can be reached at @ziegerhealth or www.ziegerhealthcare.com.

According to a recent study by IMS Health, there were 165,000 mHealth apps available on the Google Play and iTunes app stores as of September. Of course, not all of these apps are equally popular — in fact, 40% had been downloaded less than 5,000 times — but that still leaves almost 100,000 apps attracting at least some consumer attention.

On the whole, I’m excited by these statistics. While there’s way too many health apps to consider at present, the spike in apps is a necessary part of the mobile healthcare market’s evolution. Over the next few years, clear leaders will emerge to address key mHealth functions, such as chronic care and medication management, diet and lifestyle support and health data tracking. Apps offering limited interactivity will fall off the map, those connected to biosensors will rise, IMS Health predicts.

That being said, I am concerned about how data is being managed within these apps. With providers already facing huge interoperability issues, the last thing the industry needs is the emergence of a new set of data silos. But unless something happens to guide mHealth app developers, that may be just what happens.

To be fair, health IT leaders aren’t exactly sitting around waiting for commercial app developers to share their data. While products like HealthKit exist to integrate such data, and some institutions are giving it a try, my sense is that mHealth data management isn’t a top priority for healthcare leaders just yet.

No, the talk I’ve overheard in the hallways is more geared to supporting internally-developed apps. For example, seeing to it that a diabetes management app integrates not only a patient’s self-reported blood sugar levels, but also related labs and recommended self-care appointments is enough of a challenge on its own. What’s more, with few doctors actually “prescribing” outside apps as part of their clinical routine, providers have little reason to worry about what commercial app developers do with their data.

But eventually, as top commercial health apps become more robust, the picture will change. Healthcare organizations will have compelling reasons to integrate data from outside apps, particularly if doctors begin viewing them as useful. But if providers and outside app developers aren’t adhering to shared data standards, that may not be possible.

Now, I’m not here to suggest that commercial mHealth developers are ignoring the problem of interoperability with providers. (Besides, with 165,000 apps on the market, I couldn’t say so with any authority, anyway.) I am arguing, however, that it’s already well past time for health IT leaders to begin scoping out the mobile health marketplace, and figuring out what can be done to help with data interoperability. Some sit-downs with top app developers would definitely make sense.

What I do know — as do those reading this blog — is that creating a fresh set of health data silos would be destructive. Creating and managing useful mobile health apps, as well as the data they generate, is likely to be important to next-generation health IT leaders. And avoiding the creation of a fresh set of silos may still be possible. It’s time to tackle this issue before it’s too late.

Interoperability Challenges (VA, DOD, Epic, CommonWell) – Where Do We Go From Here?

Posted on November 16, 2015 I Written By

David is a global digital healthcare leader that is focusing on the next era of healthcare IT.  Most recently David served as the CIO at an academic medical center where he was responsible for all technology related to the three missions of education, research and patient care. David has worked for various healthcare providers ranging from academic medical centers, non-profit, and the for-profit sectors. Subscribe to David's latest CXO Scene posts here.

The state of healthcare in the United States is fairly well known with the US healthcare spend between 17-18% of the GDP. It is one of the most expensive countries in the world for healthcare. America is also one of the few developed nations not to have a universal healthcare scheme, and one of the main barriers is interoperability challenges.

As we have just finished celebrating veteran’s day, one of the challenges in our federal system is interoperability. In order to provide these veterans with proper healthcare, the Veterans Association and the Department of Defense each proposed an update to the way medical records were stored. The proposed system involved purchasing or customizing an existing an EMR software, which would allow doctors to access patient files far more easily.

This would make it easier for veterans to switch doctors without having to worry about taking large amounts of paperwork along with them. It would also allow doctors to give their patients the best care possible without having to worry about red tape and legal hoops they have to jump through. While this makes sense to everyone, a decision has been made to have two separate systems.

We are also having the same discussion in the commercial EMR space recently where representatives from Cerner asked Epic to joing the CommonWell Health Alliance. Based on my experience Epic has done a great job at exchanging data with other Epic customers. At the request of the customer, Epic will work on creating interoperability with other non-Epic systems. The challenge is the need to create a special request for data sharing every time an Epic customer wants to communicate with a non Epic facility.

The House of Representatives have questioned the VA and DOD decisions to create these separate EHR systems. This makes perfect sense since I am also questioning the decision myself. What should have happened in this situation is the VA and DOD should have come together to collaborate on one EHR system. At the same time, the federal government should step in to create a standard for interoperability and mandate that we move towards collaboration.   If you think about the impact that meaningful use had on transforming the healthcare sector’s move towards digital, I believe the government could have the same impact on interoperability if they made it a requirement.

HIM Professional Sing-Along – Let’s Help Doctors Be Doctors Again

Posted on October 28, 2015 I Written By

Erin Head is the Director of Health Information Management (HIM) and Quality for an acute care hospital in Titusville, FL. She is a renowned speaker on a variety of healthcare and social media topics and currently serves as CCHIIM Commissioner for AHIMA. She is heavily involved in many HIM and HIT initiatives such as information governance, health data analytics, and ICD-10 advocacy. She is active on social media on Twitter @ErinHead_HIM and LinkedIn. Subscribe to Erin's latest HIM Scene posts here.

Last week, someone shared with me this amazing video and I have been singing along all weekend. There is quite a bit of skepticism in the lyrics to “EHR State of Mind” but it’s a clever expression of a physician’s view of the shortcomings of using EMRs. I enjoyed the creativity of this song and the video and I hope that these EMR issues are addressed soon as the frustrations he shared are definitely unintentional.

I have highlighted some of my favorite lines from the song below and wanted to share my interpretation from an HIM viewpoint.

“Notes used to be our story…narrative…but replaced with copy-paste…now a bloated ransom note”

This statement really resonated with me and my experiences over the past several years. I have definitely seen the decline in the quality of documentation since the install of the EMR. It doesn’t matter what vendor product is used, the reality is that the documentation has severely suffered because we’ve shifted the physicians’ attention to other workflow processes and EMR checkboxes. Copy and paste has reared its ugly head in far too many charts and we must stop the madness! HIM professionals have stepped in to assist with this by providing real-time auditing and feedback. Plus, HIM has provided assistance by enhancing documentation tools.

“Just a glorified billing platform with some patient stuff tacked on.”

I have heard similar statements on many different occasions. Some EMRs were structured around automating billing processes but that doesn’t mean they have to lack in clinical functionality. From the HIM perspective, we are accustomed to reimbursement and clinical documentation going hand in hand. Coding and billing processes were in need of an overhaul to make for more timely reimbursement and EMRs promised to do just that. Having the clinical documentation and data built into the same system was revolutionary and very exciting for us but it’s still a work in progress to optimize the clinical documentation.

“Uncle Sam promoted it but gone is the interop.” 

Wow- this is sad but true. I remember when I first heard about EMRs, HITECH, and Meaningful Use. I had dreams of sharing data with anyone involved in a patient’s care regardless of geographic location through an EMR health information exchange. Unfortunately, this hasn’t even been possible within the same zip code and sometimes not even among providers in the same organization. True interoperability is definitely missing from our EMR systems.

And lastly, “Crappy software some vendor made us.”

Out-of-the-box EMRs are not a one size fits all by any means. EMRs must be customized, trained on, and implemented in a fashion that works for each provider and healthcare system. The implementation process is not complete at “go-live”. The optimization (and most likely, re-build) period must continue indefinitely until the EMR workflows and data capture are ideal for all patient care, quality reporting, and billing purposes.

Do we really need a “new chart” or is enough optimization possible to get us where we need to be? We are constantly having discussions, starting committees, releasing updates, running reports, and everything in between with hopes that our enhancements will make the EMR more functional and meaningful. I value the feedback from physicians and other clinicians who are using the system daily because their intentions are to deliver the best patient care. EMR obstacles are unacceptable and must be fixed with the help of skilled EMR specialists, HIM and IT professionals, and workflow experts.

Enjoy the video by Dr. Z.

If you’d like to receive future HIM posts by Erin in your inbox, you can subscribe to future HIM Scene posts here.

HIM Professionals and the Patient Portal

Posted on October 21, 2015 I Written By

Erin Head is the Director of Health Information Management (HIM) and Quality for an acute care hospital in Titusville, FL. She is a renowned speaker on a variety of healthcare and social media topics and currently serves as CCHIIM Commissioner for AHIMA. She is heavily involved in many HIM and HIT initiatives such as information governance, health data analytics, and ICD-10 advocacy. She is active on social media on Twitter @ErinHead_HIM and LinkedIn. Subscribe to Erin's latest HIM Scene posts here.

One of the hot topics in healthcare that has been consistently developing and growing over the past few years is the patient portal. Since many different EMRs and portal platforms are used across hospitals and physician offices, each facility is left to develop policies and procedures for what will be released through the portals and how they will be used. There are no specific standards for patient portals, aside from those needed to meet Meaningful Use requirements, which results in different experiences and functionality for end users.

HIM involvement with patient portal implementations has been a little spotty over the years from what I gather from my peers. I heard someone say we “missed the boat” on patient portals. I don’t necessarily agree but I do see inconsistencies in the level of HIM involvement. When it comes to developing policies governing the content that will be released through the portal, HIM professionals are the experts on this initiative. HIM professionals have always been the stewards of the medical record and keeping release of information processes secure and appropriate. There has been a focus on encouraging patients to keep a personal health record long before EMRs and patient portals came to exist. So how could some HIM professionals get left out of the patient portal process?

My first assumption is that patient portals came to exist mostly, although not solely, as a result of Meaningful Use initiatives. If you have had similar experiences to mine, you have witnessed Meaningful Use initiatives typically being handled by IT professionals. As a result, patient portals have fallen under that umbrella from a technology standpoint but I see great opportunities for HIM professionals to be involved to optimize the content shared for the end users. Since the main intent of patient portals is to encourage patients to be engaged in their own care, these portal initiatives have much more benefit beyond attesting to Meaningful Use and should be incorporated into organizational strategic plans for patient engagement.

There has been a lot of discussion around the struggle of increasing patient portal participation. A common factor in patient portal adoption is the lack of patient competencies in using the technology involved. Some patient populations do not frequently use computers, email, or mobile applications which are all a part of the patient portal functionality. To address this at my facility, we created a position within the HIM department to coordinate all patient portal functions including enhancing the user experience by creating frequently asked questions and answers, troubleshooting issues that patients may have when attempting to login, and resetting portal passwords as needed among many other initiatives. Policies were developed to address who can have access to the portal information, how the patients confirm their identity to log in, what is released, and the duration of the availability of the information. We have an interdisciplinary team that contributes to the patient portal process but having the point person reside in the HIM department makes the most sense for governing the entire concept.

One thing to remember is that patient portals do not eliminate the need for traditional release of information processes because we release information to many different requestors for different purposes. The portal does not include every patient document due to the sensitive nature of some results therefore requests for entire charts and abstracts are still necessary in some cases. Patients should participate in the portal for the personal benefit of being proactive in their own healthcare but they should not expect it to replace release of information. I encourage HIM professionals to be involved in the patient portal process in an administrative capacity. The strides made with patient portal optimization are key in optimizing the transition to health information exchange (HIE) concepts which also require heavy HIM involvement.

If you’d like to receive future HIM posts by Erin in your inbox, you can subscribe to future HIM Scene posts here.

Where’s Interoperability Happening in Healthcare?

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

My tweet this morning inspired this post. Interoperability this and interoperability that. We hear all about interoperability everywhere in healthcare. It’s so important that ONC has put together a 10 year plan for healthcare interoperability. We have more interoperability initiatives than we have actual interoperability. I asked one EHR vendor recently about their thoughts on interoperability and which interoperability initiatives they were involved in. They responded that they were taking part in all of them and then they started listing off them all: Common Well, Argonaut, etc etc etc.

With all of this talk about interoperability, you’d think we’d have a wave of success stories. It’s hard for me to believe that with the hundreds of millions of dollars that’s been spent on HIEs and who knows how much money being spent by private organizations, we don’t have a wave of success stories.

You’d think by this point we’d have so many stories of lives saves, costs reduced and care improved that every organization would have to hop on the healthcare interoperability bandwagon. Peer pressure is a real thing. It’s unfortunate that we don’t have so many good interoperability stories that the peer pressure for everyone to take part isn’t reaching a maximum level.

Sadly, I think the opposite is occurring. All of the stories say that healthcare interoperability isn’t happening. These stories provide peer pressure in the opposite direction. “No one is doing it, so why should I start?”

Although, I think the real problem with interoperability was highlighted in this recent press release about the KLAS Keystone Summit. KLAS brought together 12 EHR vendors (we’ll leave a discussion of which EHR vendors were left out for another post) to “independently and transparently measure/assess the status and trajectory of interoperability.”

While it’s great that these EHR vendors have started talking (5 years ago this would have been laughable), it’s disappointing that this meeting where they supposedly “agree” to an interoperability metric then says “The next step is to put a cohesive plan in place to launch and monitor the measurement.”

Excuse me if I’m skeptical, but I feel like I’ve been here before. A bunch of vendors get together and agree to interoperability. The next step is to put together a plan which never happens and never actually reaches reality. I feel like I’m in interoperability groundhog day.

This isn’t a knock on this specific meeting since it seems to be what’s happened at every meeting which has tried to work on interoperability. We have a nice kumbaya moment where all the EHR vendor executives get in a circle, hold hands and say we’re going to work together and then it never happens.

We need to have more stories shared about EHR vendors and healthcare organizations actually sharing data. That’s going to be the only thing that will turn the tide. I don’t even care if it’s really small data sets. Let’s stop talking about interoperability and start doing it.

If you know of places where interoperability is actually occurring, I’d love to hear about it. Please leave a note in the comment or on our contact us page.

Thoughts on Leveraging EMRs Effectively

Posted on September 28, 2015 I Written By

Anne Zieger is veteran healthcare editor and analyst with 25 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. She can be reached at @ziegerhealth or www.ziegerhealthcare.com.

Whenever I scan Twitter for #HIT ideas, I find something neat. For example, consider this intriguing tweet:

I say intriguing not because the formula outlined will surprise anyone, but rather, because it captures some very difficult problems in a concise and impactful manner.

Here’s some thoughts on the issues Portnoy raises:

* Optimization:  Of course, every healthcare IT organization works to optimize every technology it deploys. But doing so with EMRs is one of the most difficult problems it is likely to encounter. Not only do IT leaders need to optimize the EMR platform technically, they may also face external demands placed by ACOs, HIE partners and affiliated providers. And it’s also important to optimize for Meaningful Use functions.

* Workflows:  Building workflows that address the needs of various stakeholders is critical, as pre-designed vendor workflow options may be far from adequate. While implementing an EMR may be an opportunity for a hospital to redesign workflows, or to enshrine existing workflows in the EMR interface and logic, hospital leaders need to take charge of the workflow implementation process. Inefficiencies at this level can be costly and will erode the confidence of clinical teams.

* Revenue capture:  When properly implemented, EMRs can help providers generate more complete documentation for claims reimbursement, which leads to higher collections volume. As time has shown, difficult-to-use EMRs can lead to physician frustration, and in turn, cut-and-paste re-use of existing documentation — which is why carefully-designed workflow is so important. But if they are used appropriately, EMRs can boost revenue painlessly.

* Patient and provider engagement: True, IT needs to take the lead on getting the EMR in place, and must make some important deployment decisions on its own. Still, hospitals will have trouble meeting their goals if patients and providers aren’t invested in its success, and without patient interest in their data I’d argue that meeting long-term population health goals is unlikely. On the flip side, if clinicians and patients are engaged, the feedback they offer can help hospitals shape not only the future of their EMR, but also the rest of their clinical data infrastructure.

If there’s any common theme to all of this, I’d submit, it’s participation. Unlike most efforts corporate IT departments undertake, EMR rollouts are unlikely to work until everyone they touch gets on board. Hospitals can invest in any EMR technology they like, but if providers can’t use the system comfortably to document care, patients don’t log on to access their data, or revenue cycle managers don’t see how it can improve revenue capture, the project is unlikely to offer much ROI.

Learning About Interoperability from Other Industries

Posted on September 21, 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.

In my recent post about DeSavlso suggesting we needed a common interoperability standard, Karl Walter Keirstead offered the following comment:

Finally, someone in government agrees that MU has not had a focus on the right things.

It’s amazing to me, coming from the industrial process control domain where interconnectivity across multiple systems and applications has been routine for 70 years, to see healthcare fussing over interconnectivity.

Their is no need to standardize.

Each set of trading partners the publisher needs to format data for easy posting to a generic data exchanger and the subscriber needs to be able to read data at the data exchanger for easy import to the subscriber environment.

The design criteria are that each partner be allowed to read/write using their own native data element naming conventions (i.e. I post “abc”, you want to be able to read it as “def”, a 2nd subsriber may want to read “abc” as “ghi”.

Of course, a long name is required per publisher data element so that subscribers are able to figure out what they are subscribing to and the other requirement is that a publisher be able to share on a need-to-know basis.

And, yes, since the usual setup will be “pull” instead of “push” each subscriber needs to be able to retain a cursor position at the exchange so they know the last line item they read.

I always learning from other industries and I think the way Karl frames it is really valuable. There are a few challenges that are unique to healthcare. First, we’re talking about 300 different EHR vendors. I guess you could argue that there are even more suppliers in industry for say something like a car or a computer, so they understand integrating with a lot of vendors. However, I think it’s slightly different since all 300 EHR vendors are trying to do more or less the same thing. Still doable, but it does add some different dynamics.

Second, I think that healthcare data is an order of magnitude more complex than much of the data that’s being shared in other industries. I still feel like that’s an excuse as opposed to a real reason for it not to happen. I know this because for years we’ve seen this data being shared at the HIMSS interoperability showcase. It’s more about will than it is about the complexity.

This all reminds me of the time I asked Judy Faulkner, CEO of Epic, if she knew the opportunity she was sitting on. She gave me a blank stare and asked what I meant. I then proceeded to tell her that if she opened up Epic to other people she’d effectively create a standard that everyone would adopt. That’s essentially what I think Karl is saying when he says:

Each set of trading partners the publisher needs to format data for easy posting to a generic data exchanger and the subscriber needs to be able to read data at the data exchanger for easy import to the subscriber environment.

Yep. Epic, Meditech, and Cerner could create a standard for EHR interoperability and everyone would start to use it. Good standard. Bad Standard. It wouldn’t matter, their “trading partners” would adapt to whatever they set as the standard.

What’s the Glue Holding EHR Migration and Conversion Projects Together? – Optimize Healthcare Integration Series

Posted on August 13, 2015 I Written By

The following is a guest blog post by Stephane Vigot, President of Caristix, a leading provider of healthcare integration products and services. This post is part of the Optimize Healthcare Integration series.
Stephane Vigot - Caristix
Are you considering migrating from an older EHR to a newer EHR or are you in the process of that conversion? If so, you are well aware of the complexity of this process. There are a lot of reasons that drive the EHR conversion decision, but the primary reason that organizations undertake EHR conversion is simply to improve patient care and safety by providing clinicians and caregivers with the right information at the right time.

It’s easy to think that this is all about the technology. EHR conversion is far more than an IT project. It is a central business issue that needs to be strategically sponsored and backed by upper level management. In our previous post, we addressed the issue of aligning integration goals for business and technology.  In a project of this magnitude, aligning business and technology goals becomes critical. Implementation takes hard work, time, and is very expensive. Effectively dealing with scope, budget & time creep, and change management matched to the stated business goals is the key to success. The complex planning needed is just one part of the story but the actual execution can be extremely problematic.

Since the primary reason for undertaking EHR conversion is to improve patient care and safety, clinical workflow is top-of-mind and coupled to data exchange and flow through your systems. On the IT side, your analysts define the project requirements and your developers build the interfaces based on those requirements. But the team that plays the most critical role is your quality team. Think of them as your project’s glue.

QA has layers of responsibilities. They are the ones that hold the requirements as the project blueprint and make sure that those requirements, driven by the pre-identified business needs, are being met. They also make sure that all defined processes are being followed. Where processes are not followed, QA defines the resulting risks that must be accommodated for in the system. A subset of responsibility for QA is in the final gate-keeping of a project, the testing and validation processes that address the functionality and metrics of a project.

Analysts work to build the interfaces and provide QA with expected workflows. If those workflows are not correctly defined, QA steps in to clarify them and the expected data exchange, and builds test cases to best represent that evolving knowledge. Identifying workflow is often done blindly with little or no existing information. Once the interface is built, those test cases become the basis for testing. QA also plays an important role in maintenance and in contributing to the library of artifacts that contribute to guaranteeing interoperability over time.

Though it is difficult to estimate the actual costs of interfacing due to the variance implicit in such projects, functional and integrated testing is often up to 3x more time consuming than development. It’s important to note that this most likely represents defects in the process. Normally, in traditional software development those numbers are inversed with QA taking about 1/3 of development time. It’s quite common that requirements are not complete by the time the project lands in QA’s lap. New requirements are continually discovered during testing. These are usually considered to be bugs but should have been identified before the development phase started. Another major reason for the lengthy time needed is that all testing is commonly done manually. A 25 minute fix may require hours of testing when done manually.

In technology projects, risk is always present. QA teams continuously work to confine and evaluate risk based on a predefined process and to report those issues. The question continually being asked is: what are the odds that X will be a problem? And how important is that impact if there is a problem? Here the devil is in the details. QA is constantly dancing with that devil. Risk is not an all or nothing kind of thing. If one were to try and eliminate all risk, projects would never be completed. QA adds order and definition to projects but there are always blind alleyways and unknown consequences that cannot be anticipated even with the most well defined requirements. Dealing with the unknown unknowns is a constant for QA teams. The question becomes how much risk can be tolerated to create the cleanest and most efficient exchange of date on an ongoing basis.

If QA is your glue, what are you doing to increase the quality of that glue, to turn that into super glue? What you can do is provide tools that offset the challenges your QA team faces. At the same time, these tools help contain project scope, time & budget creep, and maintain continual alignment with business goals. The right tools should help in the identification of requirements prior to interface development and throughout that process, identify the necessary workflows, and help in the QA process of building test cases. De-identification of PHI should be included so that production data can be used in testing. Tools should automate the testing and validation process and include the capability of running tests repetitively. In addition, these tools should provide easily shared traceability of the entire QA process by providing a central depository for all assets and documentation to provide continuity for the interoperability goals defined for the entire ecosystem.

What is your organization experiencing in your conversion projects? We’d love to hear your thoughts in the comments.

Caristix, a leading healthcare integration company, is the sponsor of the Optimize Healthcare Integration blog post series.  Check out this free online demo of Caristix Workgroup product which helps you test your interface and speed up HL7 interface development.

About Stéphane Vigot
Stéphane Vigot, President of Caristix, has over 20 years of experience in product management and business development leadership roles in technology and healthcare IT. Formerly with CareFusion and Cardinal Health, his experience spans from major enterprises to startups. Caristix is one of the few companies in the health IT ecosystem that is uniquely focused on integrating, connecting, and exchanging data between systems. He can be reached at stephane.vigot@caristix.com

The Top 3 Reasons Your Health IT Systems Take So Long To Integrate – Optimize Healthcare Integration Series

Posted on July 1, 2015 I Written By

The following is a guest blog post by Stephane Vigot, President of Caristix, a leading provider of healthcare integration products and services. This post is part of the Optimize Healthcare Integration series.
Stephane Vigot - Caristix
The push for interoperability is on. What’s at the core of interoperability that truly supports next generation analytics, real patient engagement, true care coordination, and high value population health? Data exchange through interfacing. And that means HL7.

HL7 represents 95% of interfacing in hospital environments for clinical systems and many other information systems in healthcare.  Many people make the error of thinking HL7 is just simple strings, but it’s a lot more than that. It’s a system of data organization, a dynamic framework that establishes the base of data exchange through its specifics, syntax and structure. But, despite standards, if you take two identical systems, same vendor, deployed in two different environments, you’ll find discrepancies 100% of the time when it comes to data management.

What’s the result? It takes too long to take systems live. And that means time, money, resource drain, and headaches for integrators, maintenance and quality teams. The most critical impact is on essential clinical care. Beyond that, this negatively impacts your short and long term business goals over time. This impact will grow with the increasing demands of interoperability, particularly with the drive for automation and easy data access and analytics.

There are three primary challenges that feed into this problem of getting a system live. These are:

Aligning the integration goals for business and technology users – This step alone will differentiate success or failure. Without a clear picture of your goals and environment from day one, you can’t measure the required investment and resources. Project planning becomes a wild guess. How do you get everyone involved on deck with a common understanding of the overall project?  Is it crystal clear how your new system fits into your existing ecosystem in the context of your data flow and structure? Do you know what information you need from whom, when? Is all documentation readily available? Are the business impacts of the interface understood?

Complete and clear data transformation requirements – It’s common to manually compare outdated specs, list the differences and jump into the code. This makes it virtually impossible to quickly come up with a complete list. Complete requirements are not identified until too late in the project, sometimes not until it’s in production. Are all data flows and system workflows identified? Are the system’s data semantics clear? Are documented system specs accurate? Has customized data been included?  Are all the transformations and mappings defined?  Have you automated the processes that define requirements?

Testing/Verification – Your QA team knows this is about a lot more than making sure all the dots are connected. You want to get this right before your go live and avoid handling data related emergencies in production with constant break-fix repairs. Are you doing enough testing before go live so your caregivers can count on applications being completely functional for their critical patient care? Are your test cases based on your requirements? Are you testing against your clinical workflows? Do you include edge cases and performance in your testing? Are you testing with de-identified production data that accurately represents your system’s data flow and needs? Is your testing HIPAA compliant? Are you prepared for ongoing maintenance and updating with reusable test cases backed by reliable and repeatable quality measures? Is your testing automated?

What’s the most efficient solution to these three challenges?  Productivity software that supports your integration and workflow process from start to finish. With the right solution, you understand the big picture before you start with complete requirements built upon your specifications that set you up for robust system testing and maintenance. The right solution will cut your project timelines in half, reduce your resource drain and costs, and guarantee predictable results while streamlining the repetitive tasks of your teams. In addition, gap analysis, automatic specification management, HL7 message comparison and editing, debugging tools, PHI de-identification, documentation building, and team collaborative depositories should be included. As seen in the charts below, savings of up to 52% can be realized through optimization with productivity software.
Healthcare Integration Project Time Chart
Do these healthcare integration challenges resonate with you? What is your organization experiencing? We’d love to hear your thoughts in the comments.

Caristix, a leading healthcare integration company, is the sponsor of the Optimize Healthcare Integration blog post series.  If you’d like to learn more about how you can simplify your healthcare integration process, download this Free Whitepaper.

About Stéphane Vigot
Stéphane Vigot, President of Caristix, has over 20 years of experience in product management and business development leadership roles in technology and healthcare IT. Formerly with CareFusion and Cardinal Health, his experience spans from major enterprises to startups. Caristix is one of the few companies in the health IT ecosystem that is uniquely focused on integrating, connecting, and exchanging data between systems. He can be reached at stephane.vigot@caristix.com

Interoperability Becoming Important To Consumers

Posted on June 26, 2015 I Written By

Anne Zieger is veteran healthcare editor and analyst with 25 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. She can be reached at @ziegerhealth or www.ziegerhealthcare.com.

The other day, I was talking with my mother about her recent primary care visit — and she was pretty po’d. “I can’t understand why my cardiologist didn’t just send the information to my family doctor,” she said. “Can’t they do that online these days? Why isn’t my doctor part of it?”

Now, to understand why this matters you need to know that my mother, who’s extremely bright, is nonetheless such a technophobe that she literally won’t touch my father’s desktop PC. She’s never opened a brower and has sent perhaps two or three e-mails in her life. She doesn’t even know how to use the text function on her basic “dumb” phone.

But she understands what interoperability is — even if the term would be foreign — and has little patience for care providers that don’t have it in place.

If this was just about my 74-year-old mom, who’s never really cared for technology generally, it would just be a blip. But research suggests that she’s far from alone.

In fact, a study recently released by the Society for Participatory Medicine and conducted by ORC International suggests that most U.S. residents are in my mother’s camp. Nearly 75% of Americans surveyed by SPM said that it was very important that critical health information be shared between hospitals, doctors and other providers.

What’s more, respondents expect these transfers to be free. Eighty seven percent were dead-set against any fees being charged to either providers or patients for health data transfers. That flies in the face of current business practices, in which doctors may pay between $5,000 to $50,000 to connect with laboratories, HIEs or government, sometimes also paying fees each time they send or receive data.

There’s many things to think about here, but a couple stand out in my mind.

For one thing, providers should definitely be on notice that consumers have lost patience with cumbersome paper record transfers in the digital era. If my mom is demanding frictionless data sharing, then I can only imagine what Millenials are thinking. Doctors and hospitals may actually gain a marketing advantage by advertising how connected they are!

One other important issue to consider is that interoperability, arguably a fevered dream for many providers today, may eventually become the standard of care. You don’t want to be the hospital that stands out as having set patients adrift without adequate data sharing, and I’d argue that the day is coming sooner rather than later when that will mean electronic data sharing.

Admittedly, some consumers may remain exercised only as long as health data sharing is discussed on Good Morning America. But others have got it in their head that they deserve to have their doctors on the same page, with no hassles, and I can’t say the blame them. As we all know, it’s about time.