Patient Panel Analytics

In a recent interview with a provider about how to gain some efficiencies in her practice, I asked how many patients she was caring for with a diagnosis of cancer in the past few years. After a “from the hip” answer, I showed her a report from one of her payers, and she became frustrated that the payer had a better summary of her patients than she could obtain from her own EHR.

Healthcare providers and management need to be empowered with tools to analyze information about their practice in which much effort is spent creating the data.

This podcast will demonstrate our Accountable Care Analytics Application’s ability to define patient panels and provide integrated summaries of patient information from clinical and claims data sources.

Accountable Care Analytics: A data-driven approach to achieving value-based healthcare

Edgewater’s Accountable Care Analytics application is comprehensive set of data integration and business intelligence capabilities for use by clinical, financial, and care management professionals that empower organizations to improve quality and reduce costs across a spectrum of care delivery settings.  The application streamlines many of the labor-intensive aspects of capturing and reporting quality and financial performance of accountable care, alternative quality contract, and similar risk-based arrangements operating in healthcare today.  It achieves this by enabling healthcare providers to take a data-driven approach to understanding the impact of quality, cost and outcomes on performance across the extended ACO enterprise.

In this podcast, Edgewater provides a high level overview of the Accountable Care Analytics application.

time flying

Avoid these Top Ten Mistakes when Transitioning to the Cloud

Time and again, organizations erode potential benefits of a cloud transition. More thought on the front end can help you achieve a shorter time to value.

  1. Not thinking through your SLA requirements.  Your SLA needs should be part of your RFP or RFI, based on your internal business priorities. Many companies, when taking their first steps into the cloud, accept the SLA’s offered by the vendor in the first contract draft.
  2. Failing to model total cost of cloud and on-premise options:  Apples to apples comparisons are hard to find in the cloud world.
  3. Failing to ask potential vendors (and the references you will be checking) how long it takes to:
    • Get contract redlines turned around
    • Get from a handshake to implementation-boots-on-the-ground
  4. Not thinking through support processes, roles and responsibilities. As more assets are moved into the hands of multiple cloud vendors, it’s important to document crystal clarity of responsibilities, accountabilities, and notification/approval policies. The best way to do this is to construct a RACI matrix.
  5. Under preparation for testing:  Do you have a formal QA methodology? Do you have a body of test scripts prepared for the deployment?  What about performance testing and integration testing?  Don’t let test planning and preparation impose a drag on the implementation timeline. Look before you leap, or you may be disappointed by poor performance or failing interfaces down the road.
  6. Under thinking security: What are the liabilities? Did you stipulate access for annual security testing in the contract?
  7. Rushing forward without an enterprise cloud strategy: Proliferation of departmental cloud applications has taken much of the decision-making out of IT’s hands. A cloud approach that grows up organically can result in compromised information security and lack of critical integration between applications.
  8. Failing to manage end user expectations: Have you documented and communicated the changes adequately?
  9. Overestimating your in-house IT skills:
    • Does your team really have the systems integration knowledge and experience with the cloud to take your critical business apps through the transition?
    • Overestimating your in-house skillset
  10. Underestimating bandwidth requirements: Your “big pipe” locations are one issue, but do you understand how much work really gets done by remote workers? Will they see adequate performance from the cloud? How will additional bandwidth affect your cost model?

ACO Disease Specific Analytics

“What can Edgewater’s Accountable Care Analytics do for me that we cannot already do with our EHR and patient financials reporting?”

To be successful, ACOs and other integrated health systems must bring together both clinical and claims data – and they must make the data available for use by clinical, operational and financial leadership across the entire organization.  The biggest challenge our clients face is an ability to provide management this data now, to drive early operational decisions. This is what Edgewater’s Accountable Care Analytics can do – provide organization-wide dashboards for decision support in advance of the complex and time consuming integration projects these health systems face.

This podcast shows a quick demonstration of the capabilities our ACA application.

Edgewater Healthcare Analytics

I recently read an article called “The 4 Biggest Obstacles ACOs Face” on Forbes.com that I found really interesting. In it, the author identifies what I think are the primary challenges for Accountable Care Organizations (ACO). But, I would change the order.

ACOs need a management structure in place to make critical operational decisions. But those decisions should be made leveraging enterprise wide data. So, the primary challenge for ACOs — Providing management with accurate, actionable data to make management decisions, before all of the technical integration challenges have been addressed.

To learn more about Edgewater’s Accountable Care Analytics application, and how it can help you get meaningful data to ACO decision makers, email us.

Edgewater Consulting blog

Technical How-to: Redirecting SSLv3 Users to a POODLE warning page using Apache2 mod_rewrite

The Padding Oracle On Downgraded Legacy Encryption (POODLE) vulnerability has been making headlines since September 2014. There are a few options for mitigating the risk, but our infrastructure team has found that not all organizations are able and willing to implement them. Disabling SSLv3 entirely can cut users off from secure websites they rely on, and Google’s TLS_FALLBACK_SCSV mechanism requires support from the web browser, and has not been implemented server-side by all distributions, especially on older and unsupported versions. Further, TLS_FALLBACK_SCSV does not address the issue of SSLv3 support itself, rather it prevents devices which support TLS from downgrading connections to SSLv3. It does not help in cases where the browser is Internet Explorer Versions 1 through 6 (although Internet Explorer versions 4 through 6 can be configured to enable TLS.)

A more elegant solution is not to block SSLv3, but to instead warn users that their current browser is vulnerable to known attacks and instruct them on how to upgrade. With Apache2 and mod_rewrite, it is possible to redirect SSLv3 connections to such a warning page and advise users of the issue and how to resolve it. Here are the steps to do so:

  1. Prepare or find an explanation page you wish to redirect insecure SSL sessions to and note the URL.
  2. If you run a reverse proxy, load balancer, or other session layer device between your apache server(s) and the Internet, please be aware that those devices may be vulnerable to POODLE even though they support TLS: http://www.computerworld.com.au/article/561828/poodle-flaw-returns-time-hitting-tls-security-protocol/
    To be sure that your entire chain of TLS implementations is secure, temporarily disable SSLv3 in apache2 and head over to SSL Labs to test your site. If your TLS chain is vulnerable you should receive a grade of “F” with a warning (emphasis ours:) “This server is vulnerable to the POODLE attack against TLS servers.” If you receive this warning, you should contact your vendors and request patches.
  3. Make sure that Apache2’s mod_rewrite has been installed on your system. Apache2 runs on a variety of architectures and operating systems, so installing individual Apache2 modules is beyond the scope of this article.
  4. Make sure that Apache2’s mod_rewrite is enabled. To do this, run the following as root/administrator:
    a2enmod rewrite
  5. Add the following lines, without the line numbers, to your Apache2 HTTPS site configurations, changing http://yourwebsite.com/yourexplanationpage.html to the explanation page you wish to redirect users to:
    1. #POODLE REDIRECT CONFIG–
    2. SSLOptions +StdEnvVars
    3. RewriteEngine On
    4. RewriteCond %{ENV:SSL_PROTOCOL} ^SSLv[2-3]$ [NC]
    5. RewriteRule ^.*$                    http://yourwebsite.com/yourexplanationpage.html
    6. #END POODLE REDIRECT CONFIG–
  6. If you have disabled SSLv3 already, undo the configuration disabling it.
  7. Restart Apache2
  8. Now test, test, and then test some more! You can use Firefox and enable/disable SSLv3. To force an SSLv3 connection set both security.tls.version.min & security.tls.version.max to 0. To disable SSLv3 in Firefox set security.tls.version.min to 1 or higher and set security.tls.version.max greater than or equal to security.tls.version.min
blended project management

Have you tried to blend agile methodologies into your traditional waterfall world?

Did you get a tasty stew?

….Or a culinary disaster?

I like to cook, but I’m not exactly a purist.  By that I mean that I almost never follow a recipe exactly.  Instead I treat a recipe as more of a guide.  Sometimes I omit ingredients that my family doesn’t like; other times I add in ingredients to see what the affect will be. I often combine a couple of recipes together, mixing and blending ideas from several sources.  Sometimes the result is a wonderful creation that suits the tastes of my family.  Other times, we take a bite and reach for the pile of take-out menus.

I find myself taking the same approach to development methodologies.  Like most of you, I find traditional, waterfall methodologies to be too rigid, too slow, and too removed from reality.  Their assumption that everything about a project can be known and documented up front has always struck me as laughable.

But when I look at pure agile methodologies, I find them too rigid and idealistic as well.  Successful projects need a framework around them; they can’t be driven simply by empowering a team to prioritize a backlog and deliver chunks of code.  Project components need to be fit into a larger vision and architecture; organizations need to have a sense of scope, plan, and budget.  Large, complex systems can’t always be nicely packaged in 2 or 3 week sprints.

So I find myself mixing and blending.  Take a few waterfall concepts like a defined project scope, written business requirements, defined technical architecture, and a project plan.  Blend with an agile development window where the project team can work through detailed requirements, development, and testing together; shifting priorities as business needs change.  Garnish with some user testing, training, and release planning.

Maybe this is agile book-ended by just enough waterfall to frame the work that the agile teams will take-on and integrate their work with the organization’s larger planning processes.  Maybe this is diluting agile precepts by subjugating them to overreaching controls.  Some call these approaches “waterscrumfall”; some call them an abomination.

My experience (and the experience of at least one of my colleagues) has been that a pragmatic blending better suits the needs of most projects and most organizations. It creates just enough structure to tame the chaos while recognizing that projects can’t be and shouldn’t be totally defined up-front.  It ensures that project deliverables fit into the larger enterprise architecture and meet strategic objectives.  Yet it takes advantage of the agile team’s strengths, allowing them to drive the project’s pace and details.

What has your experience been?  Have you tried more blended approaches?  Have they been successful?  Or have they resulted in the equivalent of a culinary disaster?

Chinese_character_採_cai3_pick

Just Pick 3

Fast away the old year passes, as the song goes.

It’s that introspective time when we all review the victories and defeats of the last twelve months and come up with a list of resolutions.

How long was your list last year?
How many of those goals did you attain?
Did you come out of the gate in January with a bang, and light a fire under 10 or more action plans, or did you attack your list in a prioritized sequence?
How did that work out for you?

In any year where I made a lengthy list, I ended up frustrated before February rolled around, and never looked at my list again. I just couldn’t achieve the progress I envisioned.

This year, I am going to do something different, and I think you should too.

By January 1, I will pick 3 areas to focus on in my work and personal resolutions. When I have achieved the desired results there I will pick 3 more.

The best way to do this is to pick 3 goals phrased as metrics you can measure.

Start your list. What do you want to change? How will you measure it?

Decide what is  most important.

Then, just pick 3.

homer_simpson_doh_02

Does your PMO get in the way of your Agile Development Teams?

Do your agile teams have your PMO pulling their collective hair out in frustration?

A family in harmony will prosper in everything. ~ Chinese Proverb

Does this sound familiar:

We value face-to-face conversation We need formal, written documents
Working software is our primary measure of progress Where is your status report?
How are you progressing against your project plan?
Self-Organizing Teams Defined Roles and Responsibilities
Individuals and Interactions Processes and Tools
Respond to Change Follow a Plan
Culture of Change Culture of Order

You’ve embraced an agile development methodology, empowered your teams, and they are eager to move forward.  They want to deliver a quality product to the organization as quickly as possible.  They want to add value and make a difference.

Your project management office (PMO) understands and supports the agile development approach, but they still need to manage the overall project portfolio and they want to be sure that the agile teams deliver in alignment with the organization’s strategic objectives.  They want to add value and make a difference.

Both groups have the organization’s best interests in mind, but there is a definite culture clash.

Agile teams can be dismissive of the PMO. Their approach is different, they don’t need to worry about those processes and frameworks; they just need to focus on their own project.  The PMO should get out of their way.  It reminds me of a teenager who wants their parents to just leave them alone – until the parent is needed.

PMOs can act like a dictatorial parent.  They can demand process and procedure from agile teams because that is what they’ve always done.  But process and procedure that doesn’t add value does get in the way.

Both groups need to respect each other and adapt.

Just like the parent of a teenager, the PMO should be loosening the rules and allowing greater freedom while demanding accountability (and standing by with a safety net). The PMO has to adapt itself to the agile world,  working with the agile teams to understand the tools that they are using to manage and control the agile project.  It should adapt these tools to their use rather than making the agile team use the same old PMO provided reports and templates.

The agile team, like the teenager, also needs to acknowledge and respect the role of the PMO.  The project and the project team aren’t operating in a vacuum.  It needs to fit into the larger organizational plan and processes.  So the agile team needs to fit itself into the framework that the PMO has established.  That may mean complying with certain project checkpoints or processes, such as conducting a formal risk analysis or establishing a milestone-level, project plan, budget, and scope.

If each can recognize that the other is not purposely trying to obstruct them and understand the value of the other to the organization, they should be able to leverage on another’s strengths.  While there may still be friction and areas of disagreement, the end result should be a set of processes that improve project outcomes and ensure alignment with overall organizational objectives.

Edgewater Consulting blog

Voice of the Customer – Kano Analysis

As a Consultant, I’ve acquired specific preferences when traveling, and learned to adapt behaviors that make these experiences as stress free as possible. For example, at airport security, I try to avoid standing in line behind anyone who is dressed too “casually” or has sun screen as one of the items in their plastic bag. Chances are that they will take twice as long going through security, thus delaying my time to reach my gate/flight. When selecting a hotel, I look for one with a good in-house dining menu. The benefit of coming back to the hotel and enjoying a good meal without having to leave my room is priceless. Also, let’s be honest, it all comes down to points.

The casual traveler might see little value in earning points or priority boarding; however, the business traveler sees great value in these service items.  Not all consumers value the same services and products on the market in the same way and many companies are keen to analyze these trends. To aid in analyzing customer needs, and provide insight into services or products of little importance or that miss Critical to Quality (CTQ) features, companies may want to perform a Six Sigma process based on the Voice of Customer (VOC), called Kano Analysis.

What Does It Do?

Kano Analysis identifies and prioritizes customer needs or requirements by classifying them under key categories, including: basic services a customer expects, services that a customer desires, and services that delight a customer. Below is a summary of categories and definitions (terminology may vary slightly).

Requirement/Need Definition
  • “Must Be”
  • Basic Requirements
  • Dissatisfiers
  • (Expected Quality)
  • Expected features – cannot increase satisfaction
  • Taken for granted, rarely voiced
  • If not fulfilled, customer is extremely dissatisfied
  • “More is Better”
  • Performance Requirements
  • Satisifers
  • (One Dimensional Desired Quality)
  • Linear effect – the more needs are met, the more satisfied
  • Customer is aware that feature is important to them
  • Remain in the market
  • “Delighter”
  • Excitement Requirements
  • Satisifers
  • (Excited Quality)
  • Unexpected feature – impresses customers
  • Delights when present – does not cause dissatisfaction when not present – rarely voiced
  • Leading edge in the marketplace

How To Do It?

Gather as much VOC information as possible (via interviews, focus groups, surveys, etc.) from your customers regarding service or product offerings. Have them classify the requirements / needs under the three categories. Eliminate any requirements that aren’t relevant. The example below shows classifications pertaining to hotel services.

Requirement/Need Definition
  • “Must Be”
  • Basic Requirements
  • Dissatisfiers
  • (Expected Quality)
  • Clean hotel room
  • Reinforced lock
  • Toiletries
  • Towels
  • “More is Better”
  • Performance Requirements
  • Satisifers
  • (One Dimensional Desired Quality)
  • Large work desk
  • Wi-Fi
  • Car service
  • Hair dryer
  • Bed-side outlet
  • On-Demand movies
  • “Delighter”
  • Excitement Requirements
  • Satisifers
  • (Excited Quality)
  • Dimmable lights
  • Heated floors
  • Bottle of wine on birthday
  • Cappuccino machine in room
  • Room access activated via smart phone

It’s important to point out that a customer’s needs / requirements change over time. What was once a “Delighter” could be a “Dissatisfier” nowadays. For example, receiving an invoice (slipped under the hotel room door) used to mean that it wasn’t necessary to wait in line to check out of the hotel. Nowadays, it’s just one more piece of paper to file. Many travelers prefer to automatically receive an electronic copy of the invoice.