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.
Subscribe to:
Posts (Atom)