Alright, now that I have your attention by throwing out the biggest buzzword of recent times (watch it, if I still don't have your attention, I might start talking about 2012!!), I cringe every time I hear the word Cloud Computing being equated with "redundant data storage", "ASP" (application service provider) model applications, "load balancing" and "SaaS". Can I throw out some simple definitions out there? No? Well, I am going to, anyway!
SaaS - Software as a Service. Much like leasing a car. Instead of paying a one time purchase price, you pay over time. It is not new architecture or software, folks, it is a method of payment.
Load Balancing - You call in to a call center. "Please hold while we find the next available representative....". Not new architecture or software. Just finding the next available resource to answer your question.
ASP - Application Service Provider. Bill Pay Online anyone? Also, see SaaS. Not new architecture or software.
Storage of Data at Multiple Locations - Redundancy? Mirroring? Disaster Recovery? Not new architecture or software.
So, my dear sales person, please read Wikipedia before you call your application "Cloud enabled" or "water vapor" or any new term that your marketing folks thought up.
Internal Directive to Meta Analytix employees:
Starting immediately, please re-do our website and use the word "Cloud Computing" everywhere.
Sales: Please tell everyone our products are "SaaS enabled" and "Cloud Enabled".
Marketing: Please come up with some snazzy terms. I am thinking "SaaSy" or "Cloudy"
Technology: Enjoy your vacation. I will see you all next year.
--Your President
Friday, December 4, 2009
Tuesday, November 3, 2009
The "Un" Case Study - The never ending Informatics Initiative!!
I play golf. In fact, I am sort of obsessed with it at the moment. Recently, a friend of mine invited his co-worker to play with us. I welcomed him as a friend of a friend and went to play. The man, first of all, showed up while we were on the 5th hole. Then he joins us (thank God the rangers never found out) and starts playing. Long story short, every time any one of us tried to make a shot, he would loudly point out that it was our "2nd", "3rd" or "4th" shot and "cheer" us to make the shot! I kid you not, he did a "back flip" on the golf course when he chipped a ball in straight to the hole. At the 18th, since he had fewer number of shots on the hole than either of us, he decided that he was the "winner". Needless to say, he was never invited again. My friend profusely apologized to the rest of us.
How does it relate to Informatics, you ask? Well, consider this. You are in the market for a vendor ( as I have said earlier in one of my blogs, I don't like the term "vendor" when it comes to Informatics initiatives. I think of it as a partnership, because, guess what, if the initiative fails, so do we and vice versa ). So you are in the market for a "partner" to take you through a complex informatics initiative. You ask your friends and a friend suggest "OverPriced Consulting" as a partner because she has heard good things about them. "OverPriced" does a presentation for you and tell you about all the clients they have and how they have had "successes" with other firms. You feel warm and fuzzy. You hire them to implement your initiative. They come in with their solutions architects and do a "roadmap" for you (3 months, $150K). Looks good. The roadmap includes a project plan with their technologists, data modelers, ETL architects, developers and BI architects and developers. The Solution Architects have moved on to other clients by now. They suggest you buy Cognos/Business Objects and AbInitio/Informatica.
"Isn't the price tag a bit steep?" You ask. Scalability, Metadata management, Data governance and other terms convince you that you need the Ferrari instead of the Prius. All the time, they cheer you on as to what a great purchase you made and you can't go wrong with these purchases.
3 monhs later, you find out that Cognos can't write to the database and you need a Java interface to manage security. 8 months and $5M later, you are still working on bringing data to your warehouse and the blame game starts. Fault of the product we purchased, dependency issues, data not in the right format, data quality issues....the list goes on.
What went wrong? Let's look at the golf game I talked about. First of all, he was late. We should've told him to come another day. But since he was already there, we let him play, starting from the 5th hole! But since he is a friend of a friend, we thought it would be ok. He started "cheering" us. We should've stopped and taught him some golf etiquette. We never did. He is the friend of a friend after all! At the 18th and a painful 13 holes at that, he declared that he was the winner. By that time, we were licking our wounds and too anxious to get out of there that we didn't care.
Parallel, you ask to the informatics initiative? Even with the company you hired having a great reputation and being a "known" entity, they never stopped to do the "first"thing in an informatics initiative. "Define your measures". They put together a "roadmap" and said you needed the Ferrari. What they should've done is to look at your measurements, what data elements you needed, what requirements you had (security and others), do a gap analysis with your existing technology and "then" suggest what technology to buy.
It is a "partnership" folks. While we are all in business to add to our bottom lines, the responsibility of executing lie in the hand of the "vendor" and you. So remember, if someone walks on your line on the green, call them out on it!
How does it relate to Informatics, you ask? Well, consider this. You are in the market for a vendor ( as I have said earlier in one of my blogs, I don't like the term "vendor" when it comes to Informatics initiatives. I think of it as a partnership, because, guess what, if the initiative fails, so do we and vice versa ). So you are in the market for a "partner" to take you through a complex informatics initiative. You ask your friends and a friend suggest "OverPriced Consulting" as a partner because she has heard good things about them. "OverPriced" does a presentation for you and tell you about all the clients they have and how they have had "successes" with other firms. You feel warm and fuzzy. You hire them to implement your initiative. They come in with their solutions architects and do a "roadmap" for you (3 months, $150K). Looks good. The roadmap includes a project plan with their technologists, data modelers, ETL architects, developers and BI architects and developers. The Solution Architects have moved on to other clients by now. They suggest you buy Cognos/Business Objects and AbInitio/Informatica.
"Isn't the price tag a bit steep?" You ask. Scalability, Metadata management, Data governance and other terms convince you that you need the Ferrari instead of the Prius. All the time, they cheer you on as to what a great purchase you made and you can't go wrong with these purchases.
3 monhs later, you find out that Cognos can't write to the database and you need a Java interface to manage security. 8 months and $5M later, you are still working on bringing data to your warehouse and the blame game starts. Fault of the product we purchased, dependency issues, data not in the right format, data quality issues....the list goes on.
What went wrong? Let's look at the golf game I talked about. First of all, he was late. We should've told him to come another day. But since he was already there, we let him play, starting from the 5th hole! But since he is a friend of a friend, we thought it would be ok. He started "cheering" us. We should've stopped and taught him some golf etiquette. We never did. He is the friend of a friend after all! At the 18th and a painful 13 holes at that, he declared that he was the winner. By that time, we were licking our wounds and too anxious to get out of there that we didn't care.
Parallel, you ask to the informatics initiative? Even with the company you hired having a great reputation and being a "known" entity, they never stopped to do the "first"thing in an informatics initiative. "Define your measures". They put together a "roadmap" and said you needed the Ferrari. What they should've done is to look at your measurements, what data elements you needed, what requirements you had (security and others), do a gap analysis with your existing technology and "then" suggest what technology to buy.
It is a "partnership" folks. While we are all in business to add to our bottom lines, the responsibility of executing lie in the hand of the "vendor" and you. So remember, if someone walks on your line on the green, call them out on it!
Monday, October 19, 2009
K.I.S.S Method
Ever since we published our whitepaper called Value-1000, I have been asked several times "why so simple?" "What about a transformation curve approach?", "What about weighting the measures"? Well folks, I subscribe to the K.I.S.S method. And I am not talking about smooching.
To weigh or not to weigh?
While weighting has it's benefits in some other industries, I just can't wrap my head around "weighing" a measure in healthcare. If we divide measures into several groups, then maybe. But when it comes to patient care measures, I don't think it is the right approach. Let me explain. There has been a paper published that talked about adding weights to severity of outcome. Arguably, Patient mortality can be considered the worst outcome ever and we can give it a weight of 100 (max available, let's say, for example's sake). So, we add a weight depending on the severity of the outcome. My problem is this: the weightage of any measure is decided by a person or a panel that decides that this should be the weightage given to a particular measure. An athlete who became a quadriplegic, but lived might argue that the severity of her care outcome is as severe as Patient mortality and hence should be given the same weightage. To me, it is subjective. The subjectivity in care should be left to the experts, if you ask me and that expert is not I. It is the "provider", in my humble opinion.
Curving
Sure, we can "curve". But to get to the curve, we still need to collect data points based on one or more algorithms for each measure.
So, in Value 1000, we are only talking about "one" approach of measuring quality in healthcare. The paper is not intended to be the "be all, end all" approach either. It is intended to generate discussion and ideas. So feel free to send me comments about it. And if you have a great idea on measuring quality, publish it!
To weigh or not to weigh?
While weighting has it's benefits in some other industries, I just can't wrap my head around "weighing" a measure in healthcare. If we divide measures into several groups, then maybe. But when it comes to patient care measures, I don't think it is the right approach. Let me explain. There has been a paper published that talked about adding weights to severity of outcome. Arguably, Patient mortality can be considered the worst outcome ever and we can give it a weight of 100 (max available, let's say, for example's sake). So, we add a weight depending on the severity of the outcome. My problem is this: the weightage of any measure is decided by a person or a panel that decides that this should be the weightage given to a particular measure. An athlete who became a quadriplegic, but lived might argue that the severity of her care outcome is as severe as Patient mortality and hence should be given the same weightage. To me, it is subjective. The subjectivity in care should be left to the experts, if you ask me and that expert is not I. It is the "provider", in my humble opinion.
Curving
Sure, we can "curve". But to get to the curve, we still need to collect data points based on one or more algorithms for each measure.
So, in Value 1000, we are only talking about "one" approach of measuring quality in healthcare. The paper is not intended to be the "be all, end all" approach either. It is intended to generate discussion and ideas. So feel free to send me comments about it. And if you have a great idea on measuring quality, publish it!
Tuesday, October 13, 2009
Buzz (kill) Words!
If you have talked to a technologist or a technology sales person lately, you have certainly heard of SaaS, Cloud, Disruptive Innovation etc. Hmmm... "disruptive" innovation? Do you really have to say that innovation is "disruptive"? Didn't people stop riding horses to work when cars came around? So, when you are trying to choose your informatics solution, kick the first sales person that tells you that their solution is "in the cloud"!
Cloud is Water Vapor!
Don't believe me? Ask Larry Ellison, the CEO of Oracle (http://www.youtube.com/watch?v=8UYa6gQC14o). So what prompted him to give a (ahem) "passionate" speech about the cloud?
Let's examine the facts. If you really want to put your software "in the cloud", a fundamental engineering shift is needed than what is being purported as cloud computing. The closest thing we have seen to a truly "cloud" architected software, is the screensaver that SETI(Search for Extraterrestrial Intelligence...to you and me, that is looking for E.T! ) put out 10 years ago (http://www.planetary.org/news/2009/0521_SETIhome_Celebrates_10_Years_of.html). Yes folks, "Cloud" computing happened back then! People downloaded the screensaver, and when they were not using their computers, the screensaver kicked in and started analyzing data for SETI, sending data back to their main computers once the analysis was done.
What is being sold as "cloud" computing today is nothing but a software that resides on one or more servers at the vendor's data center. In other words......wait for it....an ASP model! Remember that term? Application Service Provider model? Remember all the VCs who wanted to invest only in ASP model companies? Now, here is the kicker. Application Service Provider - Software as a Service (SaaS). You "lease" the software. Just like leasing a car. See the similarity? Are you seeing a pattern here? So, yes, I agree with Mr. Ellison..." we change the term and think that we have invented technology...".
The point being, forget cloud, forget SaaS, look for "functionality" in the software. Can it deliver what you need? Once you have ascertained that, then you can think of where it is going to be hosted!
Cloud is Water Vapor!
Don't believe me? Ask Larry Ellison, the CEO of Oracle (http://www.youtube.com/watch?v=8UYa6gQC14o). So what prompted him to give a (ahem) "passionate" speech about the cloud?
Let's examine the facts. If you really want to put your software "in the cloud", a fundamental engineering shift is needed than what is being purported as cloud computing. The closest thing we have seen to a truly "cloud" architected software, is the screensaver that SETI(Search for Extraterrestrial Intelligence...to you and me, that is looking for E.T! ) put out 10 years ago (http://www.planetary.org/news/2009/0521_SETIhome_Celebrates_10_Years_of.html). Yes folks, "Cloud" computing happened back then! People downloaded the screensaver, and when they were not using their computers, the screensaver kicked in and started analyzing data for SETI, sending data back to their main computers once the analysis was done.
What is being sold as "cloud" computing today is nothing but a software that resides on one or more servers at the vendor's data center. In other words......wait for it....an ASP model! Remember that term? Application Service Provider model? Remember all the VCs who wanted to invest only in ASP model companies? Now, here is the kicker. Application Service Provider - Software as a Service (SaaS). You "lease" the software. Just like leasing a car. See the similarity? Are you seeing a pattern here? So, yes, I agree with Mr. Ellison..." we change the term and think that we have invented technology...".
The point being, forget cloud, forget SaaS, look for "functionality" in the software. Can it deliver what you need? Once you have ascertained that, then you can think of where it is going to be hosted!
Tuesday, October 6, 2009
Value 1000 - A practical proposal for measuring quality
The healthcare industry is abuzz and almost obsessed with improving quality of care and reducing cost of coverage. While there are several proposals out there on how to do this, the big question still remains. How do we "measure" and "reward" quality? Mayo’s recent recommendation of Medicare Value Indexing is a step in the right direction. Well we took it a step further and explored some ways of actually implementing it.
Here is a proposal that we think could add value and is simple enough to implement. And don't flame me, you Six Sigma people! I actually do know karate!
You can download the white paper (it's FREE, people!) from here :
http://www.metaanalytix.com/whitepaper_value1000.html
Let me know your feedback
Here is a proposal that we think could add value and is simple enough to implement. And don't flame me, you Six Sigma people! I actually do know karate!
You can download the white paper (it's FREE, people!) from here :
http://www.metaanalytix.com/whitepaper_value1000.html
Let me know your feedback
Thursday, October 1, 2009
Buying an EHR - What you need to know
I have been asked many a time as to how to make the decision of buying an EHR system. I love cars, so I am going to talk about cars for a while! You may ask what car buying has to do with EHR buying. Read on!
Tool vs. Product vs. Solution
So you are in the market for a "fuel-efficient" car that can take your kids to soccer practice and be good enough to take you to work and shopping and you are proud to show your co-workers. You don't come back from that shopping trip with a spanner, do you? Nor do you buy just any car that is on the lot and walk away. Well, let's look at the evaluation criteria you employed in buying the car. A spanner is a "tool" that may have been used in the building of a car. The car itself is the "product". The "solution" was a fully loaded car (or minivan) with third row seating, fuel-efficient, loaded with fuel, registered with the state and a jazzy thing that you are proud to show your co-workers the next day!
So, let's break it down:
Criteria #1: Identify the need (you "needed" a new car which is why you were in the market)
Criteria #2: Choose the product ( Had to have a steering wheel, tires, doors, third row seating, fuel efficient etc.) that satisfied the need.
Criteria #3: Is the product green "certified"?
Criteria $4: Can I show it to my co-workers and not be ashamed?
Let's apply the same concept to EHR buying. There are several "tools" in the market. They might be "certified" tools. There might be several "products" in the market. They too, might be "certified". But the question you have to ask yourself is, is that "solution" going to fit my "need".
Criteria #1: So, identify your "need" first. Why are you buying the EHR? Compliance with ARRA? Want to make your practice more efficient? Reduce your costs?
Criteria #2: Choose the product. Can your practice run on it? What additional "functionality" do you need? Is it suited for the way you conduct your day to day business?
Criteria #3: Is it certified? (This question arises if your primary reason for adopting an EHR system is compliance and getting some of the stimulus funds)
Criteria #4: Well, this doesn't apply to EHR buying, but you can tout yourself to be on the "bleeding edge" (pun intended) of technology and show everyone how cool you are :)
Tool vs. Product vs. Solution
So you are in the market for a "fuel-efficient" car that can take your kids to soccer practice and be good enough to take you to work and shopping and you are proud to show your co-workers. You don't come back from that shopping trip with a spanner, do you? Nor do you buy just any car that is on the lot and walk away. Well, let's look at the evaluation criteria you employed in buying the car. A spanner is a "tool" that may have been used in the building of a car. The car itself is the "product". The "solution" was a fully loaded car (or minivan) with third row seating, fuel-efficient, loaded with fuel, registered with the state and a jazzy thing that you are proud to show your co-workers the next day!
So, let's break it down:
Criteria #1: Identify the need (you "needed" a new car which is why you were in the market)
Criteria #2: Choose the product ( Had to have a steering wheel, tires, doors, third row seating, fuel efficient etc.) that satisfied the need.
Criteria #3: Is the product green "certified"?
Criteria $4: Can I show it to my co-workers and not be ashamed?
Let's apply the same concept to EHR buying. There are several "tools" in the market. They might be "certified" tools. There might be several "products" in the market. They too, might be "certified". But the question you have to ask yourself is, is that "solution" going to fit my "need".
Criteria #1: So, identify your "need" first. Why are you buying the EHR? Compliance with ARRA? Want to make your practice more efficient? Reduce your costs?
Criteria #2: Choose the product. Can your practice run on it? What additional "functionality" do you need? Is it suited for the way you conduct your day to day business?
Criteria #3: Is it certified? (This question arises if your primary reason for adopting an EHR system is compliance and getting some of the stimulus funds)
Criteria #4: Well, this doesn't apply to EHR buying, but you can tout yourself to be on the "bleeding edge" (pun intended) of technology and show everyone how cool you are :)
Monday, September 28, 2009
Failures!
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.
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 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.
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)