Fall 2014  
The Value Proposition for Interim Clinical Department Administrator Services
By Jerry Broderick
Administrative Professional Staff turnover is a daily challenge in today’s dynamic academic healthcare centers. Whenever a Chair faces the loss of a clinical department administrator one of three directions can be chosen. The first is to reassign duties, tasks and responsibilities to current internal department members. The second is create an arrangement with a fellow Chair and purchase a portion of the effort of the incumbent administrator in the other department The third option is to bring in an Interim Clinical Department Administrator. Upon close examination the value proposition in adopting this latter strategy is clear.
Initially the Chair has the following questions to ponder.
  • How do I identify the right individual for the role of Administrator?
  • How long will this process take?
  • Should the search focus on an external or internal candidate?
  • What about the impact on the department performance during the interim period?
The latter concern often clouds the picture - no Chair wants to have his/her department experience any kind of setback during this time whether it be in the area of clinical services, business office, revenue cycle performance or overall department financial performance. Rarely does a department have the luxury of reassignment of duties of the clinical department administrator to qualified individuals within the department. Often the initial reaction is for a Chair to consider pursuing a temporary arrangement whereby an administrator of another department can assume the added duties of this department on an interim basis. At first glance this seems to address a number of crucial concerns such as the benefit of having an administrator who is familiar with the organization, even if the Chair only owns a piece of that individual’s time. In addition, in the shared role the Chair assumes that the administrator embraces the culture, is knowledgeable about business processes, and has demonstrated a certain level of performance.
Experience has shown that there are significant shortcomings in sharing an administrator from another department. Neither the chair nor the department faculty and staff can expect to receive the full attention of the shared administrator. Also, the lack of physical presence often creates a negative impression for the work force that no one is on the job and watching daily activity. The lack of full-time dedicated effort to one Chair and department also results in a compromise in terms of major strategic projects or initiatives. In fact, often times the path of least resistance is the road chosen. This is the result of the limitation of time that is placed on the administrator. It is far easier to move forward on a number of minor initiatives and projects in both departments that meet with little resistance than to focus time, energy and resources on one major priority that takes attention away from these lesser priorities – in both departments. Also, due to time constraints the split administrator has little time to engage with faculty physicians – an important factor in the success for any department administrator.
With succession planning not normally an option there is not a viable candidate is waiting in the wings. The timeframe for posting the position, screening applicants, on-site interviews, negotiation with the finalist, relocation (perhaps), orientation and training can be significant. These steps can be accomplished in no less than 3 months in an ideal situation but realistically may require up to 6 months. During this time all the parties involved in the shared clinical department administrator relationship face daily compromise and must settle for less than ideal results.
Increasingly, academic healthcare organizations are looking to interim clinical department administrators to help bridge the gap during a period of turnover. Unlike an administrator whose time is split between department and interim clinical department administrator is fully dedicated to addressing matters of strategic importance to the department.
Epic Clinical Documentation Improvement
By Jaffer Traish
Spotlight Article
As organizations move from fee-for-service to fee-for–value models, clinical and financial leadership are challenged to work together even more closely to identify opportunities for care improvement. Often times, these efforts begin with deep dives into the data, searching for ordering patterns, documentation gaps, result-to-outcome correlations and more. Business intelligence teams are asked to move into high gear to evaluate data integrity and produce highly visible reports, not only for leadership to learn from, but to leverage to attest to many federal incentive and penalty programs.
One of the most essential programs to support the fee-for-value model is Clinical Documentation Improvement (CDI). These highly visible programs assess education, configuration and use of EMR functionality with an operations process review to improve documentation quality, efficiency and accuracy in support of patient care and data integrity. Main goals include 1) improving clinician satisfaction and efficiency through clinical content, 2) enhancing overall revenue integrity, 3) increasing patient acuity reporting 4) preparing for ICD-10 specificity, and 5) optimizing EMR tools to support best practices
Typically, these programs involve the following in preparation:
  • inventorying tools and usage metrics
  • evaluating notes and dictation format and functionality
  • clinician and revenue shadowing
  • financial risk reporting and dx report correlations
  • collecting coding feedback
Next, prioritization of actions takes place through:
  • prioritization of content gaps identified
  • consideration of evidence based medicine and build/buy/borrow approach
  • development of educational plans and coding feedback
  • CDI merge with ICD-10 efforts
After operational process improvement and content build:
  • measurement of efficiency and time savings
  • measurement of data integrity improvement and patient acuity improvements
  • measurement of user satisfaction and deficiency improvement
Success factors for CDI programs include having strong clinician champion support and communication, as well as having concurrent assessments with a truly cross functional operations and EMR IT team. In addition, having a clear change management process to handle high volume changes and collaboration with the ICD team and coding/clinician educators is key.
CDI programs support not only Value Based Purchasing models, but also the ACO model, ICD-10, reducing readmissions through improved reporting and will also support your informatics and intelligence data integrity. CDI is an ongoing program for many of the top performing organizations we collaborate with – we’d love to share more!
Physician Networks – Who Wins? When It’s Done Right - Hospitals, Physicians, and Patients
By Jerry Broderick
Physician networks have become an integral part of nearly every health system. Successful networks implement an operating model that result in benefit for the hospital and the physician group. The health system’s focus is on holding onto its current book of business and expanding through intelligent investment in the physician network. The physicians belonging to the network want to, as much as possible maintain their current level of compensation. This may occur despite the overall decline in reimbursement as a result of improved volume. In some cases, physicians join a group in the hope of having a reduced role in the management of the day-to-day operations of the business. With the shift of most health systems to a focus on population health management it puts an even greater degree of urgency and necessity on having in place a clinically integrated physician network.
Types of Networks
The physician network may be one of two forms. There is the employed physician network and there is the clinically aligned network. The latter can consist of physicians in private practice and may also include employed physicians. For the purpose of this discussion the focus will be on the employed physician network.
Reasons to Form a Network
To many there appears to be several reasons to form an employed physician network. However in fact there are many reasons to create a network. Top 15 Reasons for an Employed Physician Network
  1. Opportunity to improve coordination of care
  2. Physician recruitment and retention
  3. Potential for consolidation of overhead
  4. Process improvement – cleaner claims, greater percentage of timely filing
  5. Positioning for Population Health Management
  6. Centralized revenue cycle management
  7. Improved AR Management
  8. Stronger representation with managed care payors
  9. Tighter referral management
  10. Standardization of business procedures and processes
  11. Potentially reduce professional liability cost
  12. With system-wide EHR, opportunity to capture data otherwise not available
  13. Access to capital to expand physician network or invest in infrastructure (depending upon legal limitations)
  14. Opportunity to participate in ACO and CI providing new revenue streams to physicians
  15. Seat at the table for physicians to participate in decisions regarding cost savings distributions and other financial decisions affecting the network
Strategic Vision – Key to Success
Early in the process of forming an employed physician network a strategic plan should be developed that is aligned to the vision of the physician group and the health system. The strategic plan should set clear performance expectations for the physician network going out several years. The plan should incorporate a set of assumptions with regard to the desired make-up of the network to be reflective of the clinical services that are offered by the health system. For example, if the system does not have a robust cancer program, it might be ill-advised to bring on board a pediatric surgical oncologist or similar subspecialists. This may be despite the fact that the surgeon may be currently on the medical staff. Also, there is a great risk assumed when too many of one specialty are brought into the network. If volumes are not sufficient to support the number of specialists - the health system could find itself absorbing significant cumulative losses with no end in sight.
Several decisions should be made with regard to leadership and make-up of the physician network. Regarding leadership – can a physician leader be identified who has the respect, the ability, the desire to take on the demanding role? Will he/she be compensated for serving in this role? The physician leader should occupy a seat on appropriate committees and be given equal status to the Chief Medical Officer.
Communication by the CEO and other senior leaders of the health system is key to physicians’ satisfaction and success. All too often in health care organizations that are under-performing and facing significant challenges the criticism is heard that leadership is not in contact with the physicians and doesn’t really know what they are facing. Physicians respond when they understand the win:win proposition. This can be delivered in many ways – verbally, emails, newsletters, etc.
Physician compensation can be a key component in driving change and improving performance. As physicians enter the network, at some point, a review of the composition and structure of physician compensation plans should be undertaken. If necessary, the plans and the physician contracts should be revised and reflect the performance expectations of the network – thereby eliminating criticism about the treatment of one over the other. If the system is committed to population health management then leadership should consider performance targets as part of the overall comp structure for physician. Examples of this include: primary care physicians being eligible for incentive when they achieve certain targets set for HEDIS measures. Specialists my earn a bonus incentive on basis of the hospital clinical service line meeting or exceeding target set for the system such as: length of stay, infection rate, readmission rate, mortality rate, length of stay, cost of care. If the health system owns or is a part of an ACO it is essential that a portion of the shared savings be distributed back directly to the physicians. This will drive providers to becoming even more diligent about managing the cost of care. To do so, requires transparency and periodic reporting of the key metrics as well as other feedback.
A strong focused must be made to identify and hire dedicated, talented individuals, provide growth opportunities for current physicians and administrators, charge the team to adopt best practices, educate providers and maintain transparency with regard to the compensation model. A highly functioning network as part of a health system will enjoy a lean staffing design within an environment that reinforces a team-based approach that will incorporate efficient workflows and stimulate the staff to focus on high value activities.
CareGuides or v11.4 Features: Which is better for your organization?
By Joy Spitznogle
As organizations transition to v11.4 many are revisiting their decision about whether or not CareGuides would be beneficial for their providers. While many providers choose to use the standard functionalities of v11.4, some have found that the use of CareGuides with select visit types and diagnosis codes have allowed them to reduce their keystrokes, streamline their workflows and increased productivity. Additionally, CareGuides can assist an organization in achieving Meaningful Use by increasing the use of CPOE, patient-specific education, and clinical decision support.
However, some providers may not have much need for CareGuides in their current workflows. For example, specialists who make an assessment at the end of a visit and often prescribe different tests and medications to different patients with the same diagnosis codes may not see any increase in productivity with the addition of CareGuides. These providers may instead choose to use v11.4 functionalities such as organized favorites in orders and instructions, patient care team, order details changes, family history changes and Meaningful Use alerts.
The best way to determine whether or not CareGuides could be beneficial to your organization is to conduct a hands-on assessment of current provider workflows and preferences during routine daily tasks. Some questions to consider before implementing the use of CareGuides include:
  • Does the provider assess the patient’s problem for the visit prior to opening of the note?
  • Is the assessment done at the end of the visit?
  • How does the provider use the EHR? Does he/she use just the note for all documentation, or does he/she use the ACI for the problems, medications, orders, etc.?
  • Does any of the nursing staff input the patient information for the patient visit?
Ideally, organizations should utilize a Clinical EHR analyst to review their current systems and provider workflows over a two to three day onsite evaluation period. The analyst should spend significant time in varying specialty groups to fully understand workflow patterns across the organization. Additionally, the analyst should spend two to three hours with each provider to identify the key aspects of CareGuides that will affect providers on an individual level. This assessment will allow your organization to accurately determine how the addition of CareGuides will benefit the system as a whole.
Epic Interfaces: Bridges White Paper
By Tom Gantzer
One purpose of any electronic health record is the accurate collection and the secure dissemination of patient health information. Today, organizations are constantly working to identify more efficient ways of performing these tasks to improve the quality of patient data, streamline patient access and provide clinicians with real time decision support. Organizations are using electronic interface communications more than ever before as a way to improve the quality and quantity of data being shared. Interface and integration implementations are becoming more complex with the addition of web, security and regulation compliance. Below is a discussion of common challenges and approaches with effective integration programs.
Delivery and Connections
While on the surface, delivery of an interface and establishing basic connections seems to be the most straightforward in the entire development cycle, though it is the one which many times causes deviation from planned timelines. The most common cause for delays in this phase is paperwork, payments and signatures. It can be difficult to connect key decision makers between multiple organizations. The healthcare organization, the HIE vendor, the product or organization you want to interface with and possibly a vendor building the interface are all common contact points in this process. Once paperwork is in order, basic interfaces are delivered and communications can be established for development. During this time developers may see their timeline become smaller for development, thus constant communication with project leadership is key.
Design and Develop
As the technical phase of the project begins, analysts working on both ends of the interface trade specifications and technical documents and begin discussing how both systems operate. Sometimes this exchange can happen earlier, though most vendors require the aforementioned paperwork before sharing documentation on their products.
One common misconception is that a developer can look at documentation or specifications in order to begin work around translations, mappings and build. While this is a crucial first step, it is only a start. Even in scenarios where two vendors have interfaced previously, it is impossible to predict mappings for various fields. No two clients have built the exact same set of values and developers do their best to exchange all of these mappings initially. Constant evolution of products requires attention to detail and approved deviation from standards in almost every case. Tracking and managing message failures early and often is a great outcome during the initial testing process. Every message failure provides a great starting point for dialogue with workflow and application teams. Having application teams, subject matter experts and end users validate outcomes is crucial to success of initial design.
The testing phase can often cause frustration from a project management perspective. This is the time where teams responsible for build begin to perform complete workflows that generate messages. This is where the volume of message failure becomes much more frequent. The developer will have been focused on interface message development using a few workflows which are common. When real-word patient care scenarios begin to be tested, the developer can now begin to discover the many nuances and customizations that reside within the client’s system along with workflows that are unique to the organization. As an example, perhaps a registration person does not always capture a SSN but it is required in the receiving system or the interface is using NPI as an identifier for providers.
The design phase should include an understanding of workflows and a degree of end-user input. Just as important, this is where the testing phase of an interface project differs from many other technical implementations. When implementing an interface, the testing phase should be partly considered an extension of the development phase. In the testing phase of a normal project, management would and should expect for build to be near completion. However in this scenario some complexities do not present themselves until this time. These findings lead to the more granular, fine tuning of the interface and where reliability and stability is achieved.
Many vendors will supply initial project plans which read two weeks for development and two weeks for testing. It is important to understand that these generic project plans do not account for any of your organizations complexities. While ADT interfaces, for example, seem relatively straightforward; they often require the most validation of field mapping and exhaustive mapping.
Interfaces are often one of the first parts of an EMR build to go live. Depending on the type of interface, there should be technical staff available for working errors including high volume interfaces. Even a well-designed and built interface can have a batch of fatal errors when the input is turned over to human error during a given workflow. Simple issues can be compounded by volume, and when the interface carries time sensitive information like lab results, the errors must be worked and the issue resolved quickly.
Post Go-Live
After the initial go live and round of issue resolution, regular post live review and maintenance should be planned and organized. Errors queues should be part of the initial development and should be regularly maintained to ensure data is passing accurately and efficiently. It’s important to keep in mind that development on the other side of the interface can occasionally be suspect and at risk for problems as well.
There are a few different types of errors:
Mapping errors will likely continue through the life of the interface as both systems are constantly being updated and maintained. Good communication and change control processes can be the biggest weapon against these errors using valuable hours from the interface team. Workflow errors are caused by non-standard workflows on the front end. Continued training and support can reduce these errors post go live. Having a strong physician champion is a great way to communicate changes. A strong physician champion should not only be a voice for the front end but also a valuable resource for the technical staff especially when he or she is willing to be involved in the development process. There are many miscellaneous errors, requiring constant monitoring and change control to address. As Epic expands its third party integration services through the datamart, HL7/bridges standards and web services, demand for top integration talent is high. At Culbert, we support data conversions, new and standard interfacing, API development and much more. More often, the driver for this work may be organization merges or separations, support staff reduction and efficiency standards – we’re excited to partner with you on these initiatives and more.
7 Key Questions to Ask When Planning Your Rhapsody Transition
By David Oxtoby
1. What’s the timeframe?
Underestimating how long a project will take is an easy mistake to make. Starting with detailed documentation on your existing interface environment will enable you to make an informed decision on project length and will serve as a great asset while making the transition. Documentation should include details on all systems, scripts, translation tables, message definitions and of course, mappings. A good rule of thumb for transitioning 50 interfaces of medium complexity is about 18 months.
2. What system resources will we need?
Although certainly not resource intensive, Rhapsody does require a more robust platform than ConnectR. Below are the recommended minimum system requirements for Rhapsody. Remember that your plan should also include resources for a full test system.
All requirements rest heavily on the amount of data that will be passing through the interfaces. As organizations grow, whether through more systems or more patients, the amount of interfaced data will increase as well. This brings us to the next question..
3. How do we handle scalability?
Thinking now about system utilization 6 months down the road is a great approach to this question. Having a virtual environment (VMs are supported) for your interface servers to reside on, gives you the flexibility to increase resources rapidly and at low cost. If a virtual environment is not a possibility right now, creating servers that exceed the minimums by 1 level is a safe bet. Utilizing expandable storage options will allow you to tweak message retention policies without worrying about exceeding resources.
4. What are our team resources?
Considering your team members as a resource, much like your servers, you need to ask yourself whether or not you have the people in place to handle a far more granular, robust approach to interfaces. Having one person with all the knowledge creates a single point of failure that you’ll want to avoid. Use the transition as a teaching/learning opportunity to bring other team members(s) up to speed.
5. When do we make the switch?
While there’s currently no date set in stone for Allscripts to stop supporting ConnectR, the time is approaching. Getting an early start will lessen the potential for mistakes due to being rushed. If you have the resources available, creating your new Rhapsody environment while still using ConnectR and then switching over interfaces one at a time will allow you to make sure each interface is working correctly before moving onto the next.
6. What should we be testing and how?
Outlining a solid test plan before the project commences will not only help you avoid missing any potential issues, but will also help you decide your timeline and checkpoints. Rhapsody’s EDI Explorer, part of the EDI Toolset, is a great tool to utilize for testing and design. Testing should include every aspect of the interface from source system to target system. This means testing connectivity, message definitions, scripting, lookup tables, routing, mapping and everything in-between….twice.
7. How do we handle system security?
Since the security setup in Rhapsody is more granular than it is in ConnectR, simply transferring existing security schemes will most likely end up being either too restrictive or too loose. Decide who will be handling what functions and remember that more tedious tasks, such as bridging, can now be handled from within Touchworks using the reconciler. Monitoring can now be handled from the web-interface without access to the IDE. Both of these changes allow for task delegation without worrying about security issues.
To summarize, handling a ConnectR to Rhapsody transition is much like any other major project. Timelines and scope need to be established, test plans need to be outlined and training needs to be performed. Having a solid grasp on both the system and team resources that you’ll need to meet these requirements is key to completing a successful project and building a robust, dependable interface system.
800 West Cummings Park, Suite 6000, Woburn MA 01801 Tel 781.935.1002