In Chapter 1, we defined master data as the data represented by the key enterprise data entities, attributes, and relationships. We defined Master Data Management (MDM) as a discipline that resolves master data to maintain the golden record—a holistic and panoramic view of master entities and relationships, the benchmark for master data that can be used across the enterprise, and sometimes between enterprises, to facilitate data exchanges. Master Data Management applies equally well to any commercial market segment, such as financial services, the healthcare industry, telecommunications, consumer retail, and many others. Moreover, MDM can be beneficial to any public sector business, including government agencies that deal with citizens, employees, tourists, immigration, law enforcement, and others. In other words, using the definitions of master data and MDM as a guide, we showed that Master Data Management is a horizontal discipline and technology that applies to all industries and markets and is global in nature.
In Chapter 2, we discussed the key drivers and challenges that are also mostly horizontal in nature and apply to all industries that face challenges of improving customer service; improving management of their products, servicers, and assets; enhancing the accuracy of reporting and analytics; reducing customer churn and attrition; increasing efficiency of operations; reducing risks; strengthening compliance; and so on. We showed that increasing sales productivity and revenue, improving customer satisfaction, and reducing IT infrastructure costs represent intrinsic MDM properties and thus can be found in MDM implementations for practically every market segment. We also discussed key business, organizational, and technical challenges at a high level.
Although the scope of Master Data Management is extremely broad and includes customers, products, hierarchies, reference data, and other data types and domains, we put a significant focus of the discussions in Part I on the party domain. A focus on the party domain does not make the scope of the discussion smaller. Indeed, customer master (or, more generally, party master) is a requirement for any business-to-consumer (B2C) or government-to-citizen (G2C) organization, which of course is a very broad field. Based on market size, the customer domain is the largest MDM market domain and, hence, deserves the highest level of attention. Many considerations applied to the customer domain are equally applicable to other domains. We are discussing several other non-customer-domain-specific considerations in the context of industry-specific needs.
When dealing with such a large area of MDM coverage, it is important to recognize both the similarities and differences, not only in business and data semantics, but also in the way MDM is viewed and implemented across various industries and government sectors. Therefore, we will look at the MDM requirements, approaches, and challenges that different industries and organizations have to deal with in order to achieve the stated MDM goal of creating an authoritative, accurate, timely, and comprehensive master data resource. Clearly, each industry brings its own set of requirements and challenges that are specific to the industry.
As individuals, we deal with MDM problems in everyday life:
• When we interact with our phone, TV services, or the Internet provider
• When we call a bank or interact with a financial advisor
• When we call a credit card company as a credit card holder to resolve an issue or to apply for a card
• When we call a mortgage servicer or are looking to apply for a mortgage or loan
• When we buy medicine, contact a healthcare provider, are treated in a hospital, or get reimbursed by a health insurance company
• When we shop in a retail store or a supermarket
• When we travel by air, train, or bus
• When we call an insurance company for quotes or a claim
• When we make a hotel reservation or buy a vacation package
• When we send a FedEx or UPS package
• When we interact with social security services, law enforcement, public education, and other government agencies
And this list can grow easily with other examples.
With a lot of commonality across a variety of industry verticals that can benefit from MDM, our MDM overview in Part I of the book would not be complete without a discussion of specific vertical MDM variants and applications. Every company embarking on an MDM project or program is looking to understand what MDM can do specifically for their industry, the adoption of MDM in their industry area of interest, how MDM has been leveraged by their industry competitors, and what MDM would mean for their enterprise business processes, systems, applications, capabilities, competitiveness, and the bottom line. Even though it is practically impossible to provide a comprehensive list of usage scenarios by industry, there is a need to articulate the predominant case studies and scenarios. In order to address this need, in this chapter we focus on several industry verticals to discuss specific case studies as they apply to multiple commercial enterprises and the public sector.
In the sections that follow, we limit the discussion to the following categories and examples of industry sectors and subsectors:
• Services Financial services, telecommunications companies, healthcare, hospitality and the gaming industry
• Products Manufacturing, software publishing, and pharmaceutical companies
• Transportation Airlines, shipping and logistics companies
• Retail sales
• Public sector
Let’s start this discussion with a review of the MDM suitability and usage in various industries of the commercial sector. In this discussion, we focus on the information management needs of a given industry rather than on the interactions/delivery channels and marketing viewpoints, such as those typically found in B2B and B2C models. Although B2B and B2C differ from each other in several ways—including longer sales cycles and more structured, often bi-directional relationships for B2B, and the relatively more dynamic, almost “social” nature of B2C interactions—the similarities between B2B and B2C are meaningful enough to benefit from an MDM solution that creates, maintains, and makes available an accurate, timely, and secure authoritative source of information about customers, service providers, suppliers, products, and other relevant domains.
For the purpose of our discussion, financial services include banks, brokerages, wealth management organizations, credit card companies, mortgage companies, and insurance firms. The financial services industry has been one of the early adopters of MDM concepts and technologies, including MDM Data Hubs. The industry has significant interests in both individual (retail) customers and institutional or commercial organizations. In the previous chapters, we discussed financial services institutions as good illustrative examples of how a customer-facing enterprise can benefit from implementing an MDM solution. Here, we take a more detailed view of the needs of the financial services industry.
Retail financial services institutions (FSIs) such as consumer banks, life insurance companies, and retail brokerage houses have always faced the challenge of dealing with thousands and even millions of their customers and prospects in a highly competitive marketplace. In that respect, these types of FSIs are similar to consumer retail businesses such as Walmart and Sears, and they have been at the forefront of creating and using the concept of a single-customer view. This need to have an accurate and complete customer view is not new—as stated in Chapter 1, MDM precursors designed to create a single-customer view included Customer Information Files (CIF), Enterprise Data Warehouses (EDW), and Operational Data Stores (ODS). Financial services organizations were some of the first companies to pioneer and effectively use customer analytics, data mining, and multichannel CRM systems to better understand customer behavior and the factors enforcing customers’ brand loyalty, propensity to buy, and reasons for customer attrition. Today, financial services institutions embark on MDM initiatives to overcome the inefficiencies and limitations of CIF and other MDM precursors and to collect, manage, and analyze hundreds of financial metrics that heavily rely on the accuracy, consistency, and timeliness of corporate reference data and various views of corporate hierarchies. In addition to managing financial metrics, modern MDM initiatives enable the delivery of accurate, cross-channel-integrated, and current customer information to the point of sales, service, or online channel in a timely fashion to have an impact on the outcome of a customer transaction.
Financial services organizations servicing retail customers do not limit the scope of the solution on individual customers and prospects. The party model for financial services organizations is typically complex and comprehensive in order to address the enterprise’s needs for customer relationships and customer and account groupings. Consequently, in addition to individual customers, the party model oftentimes includes formal and informal organizational entities such as mutual funds, informal investment groups or clubs, associations, trusts, estates, tax groups, and other entities representing more than one customer. Wealth management and financial advisory organizations often operate as multiple financial advisory teams serving their customers under the umbrella of a large financial services corporation. The financial advisors may not even be the company’s employees; they may operate as a collection of small virtual companies (teams) under the umbrella of another established financial institution. For large wealth management and financial services organizations, where the number of financial advisors can be measured in the thousands, MDM has significant data security, visibility, and eligibility requirements that we will concentrate on in Parts II and III of this book.
MDM enables customer on-boarding as well as global account opening and management processes. These processes and the supporting user interfaces include the ability to look up the reference data in the Data Hub before a new customer or prospect record is created. The process helps to prevent the creation of multiple records that refer to one customer, even if the records have different information. This improvement at the point of entry introduces efficiencies downstream. We will discuss this approach to Data Hub Design and Use Pattern in more detail when we discuss MDM architecture styles in Parts II and IV of this book.
The same approach applies to insurance firms for a policy issuance process and some other industries, such as mutual funds. For insurance, this method (look up before create) is used when MDM is integrated with claim-processing applications and other key insurance operational systems in all areas of insurance—Property and Casualty (P&C), Life, and Auto. Many established insurance companies operate globally and provide a variety of insurance products. In doing so, insurance companies need the ability to associate new customer applications with already existing accounts and manage a variety of corporate hierarchies (legal, sales, marketing, risk, and so on) with arbitrary hierarchy levels. By design, MDM is a major enabler of these capabilities for insurance firms.
As do most banks, credit, loan, and mortgage companies leverage MDM to match applicant records against the Office of Foreign Assets Control (OFAC) list,1 Specially Designated Nationals (SDN) lists,2 and other watch lists to get a holistic view of a customer and make substantiated application decisions.
Banks often embark on MDM projects because MDM is looked upon as an important and foundational capability when a bank intends to re-platform from legacy system environments to a new, more efficient, cost-effective, or more functionally rich environment—for example, a move to a new core banking system3 or trust accounting system. These systems are typically the key operational systems that own the most important and complex business rules and transactions managed by the organization. Similarly, claim-processing systems4,5 represent the engine of operational processing in insurance companies. A successful completion of a re-platforming project or migration from an obsolete legacy system to a new claim-processing or core banking system can utilize the MDM Data Hub to ensure continued operations and improve the agility of the enterprise architecture to support quickly evolving business needs.
Until recently, the single-customer view was the predominant driver of data integration initiatives throughout financial services institutions. However, ever since financial services organizations became subject to numerous regulations such as the Gramm-Leach-Bliley Act, the Sarbanes-Oxley Act, the Basel II Capital Accord, the USA Patriot Act’s AML and KYC provisions, and many others, a new and compelling reason to implement MDM has emerged. Indeed, because these and other regulations deal with accuracy of financial information, protection of customer data, and the need to capture and enforce customer privacy preferences, the need to have accurate, complete, secure, and available master data about customers, their portfolios, transactions, sales, and service records became a mandatory requirement. Financial services organizations that develop their MDM solutions to comply with the regulations and laws find the justification for building an MDM system to be relatively straightforward.
Large financial services institutions have grown through several mergers and acquisitions (M&A) and as such have consolidated multiple lines of businesses within their organizations. For example, the companies that started as purely insurance businesses focused on some specific line of business (Life, P&C, or Auto) started offering lending and wealth management and advisory services. Similarly, many banks broadened their offerings to include life insurance and other services traditionally provided by insurance. Although M&A is not an exclusive business strategy reserved for financial services organizations, the business strategy of many financial services institutions considers M&A as an effective growth vehicle and a competitive differentiator. Obviously, one of the challenges of the merged organization is the integration of its customer bases and harmonization of financial instruments and associated procedures. This is where MDM capabilities become highly beneficial; in fact, an MDM solution can quickly become a system of record for the new, merged enterprise or can be used to arbitrate entity resolution when data entry is done through the legacy operational systems of each firm. In Part IV we will discuss what MDM can do for M&A in more detail.
Financial services institutions manage complex products known as financial instruments. Financial instruments continuously grow in their complexity and variety (currently about 8.4 million). These products include securities, bonds, stocks, deposits, loans, options, futures, derivatives, swaps, collars, and so on. Derivatives are complex products that derive their value from the underlying assets; new derivatives are created frequently by financial services firms, whenever the firm sees an opportunity to offer a new product with attractive characteristics that can help the firm to differentiate itself from the competition and to establish or strengthen customer relationships in the process.
But the issue with derivatives is only one concern. Generally speaking, accurate, timely, and reliable information about the financial instruments is a core reference source for practically all financial services companies, and it should be treated as a special domain of the Master Data Management environment. There are several reasons for this treatment, including a wide variety of identifiers that require rationalization and may be difficult to reconcile. For example, when we look at the most popular identifiers of securities, we can easily see how numerous and diverse these identifiers are.
The Committee on Uniform Security Identification Procedures (CUSIP)6 manages CUSIP as a unique nine-character (alphanumeric) security identifier used for all North American securities and their issuers for the purpose of the clearing and settlement of trades. The CUSIP system is owned by the American Bankers Association. In addition to CUSIP, financial services companies sometimes use CUSIP’s international equivalent, CINS,7 the International Securities Identification Numbering (ISIN) system,8 and other standard and sometimes internal, organization-specific identifiers for financial instruments.
Note The International Securities Identification Numbering (ISIN) system is an international standard set up by the International Organization for Standardization (ISO) and used for numbering specific securities, such as stock, bonds, options, and futures. ISIN numbers are administered by a National Numbering Agency (NNA) in each country, and they work just like serial numbers for those securities.
In addition to the identifier problem for existing securities, information on new securities and updates on existing securities is often unavailable in a timely fashion, and it’s not unusual that the information about the securities is incomplete or inaccurate. In the absence of a systematic MDM solution, inconsistencies in securities description and indicative information can be reconciled only through manual processes. As a result, many trading activities can be negatively impacted by the lack of accurate and timely securities reference data. This poor data quality and unavailability delays trades clearing and settlement, and in general can prevent real-time trade matching, Straight-Through Processing, and next day settlement (T+1) activities.
This discussion, although focused on the financial instruments and securities, clearly illustrates that with the variety and complexity of financial instruments, product-centric variants of MDM are growing in importance. In combination with the need to manage positions, issuers, and other entities associated with product-centric MDM, its data models can be fairly complex.
The telecommunications sector includes companies that provide voice, data, and video communications services. These services can be delivered via wired, wireless, cable, or satellite communications.
Telecommunications companies deal with customers that include individuals as well as business entities. From the individual customer-support point of view, telecommunications companies face mostly the same issues as retail financial services, and having a single-customer view is considered a primary driver to improve customer service and create up-sell and cross-sell opportunities. Telecommunication companies are experiencing significant market transformation where the competition for communications products and services has intensified drastically over the last several years, and today their customers are able to choose and switch to a different service provider with relative ease.
In the days of telecommunication monopoly, customer attrition was not even a possibility, but today telecommunication companies are looking into MDM solutions to get a better understanding of customer retention drivers, and to deliver personalized, specially configured and priced service packages that would help increase the customer retention rates.
Other drivers for MDM in telecommunications include support for customer self-service, detection of fraudulent transactions, and communication and integration of customer accounts and customer billing for those customers who chose to purchase multiple services from the same provider, but who did that not as a package but rather as individual transactions (it is not unusual today for a customer to receive numerous separate invoices for various telecommunications services from the same provider). Moreover, the telecommunications industry has been going through significant changes driven not just by deregulation and the introduction of new communication technologies, but also by significant mergers and acquisition activities. These drivers have naturally resulted in the need to integrate and rationalize both product and service offerings as well as customer bases.
Looking at the product domain in particular, we can see that many telecommunications companies developed two major groups of products and lines of business supporting them: wire-line (TV cable, phone landline service, and so on) and wireless (mobile, satellite service, and so on). Historically these services grew independently, with the traditional wire-line service having been in existence for decades while the wireless services have been quickly growing in the last 15–20 years. Wire-line and wireless services may be managed by different departments or divisions that used to be different independent companies in the past and then merged as a result of an M&A transaction. As is not unusual in any M&A situation, these divisions are likely to have different operational models and organizational cultures. They use different systems to manage accounts and customers. Clearly, an MDM challenge is to provide a holistic, panoramic view of products and services offerings as well customers across the divisions and lines of business. This is something that traditionally was addressed by different MDM projects and different MDM technology solutions.
However, as the MDM technologies and approaches mature, we have started to see that MDM initiatives in the telecommunication sector usually include several MDM domains, such as Customer and Services/Products, in order to deliver a master environment that can support an integrated authoritative source of customer references in conjunction with critical product and service bundles.
Leading telecommunications companies engage in multidomain, multiphase programs addressing one or two master data domains in each phase. Frequently, these MDM programs begin with the customer domain (consumer and commercial) and then deal with products, locations, services, assets, and suppliers in the consequent phases.
To sum up, MDM enables a holistic view of the telecommunication company’s products, assets, and locations. As new, advanced telecommunications products pour into the market, the complexity of resources and assets required to support these products grows, too. The companies need to understand which of their individual and corporate customers at given sites and locations can benefit from the new advanced products, services, and upgrades. The offers should be extended only to the customer groups and locations that meet asset and resource qualifications criteria (for example, network requirements). Furthermore, the telecommunication industry is often said to be “process driven,” including robust and well-defined service provisioning, order processing, and billing. Thus, many MDM projects require tight integration with established process flows and business rule engines to support these complex business processes.
In the U.S., the healthcare ecosystem includes hospitals, medical centers, medical offices and providers, Integrated Delivery Networks (IDNs), Regional Healthcare Information Organizations, medical insurance companies (payers), medical labs, pharmacies (this is where healthcare overlaps with the pharmaceutical industry), and other segments.
Over 17% of the U.S. Gross Domestic Product (GDP) falls under the healthcare ecosystem,9 and this number keeps growing. Similar estimates apply to most other developed countries and economic zones.
The term “interoperable health” was introduced by Tommy Thompson, head of Health and Human Services in the George W. Bush administration (2004), in a ten-year plan to build a national electronic health infrastructure in the U.S. The idea is that with interoperable electronic health records, always-current medical information could be available wherever and whenever the patient and attending health professional needed it across the healthcare ecosystem. As per the Obama-Biden plan,10 health insurance premiums have doubled in the past eight years, rising 3.7 times faster than wages. Over half of all personal bankruptcies are caused by medical bills, and about 100,000 Americans die from medical errors every year.
The notion of interoperable health is closely related to the terms Electronic Medical Record (EMR), Electronic Health Record (EHR), and Electronic Personal Health Record (ePHR). The National Alliance for Health Information Technology (NAHIT) established definitions for these terms.11 The term EMR refers to the electronic record of health-related information on an individual that is created, gathered, managed, and consulted by licensed clinicians and staff from a single organization that is involved in the individual’s health and care. An EMR can be limited to a single system or an office.
An Electronic Health Record (EHR) is defined as the aggregate electronic record of health-related information on an individual that is created and gathered cumulatively across more than one healthcare organization and is managed and consulted by licensed clinicians and staff involved in the individual’s health and care. By these definitions, an EHR includes an interoperability of EMR records across multiple organizations and systems. Sometimes the term EHR is used in the U.S. nationwide context as an electronic record for a patient available nationally.
The term Electronic Personal Health Record (ePHR) refers to an electronic, cumulative record of health-related information about an individual, drawn from multiple sources, which is created, gathered, and managed by the individual. The integrity of the data in the ePHR and control of access to that data is the responsibility of the individual and can be used for patient electronic portals. An ePHR should include cumulative health information ranging from past and current illnesses, demographics, allergies, prescriptions, and more. The patient makes a decision on what information is stored and who has access to it. Microsoft’s HealthVault12 and Google Health13 are two prominent examples of ePHRs.
On December 30, 2009, the Office of the National Coordinator for Health Information Technology (ONC) and the Centers for Medicare & Medicaid Services (CMS) released documents that outline what physicians and hospitals must do to qualify for EHR incentive payments under the information technology section of ARRA.14 To qualify for incentives, physicians and hospitals must be using EHR technologies in a “meaningful manner.”15 The providers who adopt EHRs earlier may be eligible to receive greater incentive payments over time, while late adopters will be penalized beginning in 2015. For providers that implement EHRs and demonstrate meaningful use,16 the highest incentive payments will be available from 2011 through 2013. Additional, but reduced incentive payments will be available in 2014 and 2015, and penalties will begin in 2015.
MDM, and more specifically its patient-centric variant, Enterprise Master Patient Index (EMPI), along with other interoperability certification standards (CCHIT, HL7, Information Healthcare Exchanges [IHE] profiles)17 are at the very heart of what is required to enable a holistic, panoramic view of patient information and accomplish the EMR, EHR, and ePHR goals.
According to FactCheck.org, President Obama cited a RAND study18 stating that if most hospitals and doctor offices adopted electronic health records, up to $77 billion of savings would be realized each year through improvements such as reduced hospital stays, avoidance of duplicative and unnecessary testing, more appropriate drug utilization, and other efficiencies.
In the U.S., 785 million health care tests are conducted each year.19 The lack of interoperable systems to effectively communicate the results among the various providers who need to review them is consuming 1 billion hours of administrative processing time just to get the data in the right place, according to one estimate.
Integration of patient registration20 and clinical21 and medical claim–processing systems22 with MDM, EMPI, document management systems, imaging systems, and other unstructured information are the key steps in the move to interoperability and EHR.
Hospitals and medical centers are on the forefront of MDM integration with unstructured information. This type of integration is much less adopted by other industries—for example, financial services, pharmaceutical companies, manufacturing, telecommunications—even though there exists a demand to integrate MDM with document management systems, contract management systems, image repositories, and so on.
The primary focus on a single entity (patient) in hospitals and medical centers is evolving to include other master entities, such as provider, medical office, and other critical healthcare entities.
Additional classes of healthcare data are expected to come into the scope of MDM in healthcare, including medical procedures, diagnoses, treatments, and medication. MDM needs in healthcare are likely to grow beyond clinical departments and include marketing, supply and inventory management, biosurveillance, and other areas important for the operations of hospitals and medical centers.
Pharmacy health information exchanges enable physicians and pharmacists to electronically exchange prescription information, match physician requests for patient medication history, deliver patient formulary and eligibility across multiple systems, and make information available at the point of care in real time. MDM improves pharmacy operations due to a reduction of follow-up calls from pharmacists and Pharmacy Benefits Management (PBM). MDM solutions with their holistic panoramic view of patients and providers enable the Drug Enforcement Administration (DEA) to screen medicine seekers, fill prescriptions in all stores using a single MDM Data Hub, and improve patient safety by identifying potentially harmful prescription interactions across stores.
MDM needs of pharmacy chains are somewhat similar to the needs of retail stores, which will be covered in later sections. In fact, the largest retail stores run pharmacies as part of their operations.
The hospitality and gaming industry includes hotels and gambling establishments. It is clear that having an accurate and complete guest master that delivers a timely single-customer view is as beneficial to hotel chain management as it is to a retail bank. At a minimum, a single-customer view can help hotel management to provide better customer service, enable bigger cross-sell and up-sell opportunities, increase marketing campaign effectiveness, and enable better management of hotel inventory. However, this segment (and its gaming component in particular) brings an additional MDM requirement—to provide a complete guest view, together with all his or her relationships, and integrate this information with prior history of gambling activities linked with this guest in order to detect fraudulent gamblers and potential collusion between casino employees and players, employees and vendors, employees who are players, and so on. In this case, an MDM system would source information from a variety of applications, build and maintain the resolved entity, and make a new guest master available for advanced analytics.
Established casino firms are geographically diverse with scores of locations worldwide. A single company’s operations may include casino hotels, dockside and riverboat casinos, and other establishments. A significant part of the revenue often comes from casino gambling. This revenue stream heavily relies on the quality of the company’s loyalty programs. Recognizing and understanding the customer in the gaming and hospitality industry is critical. Therefore, MDM drives loyalty, revenue, and profitability. Improvement of guest data quality is a significant challenge in the hospitality industry due to the data volumes, sparseness, and inaccuracy of the data.
International hospitality organizations have developed complex operating models aimed at driving demand to their subsidiaries and brands. This includes advertising and marketing campaigns, call centers, websites that support multiple languages, large sales force organizations, and advanced hotel loyalty programs that count millions of members. Strategic information and re-platforming initiatives often begin with the consolidation of customer information.
MDM Data Hubs leverage sophisticated probabilistic capabilities to match disparate guest records despite misspellings, transpositions, dropped or extra characters in customer names and addresses, nicknames, and other inconsistencies. This enables the hospitality industry enterprises to effectively and accurately match guest records, resolve customer relationships in real time, and prevent duplicate guest entries.
Many established hotel chains are still lacking real-time guest-recognition capabilities. They lack an ability to track guests and assemble a holistic view for the guests that do not have the top parent loyalty program identifier, even if the guests have long-term loyalty relationships with one or several company brands. This is due to the fact that many large hospitality companies have grown through multiple acquisitions of smaller hotels, casinos, and so on. As a result, the hospitality industry faces a challenge due to the extremely high number of systems and brands that are to be integrated into the scope of MDM. Whereas for most other industries the integration of 20–40 operational systems under the MDM Data Hub umbrella may be a meaningful enterprise scope, the hospitality industry companies may require an MDM integration of thousands of systems across multiple brands.
This sector includes the companies that produce a wide variety of products, such as chemicals, hardware, devices, parts, cars, planes, cosmetics, software, home products, electronics, food, and furniture.
Manufacturing companies implement MDM solutions that often begin with the product domain to support their complex supply-chain requirements. Specifics depend on what the company produces. For instance, cosmetics and chemical manufacturing companies develop their products in highly collaborative environments required to maintain the continuity of supply-chain processes. These processes may include chemical synthesis, chemical analysis, technical operations, supplier management, quality assurance, labeling, packaging, marketing, billing, shipments, and so on. The Bill of Materials (BOM) is the single most import element of master data for many manufacturing organizations. Bill of Materials management can be especially challenging for global companies with multiple geographic sites and locations that manage the BOM with different granularity, systems, standards, and languages. Even the governance around BOM is a complex issue that requires a balanced approach, combining a centralized management of some generic aspects of the BOM with other more specific aspects that should be managed in a federated fashion and controlled by divisions, brands, and sites. Once the key challenges of the product domain are addressed, manufacturing companies can concentrate on the customer domain.
Manufacturing companies strive to create additional distribution channels for their products and services. Traditionally, many manufacturers distribute their products through distribution centers, department stores, and other channels. Until recently, the manufacturing companies did not maintain direct relationships with the consumers, delegating this role to department stores and other distribution channels. In order to enable additional channels, manufacturing companies build customer portals. These portals, depending on the nature of the manufacturing products, can service individual consumers or businesses. Naturally, customer portals use an e-mail address as an important account identifier. This e-mail identifier is well maintained, along with the credit card or bank account information used for billing, while other pieces of information about the account holder can be populated very sparsely and inaccurately. Consequently, manufacturing companies are lacking complete, accurate, and holistic information about their customers, which impacts the efficiency of marketing, risk management, and ultimately the profitability.
More recently, many manufacturers are selling directly to their customers using the Internet portal. Therefore, the challenge to maintain a single-customer view, whether the customer bought from a store or the portal, is even more challenging. An MDM approach that combines the use of data gathered from the Internet about customer behavior, along with using data collected from traditional channels, can be used to address this challenge. Car manufacturers deal with the challenges that arise from the fact that car dealerships are typically independent companies that guard their customer data. Still, these dealerships can benefit from marketing campaigns developed by the car manufacturer centrally. MDM helps preserve the balance between the dealerships’ demands to protect the access to their customer data in dealership-specific systems and a holistic customer view required by the manufacturing company to perform marketing campaigns. MDM resolves highly fragmented customer data and enriches it to enable cross-sell and up-sell opportunities during servicing; it improves campaign management processes while maintaining security of customer data in the local dealerships’ systems.
Software mega-vendors operate somewhat similarly to large manufacturing companies. Software giants have developed hundreds of products, and they license these products globally to millions of customers, including individual consumers and commercial organizations. MDM for corporate hierarchies allows software companies to understand what products their business customers decided to license and what discounts their customers are eligible for. MDM helps with reliable pricing, credit risk estimates, and marketing aspects for subsidiaries and divisions of large corporations. Many software companies serve customers around the globe, which makes their customer base multilingual and results in very high volumes of customer data. One of the important specifics of software companies is that their products can be downloaded over the Internet. Consequently, many customers who place their orders online do not have to provide accurate postal address information for delivery purposes, which creates additional challenges for customer matches across systems and accounts and ultimately makes it extremely challenging to build a single-customer view. The MDM market in the software vertical until recently has been limited mostly by very large software companies. Today, MDM adoption is moving downstream toward smaller-size companies.
The pharmaceutical industry deals with research, development, production, and the sale of various products for approved medical use. Typically, pharmaceutical companies do not deal directly with consumers but rather with physicians and service providers, who in turn prescribe and deliver the company’s products to their customers (patients). To a certain degree the pharmaceutical industry can be considered under the umbrella of manufacturing. From the pharmaceutical manufacturing perspective this would be a fare categorization. Because the pharmaceutical products (drugs and vaccines) require a very specialized, highly regulated, lengthy, and costly research and development process, this industry deserves a separate discussion, which is why we have placed the pharmaceutical industry in a separate section. Furthermore, the unique three-cornered process of manufacturer, customer (provider and physician), and consumer (patient) presents special MDM opportunities.
Pharmaceutical companies are challenged by the task of rationalizing and integrating physician/customer information from multiple systems and business units in order to deliver a comprehensive view of their consumers’ network and better insight into the competitive landscape.
In this industry segment, where the customers (physicians) also act as participants in the supply chain, MDM is viewed as an enabler of increased efficiency and effectiveness of supply-chain operations. Pharmaceutical companies see MDM as an enabler to reconcile various industry-standard identifiers, thus creating an integrated view of the customer (that is, physician, healthcare provider organization, medical group).
Having an accurate healthcare provider (physician, medical office, hospital, and so on) master data set that contains all relevant information in one place allows a pharmaceutical company to increase the effectiveness of the company’s sales representatives; to increase the acquisition, retention, and profitability rates of its customers (physicians and physician groups); and to enable better regulatory and compliance controls. For example, pharmaceutical companies need to adhere to strict regulations that require them to monitor and limit the total amount of various forms of compensation to their customers (that is, a physician may attend a conference sponsored by the company, give a for-pay lecture discussing the latest company product, and so on). And these activities can be performed using different names, including a medical group of which this physician is a member. Traditionally, these activities were recorded in different, disconnected systems, and this is where an MDM solution would enable information integration across these disparate systems into a single view in order to assess the total compensation.
Pharmaceutical and large biotechnology companies have to deal with the complexities of their product pipelines that begin with drug target identification, identification and screening of active substances, and screening of drug candidates for drug development. This complex process often takes over ten years before the company can bring a drug or vaccine to the market. Each of the functional areas across the drug discovery and development process uses its dedicated Laboratory Information Management Systems (LIMS) and other applications. These functions include, but are not limited to, lead generation, active compound screening and drug development, candidate selection, pharmaco-kinetics, toxicology, teratology, drug metabolism, drug formulation, pathology, stability studies, chemical analysis, and so on. During this process, multiple entities come into play: drug, indication, route of administration, and so on. Although some of these entities may change rather frequently, the need for an accurate, consistently available authoritative source of these entities nevertheless makes these entities good candidates for master data in drug discovery, development, clinical research, and manufacturing.
In clinical research and pharmaco-vigilance, patient-centric MDM is also important. Disparate LIMS systems limit the holistic view of the product (drug or vaccine candidate) across the variety of pharmaceutical enterprise functions. As a drug candidate moves along the pipeline, the R&D process becomes increasingly regulated, subjected to the practices required for Investigational New Drug (IND) applications and New Drug Applications (NDAs). Complex submission processes regulated by the FDA CFR part 11 in the U.S. domestically and other country-specific regulations internationally exacerbate the complexity of the process. Ultimately, pharmaceutical companies not only need to integrate all structured data about a drug candidate, drug, vaccine candidate, or vaccine, but also provide a panoramic view of unstructured data associated with the product. This unstructured content is not limited to formal submission documentation residing typically in document management systems, but also includes informal memos, e-mails, images of chemical structures, graphs, intermediate test results, and so on.
Pharmaceutical companies oftentimes outsource certain types of studies and tests to contract research organizations (CROs). Master Data Management can help to manage the contracts and other vendor and supplier information if integration with unstructured information is in the scope of MDM.
Shipping companies need to understand not only customers’ special pricing eligibility at present but also the eligibility status at a point in time in the past (support for temporal hierarchies), which makes MDM even more challenging. Location is a critical entity for shipping companies. Advances in GPS technologies have created additional opportunities when a location is identified by both postal address and GPS coordinates.
Understanding corporate hierarchies in conjunction with very high volumes of data and global, multilingual implementations is also a challenge for leading shipping companies. From the business perspective, these shipping companies embark on MDM implementations to better understand customer eligibility for special rates and discounted pricing for postal packages. This intelligence results in increased revenue and loyalty through price optimization and effective differentiation of services and products between the B2B and B2C models.
Airlines are under tremendous pressure to reduce their operational costs while retaining their best, most profitable customers. For the U.S. domestic airline companies, it is critical to survive during a long-term recession (2008–2010) and in the face of intense competition domestically and internationally with the largest European airlines. To accomplish this objective, the airlines offer loyalty programs to their customers that include a number of benefits, such as upgrades from Economy to Business or First Class. Frequent-flier miles can be used for free-of-charge plane tickets. In addition to mergers and acquisitions (for example, the recent merger of Delta Air Lines and Northwest Airlines), airlines develop alliances (Star Alliance, Skyteam, and so on). All airline consolidation and partnership scenarios drive the demand to merge loyalty programs and better recognition of a customer across merged companies and across the companies in the alliance. The airlines establish partnerships with hospitality companies, credit card firms, rental companies, and so on. These partnerships also contribute to the need of a panoramic view of a customer and household.
Airline security is an additional driver for a holistic passenger view. El Al is the recognized gold standard in this area. All airlines could benefit from better and timely intelligence about their passengers. In the U.S., the burden of passenger security lies mostly on the government and specifically on the Transportation Security Administration (TSA). We will continue our discussion of airline security in the section that focuses on MDM in the public sector.
In earlier days, airline ticket reservation systems were managed exclusively by the airlines. The Computer Reservation Systems (CRS) used to store, retrieve, and process air travel information were extended for use by travel agencies. The need to book and sell tickets for multi-airline trips drove the demand for Global Distribution Systems (GDS). GDS companies make their systems accessible to consumers over the Internet. Modern GDSs enable users to book not just plane tickets but also hotel rooms and rental cars. There is a significant potential in the integration of these global systems with MDM Data Hubs to improve airline security and other applications.
Retail stores often tackle multiple domains—customer, location, product, and supplier—in the scope of their MDM solutions. The primary goal in the customer domain is to resolve (match, link, and merge) scores of millions or even hundreds of millions of customer records across systems and store locations. The complexity of the high volumes is often exacerbated by high transactional volumes that can reach and even exceed a million transactions per day with peak rates nearing 1,000 transactions per second. Retail stores use MDM as the enterprise source of panoramic information about their customers to make better and faster credit decisions based on a holistic view of a customer. The view takes into account the house-holding and relationships aspects of the customer’s profile. MDM helps to enhance customer experience, minimize fraud, and gather business intelligence about the customer’s spending patterns.
Although data warehouses have had a long history in retail chain operations, real-time capabilities provided by MDM are relatively new and on the rise. Despite the fact that these real-time capabilities have a short history, they have already proven themselves to be a powerful enabler. These capabilities help sales organizations to provide timely customer intelligence in order to make immediate offerings to a customer based on the purchasing patterns at the point and time of sales. When a customer buys or even expresses an interest in a certain product in one department of the store, other departments receive this information in real time, which positions the sales representatives to promptly offer relevant additional products to the customer.
The relationships between correlated products that are often purchased together can also be maintained by MDM and is referred to as Market Basket Analytics. As an illustrative example, similar capabilities are employed on Amazon.com when the website offers books and other products that are often purchased with the product the customer search was originally focused on.
Customer data, along with locations, product hierarchies, and supplier data are fed to operational systems. This way, MDM maintains the content of the most complex data warehousing dimensions. From the business perspective, MDM improves risk management, customer intelligence, and marketing.
It is not feasible, or even practical, to try to cover all commercial verticals and industry segments that can benefit from MDM. Having said that, we believe that the industry segments described thus far represent the most significant areas of MDM adoption. Industry segments such as energy, gas, and utilities companies, even though they have not been covered, have similar MDM requirements as telecommunications companies when they support similar customer groups or bases. Other industry segments that have not been covered in this section may have some specific characteristics, but, generally speaking, have similar MDM requirements, drivers, and challenges.
When we discuss MDM implementation in the public sector, we include not only the departments and agencies of various national governments, but also businesses run by governments (various utilities, research establishments, transportation companies, and so on). Similar to the commercial sector, government organizations dealing with businesses and individuals (G2B and G2C) are also looking to improve efficiencies, reduce expenses, and improve levels of customer service. Government-sponsored businesses and various agencies are concerned that poor service levels may lead to a public outcry that can impact the policies, rules, regulations, staffing levels, and even the management teams running these organizations. Therefore, government organizations are looking to implement MDM solutions that deliver a single-customer view (or, as the case may be, a single-citizen view) in order to better understand the needs and behavior traits of their constituencies.
In essence, many of the commercial industry verticals described earlier in this chapter can be presented in the public sector. For instance, some healthcare organizations can be in the private or public sector. In most of the European countries, Canada, and Australia, the role of the public sector in healthcare and other verticals is much higher than that in the U.S. For example, many telecommunications, utilities, and energy companies in Canada are Crown corporations. Crown corporations are state-owned companies. This ownership can reside at the federal, provincial, or territorial level.23 And for most of the industries, the need for MDM remains mostly the same, regardless of whether an enterprise belongs to the private sector or is a government-owned organization.
Among the great variety of functions and areas where different levels of government are involved include social services, law enforcement, border protection, and intelligence agencies. All of these are the primary consumers of MDM.
We will focus on MDM applications in social services first and then continue with MDM in law enforcement, border protection, and intelligence agencies.
Social Services departments, Human Services departments, and their country-specific equivalents represent an inherent government function typically responsible for a wide range of services to diverse groups of citizens and residents across the country, state, or province. The primary function of the department may involve the delivery of a range of health services, including primary health, mental health, alcohol and drugs, retirement/aged care, disability services, children/youth care, family services, and housing for homeless. The purpose of these departments is to provide for the most needy groups of the population by helping them with certain basic needs: healthcare, food, shelter, special education for disabled children, and so on.
Social Services departments provide multiple variations of services. Eligibility to receive certain services by individuals and households is governed by complex rules defined in government regulations and guidance documents. Social Services agencies need to create a holistic view of a citizen who is in fact a client of the social service, understand what social services are already provided to the individual and the household or were provided in the past, and what agency or organization provides or provided each service. Therefore, from the MDM perspective, three complex entities dominate social services: Client, Service, and Agency or Organization.
This holistic, panoramic view of a client (individual and the household) and the services he or she receives are critical for services coordination to prevent delays in providing timely vital services. This is also important for timely recognition of individuals who receive services they are not eligible for and have possibly obtained due to incorrect or even fraudulent information provided when applying for the service. Understanding the relationships is important for Departments of Social Services so that these departments can get a holistic view of the providers in the context of the services they deliver. Relationships between a provider and a client are important for understanding who provides the services for each client.
Typically, multiple client databases and systems are used by Departments of Social Services. Each of the systems serves a single function in the department. The systems are generally not integrated due to privacy concerns or a lack of a holistic strategy. An increasing complexity in client data and regulatory rules and requirements often leads to a client accessing several different services delivered by both the department directly and by a service provider indirectly. For example, a mental health patient occupying a public housing unit may face eviction due to behavioral problems. Because this information may reside in different service-specific systems, the department is not aware of a pending problem that can cause new hardships to the Social Services client.
In another scenario, a patient may receive some equipment in a hospital after an injury for short-term disability needs. The client may be unaware what needs to be done to secure this equipment for longer term disability services. Lack of systems integration makes it very difficult to generate automatic alerts in these scenarios. This lack of integration and coordination can leave a disabled person without a required piece of equipment. There exist multiple scenarios that require alerts and coordination between the systems and functions of Departments of Social Services or Human Services in government organizations at different levels worldwide.
Overall, Departments of Social Services leverage MDM capabilities to improve service levels and client intelligence, move from product-/account-/policy-centric processes to party-/client-centric operations, support fast-evolving risk and compliance needs, reduce operational costs, reduce errors by enabling cross-functional alerts, and improve the outcomes of services and the client/citizen experience overall.
A widely known MDM program implemented in the UK nationally is ContactPoint.24 ContactPoint is a key element of the Every Child Matters initiative in the UK, transforming child services through prevention and early intervention. The MDM Data Hub holds information about all children under the age of 18 in England. The system was created under the Children Act 2004. The history of this program began in 2000. Victoria Climbié, an 8-year-old girl, was abused and murdered by her guardians in London. Separate agencies, including the police, many local social services, the NHS, and local churches all had contact with her and noted signs of abuse. All failed to properly investigate the abuse, and little action was taken.
A government study recommended that the government investigate the feasibility of a database covering all children, providing basic identifying details and contact details for practitioners and services involved with the child. ContactPoint has been developed as a quick way for a practitioner to find out who else is working with the same child, making it easier to deliver more coordinated support and enabling more effective prevention and early intervention. Contributing systems include schools, doctors, social services, benefits, and official records.
Despite children privacy concerns and multiple regulations restricting information sharing between providers, the solution design has found a balance between children privacy needs and the required level of information sharing, which ultimately resulted in a successful program implementation.
Law enforcement organizations, border protection, intelligence and national security agencies, homeland security, antiterrorist organizations, and some other agencies can leverage MDM capabilities to provide a comprehensive view of a person of interest (POI). Law enforcement and intelligence agencies are established consumers of MDM. Person of Interest is a fast-growing MDM domain in law enforcement and intelligence agencies.
In the U.S., the Law Enforcement National Data Exchange (N-DEx)25 is based on MDM Data Hub technologies that link and bring together data from law enforcement agencies throughout the U.S. As per the referenced N-DEx website, this includes “incident and case reports, booking and incarceration data, and parole/probation information. N-DEx detects relationships between people, vehicle/property, location, and/or crime characteristics. It ‘connects the dots’ between data that is not seemingly related. And it supports multi-jurisdictional task forces—enhancing national information sharing, links between regional and state systems, and virtual regional information sharing.”
The needs of intelligence agencies go far beyond POI, weapons, and vehicles. MDM, in conjunction with advanced entity-resolution technologies, can resolve complex composite entities such as an incident report, a collection of containers on a ship, and even a terrorist network.26–30 Extremely high volumes of data and the complexity of entities and relationships are some of the characteristics and challenges of MDM applications for global law enforcement and intelligence agencies.
In addition to improved service levels and operations, MDM in the government sector holds tremendous promise for providing necessary just-in-time insight into individual behavior, transactions, relationships, and linkages with various terrorist groups and their supporters.
A properly designed MDM solution can help to identify and track individuals both inside the country and across the globe. Despite the absence of a national identifier in the U.S., an MDM solution used by a public sector entity (Person of Interest) can be integrated with technologies that implement strong biometrics-based authentication and identification of individuals at points of entry into the country. These capabilities of an MDM solution are very attractive to international, federal, and local law enforcement as well as to various intelligence agencies, and hopefully could be used in the future to prevent acts of terrorism and other harmful activities.
Given the highly confidential nature of some of the information handled by most of the government agencies, it is not surprising that data security, privacy, confidentiality, and integrity concerns are some of the top priorities for implementing MDM solutions in the public sector.
From the entity-resolution and matching perspective, MDM probabilistic algorithms are more tuned to minimize false negative matches, whereas in most other industry-specific MDM applications the primary concern is not to allow false positive matches. Indeed, for example, in financial services a false match on customer records can cause a check, statement, or other sensitive material to be sent to the wrong person. In healthcare, even worse, a false positive match can cause life-threatening scenarios when a person receives the wrong medication, gets a blood transfusion with an incompatible blood type, and so on. Conversely, for law enforcement, counterterrorism organizations, and intelligence agencies, false negative scenarios are very important to avoid. They result in failures to recognize a Person of Interest.
Due to their sensitive nature, successful MDM applications for the POI and the corresponding case studies are not readily available in public domains. Having said that, when the capabilities that are supposed to be enabled by MDM fail to prevent terrorism, the importance of MDM for the POI gets crystal clear. A misspelled name caused a false negative match, which in turn caused a failure that resulted in the issuance of a U.S. entry visa to Umar Farouk Abdulmutallab, known as the “underwear bomber,” a 23-year-old Nigerian man accused of trying to blow up Northwest Airlines Flight 253 from Amsterdam to Detroit on Christmas Day, 2009. This story was widely discussed on all world news channels and analyzed in the mass media.
Various articles discuss the event from the MDM perspective.31–35 Politics aside, a few considerations important from the MDM perspective should be mentioned:
• Abdulmutallab was not on the No-fly List or the Selectee List. He was only on the Terrorist Identities Datamart Environment (TIDE) list as a Person of Interest with possible terrorist ties. As a result, the answer to the yes/no question of whether Abdulmutallab should be allowed to fly was “yes.”
• A probabilistic MDM approach in combination with entity resolution should replace the notion of a static “watch list.” Scoring entity-resolution algorithms should be able to bring together multiple indications about the terrorist despite this information being scattered around multiple databases. Using all the relevant information about Abdulmutallab and applying the concept of probability to the question of whether he should have been granted the entry visa and allowed on the plane leads to much better decision making. However, it requires that all the relevant information be shared and available to the algorithm that should be able to alert the decision maker.
• In the case of Abdulmutallab, the systems should have been able to take into account the following circumstances by scoring them from the terrorist threat perspective:
• The person was barred from entering a foreign country because he was on that country’s (the UK) “watch lists.”
• The passenger was reportedly associated with a radical terrorist group. His father told U.S. authorities he believed Abdulmutallab was being radicalized in Yemen.
• The person paid cash for the plane ticket. Not many people do that. A cash payment for a fairly expensive flight may indicate an intent to conceal one’s identity.
• The passenger boarded the transatlantic flight without any baggage, which is another indication.
• In order to bring together all these data points, the disparate indicative pieces of information should have been matched and assembled to connect the dots. A high terrorist threat probability score was supposed to raise the alert, prompting the denial of the entry visa in the U.S. or triggering an extra screening for the individual. This could have led to his detention in case a bomb or any other suspicious explosive device or hazardous material was found.
Timely access and dynamic assembly of all the available information like what was known about Abdulmutallab is a daunting information technology task. But from the technology perspective, this task can be resolved by modern MDM Data Hub systems.
There is another aspect that should be taken into account. Commentators have recently been calling vociferously for better information sharing. Information sharing is clearly a necessary part of the solution to prevent another terrorist attack, but it is not as easy as it sounds. Information sharing can be potentially damaging and involves risks. Let’s assume, as some people propose, that the government starts sharing all its lists across multiple agencies and branches of government. We can’t envision all the complications but it is fairly clear that some “list sharing” can result in serious adverse consequences. As information sharing is spread among many individuals and agencies, the chances of information leaks grow. A simplistic uncontrolled “list sharing” can help terrorists to understand what names are on the “lists” and what names are not. This may shed some light for them on how this information got collected and the methods used by agencies to gather the information. This can unintentionally aid terrorist operations, and possibly reveal the techniques and individuals responsible for making the terrorist names available to the intelligence agencies. Politics aside, it is fairly clear that “list sharing” across agencies is a complex master data governance problem applied to multiple “lists” (or, in more “physical” terms, “multiple MDM Data Hubs”). Obsolete, outdated thinking in terms of static “watch lists” is one of the barriers that governance agencies must overcome to correctly approach the problem.
Master data governance is a control discipline with the primary focus on cross-functional master data quality, consistency, and sharing of master data. This includes technologies, processes, and control options that enable master data sharing while balancing the risks of information sharing with the risks of not sharing. This is an opportunity to use entity resolution in conjunction with advanced master data governance to connect the dots across intelligence and law enforcement data sources while minimizing the risks of information sharing.
Following the attempt to bring down the airliner, President Obama directed Assistant to the President for Homeland Security and Counterterrorism John Brennan to conduct a review of the circumstances leading to the airline security failure.36 Here’s what it found:
• The report found that significant progress had been made since 9/11/2001. The report states the data integration and information sharing had been significantly improved. Information Technology within the U.S. counterterrorism community “did not sufficiently enable the correlation of data,” which is a clear indication that more complex problems around MDM as well as entity and relationships resolution remain unsolved by the counterterrorism community.
• The summary report also suggests that the current process involves many manual procedures performed by “watch listing personnel” who use deterministic rules to define “minimum derogatory standards,” as opposed to quantitative matching thresholds to place the person of interest on the No-Fly List.
• Finally, the fact that the U.S. entry visa was given to Abdulmutallab was a typical MDM matching problem from the MDM perspective. His name was misspelled, and the technologies that were used for screening failed to detect the similarity between the name on the visa application and the name on one of the “watch lists.”
1. http://www.ustreas.gov/offices/enforcement/ofac/.
2. http://www.ustreas.gov/offices/enforcement/ofac/sdn/.
3. http://www.inntron.co.th/corebank.html.
4. http://www.fineos.com/solutions/claims.htm?gclid=COjhjcf_ sZ8CFQYeDQodenXy1g.
5. http://mvsc.com/contact.cfm?gclid=CLabxJ-Asp8CFQMNDQoduH_Rzw.
6. https://www.cusip.com/static/html/webpage/welcome.html.
7. https://www.cusip.com/static/html/webpage/cusip_based_iden.html&002.
8. http://www.investopedia.com/terms/i/isin.asp.
9. http://politifi.com/news/Healthcare-spending-17-percent-of-economy-171793.html.
10. http://www.barackobama.com/pdf/issues/HealthCareFullPlan.pdf.
11. http://www.softwareadvice.com/articles/medical/ehr-vs-emr-whats-the-difference/.
12. http://www.healthvault.com/personal/index.html?WT.mc_id=M10011214&WT.ad=text::HealthVault::GoogSrch::HvPHp::Goo&WT.srch=1&WT.seg_1=healthvault.
13. https://www.google.com/accounts/ServiceLogin?service=health&nui=1&continue= https%3A%2F%2Fhealth.google.com%2Fhealth%2Fp%2F&followup=https%3A%2F %2Fhealth.google.com%2Fhealth%2Fp%2F&rm=hide.
14. http://hitechanswers.net/about.
15. http://www.softwareadvice.com/articles/medical/the-stimulus-bill-and-meaningful-use-of-qualified-emrs-1031209/.
16. Fernandes, Lorrain. “Discover Meaningful Use.” http://www.healthcareitnews.com/news/discover-meaningful-use.
17. http://ihewiki.wustl.edu/wiki/index.php/Connectathon_Testing_PIX_PDQ_XDS.
18. http://www.factcheck.org/elections-2008/obamas_inflated_health_savings.html.
19. http://www.comport.com/healthcare_provider.html.
20. http://www.jazdhealthcare.com/healthtech/leaf/Hospital-Management/Patient-Registration-Systems.htm.
21. http://www.epic.com/.
22. http://verticals.botw.org/Software/Insurance/Claims-Processing/.
23. http://en.wikipedia.org/wiki/Crown_corporations_of_Canada.
24. http://en.wikipedia.org/wiki/ContactPoint.
25. http://www.fbi.gov/hq/cjisd/ndex/ndex_home.htm.
26. Schumacher, Scott. “Complex Entities: Tracking a Vehicle Across State Lines.” http://blog.initiate.com/index.php/2009/12/16/complex-entities-tracking-a-vehicle-across-state-lines/.
27. Talburt, John. “Entity-Based Integration Model.” http://identityresolutiondaily.com/684/entity-resolution-integration-model/.
28. “Identity Resolution Daily Links 2010-01-11.” http://identityresolutiondaily.com/683/identity-resolution-daily-links-2010-01-11/.
29. Calvert, Brian. “Actionable Identity Intelligence from Identity Resolution Identity Resolution Daily Links 2010-01-11.”
30. Schumacher, Scott. “Agencies Sharing Information with Entity Resolution.” http://blog.initiate.com/index.php/2009/12/02/agencies-sharing-information-with-entity-resolution/.
31. Dubov, Lawrence, Alex Eastman, and Jeffrey Huth. “Connecting the Dots Before Boarding.” http://blog.initiate.com/index.php/2010/01/05/connecting-the-dots-before-boarding/.
32. Loshin, David. “President Obama: Problems Connecting the Dots? How About a Master Terrorist Management System?” http://www.b-eye-network.com/blogs/loshin/archives/2010/01/president_obama.php.
33. Eastman, Alex. “A Reference Architecture for Connecting the Dots.” http://blog.initiate.com/index.php/2010/01/25/a-reference-architecture-for-connecting-the-dots/.
34. Dubov, Lawrence, Alex Eastman, and Jeffrey Hugh. “Entity Resolution to Build a Better ‘Watch List.’” http://blog.initiate.com/index.php/2010/01/06/entity-resolution-to-build-a-better-watch-list/.
35. Chen, Ramon. Systemic Failure—Will the Government Put in a Decent MDM System Already!” http://www.ramonchen.com/?p=1968.
36. “Summary of the Whitehouse Review of the December 25, 2009 Attempted Terrorist Attack.” http://msnbcmedia.msn.com/i/MSNBC/Sections/NEWS/summary_of_wh_review_12-25-09.pdf.
3.22.241.228