Informatica On Demand

Who can blog

1. Need to be trained by Legal, PR, IR. No author account unless trained.
2. Create account.
3. Work with Jim and PR to get content posted (goal: 3-5 articles per week)
4. Content is SE friendly
5. Debra Wiltshire keeps the calendar to coordinate posts

• Home is the most recent posts.
• Left column, which shows the posts, is called the “loop.” This template is not often edited.
• Read more is author-defined within their content.
• Graphics max width should be around 400 px.

  (more…)

This is a sentence.

• one
• two
• three

ss

aaaaaaaaaaaaaaaaaaaaaaaaaaa

aaaaaaaaaaaaaaaaaaaaaa

(more…)

Healthcare is one of the last industries where you hear the term MDM (Master Data Management) mentioned. Most IT industry analysts, software firms and consulting organizations are geared towards your typical company that sells products to people or businesses. MDM examples are always getting a master list of products or cleansing your way to a consistent list of customers, which is not exactly the mindset of healthcare organizations. But lack of MDM is precisely what is adding untold costs on healthcare organizations (and ultimately on all of us) and inhibiting these organizations from improving the quality of health care services at an affordable cost.

Let's divide the healthcare industry (simplistically) into insurers and providers (we will position pharmaceuticals, biotechs and medical device companies as life sciences). Many of the large insurers have invested in data warehousing and data integration, but smaller insurers, i.e. regionally based HMOs (healthcare maintenance organizations) and healthcare providers, such as hospitals and physician groups, have fledgling efforts or have been bogged down in many of the issues below.

Healthcare organizations have significant data consistency issues regarding the following data subjects:

• Patients
• Physicians
• Procedures
• Diagnosis codes
• Service Rates
• Pay for Performance (P4P) measures

Each insurer and each healthcare provider tracks this data differently. The problems are magnified because healthcare is regulated on a state by state basis along with federal and industry regulations. Throw in privacy and security concerns to exacerbate what healthcare groups need to deal with.

Most healthcare organizations, even large ones, are an affiliation of generally small physician groups. These groups may be your local doctor's office, i.e. primary care physicians (PCP), specialists or emergency room (ER) providers. Often these groups do not have a lot of IT resources at their disposal.

Data flow is often flat file transfers between insurers and healthcare provider organizations, as well as from the individual physician groups and the larger provider organization. These flat files are generally not standardized and change each year when contracts are renegotiated between insurers and providers. This is an industry where you typically are not in control of your source data. It is thrown at you and you have to deal with it.

The need for an MDM is significant at healthcare organizations. The benefits from MDM are

• Data consistency
• Productivity
• Enabling more cost effect patient care

It is remarkable when one looks at the amount of resources devoted to manually dealing with inconsistent master data throughout health care. People in this industry do an amazing job of dealing with it, but it is often a time-consuming manual effort with much reconciliation. Having an MDM program would improve overall productivity and enable organizations to process and react more quickly to patients, insurers, employers and physicians.

A hidden jewel of an MDM effort though is enabling health care organizations to provide more proactive care. I have seen healthcare providers develop data solutions oriented to specific populations of patients who have diseases, chronic conditions or are at specific risks. These solutions may be for diabetes or asthma, for instance.

By bringing in historical clinical or demographic data related to patients tied together through consistent master data and taking advantage of predictive analysis, health care providers can proactively help their patients rather than waiting for the next episode when the patient's health has worsened. Many insurers are linking Pay for Performance (P4P) programs with these kinds of efforts because a healthier patient is a great goal by itself but better health also means lower health care costs.

The MDM silver bullet product has not been invented for healthcare industry but these organizations should not despair. There are concrete steps these organizations need to take.

• First, healthcare organizations need to examine where they are spending their resources on handling inconsistent master data and focus their efforts on those areas.
• Second, the efforts need to be in collaboration with business operations, physicians, insurers and IT, and need to involve defining master data and performance metrics.
• Finally, such organizations need to leverage their data warehousing and data integration efforts.

ShareThis

The most recent TDWI Boston Chapter meeting focused on how companies should approach and implement Master Data Management (MDM). Although the meeting had a keynote presenter and panelists with strong industry expertise and experience, the key to the discussions were the questions and insights of the audience attending the meeting.

The Boston chapter, with industries representing financial services, insurance, high tech, medical devices, biotech, retail, professional services and consumer products goods companies offers a diversity of perspectives about the challenges and benefits of addressing MDM.

Two key insights kept being reinforced during the discussions:

1. Leverage, Leverage, Leverage

Any company that will benefit from tackling MDM has most likely already been attacking the problem but not in the focused manner that MDM needs to truly be successful. But the biggest mistake that people saw with their peers and early adopters was the belief that MDM was something different than before.

Too often MDM is pitched as a "green field" opportunity with some solution as the "silver bullet" to one's problems. This approach fails to leverage past efforts from a business and technical perspective, thereby creating the potential for yet another application and data silo.

And, more importantly, failing to realistically assess the shortcomings and successes of existing efforts in making master data consistent is a sure fire way to plan to fail, i.e. repeating the failures of history is inevitable if you fail to learn from them.

Participants suggested looking at existing data warehousing and data integration efforts to leverage data, technical and people resources. Learn from the past.  Turn your joint IT and business efforts to define and manage data into a full-fledged  data governance program. If you have already started that type of program, expand  it and tie it into business successes (below).

2. Business Value

There needs to be specific business value derived from your MDM efforts. Catch phrases like "360 degrees of the customer" or "single version of the truth" are great marketing slogans but are esoteric and will become the brunt of jokes if they don't help you achieve real business value that can be measured. You can use these slogans to rally the troops and to get funding for the MDM efforts, but don't fall into that trap of believing your own sales pitch.

Your MDM will undoubtedly provide business ROI. Participants stressed that you should seek out those business opportunities and target your MDM towards them. Focused MDM efforts are more likely to get business participation, a critical success factor, to help you be on track to building your MDM program. Trying  to boil the ocean, i.e. trying to solve everyone's problems all at once,  generally fails to solve anyone's problems.

There are countless business processes or analytics that can be and are improved  by implementing MDM in your company. Find them, document them and determine  the business ROI that you can quantify or qualify. Get the business people involved  to be your customer references to sell the MDM program.

Success breeds success.

ShareThis

A post with “MS Word characters” will invariably cripple & maim the blog feed on the home page’s

Test Title ©Informatica?

Just Testing this out to see what happens with various text and “formatting”?

≥2000 people have problem’s like this

©Informatica

®Informatica

€200

�

SOA has nothing to do with technology. It has everything to do with defining and managing the business as a collection of service functions and information exchanges. A business may be viewed as an internal organizational unit within a large company that provides services to other other units and consumes services from yet other groups. Or if you view the business as the company overall at the macro level, then you could define and manage the business as a collection of services consumed from its supply chain and provided to its customers.

All of these service interactions require information to be exchanged. The information may be verbal or written, structured or unstructured, and is governed by service level agreements which may be explicit (contracts) or implicit (based on past behavior or industry norms). For example, a customer orders a hamburger (verbal information exchange), receives the order within a few minutes (implicit service level in a fast food restaurant), and pays with a credit card (structured information exchange).

All of the service flows inside a company or outside in the supply chain can be described (modeled) as functions with information inputs and outputs. Furthermore, a holistic model of all the functions in an enterprise or supply chain and the information exchanges between them will quickly identify which services are used by more than one consumer and therefore are opportunities for re-use and for investment in process improvements. This is a service oriented architecture.

Note that to this point I have not said anything about technology. Technology is an implementation detail which by most definitions is not “architecture”. Architectures are the plans and models – not the systems that result from them. There is of course such a thing as “technology architecture” which, in the case of service-based information exchanges may include protocols and standards such as SOAP, XML, WSDL, HTTP, MQ and REST among others.
When IT professionals speak of SOA, many of them are actually talking about technology architecture. My point is this – unless you take a business view of service orientation (which has nothing to do with technology) you shouldn’t call it a service-oriented architecture. If the focus of your SOA is on the technical implementation details, then you should call it application integration architecture or something like that.

This is the root cause of the trough of disillusionment when it comes to SOA. SOA has been promising lower costs and agile business processes for years, but the enabling technologies alone won’t provide the benefits (except by accident). Business flexibility and service re-use arises from a clear view of the business as a set of service functions and information exchanges. Once you understand the business in this context, the opportunities for technology solutions to support the business become clear and the path out of the trough of disillusionment and onto the plateau of productivity is illuminated.

ShareThis