Gregory Maciag

Healthcare Data Standards

A 2004 introduction to healthcare data standards is available as part of the book Patient Safety: Achieving a New Standard for Care, which you can read online or download as a PDF. The relevant chapter is number 4, which starts, at page 127, like this:

“Data standards are the principal informatics component necessary for information flow through the national health information infrastructure. With common standards, clinical and patient safety systems can share an integrated information infrastructure whereby data are collected and reused for multiple purposes to meet more efficiently the broad scope of data collection and reporting requirements. Common data standards also support effective assimilation of new knowledge into decision support tools, such as an alert of a new drug contraindication, and refinements to the care process.”

This would serve as a template for a description of the role of data standards in any sector. Change the healthcare-specific terms to equivalents in your own domain, and you have the base case for standards.

Healthcare standards have moved on since 2004, but the role of standards remains the same. But how many handbooks on the key topics in other industries feature standards in such a prominent way? If you know of any, let me know.

Meanwhile, the web serves to keep people informed about data standards on a day-to-day basis. Take a look at CommonDataHub (CDH), “the global repository for commonly used data standards such as ISO codes and industry code sets. CDH consolidates data sets from multiple sources, provides additional attributes in some cases, and maps related code sets to provide a complete picture of a subject area”. 

National Academies

Common Data Hub

Inconsistent Data is the New Normal

Should we stand for bad data? I don’t think so. Elliot King thinks otherwise. He believes “data errors are intrinsic to IT’s DNA” and we have to live with them.

I don’t see why we should give up so easily. Wrong is wrong. If you make a bad decision based on wrong data, you can’t just shrug it off. The fact there’s a lot of bad data out there isn’t a reason for accepting the status quo. 

I think King also slides too easily from issues of quantity to conclusions about quality: “It seems pretty obvious that the more data you collect, the more mistakes will be embedded in the data.” Well, no, it’s not obvious to me. I guess if you do something badly, then doing it a lot will add up to a lot of badness. But it’s up to us if we accept poor quality data as a given.

King also says: “The main driver of big data is unstructured information and almost by definition, unstructured information is inexact...” By definition, unstructured data is unstructured. It’s not inexact. A photo of a face is unstructured data, but it’s not inexact.  

What’s the oldest saying in IT? Garbage in, garbage out. Errors have been being rejected by “IT’s DNA” since the first programmer squished the first bug. King finishes by saying “data quality efforts have to be consistent and ongoing”. I agree. But I believe data quality is everybody’s business. Ensure data quality when it enters the system. Don’t encourage poor data habits with the idea that data personnel will be able to clean it up down the line. That’s a recipe for disaster.   Melissa Data

Sewing with Data

The sewing machine has arguably had a bigger impact on the way we live than computers – though not as much as the domestic washing machine. Now, according to an article in the Wall Street Journal, industrial sewing machines are getting connected, bringing the garment industry up to speed with the rest of so-called “fast retail”.

With a traditional sewing machine, operators control the machine with pedals and switches. They fix problems through their own knowledge or by calling for help. Changing stitch and material types is slow and complicated, because it's all about human communication and coordination.

Link sewing machines to computers and you get something more like modern automated factory production familiar in, for example, car construction. The network can take basic control of individual machines, freeing operators to do more complex operations. Problems can be flagged on a LCD display along with videos showing the fix. Also, retooling for short runs is much easier.

One New Jersey factory installed the technology nine months ago and has experienced a 25% jump in orders. Impressive. Imagine also the data which managers of such factories are going to have at their disposal. They'll be able to understand their own business so much better.  Wall Street Journal

Patient Data

The healthcare sector is considering how to include patient-input data in electronic health records (EHRs). The idea is to use existing document standards.

Seems obvious enough. We should think of patient input as a kind of form-filling. Items on forms need to be standardized and verifiable. They need to be recognized by collaborating systems.

I guess that in the future large amounts of patient data will be automatically generated and delivered to analysis and workflow systems by personal devices. Various health factors will be monitored and relayed without our ever having to look at the readings, let alone transcribe them into a system.

Patient-input can be presented as patient empowerment. But it's also about downstreaming work. The more the customer does, the less clerking the organization has to do. That's been one side of self-service from the supermarket through the ATM and beyond.

The difference (an difficulty) here may be about nuances. In order to allow a patient to enter, say, symptoms, we'll need to present them with a set of possible symptoms to check. This may encourage people to check more symptoms than they would have done unprompted. It will also mean that the degree to which the symptom itself is causing distress will be masked, meaning that a piece of potentially important data is lost. Call it the light and shadow – the subtleties of human communication that physicians use in the diagnostic process. So maybe patient input will be limited to basic items rather than nuanced ones.  EHR

Is Data the New Oil?

A piece about Scottish policy on data standards mentions how “futurist thinkers see data as the new oil”. As North Sea oil has long been a touchstone in discussions of Scotland's potential wealth as an independent nation, this implies quite a big claim. However, Dermot Joyce's article goes on to give examples of how data standards can improve efficiency and effectiveness in public services.

This is an anti-climax. For a minute, I thought Scottish data would somehow prove to be a great export, like malt whisky. Actually, the only “national” data set I can think of with potential commercial uses is the Icelandic genome. The article does not have much to say about how nationally applied data standards could aid the software or services industries of the nation which promotes them.

But I'd like to switch things around a little. Data may not necessarily be oil; but data standards are oil. Not the kind of oil you burn, but the oil you use to lubricate mechanisms. If, as the economist Ronald Coase said, inefficiencies like information search costs are the sand in the engine, then data standards are the engine oil.

Sure, data standards are absolutely vital to modern public services. They are also key to the development of knowledge industries. If you own or create potentially valuable data, then data standards will make that data usable. But just having data standards doesn't mean you automatically have data that's valuable to anyone else. It doesn't work that way.

Oil is oil. Data is what you make of it.

Meanwhile in Qatar, a railroad engineering software company is helping to build the Qatar Building Information Modelling (QBIM). All the data generated in its studies will be handed over to the customer and used to help populate this model. The engineers “hope they [the Qataris] create a neutral standard”. If they do, then they will really have created an important national asset.  Data Smart Nation

City Data - Open Standards

Several major cities are moving forward with open data. Open data is getting to be a catchphrase in government. It's all about getting information out to citizens, in the interests of transparency and accountability. But opening up data goes hand in hand with choosing data standards. Naturally, these city authorities are also looking to open standards.

Andrea Reimer, a city councillor at Vancouver, which decided for open data in 2009, was reported as saying: “The local online community was all very, very happy, and now we just have to look forward on implementation and figuring sort of the order with which we do that.” Is there a hint here that maybe the way ahead was a little fuzzy? I guess a councillor doesn't need to have a view on the implementation details. The city's staff will be able to figure this out.

Now San Francisco is to hire an open data officer. Every city department will also nominate someone responsible for open data, and common data standards will be established. Perhaps it's just the way this news has been reported, but there's a feeling here that standards are being tacked on as an afterthought. Also, there's an assumption that open standards are available to cover all this data.

I think there may be some more work to do here. I'd love to think existing open standards are going to be up to the job. But I'm struggling to identify those open standards. I hope the leading cities, by working together to share the load, will fill the gaps they are bound to find. It would be a tragedy if we see a proliferation of incompatible standards.

Does it matter? I think so. First, there's the unnecessary cost of developing different standards. Second, there's the matter of comparison. A citizen of one city should be able to compare services, costs, priorities, outcomes and quality with those of another city. In this context, IBM's City Forward initiative looks interesting.

Vancouver

San Francisco

City Forward

Value and Volume

Which homeowner problem leads to the most insurance claims?

If you said “fire”, you'd be wrong. True, fire is responsible for the largest payouts. But not for the largest number of claims. This honor goes to wind and hail damage. Fire isn't even third in line in the numerical claims stakes – that place goes to water damage and freezing.

 Findings like this remind us that good data give us a better handle on our business than gut reaction. The story also reinforces the point that information systems have to serve business processes rather than headline dollar amounts. It might feel wrong, but perhaps your organization is better off investing in systems, processes and people that support the high volume business rather than the rarer, big ticket events. You don't know until you measure.  Claims

The Fourth "V"

Kudos to Mark Banks of AIR Worldwide, who added a fourth “V” to a trio of definitional attributes pertaining to big data. Contributing to a lively panel at ITC 2012, he added Validity to Volume, Variety and Velocity.

This is an important addition, because we need to make a distinction between having-lots-of-stuff and having-lots-of-useful-stuff. I sometimes get flashbacks to the heyday of data warehousing when I hear some people talk about big data. There's this magical thinking that creeps in and encourages us to believe quantity alone is somehow going to deliver quality.

Yes, big data enables us to discover new patterns. It enables us to react quicker and smarter. But only when the data is valid. It's only if we're certain what data items mean, and how they relate to each other, that we can do any useful work with them.

Banks also remarked that big data has always been ingrained in risk modeling. I'd take this a step further and say the kind of analysis people in other industries are now undertaking with big data is learned from insurance industry practices. Mainstream business is catching up with the core competencies of insurance as they gain the tools to better understand behavior.

Value of Verification: Is This Happening To You?

One speaker at ITC 2012 in London spoke of how the false economies of an earlier systems decision came to light during a subsequent data migration exercise. It seems the performance of an underwriting system had been speeded up by disabling its validation. This simple intervention improved performance by 20%, at no cost. Even better, underwriters using the system found they could put whatever they wanted in its fields. Instead of asking the IT team for enhancements to cope with new data items, they simply bent existing fields to new uses. This meant everyone was even happier, not only was the system faster, but development costs went down.

Two or three years later and the need for data migration after integration exposes the folly of this decision. The systems' fields were filled with disparate data that was hard to interpret. Dispensing with quality control brought apparent short-term benefits but created massive problems further down the line.

The company concerned dealt with the problem, bringing its systems discipline back in line and insisting on validation – and thereby data quality. The speaker went on to say that organizations across the industry must hold themselves responsible for the quality of the data they send each other and not try to offload the responsibility on to intermediate handlers of the data. Whatever you do inside the organization may be okay, bit at the interfaces you must have the discipline of standards.

It's interesting that the time delay between the poor decision to unhook validation and the integration blow-up was short – only a couple of years. Since people don't often share war stories like this, you might think data quality issues like this are only relevant to aged systems. But it seems that, perhaps under the pressure to perform cost miracles, and with a lack of direction about the value of data assets, IT folks can use the kinds of strategies we associate with an era of less frequent change and more expensive storage costs.

More important is the message that data quality is today more likely to be a concern of the business than the IT professional. After all, we migrate data because it's of interest to the business, not for the  sheer fun of it. We capture data because it's fundamental to the business – at the end of the day, it is the business.

We need to educate our IT colleagues on the value of data. It's not just “content”. Or rather, “content” is more valuable than such a generic term suggests. This data we generate, store, modify and share is the stuff of business.

Identifier Failure Proves Costly

I like to collect figures relating to the benefits of standards. Sometimes these figures are like tiny case studies. Other times, they just make you go “wow”.  

Hudson Hollister of the Data Transparency Coalition gives an example of how the lack of standard identifiers can waste time, effort, and enormous amounts of money. If federal loan assessors had been able to match SEC reports on solar panels start-up Solyndra, it's unlikely the company would have got its $527m in federal loan guarantees – before filing for bankruptcy just two years later.  If only complex organizations knew what they know.

Data Informed

Data for Action

“It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

Information management expert Rob Johnson uses this quote from Sherlock Holmes to remind us that “even today decision makers need all the evidence before taking action or enacting policy. Information managers need to stress that information is a business asset just like the buildings, the IT equipment or the people. What you create may be useful to others down the line, but if it’s locked away in a personal drive or labelled incorrectly the potential value is diminished”.

We need a general change in attitudes, so that people think about the wider value of the information they are generating and processing. It's on all of us to realize that what we do with information may be part of a much bigger picture that we can't see – or that hasn't yet come into being,

By the way, Sherlock’s use of the word “capital” means “punishable by the death penalty”. I don't think we can really implement that. National Archives UK

Digital Through and Through

Digitisation is not just about customer acquisition and service. It is also about leveraging the power of data and transforming internal processes, which are ultimately the engines that drive organizational behavior.

Read more from our September Tech Focus Page in Insurance Day.  Download ID 2012-09 Tech Focus

 

Reference Data Management

Code tables are crucial. Keeping versions of inhouse and industry standard code tables up to date and consistent across the organization can be a maintenance headache. IBM have a good, clear process for keeping on top of this vital function. They call it Reference Data Management and it makes a lot of sense.

Bridging Data Divide

Cost of Poor Data Management

Experian notes an important cost of poor data management that is usually overlooked: distracted management attention. It's well known that poor data management can result in poor decisions, but it's less widely appreciated that it can also undermine decision timelines and distort the scope of decisions. (These are my terms, by the way, which I offer in addition to the comments in the Experian piece.)

I wonder also if we've become too comfortable with the idea of information overload. Since we all know there's lots and lots of data washing around our world, no one's going to yell at us if we're not on top of it. Being distracted by data issues is an acceptable form of distraction. I'm not saying that anyone consciously treats data management as a scapegoat in this way, but nevertheless it happens.

We have to remember that it's not data we need, it's relevant data. Data management is the discipline that specializes in relevance.  Cost

Big Data v Lot's of Data

It's a small word, but it's being misused. What does the “big” in big data mean?

Figures similar to the following are coming to a slide show near you: “It has been estimated that Wal-Mart records more than 1 million customer transactions each hour, resulting in more than 2.5 petabytes of data being stored, the equivalent of 167 times the data stored in the Library of Congress. Facebook is reported to store 40 billion photographs. And an estimated 35 hours of video content is uploaded to YouTube every minute.”

This is interesting stuff, but it mixes apples and oranges. WalMart cranks out a lot of data – but it's structured data. We're talking about a lot of small things. But pictures and video are another matter. These are large, unstructured data objects – what I'd call genuine big data.

Genuine big data poses novel problems of interpretation and combination. Pseudo big data – that is, large transaction volumes – might tax the processing capabilities of traditional databases, but it doesn't challenge the analysis model in the same way as unstructured data does.

So, when someone raises the problems of big data, it's worth asking whether they're talking about high volumes of structured data, unstructured data, or both. These are different topics and they call for different strategies.  Big Data

 

Data is a Boardroom Issue

Colin Rickard sees Solvency II as a crucial opportunity for the European insurance industry to get its data management house in order:

“As a veteran of the data management industry, I have witnessed organizations across different sectors grapple with the challenge of ensuring high quality business data, but never before have I seen such a direct regulatory mandate for board level supervision of data. This is an opportunity, not a threat.

Data and IT professionals within insurance companies have been presented with the foundation for a business case to tackle the long-term data problems the industry has faced. Data is now a boardroom issue and that necessitates investment, KPIs and ongoing governance.”  Colin Rickard

Data Quality is a Business Issue

How much does poor data quality cost business? There's no doubt that acting on information that is wrong or missing can lead to process failure or revenue loss. Events of this type tend to be the ones that draw attention to data quality issues. However, there are types of failures and losses stemming from lack of action based on faulty or absent information that are less noticeable. These types of event are only recognized with hindsight. But while it may be easy to categorize types of data quality costs, it's much harder to quantify them.

David Loshin, author of a 2010 book on data quality, has a blog post that rounds up various estimates of data quality costs.  He finds quoted figures ranging from 8% to 35% of operating revenue. These figures span the time period 1998 to 2009. Loshin tentatively concludes that the perceived costs of poor data quality are rising, but he also calls for more hard research to be published so that those of us who care about business information can get a better picture.

The impact of poor data quality is ultimately, like everything else, measurable. If it wasn't measurable, then it wouldn't matter. I suspect the official reason why companies don't target this metric is the difficulty of separating out the contribution of data quality from other factors in a failure or loss. I'm pretty sure the unofficial reason is that people find it hard enough to nurture a quality culture around visible and tangible quantities; asking them to consider the impact of invisible, abstract entities seems like going too far.

I think we can tackle the first objection to measuring data quality by insisting that three questions are embedded in every business decision point:

1: What items of information are used in making this decision?

2: What is the acceptable tolerance for error in each item?

3: What is the net acceptable tolerance for error in this collection of items?

Question 1 may seem obvious, and it's the basic stuff of systems development. However, not all the information consumed in a decision process is captured in systems designs. These is increasingly the case as data from emails or web sites are used.

Question 2 is harder to answer. Answering it implies providing a business value for business data. The IT profession has long talked about data as an asset. This question takes that rhetoric seriously.

And Question 3 is what I guess we can call – taking inflation into account and considering the interconnectedness of today's businesses – the sixty-four trillion dollar question.

Certain combinations of data items have net values different than simple addition. Some data collections have the effect of reducing risk. In insurance, for example, the more you know about an insurable item, the more accurate your rating will be. On the other hand, some data collections generate additional uncertainty. This is particularly true of speculative data sets, such as customer behavior models. I know from experience that getting a solid answer to Question 1 in the most prominent parts of an enterprise is pretty hard.

Applying Question 1 right across the businesses is even harder – and harder to justify, even though it's often the peripheral parts of a business that trigger catastrophic failure through incidents of poor data governance. Yet rolling out Question 1 is achievable. We know how to do it. I suggest that we don't really know how to even pose Questions 2 and 3, let alone answer them.

I say “tolerance for error”, but I don't know what units that tolerance is measured in. Is it a unit derived from the data type itself? Is it a standard corporately defined unit? Whatever the units are, they have to be convertible into cash.  I don't think we see enough discussion of these issues.

The good news is that we have IDMA (Insurance Data Management Association) (IDMA Home Page), the organization for data management professionals. Members of IDMA are dedicated to addressing data governanace and management issues.  We need more atttention paid to data. Take a look at their website, get involved.  Also see the blog from  David Loshin