As the healthcare informatics initiatives heat up and the EMR market is getting flooded with new software, the visionary in you is probably going, "what am I going to do with all this data"? And your inner visionary would be right.
Standardized Data Definitions & why it's important
It's important to think about how to gather information, organize it and disseminate it in a meaningful way. SDD helps reduce communication errors and improves interoperability with other systems. Standardized Data Definitions is one important step towards achieving this goal. Thinking about this ahead of time, when you are purchasing EMR or CPOE software, will help you get rid of headaches later down the line. The first step to achieving this is coming up with the data definitions themselves. Don't panic! People are already working on it. SNOMED is one of them. They have already achieved success in Clinical Terms definitions. SNOMED CT is available at http://www.ihtsdo.org/ (International Health Terminology Standards Development Organization).
Ontologies
In one of my previous posts, I said "whack us", if we talk about Ontologies. Well, since you are reading this over a computer and there is no great threat of bodily harm to me at this point, I am going to say it. What is an Ontology? The core meaning within computer science is a model for describing the world that consists of a set of types, properties, and relationship types (according to Wikipedia). Why is it important for healthcare? As we generate more and more data, organizing data in an effective manner is essential to a great informatics system. For example, think of a patient as an ontology. It is also a "complex" ontology, meaning it may have more than one "simple" ontology associated with it. For example, vitals of a patient may be considered a simple ontology. Organizing data in ontologies help us define complex data relationships and easier extraction points.
Summary of the matter is this: If we plan upfront, we can deliver better information at the end. There might be painstaking detail to go through in the beginning, but without it, our informatics initiatives fail.
Next week: Interoperability
Tuesday, July 21, 2009
Monday, June 15, 2009
Data Quality!
Why is Data Quality Important?
Well, DUH! The whole exercise of an informatics initiative is to be able to make intelligent decisions, faster. You wouldn’t buy a $300,000 house with less than $50,000 in annual income now, would you? Oh sorry, that was a bad example, but you get the idea. So how do you ensure quality of data that you can depend on, to make decisions?
Data Profiling
In my previous posts, I mentioned programmatical cleansing of data and usage of “discipline”. This is where the discipline part of your informatics initiative comes in. Understand your source! Garbage in, garbage out, folks! A lot of times, the mantra of “speed to market “ trumps this activity called profiling, with the assumption that data quality is fine, usually sworn on his/her first born by the Director who handles the operational system where you are sourcing your data from. Subsequently, you have data on time, but you make a decision based on what you see, only to find out later that the data lied to you and naturally your fury is directed towards the director who swore that the data was fine and just got fired because this whole fiasco cost your company a few million bucks.
What went wrong? Was the Director wrong? Did he/she lie to you? The answer is, NO. They didn’t lie to you. The fundamental difference here is, the way the data is being used. The operational systems person is not looking at 10 years worth of data to identify trends. They are not using it to formulate predictive models to go where your vision is taking you. To them, the data quality was excellent, for day to day operations. You, on the other hand, needed at least 5 years worth of data, to come up with a trend. While it was available in the operational system, nobody profiled this data and so you missed the fact that a key measure, for the past 4 years has had null values in it, flat-lining your trend analysis graph. Voila, the business case for data profiling has been made!
Data Validation
Here is where your ever so faithful IT folk can do some nifty programming to get you the quality you have always deserved. A lot of these issues can be taken care of, upfront. Element level validations can be put in at the data acquisition level, more complex validations can be put in at the integration level. This approach ensures a couple of things. One is that less garbage gets into your warehouse and the other is that processing is not heavily impacted as you are splitting the activity up in two different points of your data flow (a deeper, more technical dive on this later, as my inner-geek is screaming “Stop! Do not say that without proper clarification! You are about to get roasted over a coal fire!”).
The point of all this is, quality of data is very important in an informatics initiative. In fact, that is the most important thing. So, when you hear someone saying, “data quality is my number one issue”, you can safely assume that your informatics initiative is doomed.
Well, DUH! The whole exercise of an informatics initiative is to be able to make intelligent decisions, faster. You wouldn’t buy a $300,000 house with less than $50,000 in annual income now, would you? Oh sorry, that was a bad example, but you get the idea. So how do you ensure quality of data that you can depend on, to make decisions?
Data Profiling
In my previous posts, I mentioned programmatical cleansing of data and usage of “discipline”. This is where the discipline part of your informatics initiative comes in. Understand your source! Garbage in, garbage out, folks! A lot of times, the mantra of “speed to market “ trumps this activity called profiling, with the assumption that data quality is fine, usually sworn on his/her first born by the Director who handles the operational system where you are sourcing your data from. Subsequently, you have data on time, but you make a decision based on what you see, only to find out later that the data lied to you and naturally your fury is directed towards the director who swore that the data was fine and just got fired because this whole fiasco cost your company a few million bucks.
What went wrong? Was the Director wrong? Did he/she lie to you? The answer is, NO. They didn’t lie to you. The fundamental difference here is, the way the data is being used. The operational systems person is not looking at 10 years worth of data to identify trends. They are not using it to formulate predictive models to go where your vision is taking you. To them, the data quality was excellent, for day to day operations. You, on the other hand, needed at least 5 years worth of data, to come up with a trend. While it was available in the operational system, nobody profiled this data and so you missed the fact that a key measure, for the past 4 years has had null values in it, flat-lining your trend analysis graph. Voila, the business case for data profiling has been made!
Data Validation
Here is where your ever so faithful IT folk can do some nifty programming to get you the quality you have always deserved. A lot of these issues can be taken care of, upfront. Element level validations can be put in at the data acquisition level, more complex validations can be put in at the integration level. This approach ensures a couple of things. One is that less garbage gets into your warehouse and the other is that processing is not heavily impacted as you are splitting the activity up in two different points of your data flow (a deeper, more technical dive on this later, as my inner-geek is screaming “Stop! Do not say that without proper clarification! You are about to get roasted over a coal fire!”).
The point of all this is, quality of data is very important in an informatics initiative. In fact, that is the most important thing. So, when you hear someone saying, “data quality is my number one issue”, you can safely assume that your informatics initiative is doomed.
Friday, May 29, 2009
MetaData!
What is metadata? Simply put, it is data about other data. There is business metadata and there is technical metadata. Now, if you have undertaken an informatics initiative, you will have technologists all over you telling you how important metadata management is! Well, here is where I am going to draw the wrath of all technologists! "We created this problem"!!. Yes, time to own up to it. Technologists, like us, decided that we were going to call a part numer "part#" in one database and "part_number" in another! Now, when you are creating a warehouse and analytics platform, this becomes an issue. Data mapping ensues. Other smart technologists decided that they can make money "fixing" this problem and created "metadata repositories" and voila! Millions of dollars out of your pocket!
So, is there a way out of this mess? Well, not really. But don't lose heart. There are things that you can do, to not break the bank. First, decide what metadata you really care about. Apply the same thinking you used to decide on what to measure. Again, the more you plan, the better off you are. Don't worry about the technical metadata right now. Define the business metadata you care about. Let the technologists figure out how to get the supporting technical metadata. Basically what you have done here is reduce the amount of metadata that you want to store for your informatics initiative. Downstream effects? Less mapping, faster delivery and "CHEAPER"!
Now that we have established that you, as the business owner, should care about your metadata (because it has a direct effect on your wallet, if you still don't believe me), there is one more thing you should care about. How do you "use" the metadata that you have collected? Here is where some old fashioned "discipline" comes handy. Ingrain into your informatics team that any and all data elements that are considered candidates for your data mart, first be rationalized with this metadata repository. In simple terms, check to see if this is something you really need.
Now that you have defined your metadata and had that talk with your informatics team, boldly go where no business owner has gone before...choose the technology! (Not so fine print: strongly suggest involving your technology team here ). There are expensive repositiories out there and there are inexpensive ones. If it makes senses, use your existing database platform as a repository. Your smart data modeler/architect can design you one in no time.
So, is there a way out of this mess? Well, not really. But don't lose heart. There are things that you can do, to not break the bank. First, decide what metadata you really care about. Apply the same thinking you used to decide on what to measure. Again, the more you plan, the better off you are. Don't worry about the technical metadata right now. Define the business metadata you care about. Let the technologists figure out how to get the supporting technical metadata. Basically what you have done here is reduce the amount of metadata that you want to store for your informatics initiative. Downstream effects? Less mapping, faster delivery and "CHEAPER"!
Now that we have established that you, as the business owner, should care about your metadata (because it has a direct effect on your wallet, if you still don't believe me), there is one more thing you should care about. How do you "use" the metadata that you have collected? Here is where some old fashioned "discipline" comes handy. Ingrain into your informatics team that any and all data elements that are considered candidates for your data mart, first be rationalized with this metadata repository. In simple terms, check to see if this is something you really need.
Now that you have defined your metadata and had that talk with your informatics team, boldly go where no business owner has gone before...choose the technology! (Not so fine print: strongly suggest involving your technology team here ). There are expensive repositiories out there and there are inexpensive ones. If it makes senses, use your existing database platform as a repository. Your smart data modeler/architect can design you one in no time.
Thursday, May 14, 2009
Tools & Technologies for Informatics
Now that you have defined your measures and know exactly what data you need (if you haven't done this already, read my previous posts), how do you go about a "tool/technology" selection. I am putting those words in parantheses, because it might just end up being a new IT department that you just bought! Be careful!
1. Define your SLA (Service Level Agreements)
You know your measurements. You know what data you need. Now do you know how "fast" you need it? This is a common mistake people make. Everyone wants their data now. But does it really make sense to have all of it "now"? For example, if your measure is "quarterly revenue" or "physician performance", do you really need your data now? If you are only making decisions based on that data once every quarter, why do you need it now? So, define your service level agreement for each of your measures. For some measures, you will need your data faster than others. Understanding your SLAs early on will help you spend your money wisely without spending too much money on esoteric technologies that you may never use.
2. Evaluate your technology as it pertains to your business need
In 1998, I had a business that did staffing services and built custom applications for customers. Whenever a customer approached me with a problem, looking to build a new solution, the first thing I would do is search for a product that is already in the market that fit his/her need. If there was one that satisfied his/her need, I would simply point them to the product. The point being, if you can utilize existing technology and resources to satisfy your need, why spend hundreds of thousands of dollars on new technology? So if all you need is to have one data file loaded every month, SQL Loader or other existing technology might do the job. You don't need AbInitio or Informatica for that. Again, understanding your need, SLAs etc will help you make better decisions.
3. Cheaper options are here!!
You wouldn't go buy a Ferrari to take your three kids to school, now would you? First of all, there won't be any room to fit everyone in, second, it would cost you a small fortune and by the time your kids are done with it, your heart, wallet and pride all will be broken. While some technology vendors have reigned supreme in the DW/BI market, there are cheaper options out there who perform just as well as the big boys. Expressor is a promising newcomer in the ETL market. So are Talend and Jitterbit. Pentaho, BIRT, Jaspersoft etc. are all viable BI options. And if your argument is that open source has no support, think again! They don't cost you a fortune and do their jobs well. Some even outperform the big ones, as rumor has it.
1. Define your SLA (Service Level Agreements)
You know your measurements. You know what data you need. Now do you know how "fast" you need it? This is a common mistake people make. Everyone wants their data now. But does it really make sense to have all of it "now"? For example, if your measure is "quarterly revenue" or "physician performance", do you really need your data now? If you are only making decisions based on that data once every quarter, why do you need it now? So, define your service level agreement for each of your measures. For some measures, you will need your data faster than others. Understanding your SLAs early on will help you spend your money wisely without spending too much money on esoteric technologies that you may never use.
2. Evaluate your technology as it pertains to your business need
In 1998, I had a business that did staffing services and built custom applications for customers. Whenever a customer approached me with a problem, looking to build a new solution, the first thing I would do is search for a product that is already in the market that fit his/her need. If there was one that satisfied his/her need, I would simply point them to the product. The point being, if you can utilize existing technology and resources to satisfy your need, why spend hundreds of thousands of dollars on new technology? So if all you need is to have one data file loaded every month, SQL Loader or other existing technology might do the job. You don't need AbInitio or Informatica for that. Again, understanding your need, SLAs etc will help you make better decisions.
3. Cheaper options are here!!
You wouldn't go buy a Ferrari to take your three kids to school, now would you? First of all, there won't be any room to fit everyone in, second, it would cost you a small fortune and by the time your kids are done with it, your heart, wallet and pride all will be broken. While some technology vendors have reigned supreme in the DW/BI market, there are cheaper options out there who perform just as well as the big boys. Expressor is a promising newcomer in the ETL market. So are Talend and Jitterbit. Pentaho, BIRT, Jaspersoft etc. are all viable BI options. And if your argument is that open source has no support, think again! They don't cost you a fortune and do their jobs well. Some even outperform the big ones, as rumor has it.
Thursday, April 9, 2009
Informatics - Getting there
Ok, So I didn't get to post this last week. I was attending the HIMSS 09 in Chicago. Great city! Great Conference. If you haven't attended one, then you should. So you have decided to take the next step in process improvements and improve quality of care ( if you are a hospital ) and reduce cost of healthcare. Everyone is touting a product or service that will help you get there. But what do you need to know so you can choose the right vendor, the right technology etc? Here is what:
#1. METRIC
"Measure Everything That Really Impacts Customers". I didn't say this. I heard it at HIMSS. I couldn't agree more. Define your measures. Your customers could be internal or external. So, identify your customers, ask them what measures are important to them and capture them. The better understanding of your metrics and what you want to do with it, the easier your informatics initiative will be. Mind you, over 60% of Datawarehousing and Business Intelligence projects fail or do not meet expectations. So when I say that it is key to define your measures before you even go at it, I really really mean it!
#2. Failure of DW/BI Projects
So why do so many of them fail? Experts have studied and studied and come up with several reasons for this. I am not going to go into all of them here. But I will talk about one fundamental thing that is key here. A lot of organizations will treat a datawarehousing and business intelligence intiatives as two different projects. In my humble opinion, that is the wrong approach. It should be treated as one "Information Delivery" initiative. After all, it is the data that adds value to the business. So, the steps should be:
#3. Select your Partner
I don't like the word Vendor when it comes to working with our clients. It is truly a Partnership that defines that relationship. If you fail, we fail and vice versa. The first partner you select is your own IT department. They are the ones who are going to manage this initiative, deliver it and then support it when the external partner is gone. It is imperative to get them involved from the get go. When looking for an external partner, look for a company who can advise you on tools and technologies first (mind you, don't select your tools before you know your requirements). Your own IT department can help you with this. Of course, experience is important. Look for companies that will give you the same resources that they bring to the table in their first meeting. Often times, they will "sell" you with their best resources and once the contract is signed, switch resources on you. Insist on the best.
Next week: Tools & Technologies
#1. METRIC
"Measure Everything That Really Impacts Customers". I didn't say this. I heard it at HIMSS. I couldn't agree more. Define your measures. Your customers could be internal or external. So, identify your customers, ask them what measures are important to them and capture them. The better understanding of your metrics and what you want to do with it, the easier your informatics initiative will be. Mind you, over 60% of Datawarehousing and Business Intelligence projects fail or do not meet expectations. So when I say that it is key to define your measures before you even go at it, I really really mean it!
#2. Failure of DW/BI Projects
So why do so many of them fail? Experts have studied and studied and come up with several reasons for this. I am not going to go into all of them here. But I will talk about one fundamental thing that is key here. A lot of organizations will treat a datawarehousing and business intelligence intiatives as two different projects. In my humble opinion, that is the wrong approach. It should be treated as one "Information Delivery" initiative. After all, it is the data that adds value to the business. So, the steps should be:
- Gather requirements ( define your measures )
- Design your entire information delivery platform based on that (reporting, warehouse, ETL, DataModels and everything else in between)
- Build
- Test
- Deploy
#3. Select your Partner
I don't like the word Vendor when it comes to working with our clients. It is truly a Partnership that defines that relationship. If you fail, we fail and vice versa. The first partner you select is your own IT department. They are the ones who are going to manage this initiative, deliver it and then support it when the external partner is gone. It is imperative to get them involved from the get go. When looking for an external partner, look for a company who can advise you on tools and technologies first (mind you, don't select your tools before you know your requirements). Your own IT department can help you with this. Of course, experience is important. Look for companies that will give you the same resources that they bring to the table in their first meeting. Often times, they will "sell" you with their best resources and once the contract is signed, switch resources on you. Insist on the best.
Next week: Tools & Technologies
Saturday, March 28, 2009
Health Informatics in plain English
Lesson #1. It's the Data!
So, if you have any doubts as to what that statement means, here it is. It is the data that is of value to the business. Yes, I said business. Unless you work for a software making mega corporation whose revenues come from the software you make, you are nothing but a cost center and the only way you are going to add value to your organization is by "saving" the "business" money. Now that we are clear about us IT folks' role, let me explain the rule I mentioned above. The only thing that adds value to the business is timely delivery of "good quality" information, so they can make intelligent decisions. "Data becomes information, then knowledge, then value".Lesson #2. ETL, BI, DW, Semantics, Metadata, mart, cube, ontology etc. etc.
If you are a business person trying to make decisions on process improvements or looking to reduce the cost of healthcare coverage, this should all be gobblygook to you.
In fact, the next time one of us IT folks tells you that you can't have your data because of any of the above said acronyms or any other new reason that doesn't make sense to you, please feel free to whack us with whatever is in your hand.
Lesson #3. Data Quality
How many times have you heard this phrase ..."we're having data quality issues..." or "data quality is our number one issue.."? Well, whack us IT folks again! Why? Because, simply put, it means "bad data" and it is our fault that we can't fix all the bad data flowing through the systems. Actually my IT bretheren, you can block this whack, because we didn't create the data. But we can definitely help scrub it. Again, the point being it is all about the data.
Lesson #4. Define your measures!
Here's where we IT folk have the upper hand. If you think you know what your measurements are, think again. If you think that number of surgeries done a day is a good performance measure for your employees, think again! Define your measures (Refer to lesson #1 if you have questions). Apply critical thinking to it. Then let us know which ones are the most important ones so you can make your intelligent decisions and keep more revenue coming in the pipeline so we don't go down like AIG! Phew, that took a long breath. In fact, defining your measure should be your first priority when undertaking any Informatics initiative. If you have your measures defined, then all the acronyms & terms in lesson #2 will fall into place.
Lesson #5. Tools, platforms and appliances!
This should be the last of your concerns. Again, refer to lesson #1 if you have any questions. Tools are a way to do things. One may be better than the other depending on your current infrastructure and investments. But remember, once you know exactly what you want, tools become just that. Tools selected to do a particular job.
Next week: How to get there
Lesson #3. Data Quality
How many times have you heard this phrase ..."we're having data quality issues..." or "data quality is our number one issue.."? Well, whack us IT folks again! Why? Because, simply put, it means "bad data" and it is our fault that we can't fix all the bad data flowing through the systems. Actually my IT bretheren, you can block this whack, because we didn't create the data. But we can definitely help scrub it. Again, the point being it is all about the data.
Lesson #4. Define your measures!
Here's where we IT folk have the upper hand. If you think you know what your measurements are, think again. If you think that number of surgeries done a day is a good performance measure for your employees, think again! Define your measures (Refer to lesson #1 if you have questions). Apply critical thinking to it. Then let us know which ones are the most important ones so you can make your intelligent decisions and keep more revenue coming in the pipeline so we don't go down like AIG! Phew, that took a long breath. In fact, defining your measure should be your first priority when undertaking any Informatics initiative. If you have your measures defined, then all the acronyms & terms in lesson #2 will fall into place.
Lesson #5. Tools, platforms and appliances!
This should be the last of your concerns. Again, refer to lesson #1 if you have any questions. Tools are a way to do things. One may be better than the other depending on your current infrastructure and investments. But remember, once you know exactly what you want, tools become just that. Tools selected to do a particular job.
Next week: How to get there
Subscribe to:
Posts (Atom)