DSXchange

Hello Everyone,

Currently I thought of shifting to my domain Banking to Health care industry

Can you please share your thoughts or suggestions about the Health care industry ETL Processes ??

Data comes from this database... get's transformed over here.... then goes into that database. The only difference is that if you mess it up, someone might die.

That's it.

Thanks Paul


I am looking at a technical point of view of data or methodologies ???

So is Paul.

What would you expect to be different as far as ETL processes are concerned? They are specified by business analysis and the like and implemented by you.

There is a different underlying model, but that ought not to be the concern of an ETL developer.

Thank you Ray,

It makes sense to me that understanding the data (metadata)is some thing different for different domains .. and as an ETL Developer role, the processing on the data is based on business requirements ..

Privacy is a big concern everywhere. In healthcare especially, at least in the U.S., there are more regulations around protecting privacy. Search on the "HIPAA Privacy Rule."

Personally, I'm more concerned about learning and applying the rest of the tools in the Information Server suite (besides DataStage) than focusing on any specific industry.

True, between HIPAA, PHI & PII there's plenty of privacy issues to be aware of in the Healthcare industry. The people you work for will make sure you understand what those are. But bottom line, that doesn't mean there are any real "technical" differences or magical methodologies that you'd use in one industry but not another. Typically. Yes, you might need to learn more about masking or encryption in Healthcare but it is certainly not exclusive to that world. Sure, there will be nuances of differences with how data is transmitted or what file formats are used or how many jigabites of data you need to load every day but there's still a bottom line.

As has already been said, ETL is ETL. This may sound a little facetious but you are going to E something, then T it and then finally L it. Or maybe you reverse the order of the last two, doesn't really matter. A database is a database, relational tables relate in a similar manner and there's only so many ways to load a warehouse or mart or ODS or whatever. Do you handle a Type2 dimension differently for Healthcare than Banking? Do inserts differently? Validate dates / amounts / strings of random digits differently? No, not really.

Of course, an understanding of the underlying business can help. Having to explain to someone building a financial data warehouse what a debit is or what posting a general ledger entry does can be a little frustrating but does that mean they can't be perfectly capable of moving the data from the source to the target with all of the proper business requirement transformations in place? Nope.

Learn the tools at your disposal. Become adept in their use regardless of industry or application. The rest will come. Well... unless you switch to working with geospatial data or start plotting vectors in a Hilbert space that is.

I guess the health care industry might work more with masked data and generated test data than many other industries, at least in development environments.

PaulVL wrote:The only difference is that if you mess it up, someone might die.That's it.

That was a good one

OP,
For me, it really does not matter for an ETL consultant or developer working across industries/domains. Terms will be new for you initially, but processes will be the same. You will become familiar with their domain in couple of weeks. So nothing to be prepared.

ray.wurlod wrote:I guess the health care industry might work more with masked data and generated test data than many other industries, at least in development environments.

True, but I would imagine the Banking industry has similar privacy concerns...

I don't know if the industry has any concerns other than turning a profit, but I know the customers have such concerns!

Being familiar more with the banking side -- my first career was in insurance -- I observe one significant difference: record format standards. I mean by this that a personal info record, for example, will look very different from one shop to the next.

Banking has global standards around transmissino of data. The most common is SWIFT, and many "local" applications comply with it to a significant extent.

Insurance -- and I know from friends currently in health insurance that it is true now -- has no such standards. One can look from one region of the country to another, let alone one company to another, and find very different formats.

I too shifted from Banking domain to Health care domain , there will not be much difference in the ETL process, we will miss the domain level knowledge. But once we start working, it becomes so simple.

There will be so many sub domains which we can fall under, for example Pharmacy,Corporate,Sales reports and quotes - all these are mainly related to customers,premiums,broker transactions.

I hope masking the data will be every where as one of the guys said its upto the client whether to dispose its customer data or not.

PaulVL wrote:The only difference is that if you mess it up, someone might die.

The ISD manual specifically defines a real-time web service as "someone's life does not depend on it." I guess ISD is not designed to handle web services inside a pace maker or air traffic control tower...

Most Blue Cross Blue Shield use DataStage. They are very loyal to IBM and IBM products. Most mainframe shops are IBM first shops. So banking are also mainframe shops. This tends to be true across hospitals and pharmacies. The doctors offices tend to be Windows or UNIX.

Claims processing is very complex and knowledge of data structures and terminology is very useful to obtaining a job. Knowing what a PCP, UCR, fee schedule, PPO, HMO and other industry terms helps. There are lots of privacy issues to be concerned about as well.

The more complex an industry the better the pay and more likely you will have a job years from now.

So manufacturing is big. SAP and PeopleSoft are other smart moves if you are looking for complex software that crosses industries.

I think it is very wise to plan a long term strategy like what industry you want to work in and what products you want to tie yourself to.