May 14 2012 1:09PM GMT
Posted by: Jenny Laurello
Dashboard,
KPI,
Key performance indicators,
Quality
Guest post by: Trevor Strome MSc, PMP, Informatics Lead, Winnipeg Regional Health Authority; Assistant Professor, Department of Emergency Medicine, Faculty of Medicine, University of Manitoba
Why you shouldn’t measure everything (or at least have it on your dashboard):
While the phrase “you can’t improve what you can’t (or don’t) measure” is undeniably true, it leads many organizations to try to measure everything. It is this impulse that leads to the proliferation of massive reports (that nobody reads) and overpopulated dashboards that in fact complicate decision making and therefore lead to very little (if any) actual improvement. It is impossible for a health care organization to improve everything at the same time. That is exactly why true health care transformation is a long-term endeavor, and why analytics must remain focused on answering the right questions, and providing the right answers, to achieve change.
Analytics is the lens through which the processes, workflows and business operations of a health care organization should be viewed to guide decision-making and improvement activities. To be effective at facilitating quality and performance improvement, every aspect of the health care business intelligence (BI) tool set (be it analytical tools, dashboards, reporting, etc) should be directed at identifying what needs to improve, and identifying if a change has occurred.
Identifying what needs to improve:
The quality goals of a Health Care Organization (HCO), either organization-wide or local to a unit or department, are a critical input when designing analytics solutions that provide guidance for selecting quality and performance improvement activities. For example, if a goal is to achieve national and international benchmarks for the treatment of stroke within the Emergency Department, then the analytics performed need to focus on achieving this goal. This is done, in part, by selecting relevant quality indicators (such as the “door to CT scan” time interval) and setting appropriate targets. (Click for an article on selecting key performance indicators, or KPIs.)
Once the appropriate quality indicators have been defined, individual processes that fall within the focus of improvement need to be analyzed to identify what must change at the process level. The indicator “door to CT scan” time interval undoubtedly is comprised of several steps (including, but not limited to: arrival at hospital, triage, registration, CT order, transfer to CT machine, perform CT and waiting for results). Each of these steps in the process likely can contribute valuable information to understanding how “door to CT time” can be improved.
Analytics developed to identify what needs to improve will typically include an analysis of the organization’s past performance. Understanding previous performance is important because it helps to clarify not only the magnitude of change necessary, but may even suggest which improvement approach (such as Lean or Six Sigma) may be most suited to address the challenge of improvement. (Click for an article on how analytics and quality improvement methodologies must be integrated to achieve success.)
In addition to providing a retrospective look at performance, analytics are very helpful at providing a real-time (or near-real-time) analysis of performance. The best real-time systems not only provide dashboards that compare current performance versus targets, but include “agents” that automatically monitor incoming data and provide alerts (for example, via email, pager, or SMS) when actual performance is deviating from desired goals. The real-time alerts allow corrective action to be taken immediately (whether it involves further refining a process or simply coaching inexperienced team members on new workflows). These opportunities for a “quick fix” may be lost if performance issues are uncovered days or weeks later in a report, or not clearly highlighted on a performance dashboard.
Identifying if a change has occurred:
As mentioned above, analytical applications are very useful within health care to monitor progress toward achieving quality and performance improvement goals. To accomplish this, however, analytical solutions must be able to detect if and when a change has occurred. This is especially important when quality improvement teams are actively engaged on projects and need to monitor the effects of their changes to processes and workflows.
Despite an abundance of data that many HCOs have at their disposal, detecting a change may not be as simple as calculating an average interval time and plotting a run chart. Data analysis approaches (i.e., statistics), and the visualization of results, must be selected carefully to ensure that any impact of a change in process or workflow that occurs is detectable and apparent. There are many reasons that a change in process may not register in the data. Several such reasons (that relate to the selection and analysis of indicators) are:
- The change in process has no significant impact on performance (in which case, further work is necessary to design improved processes and workflows to achieve the desired change);
- The indicators selected are not representative of the processes being changed (which means that the indicators need to be adjusted);
- The analysis or visualization is not sensitive enough and/or appropriate.
Regarding the point on analysis and visualization, process changes may manifest in more subtle changes to data before becoming “obvious.” For example, rather than simply reporting an average (which can be greatly affected by outliers), it is usually more informative to analyze data in multiple ways. For example, the median and interquartile ranges add additional information regarding the distribution and variation in the data. Visualizing performance by plotting histograms and boxplots better highlights the intricacies of the data than a simple bar graph of averages.
It is vital to have enough confidence in your analysis to trust that if no change is showing in the data, that in fact no change has occurred and not simply missed because your analytics are off-target. The reverse is true, as well - you don’t want fluctuations in the data (as a result of seasonal or other systematic changes) to be interpreted as a change due to improvement activities.
Conclusion
Analytics are a very powerful tool for use in improving health care quality and operational efficiency. With all the data available now, however, it is possible to create myriad dashboards that essentially don’t provide any useful information at all. When engaged in health care improvement activities, analytical solutions ultimately must identify what processes need to change, and clearly demonstrate that a change has (or hasn’t) occurred. Only this will provide the information required to achieve true change in health care.
Trevor Strome MSc, PMP, is the Informatics Lead for the Winnipeg Regional Health Authority, and is Assistant Professor at the Department of Emergency Medicine, Faculty of Medicine, University of Manitoba. You can visit Trevor’s blog at http://healthcareanalytics.info, or contact him by email at trevor@healthcareanalytics.info.
May 8 2012 8:18AM GMT
Posted by: Jenny Laurello
Health 2.0,
HIPAA,
Health law
Guest post by: David Harlow, principal of The Harlow Group LLC, and featured speaker at Health 2.0’s Spring Fling Matchpoint Boston conference’s special session: Health Law 2.0 on May 14, 2012.
Q. Though the health care industry is notorious for operating in silos, collaboration among key stakeholder groups, including providers, payers, technology vendors, and patients, is needed to make a marked difference in the health care technology and data exchange landscape. What would you say are the top three challenges in terms of creating collaborative partnerships, and how should the industry be moving forward?
- A. The top challenges to creating collaborative partnerships are a combination of financial issues and questions about the evidence base associated with the new technologies. Payers are interested in reducing costs while promoting effective prevention and other forms of care. Providers already have too much on their plates, so they are less likely to adopt innovations that are disruptive to their workflow unless they are convinced of their effectiveness and/or are being compensated in a way that works for them. This means either being paid for the additional time and expense spent using these tools or being paid in a manner that breaks from the traditional fee-for-service model and pays instead for outcomes. When providers are paid for outcomes, they have more flexibility to innovate using proven new tools, because they are focused on the outputs — healthier patients who have internalized healthy behavior change — rather than the inputs — higher costs expended for a case that won’t be reimbursed at a higher rate under a fee-for-service model. Some forward-thinking payers recognize the value of new technology and other new tools and have modified their payment systems to change the incentive structure and break down the silos in health care. Commercial accountable care organizations are a prime example of this sort of development.
Q. The FDA rules with a heavy fist, though sometimes that fist is slow to come down with formal rules and guidelines related to the use and advancement of HIT in the industry. What are some of the top compliance guidelines, beyond meeting MU, with which the industry will have to grapple this year? Medical device implementation issues? HIPAA and PHI privacy and security mandates?
- A. The final unified HIPAA rule is expected to be released in late spring or early summer. The steady stream of news about significant data breaches is somewhat surprising, because there are clear steps that may be taken to mitigate this sort of exposure, such as encryption. The positive uses to which HIPAA-protected data may be put will continue to strain the HIPAA privacy and security framework, as well. The FDA has signaled its thinking on mHealth and on the use of social media with respect to off-label uses of pharmaceuticals. The FDA has also been making noises about regulating electronic health records as “devices.” As EHRs have gotten smarter, moving from electronic notepads to real decision support tools, they have gotten closer to the FDA definition of “device.” The overlapping jurisdiction of the ONC and FDA in this arena is of great interest and concern to a plethora of people, and it remains to be seen how it will play out.
Q. In following the coverage from the American Telemedicine Association’s conference, it is clear that there are great strides being taken to deliver care remotely. However, when reimbursement comes into play, care delivery expectations and workflows must be reexamined. How is the industry addressed telehealth/telemedicine reimbursement, and how can organizations continue to move ahead in building out these capabilities in the interim (i.e., convince the CFO it’s worth the investment)?
- A. A recent study concluded that telehealth visits yielded better results than in-person office visits. Now, there will always be a study supporting one side or another of this debate, but I think there is greater acceptance overall of the notion that telehealth has its place in our system on a regular basis. I see its use growing as a means to contain cost growth in health care, specifically by leveraging personnel expenses (home health monitoring can be done more on a remote basis than on an in-person basis, for example) and as another example, making a primary care visit simpler for both patient and clinician through the use of remote communication tools that may be no more exotic than an iPhone app. (Hey doc, what do you think about this rash? Can Johnny go to school?”)
Q. With the advancements in telemedicine, HIEs and other information exchange initiatives, will providers be able to navigate state licensing laws to ensure compliance while also maintaining efficient use of technologies? Are states making it easier for providers and if not, what might have to change in the legal landscape to accommodate technology?
- A. The regulatory landscape presents a challenge to innovators of all types. A handful of states have adopted limited licensure rules for telemedicine, so physicians providing services to patients in those states remotely do not need to go through the full state licensure process. One big issue, still down the road a piece, will be cross-border licensure for surgery performed remotely. A specialist in one city could use robotic controls to treat a patient using a surgical robot in another city, perhaps halfway across the country or around the world. But we are already dealing with line-drawing around cross-border practice. If a specialist is consulting to a treating physician, that does not require licensure in the treating physician’s state. If consulting with a patient, then licensure IS required. Perhaps we should work on rationalizing these requirements. On the other hand, frictionless sharing of patient information from provider to provider is a good thing. Patients who need care when away from home — some day, not tomorrow, but relatively soon, as the interoperability of electronic health records continues to improve thanks to the incentive dollars under the HITECH Act — will be able to rely on the fact that their medical records will be available to treating clinicians wherever they are. So long as one isn’t brought in to an emergency room unconscious and with no ID, the system is being built that will allow any emergency room in the U.S. to call up that patient’s medication list, recent diagnostic images and more to improve patient care and outcomes.
David Harlow is a featured speaker during the Health 2.0 Spring Fling Matchpoint Boston conference’s special session: Health Law 2.0 on May 14, 2012. David is principal of The Harlow Group LLC, a health care law and consulting firm based in Boston.
May 2 2012 7:56AM GMT
Posted by: Jenny Laurello
Social media,
HITsm,
BYOD,
HIPAA
Q&A with Jeani Park, senior director of Product Strategy at SpectorSoft, which specializes in computer, mobile device and Internet monitoring
1. What security challenges do social networking sites like Facebook and Twitter present in the health care setting?
Health care organizations are required to comply with mandates like HIPAA and the HITECH Act that dictate what types of personal information must be kept private. As more employees embrace social networking sites like Facebook and Twitter, the danger of confidential information becoming public increases. For example, in a high-profile incident last year, an employee at Providence Holy Cross Medical Center posted pictures of a patient’s medical record and mocked the patient’s condition. When several of the employee’s Facebook friends informed him he was violating HIPAA, the employee became defensive instead of removing the offensive material.
Violations may be more subtle - sometimes employees may not realize they’re breaking hospital regulations. One such example involves nurses who were eager to leave after 12-hour shifts. Before doing so, they had to access multi-tenant computers to update patient records and notes for the next shift. Instead of waiting, they sent the information via Facebook or LinkedIn on their mobile devices to the nurse handling the next shift. While more convenient than waiting, these nurses had violated HIPAA regulations and hospital procedures.
2. How does BYOD exacerbate security and regulation challenges?
Workers are more connected than ever with the increased adoption of mobile devices and the rise of Bring Your Own Device (BYOD). Since employees can work from virtually anywhere, they are more engaged. Physicians are also using tablets, laptops and other devices when treating patients to gainquick access to vital information. While BYOD has many advantages, it also creates unique challenges. For example, people are usually less cautious when sharing information in an informal setting. While chatting on Facebook , an employee may be more forthright compared to work correspondence. Or they may not pay attention to their surroundings while discussing sensitive information in public via their smart phone or tablet.
Mobile devices also present more opportunities for user error. Caregivers who text, check Facebook and Twitter may be engaged in other activities. As a result, the chances of accidentally sending information to the wrong recipient - either exposing confidential information or ensuring that time-sensitive data isn’t sent to the correct person - increases.
Employees using mobile devices and social networking sites are more vulnerable to identity theft. Many employees routinely share information identifying their employer, department, work hours and even details about their boss or patients.
BYOD amplifies many of the security and privacy challenges facing health care organizations. Employers may have limited visibility into their employees activities couldn’t on their own devices. Creating policies that dictate acceptable use is also tricky when they relate to an individual’s private device.
3. What are some best practices for governing use of social media in the workplace?
Some health care organizations have taken a firm stance against any participation in social network sites during work hours. Some hospitals and health care organizations have prohibited employees from logging on Facebook while at work. Others have created special terminals for personal use during employees’ lunch breaks.
Some best practices include:
- Create risk profiles of your employees, contractors and partners. These profiles, which are based on activity and the individual’s role, help determine what employees might be more likely to share confidential information or violate critical regulations.
- Monitor employees’ activities on social networking sites such as Facebook and LinkedIn.
- Monitor all organization-provisioned devices including laptops, desktops, smartphones and tablets.
- Provide training for employees that outlines key compliance regulations and security risks such as data theft, fraud and identity theft. Share best practices for sharing information on social networking sites.
- When employees engage in improper behavior, use it as an opportunity to stress the organization’s regulations and expected behavior.
With BYOD, monitoring becomes increasingly complex. Health care organizations need to monitor communications and use of protected health information. However, organizations don’t want to save data an employee may be looking up regarding their own personal health care records or billing information.
The juxtaposition of “having” to monitor, record and store data and having huge risk exposure for monitoring, recording and storing other data means that actions/access/applications/data must be handled differently on the same device. There are a number of ways that organizations can avoid monitoring and retaining information that violate their compliance or corporate mandates. These include:
- Creating policies that don’t capture information or screen snapshots if certain information in contained therein such as social security numbers, salary data or private health information.
- Run monitoring products only on applications, systems or data that is explicitly specified to be monitored. For example, sandbox corporate applications on mobile devices and only run monitoring products on the user activity that is sandboxed.
- Create screen log-in notices reminding employees they are logging into and using corporate-owned devices and that all activity and subsequent data they access and use on these devices is subject to monitoring.
- Block access to websites, systems and applications that contain sensitive data that companies don’t want to see or manage
4. How should employers track employees’ social network usage and address concerns?
Organizations utilizing user activity monitoring can track and record employees’ actions in real-time. With user activity monitoring, organizations can monitor, capture and analyze all user activity on the employee’s device, including chat and instant messaging and websites visited. Organizations can also set up keyword alerts that trigger a notification when certain phrases or data is entered on the employee’s system.
User activity monitoring also enables organizations to achieve a broader perspective of employees’ actions. By analyzing their actions in context, employers can gain deeper understanding of what the employee was doing. In some instances, employees accused of a HIPAA violation have been re-accused after their employers have reviewed the transaction records.
5. What are the benefits of social media usage? How can health care organizations better harness its power?
Twitter, Facebook and other social networks present incredible opportunities to build and participate in communities, engage with key constituencies and increase awareness. In the health care setting, social media platforms are an avenue for promoting programs, highlighting good news and responding to questions patients and the surrounding community. Employees can also serve as powerful ambassadors. An engaged, knowledgeable employee reflects positively upon her employer. Hospitals and health care organizations hoping to harness the power of social media should work closely with employees discussing best practices and outlining the types of information that should never be shared in social networking or in general. By doing so, organizations can reduce potential social media mishaps. As social media continues to take hold, it’s not realistic to completely crack down on all forms of social networking. While employees may not go on Facebook at work, many will still be active on the site during their off-hours and regardless of where they are, sharing confidential patient information is a serious issue.
Apr 30 2012 11:29AM GMT
Posted by: Jenny Laurello
ICD-10 transition,
ICD-10
Guest post by: Wendy Whittington, MD, MMM, Chief Medical Officer, Anthelio Healthcare Solutions, Inc.
Waiting for the new ICD-10 implementation deadline feels like waiting in line for something, but not being quite sure what you are waiting for. Most people prefer to be prepared for a future event and many have a fear of the unknown. Since CMS announced the delay of ICD-10 in February, we seem to be in that phase of “do something, even if it’s wrong!”
So, if you are in that group of health care providers who would like to do something - preferably something right - here are some suggestions:
- Education. You don’t have to start your coder training program; there are lots of other education programs you can do now. You can begin with general sessions for administration and department heads that will help remove the fear and also help folks to understand that there is a certain logic behind ICD-10. That logic will help them to begin to put a new, more positive, framework around their thoughts.
- Medical staff. Providers are anxious because there has been so much gloom and doom around ICD-10. Really, once you have divided up the body between right and left, you only have half as many codes as you thought! Also, many of the new codes that have made the news, such as getting hit by a turtle, won’t be used much anyway. Give your physicians a few examples in their own specialties and watch them! Most of the new codes are codes that they wanted all along.
- Documentation assessment. The foundation of all coding is clinical documentation. So why not improve your documentation now? RAC audits already show, for example, that 11% of transitions from Observation to Inpatient status are not documented at all. Add to that the success of Clinical Documentation Improvement programs nationwide, it’s clear that documentation assessment and improvement provides a winning strategy.
- Coding. Use this time as an opportunity to address the coding issues you already have. Most hospitals are already facing coding backlogs and coder shortages. If you have the luxury of not having one of those problems, this might be a good time to do some auditing of your coding so that you can look for ways to improve your processes before ICD-10. The processes you improve now will help with productivity issues both now and later.
- Software Updates. You know that your vendors will have to update your software for ICD-10, but do you really know who is ready and who isn’t? Do you have a comprehensive schedule for the updates? Do you know that you won’t be doing them all at once? Or at least not updating two major systems at exactly the same time? If one of your vendors is ready, why not get started?
For any project, getting started is always the hardest part. Check with your partners to see who is ready to pitch in!
Please visit Anthelio Healthcare Solutions Inc. for more information on Dr. Whittington and the Anthelio blog.
Apr 26 2012 3:45PM GMT
Posted by: Jenny Laurello
Disaster preparedness,
Disaster planning,
Infrastructure resiliency,
health IT infrastructure
We had a great live chat yesterday with Health IT Exchange expert John Donohue, Associate Chief Information Officer at the University of Pennsylvania Health System (UPHS). John fielded some great questions from users about resource allocation, infrastructure configuration at UPHS and how to plan for loss of internet services during a disaster. To learn more about how UPHS has tried to prepare itself to withstand a data center disruption of any kind, watch John’s webcast.
Check out the chat transcript below to see what advice John has to give to health IT pros who are in charge of disaster planning and infrastructure resiliency.
Chat transcript: April 25, 2012
10:48 Anne Steciw: Welcome to today’s live chat with John Donohue, Associate Chief Information Officer at the University of Pennsylvania Health System. We’ll begin momentarily.
10:49 Anne Steciw: Please feel free to start entering questions now!
10:52 Jenny Laurello: Good morning! Our live chat with John on Best Practices for Disaster Recovery and Infrastructure Resiliency will begin at 11 ET. Please feel free to enter your questions now and we will push live once the chat begins, as time allows.
11:00 Jenny Laurello: And we’re off! Welcome all to the #HITExchange Live Chat with John Donohue, Associate CIO of UPHS. Welcome, John, and thank you for joining us today!
11:00 John Donohue: Thank you Jenny, glad to be here!
11:01 Jenny Laurello: First question for you today: In 2009, UPenn decided to bring infrastructure services in-house, outsourced for a decade prior. You cited in the webcast that the key drivers of this decision were rising costs, service level issues, and lack of flexibility in response to user demand. Can you speak to how you started the in-source vs. outsource assessment process, and the first steps you took after making this decision?
11:02 John Donohue: While I was not here when the assessment process took place, my understanding is that the Health System saw an opportunity to contain costs and improve services levels at the same time. In the years prior to this assessment, the Health System had insourced the applications side of things and secured good outcomes. The opportunity presented itself to pursue the same outcomes on the infrastructure side of things… I came onboard as we were executing the insource.
The first steps were “onboarding” the employees and looking for gaps in both skills sets and performance that needed to be addressed. For us, our priority was building out the infrastructure leadership team. We knew that leadership was going to be key to building out the new team and reaching high performance standards.
11:02 Comment From ErnieCIO: What is the difference preparing for an internal disaster (something happening within the hospital) and an external disaster (i.e. mass casualty incident a couple miles away) when it comes to IT stuff? OR isn’t there any?
11:04 John Donohue: From an IS perspective, preparing for both is often the same. We do try to work on scenarios that are IT specific (ie major line gets cut, loss of access to major site, etc.)… This allows us to be prepared for IS type disasters. Additionally we work with the clinical staff and hospital administrators to plan for external type disasters.
11:05 Comment From Vishnu: How did you handle resource allocation (both in terms of funding and staff) after deciding to insource? How do you balance infrastructure resources with those needed for other ongoing enterprise-wide and live application projects? Top bits of advice as to how to prioritize?
11:06 John Donohue: From a day one perspective, our focus was on operational excellence. We knew that we needed to keep the lights on while we improved our depth and breadth of services. We made sure that we kept our best resources on operational activities and began to secure additional resources to handle project and discretionary activities. We were able to quickly secure some very talented folks that allowed us to rapidly build out our project capabilities… From a funding perspective, we were able to build out these additional capabilities and still save money from what was budgeted and being spent on the outsourcing agreement – this made things a little easier in terms of funding.
In terms of prioritizing, I think it is key to understand demand management. If you have a good sense of what the expectations are and what your actual capacity is, you can make good decisions on what you can commit to. Furthermore, I think you can selectively use partners and contractors to bridge any gaps while you are getting your permanent team onboard and ramped up. The last comment I would make is that we relied very heavily on our project management folks. They were instrumental in terms of making sure that we were not missing major milestones or missing key conflicts.
11:08 Comment From JimCIO: I’m not familiar with the UPENN configuration. Are your systems completely insourced or did you build a hybrid infrastructure utilizing both insource and outsourced systems?
11:11 John Donohue: Jim, we have what I would call a hybrid approach to infrastructure and applications. On the infrastructure front, we now implement and manage all of the core infrastructure that is local (ie on campus). However, we leverage our outsourcers data center which is located in another state. We found that at this particular time, they can do a better job managing that aspect of our IS operation. We have the same setup from an applications perspective. We run some of our own key applications locally, but also outsource some as part of an SaaS service. We feel that this provides some level of additional resiliency - in terms of our key systems being spread out. In other words one major outage would not bring down all of our systems
11:11 Comment From Carlene Miyashiro: So much of our operations and clinical care is Internet dependent. I am worried about losing it in a disaster, i.e. a hurricane knocks out the ISP. Advice for creating plan B, C and D welcome
11:14 John Donohue: Carlene, we are in the same situation…. many of our key operational and clinical systems are dependent upon the internet. We have worked hard in this area to make sure that we have full redundancy. So we actually have two points of presence from an internet perspective. They are located in buildings that are across the city from one another to provide some geographical diversity.
Again the theme being that one disaster or problem would not knock us out. We have taken the same approach by diversifying our DMZ and other core services. I would recommend that you ensure that you can get to the internet from an enterprise perspective from fully redundant service points. It will cost some money to achieve, but it will be worth it the minute you have your first outage and your user community does not feel the pain.
11:17 Jenny Laurello: Please continue submitting your questions. We will respond to as many as time allows.
11:17 Comment From Jerome Everson: You developed an infrastructure dashboard at UPenn as part of the in-sourcing assessment and prioritization process. How did you decide (or why did you decide to focus on) on the top criteria against which decisions would be made?
11:19 John Donohue: Jerome, Good question! We worked hard to get the Voice of the Customer. We found in some cases, things that we thought were important to us, were not as important to our customers. This meant getting out there and making sure that we understood the needs and desires of our customers – this also gave us a chance to set some realistic expectations.
Additionally we were very inclusive when it came to our own technical staff. We tried to make sure that we had all of our bases covered and had some consensus on the criteria. It made for some very good and very interesting discussions. For us, it was a very effective team building exercise with a fairly new team. Once we identified the criteria, it was fairly easy sailing.
11:20 Jenny Laurello: Where are you and the UPHS IT team focusing your efforts this year and beyond?
11:21 John Donohue: For us, the first year was around building out the team and getting the right people in the right roles. The second year was around making wise investments to shore up our infrastructure and eradicate enterprise single points of failure. Now we get to start to attack the fun stuff, how we can leverage technology as an enabler… how we can start to become more innovative with the technology. We are working much more closely now with the business to help create competitive advantages.
11:23 Jenny Laurello: What are some of the top lessons learned from your camp?
11:24 John Donohue: From my perspective, the top lesson learned was – be honest with yourself and get comfortable with the cold hard facts. Understand your weaknesses both in terms of staff and infrastructure capabilities. Once you accept that you have some red on the dashboard and some real work to do, you can dig in and get focused. Laser like focus and a strong communication plan are key to ensuring that your team knows the priorities and are all rowing in the same direction.
The second key for us or lesson learned was the importance of leadership that understood where we were coming from and remain committed to seeing it through…. We have a terrific CIO that was very cognizant of what it was going to take and knew that we would skin our knees along the way. At times, we were executing so much change so quickly that we would skin our knees. It did not happen often, but when it did, we recovered and kept moving forward. A supportive executive team is crucial. Getting them onboard early and often is very important.
11:25 Comment From AR: John, we are a small to midsize organization with one main site where our IT infrastructure is located. I am looking now to create a duplicate infrastructure at another one of our locations that is in another township or possibly outsource the duplicate to an IAAS company. The idea being if something happened to our main site I could failover everything to the other and if nothing is wrong load balance our application services between the two. Do you have any recommendations that could help in my decision, or alternative solutions?
11:28 John Donohue: AR, sounds like you have a great opportunity in front of you. From my perspective, getting your resilient solution properly architected is the key. I think you can do the build yourself or outsource it. Some of that will depend on your access to capital versus operating dollars. In any case, if you have someone really sharp onboard that understands both applications and infrastructure - turn them loose on what it would look like. You can then have someone from the outside vet the design. Someone that has “been there, done that”.
Otherwise, I would look for a partner to help with the design and architecture. You want a partner that is going to be with you for a while so that they have some skin in the game. Getting the architecture right is crucial. From there, I think the key is building it out and testing it regularly…
11:29 Anne Steciw: After the chat’s over, check out our recent podcast with tips on how to create an effective disaster recovery plan http://searchhealthit.techtarget.com/podcast/Why-believability-matters-in-an-effective-disaster-recovery-plan
11:30 Comment From JimCIO: Given the advancements in cloud computing over the past several years, are you currently planning (or considering), moving any (or more) of your systems to that model?
11:31 Anne Steciw: We’ve also got a great tip about creating a HIPAA compliant backup in the cloud http://searchhealthit.techtarget.com/news/2240114690/Creating-a-HIPAA-compliant-backup-in-the-cloud
11:31 Anne Steciw: Great questions everyone, keep them coming!
11:32 John Donohue: We are looking very hard at cloud computing. We are being somewhat conservative due to the issues associated with PHI and privacy. We are likely to build out our own private cloud in the next several months. From there, I would like to look at leveraging some type of public cloud for the economic benefits. There are some interesting ways now with virtualization to leverage a hybrid model with both a public and a private cloud.
Once we are comfortable that we could deploy cloud technology in a very secure manner, we will move in that direction fairly aggressively. With our thoughts on cloud, virtualization and blade technology, we are forecasting a much smaller (and cheaper) data center footprint in the future.
11:33 Comment From Tenney Naumer: When the Joplin tornado hit the hospital, it completely destroyed their back up emergency power diesel generator. Fortunately, 3 weeks prior to the tornado, they had completed their conversion to electronic documents and had off site redundancy. Do you have suggestions for what sort of physical structural design might be more appropriate for preserving backup power to information systems?
11:37 John Donohue: Tenney, we are hoping not to see too many tornados in philly, but… On a serious note, we plan for tier 3 capability for all of our key clinical systems. So as we design our solutions we are always N+1. So from our perspective, we would require a backup generator so that we would be able to survive the loss of one. We really look at resiliency at all levels in the stack, starting with the data center and its environmental systems (power, cooling, etc.). We also try to make sure that our systems have some type of resiliency and lastly we leverage backup systems and disk synchronization such that we don’t expose ourselves to key data losses…
11:37 Anne Steciw: Mercy’s hospital is being rebuilt to be 30% stronger than before the Joplin tornado http://www.prweb.com/releases/2012/4/prweb9379197.htm
11:37 Anne Steciw: One more great article about the Joplin disaster: http://searchhealthit.techtarget.com/tip/What-Joplin-teaches-hospitals-about-disaster-recovery-planning
11:38 Comment From Darren Branner: I have heard that to “practice” DR and see how policies and procedures work, some hospitals treat a new software implementation like a PACS or RIS or EHR like a disaster event and assemble teams to deal with it. We are thinking about such an exercise. From your experience, is this a good idea?
11:41 John Donohue: Darren, this sounds like a good idea. We have not yet taken that particular approach, but it seems like a good opportunity to vet out the policies and procedures as well as seeing how the staff responds…. I do think it is absolutely critical to find some way to test your disaster recovery capabilities. You really need to have some organizational rigor to make sure that your solutions work. I would recommend cutting formal projects for DR testing and “budgeting” the time that it will take for your staff to do it right.
11:41 Comment From Lloyd Reisman: How do you make a 5-year plan for DR with technology advancing so fast you can’t possibly know what will be on your network five years from now? Focus on infrastructure, mostly?
11:45 John Donohue: Lloyd, you have hit on a very critical item. Unless you have a crystal ball, we don’t know exactly what will be running on our systems and how much “capacity” they will require. For example, a year ago, we were planning for Terabytes of storage, we are now talking petabytes of storage - a potential game changer. I think you are absolutely right, focus on the infrastructure. We work hard to abide by standards and build out our infrastructure with some level of agility… In other words try not to lock yourself into some technology that would be a dead end or would be difficult to support or integrate when things change, because we know that they will. The more agility and flexibility that you build in the more you will be able to protect those investments.
11:47 Jenny Laurello: What hospital staffers should the CIO interface with re: disaster planning? I.E. a safety officer is typically the head disaster planner, and the compliance officer is responsible for HIPAA compliance in a disaster, etc.
11:49 John Donohue: We have a safety officer that is very effective in understanding the scope of the disaster, communicating the impact and rallying the right resources to address the disaster. It is key that the CIO and other IS executives work with the safety officer in advance of disasters (in terms of planning) and then during the disaster. We have had very effective “post mortem” type meetings after disaster events to make sure that we capture lessons learned and get better and strong as a result of the experience.
Additionally I think it is key that the CIO have strong relationships with the other health system executives (from nursing to operational folks) so that when disasters strike, you can quickly respond. In summary, I don’t think you can go broad enough in terms of key hospital staffers in disaster planning.
11:51 Comment From Chad J: What are your thoughts on conducting mock disaster drills? If so, are the drills conducted primarily by the IT staff, or are other departments involved since practically all medical operations involved IT?
11:53 John Donohue: Chad, I am a strong supporter of conducting mock disaster drills. The challenge is that they are time consuming and they compete against other critical IS activities like installing new systems. I think you really need someone in your organization that “owns” this process and is measure on their discipline around conducting them and making improvements based on the feedback and results. I think it has to happen at both levels, some mock planning within IS for IS type disasters and then also at the broader institutional level (my experience is that most hospitals are very good at conducing regular mock drills on the “clinical” level)
11:55 Jenny Laurello: What’s the best strategy to ensure seamless – or close as possible – EHR uptime in a disaster event?
11:57 John Donohue: From an infrastructure perspective it is all about resiliency. We have worked very hard to eliminate any and all enterprise single points of failure. Vendor diversity, location diversity, tiered data centers, etc…. We have looked at resiliency at every level in the stack from data centers all the way to the end user devices. Some very effective investments and being opportunistic with our legacy capabilities allowed us to get there fairly rapidly. I would also say that it is key to be closely aligned with the Applications leadership and your vendor(s). It needs to be a joint effort and the infrastructure is only one piece of the pie. You can get the infrastructure right and then fail in one of the other areas (i.e. applications).
The EHR is so critical that this is one area where I would recommend having very specific scenarios vetted out… Really walk through the different type of outages you have an how your infrastructure and applications would respond. Look for the weak areas and then you can work on them to ensure that you are better prepared for when something happens
11:58 Anne Steciw: Check out how this facility dealt with a disaster after a recent EHR implementation: http://searchhealthit.techtarget.com/video/EHR-implementation-held-after-Minn-bridge-collapse
11:59 Jenny Laurello: And that’s all he wrote, folks! Thank you everyone who participated for all of your great questions, and thank you, John, for all of your wonderful expertise!
12:00 Comment From Tenney Naumer: Yes, thank you!
12:00 Comment From ErnieCIO: thanks for such an informative session.
12:00 John Donohue: Thanks, I enjoyed the questions and learned a little myself today….
12:00 Comment From JimCIO: You’re welcome! Thank you!
12:01 Anne Steciw: Thanks everyone! We’re closing the chat now. Check back here for a transcript.
Apr 26 2012 6:00AM GMT
Posted by: Jenny Laurello
Speech recognition,
Voice recognition
Guest post by: Dr. Andres Jimenez, CEO, ImplementHIT
Recently I wrote about the importance of training and computer hardware as it pertains to the implementation of medical speech recognition (SR) technology. In this post, we will take a closer look at the importance of clinical workflow design.
Let me start by saying that there is no one-size fits all approach when rolling out a speech-enabled clinical workflow to your clinician base, which is why it’s best to begin the process by designing a clinical workflow plan. Clinical workflow describes the process of managing patients through a clinical setting. When you add SR to the mix you need to take into account the various documentation settings you find yourself in. For example, consider the middle aged, obese, diabetic patient with hypertension coming in for an annual visit. Several dictation scenarios exist; the provider speaks with, examines and takes care of the patient. The provider could either a) dictate at the point of care (least common), b) immediately following the patient encounter or c) in batches; [seeing two or more patients, sometimes an entire day's worth before dictating]. In the worst case scenario, patient notes aren’t finished until the next day, or in some rare cases, days to weeks later.
Clinical workflow design can lean providers toward one scenario or the other with the goal of facilitating dictation and shouldn’t be arbitrary. For instance, if your SR software is on your office work station, and not your laptop, then dictating in front of your patient in the exam room is less likely. If your office workstation is on the other side of the clinic then that might further lean your providers toward dictating in batches. If you move from room-to-room or around the hospital with a laptop loaded with your SR technology (my favorite approach), then all scenarios remain possible.
Today, several EHRs even offer the ability to go ultra-mobile by speech enabling iPad-like devices to not only produce text but hands-free navigation through the patient’s electronic chart (discussed further in our next post on EHR integration). Some might consider this is just hardware selection, or even office interior design, but both should be guided by clinical workflow from the perspective of specialty, practice setting and SR use. This is because factors, such as time between seeing your patient and documenting your note, and seeing additional patients during that interval, greatly impact note quality. What’s more, if you have a busy practice, neither of these factors are in your favor.
Over 1.2 billion patient encounters are documented by physicians each year, and a single percentage point decrease in quality can have a serious nationwide sequel. Critical documentation errors are defined as errors that could impact patient safety or continuity of care, the most common of which are wrong patient, wrong drug name or dosage and left/right discrepancy. Take for example a busy orthopedic practice where the importance of laterality is easily appreciated, time is scarce and not facilitating the use of SR quickly and easily in between patients can significantly impact critical error rates. In contrast to a critical care specialist receiving a new patient at 2 a.m., where laterality can be just as important, but time and seeing additional patients before you create your note are more controllable. In this scenario clinical workflow should lean toward SR in a comfortable setting on a workstation (next to a coffee machine as well). By accounting for clinical workflow for providers in these different specialties and practice settings, you could lean them toward the voice recognition scenarios best suited for efficiency and quality.
There is one more aspect regarding clinical workflow that should be considered. Most practitioners would agree that dictating in front of the patient can be uncomfortable (usually more so for the provider). For this reason, their clinical workflows always account for SR outside of the room, creating an additional step before moving on to the next patient. For encounter types such as post-operative visits, which are less variable, common and typically uncompensated within the global period, a simple clickable template within the EHR system might allow you to complete your note before leaving the room.
In a primary care setting, consider a monogamous female patient with a urinary tract infection. Although you now have to also document to support coding, these tend to be quick lower level visits easily captured with a clickable template completed while in the room with the patient. In both scenarios the note can be completed before leaving the room, eliminating a step before moving on to the next patient, which greatly enhances overall efficiency. Of course, we must never force the patient with the uncommon complaint or complex usually straight forward complaint down this simplified documentation approach, as that would decrease note quality as well. Furthermore, we shouldn’t ignore provider documentation preferences either, which is why these types of “quick” clickable templates should always contain placeholders for custom text generated by SR to fill in the gaps when appropriate.
The key to speech recognition success is training focused initially to leap past the accuracy hurdle, followed by hardware selection (discussed in our previous post) and carefully taking into account unique specialty and practice setting workflow characteristics as part of your speech-enabled clinical workflow design. The process should ultimately facilitate dictation to ensure quality patient records, and decreased error rates. Do not forget to check back later this month for the third and final post on the importance of EHR integration toward finding success with medical speech recognition.
Dr. Andres Jimenez is CEO of ImplementHIT, a leading Health IT training firm and creators of the OptimizeHIT training platform, which is rapidly becoming the “new standard in health IT training”. Dr. Jimenez is a Nuance Healthcare physician advocate, former Allscripts Clinical Director of Content and Online Training, and is still clinically active using voice recognition for all his clinical documentation.
Apr 25 2012 1:48PM GMT
Posted by: Jenny Laurello
Medical device integration (MDI),
Mobile applications
Guest post by: Brian McAlpine, Director, Strategic Products, Capsule Tech, Inc.
In the first post of this series, we addressed the challenges nurses and clinicians face when manually documenting patient vitals and how medical device integration (MDI) automates the process of vital signs collection and entry into the EMR. As hospitals seek to address the issue of manual charting through the use of medical device integration, there are important details of MDI that need to be understood - details that can have a major impact on the success of the implementation.
Hardware - The devil is in the details
Before deciding on a medical device integration provider, consider mapping out both a short-term and long-term medical device integration strategy. There is a myth out there that says it is possible to implement a medical device integration solution without dedicated hardware. This is a short-sighted view that can inhibit the full value of MDI. If a hospital is only connecting patient monitors it can do that through a HL7 feed by polling (or listening to) the MDI vendor’s gateway. This approach is not something that’s typically encountered at many hospitals. Even if the hospital did take this approach, it would still be managing multiple points of integration because many hospitals have installed different brands of monitors being used.
To derive true value from an MDI implementation, hospitals need to be able to integrate more than just monitors, and most hospitals want to do just that. Hospitals typically need to integrate new and older devices. Older serial devices need to be connected at the bedside. Newer devices need to be connected wirelessly. For example, hospitals need some type of device integration to connect serial (RS-232) devices at the bedside with medical devices such as ventilators being the most common example. A hospital may also want to use a serial port adaptor to enable connectivity for wireless devices. Aren’t both of these pieces of hardware?
The myth further implodes when you take into consideration the Joint Commission’s push that requires positive patient identification (PPID) and positive device to patient association. There is no way to have a device integration solution establish PPID without hardware playing a role in the association process and workflow. Most hospitals use a barcode scanner - either integrated or separate. Then the patient ID needs to be confirmed by the nurse. The nurse either needs to see the PPID confirmation on a screen and click on it or be able to pull up a pick-list and be able to select it from one of them. To do this, there are multiple solutions. Clinicians and nurses use PDAs, tablets, smartphones, PCs, mobile carts and even the Capsule Neuron. There are some solutions that require nurses to confirm all the devices associated with a particular patient and also to confirm data before it is sent.
When implementing MDI, hospitals need to think through the details that matter, especially the clinical workflow. Hardware should be integrated into the existing design of the hospital and the existing clinical workflow. Also, hospitals should make sure patient location and identification can be sent to get around EMRs that don’t accept patient IDs.
Additionally, think about the future. MDI solutions need to be flexible and scalable so hospitals can take existing and future applications and grow connectivity throughout the hospital enterprise to positively impact multiple areas of care. These are the details that really matter.
Getting the Answers
When implementing a medical device integration strategy ask these questions of the provider:
- How do you define hardware?
- Is it easy to use and does it enable an acceptable workflow?
- Is it intuitive?
- Is it visible and accessible to the clinician at the bedside?
- How do you perform PPID?
- Is data flowing before PPID is confirmed?
- Is it “future proof” or scalable?
- What are all the clinical workflow steps needed to make all of the above happen?
If these details are not factored in, they can negatively affect the total implementation, the budget and the overall adoption rate. Establishing a long-term vision and strategy for MDI can help immediately dispel myths associated with the process and position the hospital for success. In the third post of this four-part series, we’ll look at why focusing clinician workflow on the patient and not devices is an important part of this strategy.
For more information, please visit Capsule Tech, Inc.
Apr 19 2012 9:54AM GMT
Posted by: Jenny Laurello
ACOs,
Accountable Care Organizations,
Continuity of Care Document (CCD)
Guest post by: Ruby Raley, Director, Health Care Solutions, Axway
Industry discussion around accountable care organizations (ACOs) is soaring - in fact, one could argue that the main topics of HIMSS12 were analytics and ACOs. In any case, we know ACOs are coming at us head-on, with limited time to think through what needs to be done in order to be successful.
But if you are a health plan or payer, there are five tasks you can do right now to improve industry understanding of ACOs, encourage adoption of ACOs and champion improvement of health care for your members.
1. Define the data. ACOs are meant to move us away from a fee-for-service structure and toward a performance or quality-based structure. We need to define what documents to exchange, including some type of document framework between all parties involved - that is, between providers, payers, labs, clinics, long-term care facilities, etc. Continuity of Care Documents (CCDs) could be the answer, but CCDs come in many variants. Perhaps the solution is to take claims data and standardized portions of CCDs, and add other documents from our encounters with patients in order to collect enough data for us to know that we are making the appropriate decisions to provide the right care.
As part of collecting that data, many ACOs use a multi-payer structure - which is, in fact, what the Centers for Medicare and Medicaid Services (CMS) encourages when a provider sets up an ACO. That requires that health care leaders clearly and consistently define data semantics. We cannot expect one provider to produce four different variations of a document to send to four different participants in an ACO collaboration. We must work together, on the front end, to define how we’re going to use data, and how to consistently apply standards within ACOs.
2. Define critical events. As payers, what are the patient events we want to receive from providers, and when do we want to be notified? Some examples might be: When a patient leaves the hospital, so that we can follow up with them right away; when a baby is born; when patient blood work changes (e.g. for diabetic care); or when blood pressure results change. It’s critical to make these decisions now, since not every event is necessarily well-represented in the electronic exchange of information.
3. Accelerate adoption of CMS initiatives, such as claims attachments. Claims attachments enable us to send HL7-type CCD documents containing extensive patient information along with the claim. Our health plans need a better sense of the actual doctor/patient encounter - what the doctor did, what the conditions were, any counseling the patient received, etc. - and CCDs have the potential to provide that data. Such information also adds depth and context to claims and services provided to the patient. As it stands today, payers don’t usually get claims attachments as part of an online, real-time conversation, but rather after the fact as audit support. For ACOs to be successful, we have to develop the habit of sharing clinical documents with health plans.
And this leads to another extremely critical element of an ACO: trust. Trust is an extensive topic, so we’ll focus on two aspects: trust in technology and trust in the organization. Trust in technology is the reliance on secure electronic exchange using certificates or other encrypted communications. ACOs, like all other health care entities, must secure data to comply with the HITECH Act and HIPAA regulations. Trust in organizations, in this case, is the confidence that all parties involved in the ACO - providers, health plans and patients - are working together for the common goal of improving patient care while reducing cost. With trust in technology and trust in the organization established (and backed contractually), information can be successfully shared and used.
4. Find the best route for patient records and empower patients in the ACO. Are we going to route records to a patient’s personal health records system, or create a new structure for patients enrolled in an ACO? How will we ensure that the patient understands and complies with their care plan? Patients may need to provide consent, and/or want to know who has access to their health records. ACOs should consider patient rights and state regulations while working to provide a patient portal that is simple to use, understandable and consistent. Improving patient outcomes requires patients to understand how their health information will be used, and be empowered to take responsibility for their own care.
5. Health plans should expect to lead the conversation. You, the health plan, are in the best position to drive the adoption of ACOs and to make them successful. Not only do you understand what data is needed, you have the technical foundation to enable ACOs. You have an existing electronic connection to providers, and you offer member (patient) portals where information can be shared.
Just as important, health plans can offer a win-win solution to the provider through administration simplification (streamlining workflows to minimize manual processes), enabling faster eligibility confirmation, faster payment authorizations and more. Health plans can also identify cost savings to help the ACO pay for itself, instead of being yet another new initiative that adds to the cost of health care and increases the administrative burden of already overworked clinicians.
Only health plans can play this leadership role in making ACOs work. They must ensure that the right data is exchanged, develop trust between all parties and lead the conversation about how to make these activities cost effective, streamlined, efficient and, lastly, workable for everyone involved.
For more information, please visit www.axway.com.
Apr 10 2012 11:17AM GMT
Posted by: Jenny Laurello
Manual charting,
Medical device integration (MDI)
Guest post by: Susan Niemeier, RN, BSN, MHA, Capsule Tech, Inc.
As more and more hospitals prepare to meet meaningful use requirements and, more importantly, set goals to improve efficiency and patient outcomes, many are taking the next step. The first step was to transition from an archive of paper files to the EHR system. The second step that’s currently underway is to derive the full value of the EHR system. In this first post of a four part series, we’ll look at the challenge nurses and clinicians are still facing when stuck in paper-based mode; having duplicate processes because they have to manually chart patient vital signs and then manually enter that data into the EHR.
Manual charting
Let’s look at the current process of manual documentation. In non-critical care environments, such as med-surg, nurses and nurse technicians collect patients’ vital signs and write them on paper. These handwritten values must then be manually keyed into the patient’s electronic record. This duplicated process reduces clinical staff time available for patient care. It also leads to a significant lag between the collection of vitals and their availability in the patient’s record for other care providers. Ultimately, this all means less time at the bedside, a greater potential for errors and delays in decision making that could affect patient outcomes
Medical device integration (MDI) automates the transfer of vital signs to the EHR system. This opens up the opportunity for new safety and efficiency initiatives in monitoring patients. Decision making is also improved. Why? Because accurate vital signs are in the patient’s record in almost real-time. This means physician and care management teams can make decisions based on the true status of the patient and even be alerted to early warning signs of patient deterioration.
By importing vital patient data into the electronic record in near real-time, MDI transforms the delivery of patient care and communication patterns amongst clinicians around patient care. The data is more timely and reliable, which results in the avoidance of inaccuracies and the omission of errors. One of the leading providers of health care solutions in the U.S. shared the following about its MDI implementation of Capsule’s Mobile Vitals Plus solution in over 100 hospitals:
“Following our MDI implementation, nursing leadership recognized a dramatic improvement in patient care and time at the bedside. Physicians noticed a dramatic improvement in near-real time access to data in the patient’s record. In fact, in comparison to the baseline state of vital sign collection and documentation in our med-surg units, we reduced average time to get vitals into the record from 41 minutes to a mere 23 seconds after implementation.”
Real-time data capture is crucial to providing clinically excellent care while also improving hospital efficiency - all while ensuring clinician satisfaction. The value proposition is met because the clinician is now removed as the human bridge linking data to the EHR making vital sign documentation a by-product of care.
In part two of this series, we’ll uncover the myths associated with the use of hardware in conjunction with medical device integration. Part three will showcase why clinician workflow should focus on the patient, not devices, while part four will close with how hospitals can create an enterprise vision for medical device integration.
For more information, please visit Capsule Tech, Inc.