So what are some of the reasons that cause an Informatics initiative to fail? Over 50% of them fail or fail to meet expectations! If you have read all of my previous posts, you know some of them already, but let's summarize and re-examine some of those.
1. Lack of well defined measurements
For an informatics initiative to be successful, this, folks is number one. Talk with your internal and external customers. What do they need to see on a daily/weekly/monthly/quarterly/yearly basis? Understand how each measure is contributing to the well being of the organization.
2. Data Quality
When you bring data in, ensure quality. There are several industry standards that allow you to ensure this. A little extra time spent up front will help you make better decisions.
3. Lack of Sponsorship
You can build the coolest platform in the world, but no one will use it if there is no sponsorship from key executives in your organization. Even before you start, get the lines of business executives involved and "SELL" them the idea of informatics and how their organizations can benefit from efficient use of this technology.
4. Running parallel
You may think that breaking your informatics initiative into two tracks (ETL track and BI track) will save you time and money, but in reality, what comes into your warehouse might not be what the customer wants to see.
5. Tool/Vendor selection
Tools are tools. They don't produce information unless you tell them to! Without a well defined plan of execution, the coolest tools will sit there and collect dust. Get your IT folks involved early on. They have done the research and can guide you through the process.
Monday, September 28, 2009
Monday, September 14, 2009
Reforming Healthcare - "Creating Value"
I was just reading Mayo Clinic’s newsletter detailing Mayo’s point of view on healthcare reform. According to the point of view article, the Number “one” recommendation is Medicare Value Indexing or V=Q/C. Value = Quality/Cost and they give you some examples of “measuring” quality and I quote:
1. Quality (Q) — the numerator — includes clinical outcomes, safety and patient reported satisfaction.
Examples of outcome measures: hospital admissions, emergency department visits, readmission rates and mortality rates
Examples of safety measures: central line infection rates, medication errors and post-operative complications
Examples of patient satisfaction: National Research Corporation’s Healthcare Market Guide
2. Cost (C) — the denominator — encompasses the cost of care over time.
Sound familiar? Both these recommendations rely heavily on Informatics. Ability to measure outcomes, safety measures and patient satisfaction are all functions of an Informatics solution. The denominator, as explained in the article, ability to do trend analysis on cost is another function of a comprehensive informatics solution. The article goes on to recommend doing a value-based care “demonstration project”.
Now, not to brag, but our software, IATROMATIX, is a comprehensive platform that has quite a few of these capabilities built in. If you are interested in a presentation, please email me at kishore@metaanalytix.com
1. Quality (Q) — the numerator — includes clinical outcomes, safety and patient reported satisfaction.
Examples of outcome measures: hospital admissions, emergency department visits, readmission rates and mortality rates
Examples of safety measures: central line infection rates, medication errors and post-operative complications
Examples of patient satisfaction: National Research Corporation’s Healthcare Market Guide
2. Cost (C) — the denominator — encompasses the cost of care over time.
Sound familiar? Both these recommendations rely heavily on Informatics. Ability to measure outcomes, safety measures and patient satisfaction are all functions of an Informatics solution. The denominator, as explained in the article, ability to do trend analysis on cost is another function of a comprehensive informatics solution. The article goes on to recommend doing a value-based care “demonstration project”.
Now, not to brag, but our software, IATROMATIX, is a comprehensive platform that has quite a few of these capabilities built in. If you are interested in a presentation, please email me at kishore@metaanalytix.com
Monday, August 24, 2009
Interoperability
Your car is interoperable with the road. Will it take you where you want to go, though? If you answered "yes", well.... So we hear about "interoperability" a lot these days. The government is looking into NHIN to be an "interoperable" platform, your applications should be interoperable with others etc. etc. Well my friends, we are missing the point. To me, there are two different types of "interoperability". Before you jump down my throat, let me explain. There is the "business" of interoperability and then there is the "technology" of interoperability. As the informatics visionary of your organization, what do you need to focus on first? You guessed it...the "business" first before the technology.
The Business of interoperability
What does that mean? Well, it is simple. If you want to connect physicians, patients and everyone else in between, there is one thing that is important. "Information". Simply put, "information sharing" is the business. Trust me, your patients could care less how Facebook like your application looks if there is no information there. So, step one would be to nail down the information that you are going to share using your shiny new "Facebooky" (remind me to send that term to Oxford for inclusion in the next revision of their dictionary) application.
The Technology
The technology of information sharing focuses more on "how" the information gets delivered. There are people working to solve this "issue" already. To me, that is like putting the cart before the horse. Decide "what" you want to share, "who" you want to share it with and then decide on "how" you are going to share it. Minimally, your investment in technology (after the "what" and "who" are decided), should focus on a couple of simple things.
a) Can the new system "talk" to your existing systems?
b) Can it share the information it gathers from other systems with others? (will it play well with others? Is it a team player?)
If the answer to both those are yes, then you have an "interoperable" system.
To summarize, if your car needs to go where you want to go, first you need to know "where" you are going and then you need to drive it to your destination.
The Business of interoperability
What does that mean? Well, it is simple. If you want to connect physicians, patients and everyone else in between, there is one thing that is important. "Information". Simply put, "information sharing" is the business. Trust me, your patients could care less how Facebook like your application looks if there is no information there. So, step one would be to nail down the information that you are going to share using your shiny new "Facebooky" (remind me to send that term to Oxford for inclusion in the next revision of their dictionary) application.
The Technology
The technology of information sharing focuses more on "how" the information gets delivered. There are people working to solve this "issue" already. To me, that is like putting the cart before the horse. Decide "what" you want to share, "who" you want to share it with and then decide on "how" you are going to share it. Minimally, your investment in technology (after the "what" and "who" are decided), should focus on a couple of simple things.
a) Can the new system "talk" to your existing systems?
b) Can it share the information it gathers from other systems with others? (will it play well with others? Is it a team player?)
If the answer to both those are yes, then you have an "interoperable" system.
To summarize, if your car needs to go where you want to go, first you need to know "where" you are going and then you need to drive it to your destination.
Tuesday, July 21, 2009
Acquire, Integrate, Deliver
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
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
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.
Subscribe to:
Posts (Atom)