Month: September 2012

Spreadsheet Hell

Click here for more information

Jack O'Lantern hell
photo by Logan Ingalls

When it comes to relying on spreadsheets for day-to-day business, that old idiom, “better the devil you know, than the devil you don’t”, seems to be the orthodox mantra. Numerous studies indicate that more than 70% of organizations repeat the mantra of using spreadsheets as their daily financial information bread and butter — despite the fact that spreadsheets can quickly be outgrown and can become onerous task masters.

In one 2004 survey by CFO Research Services, respondents across the board (>60%) reported that they spend too much time on forecasting, budgeting, and planning — time spent inside their beloved, yet despised, spreadsheets. 43% reported that they don’t have enough time to analyze the data that they have collected.

Earlier this year, Oracle and Accenture commissioned a research study on the challenges of corporate financial reporting with input from more than 1,100 large organizations across the US, Europe, Middle East and Africa. More than 60% reported inadequate visibility into financial data. More than 80% say it is difficult to control the quality of financial data and other supporting information. Yet, spreadsheets and email are still used by more than 68% of these respondents to track and manage reporting.

CULPRITS

What are some of the culprits for this disconnect between current methods of sharing data and with controlling quality?

The CFO study found that the biggest problem was over dependence on key personnel (nearly 50 % of respondents). These people are overburdened. And from a corporate memory perspective, the organization might have too many mission critical processes trapped in too few personnel minds — risking business disruption if those key personnel no longer can perform their duties.

More than 35% of the CFO study respondents reported that version control was their biggest problem. Too many different versions of similar Excel spreadsheet data are floating around in that corporate mindspace of file shares and email. User collaboration and data consolidation are related to this same version control issue — another 35% of respondents reported these as problematic.

Complexity is another bugaboo. Just because you are capable of doing something does not mean that it is a good idea. We have clients who have come to us with Excel workbooks containing hundreds of worksheets, drowning their users in unmanageable and unresponsive data. Just because Excel can hold hundreds of worksheets does not mean that you should base your reporting infrastructure on that ability. Why, there’s even a Tetris game created within Excel, to add to the absurd lengths some people will go to stay wed to spreadsheets.

Spreadsheet Data Model
Photo by Ivan Walsh

Are you drowning in spreadsheets and need a lifeline? Give us a call.

Avoiding the Wall of Shame: Protect PHI

Click here for more information

obelisk
Photo by archer10 (Dennis)

In one of our previous posts, we said that step one in avoiding the “wall of shame” is to identify any Protected Health Information, or PHI, that your organization may have.

Step two is to protect those PHI elements, rendering them unusable, unreadable, or indecipherable to unauthorized individuals.

Isolation of PHI can be multifaceted. First ask yourself, “Do we really need to collect this? Why?” You might be surprised to learn that the real answer is “No”. One method of isolation may be not collecting the data at all.

For those instances where the PHI must be collected, you need to utilize encryption — likely multiple modes of encryption depending upon whether the data is at rest (within a database and/or on computer media), or is in motion (moving between computers). The National Institute of Standards and Technology (NIST) has guidelines that can be used as a starting discussion point for data that is at rest, and for data that is in motion.

You can also come up with a consistent method of sharing de-identified equivalents by removal of information which links medical information to a particular individual. Using a patient chart ID, for example, might sufficiently identify a record without needing to use the patient’s name and address.

You might find that for the majority of occasions where the PHI is really not needed for the task at hand, then de-identified substitutes can be used. While coming up with these equivalents, ask yourself again if the de-identified element alone is enough for all of the tasks without having to collect the actual PHI behind it.

For example, we have clients who regularly need to share lab data (CD4, HIV Viral Load, etc.) among healthcare providers. Some of this same data must also be shared with government entities charged with tracking disease progression, statistics, and outbreaks. The community-based organizations (CBO) may need a way to verify individuals to whom they provide care, while the government entities may only need to know some basic demographic data about the individual (while still isolating each individual).

For the CBOs, we might use a de-identified client code comprised of a few letters of their first and last name in combination with the individual’s date of birth and gender. The CBOs could then use an agreed upon method of comparing that client code against physical identification that the individual provides at the time they receive services — maybe requiring the individual show a government issued ID.

For the government entities who need the lab information, we might just associate some auto-incremented serial number with those same individuals when the lab and demographic information are passed along.

The key to PHI isolation and protection here is to identify those elements that must be collected, identify with whom to share those elements, and identify what form that sharing takes place.

Need help clarifying, isolating and protecting your PHI data? Give us a call.