Normally, this would be a Thursday blog entry, but because I wanted to devote two days to the ICD-10 question, I deferred my more personal weekly blog entry to today.
Post Labor Day always brings an immense amount of travel to conferences, Board meetings, and Washington policy events. This week is definitely planes, trains, and automobiles with craziness such as breakfast in Boston, Lunch in Washington and Dinner in New York, followed by Dinner in San Francisco, followed by Breakfast in Boston.
Although I do not usually frequent restaurants, I had a unique opportunity this week - to eat at the best vegetarian restaurant in New York City on Tuesday and the best vegetarian restaurant in San Francisco on Wednesday. Here's my brief reviews:
Candle 79 154 East 79th Street New York, NY 10021
Candle 79 is an acclaimed organic vegetarian restaurant specializing in fresh vegetable, tofu, seitan, and tempeh dishes. When we arrived at 8:30pm, the restaurant was packed with a line out the door. It's great to see New Yorkers flock to vegetarian and vegan food. I ordered two specials
Lentil, Arugula, Wild Mushroom, and Harvest Vegetable salad
Pumpkin seed coated Seitan with harvest vegetables and chipolte/black bean sauces
The presentation of the food was remarkable. The salad was extremely fresh, and a great blend of different textures and tastes. The spicy arugula was definitely a contrast to the typical steakhouse iceberg and tomato salad.
The Seitan was heavenly. A perfect blend of sauces, fresh vegetables, and a coating of pumpkin seeds.
The menu was filled with so many choices that I could easily eat at Candle 79 for a month without repeating myself.
Greens Fort Mason Center, San Francisco, CA 94123
When I arrived at 6:00pm, a local CSA was sorting fresh organic vegetables just outside the entrance to Greens. Definitely good karma.
I sat by the window overlooking the San Francisco Marina, watching the homebound traffic cross the Golden Gate Bridge.
Greens is affiliated with Green Gulch Farm/Zen Center and I started off with a great organic salad of fresh picked Green Gulch baby lettuces, heirloom apples, and pomegranate. Superb flavor and texture.
For my entree I had a squash and japanese eggplant lasagne - not your typical italian dish. This was a beautifully baked round stack of vegetables wrapped in a pasta covering. Tender Brocollini and root vegetables were served as sides.
Service and ambiance were great.
How do a compare the two experiences?
Candle 79 was like New York itself - a bit more edgy, energetic, and filled folks in their 20's. Vegan dishes filled the menu - no doubt that New Yorker Rory Freedman's cookbooks have popularized vegan cuisine.
Greens was filled with folks in their 50's, engaged in calm conversation, as you might expect in a Zen inspired restaurant. Most dishes have some artisan cheese in them, although Greens is happy to accommodate vegan diners with special pastas and by leaving ingredients out of their freshly prepared dishes.
Service in both spots was excellent. Vegetarian/Vegan servers are always friendly.
I enjoyed both immensely and look forward to returning to these spots as my travels take me from coast to coast.
Friday, October 31, 2008
Thursday, October 30, 2008
Healthy Halloween
Halloween has been celebrated since ancient times and the Druids, an ancient order of Celtic priests in Britain, believed that on the night before November 1 (Oct. 31), Samhain, the lord of the dead, called all the wicked spirits together. Since the Druids were afraid of these spirits, they chose that day to sacrifice, hoping they would be protected.During the middle ages, the Roman Catholic
ICD9, ICD10 and SNOMED, a guest blog
Knowing that yesterday's blog about ICD-10 would raise questions about how HITSP will incorporate ICD-10 into its future work products as well as the role of SNOMED verses ICD-10 as a clinical vocabulary, I asked one of our HITSP Technical Committee Co-chairs to give me his perspective. Jamie Ferguson leads standards efforts for Kaiser and he gave me his permission to publish his personal thoughts on ICD9, ICD10 and SNOMED, which provide helpful background about the issues. Jamie wrote:
"On the point that SNOMED and ICD-10 have the potential to be competing vocabularies, Kaiser Permanente's position is that ICD-10-CM/-PCS and SNOMED-CT are not competing vocabularies. As CMS noted in its NPRM, ICD-10 is a hierarchical classification system for billing and administrative purposes, whereas SNOMED is a knowledge-based ontology for clinical documentation and clinical decision-making purposes. SNOMED-CT is recommended for the US private sector and mandated for federal agencies for clinical documentation purposes as a result of its selection in the CHI initiative of OMB's e-Gov program. A one-way authoritative mapping from SNOMED-CT clinical documentation to the US ICD-10 billing codes is a current project and has been requested to be made official before the ICD-10 compliance date, i.e. published by an authoritative source such as NLM and cited by CMS, in comments on the NPRM from several multi-stakeholder organizations. Also, perhaps most importantly, for clinically-relevant analysis and clinical decision making the value of inference based operations such as subsumptive queries should not be underestimated. Therefore, KP would advise HITSP to make use of an authoritative mapping of clinical documentation (SNOMED) to administrative classification (ICD-10) when it is available and to include it as needed for its scenario solutions.
A further note on this was submitted to HHS by Kaiser Permanente as part of our public comments on the NPRM:
According to CMS, the benefits of transitioning to the ICD-10 code sets will include: 1) more accurate payments for new procedures; 2) fewer rejected or improper claims, i.e., fewer supplemental information requests will be required to support the medical necessity of claims and the details of procedures to be reimbursed; and 3) better understanding of new procedures. These improvements are aimed at providing more consistency in how conditions and treatment are captured for billing purposes because of the increased level of detail and specificity in the new code sets and are appropriately within the scope of the ICD-10 code sets adoption (73 FR 49821-23).
However, CMS has also identified potential benefits that go beyond the primary administrative purposes of the new ICD-10 code sets. These include improved disease management by payers, and better understanding of health conditions and health care outcomes. More specifically, CMS envisions using the ICD-10 codes within claims data to support a broad array of population health research and quality initiatives, such as: outcomes analysis, quality assessments, bio-surveillance, chronic care management, registries (including immunization registries), etc. (73 FR 49821, 49823-25). For these purposes, the SNOMED-CT is preferred because it is a knowledge-based ontology capable of inferences and subsumptive queries (e.g., “find all disorders that include “kidney””) whereas ICD is not, which among other reasons make SNOMED CT the coding system of choice for clinical documentation. Moreover, SNOMED CT codes can also be used for billing and reporting purposes without being inappropriately manipulated as CMS suggests (73 FR 49803). In fact, inference-based query systems render them more useful than billing classification systems for these reporting and analytical purposes related to population health and quality programs.
There is a distinction between coding for billing, which is relatively simple and coding for clinical documentation and decision-making, which is complex by comparison. As a result, we developed our clinical systems based on the SNOMED CT clinical terminology, which was specifically designed to support clinical decision-making and interoperability. For these reasons, we strongly support the continued use of SNOMED CT for these clinically relevant purposes and urge CMS to refrain from mandating the exclusive use of ICD-10 code sets for clinical purposes. We also note that using ICD-10 code sets for some of the cited purposes may conflict with the existing recognized federal standard, such as coding for the chief complaint or reason for visit. Those standards require SNOMED-CT in certain EHR and personal health record (“PHR”) systems, for electronic laboratory reporting, and for bio-surveillance, including public health reporting.
CMS also mentions that adoption will lead to harmonization of disease monitoring and reporting worldwide. However, these ICD-10 code sets are uniquely U.S. versions, so whether such harmonization is achievable is questionable.
HHS and OMB recommend adoption of SNOMED CT as the preferred coding system for clinical documentation in the Consolidated Health Informatics initiative within OMB’s e-Gov program, and SNOMED CT is the required clinical terminology standard in certain recognized HITSP Interoperability Specifications such as IS-01. "
Thus a strategy of using SNOMED CT for clinical observations such as problem lists while using ICD-10 for billing makes a great deal of sense. I imagine that the National Library of Medicine and vendors will develop products that will help turn SNOMED clinical documentation into accurate ICD-10 billing codes to streamline workflow and ensure appropriate coding.
"On the point that SNOMED and ICD-10 have the potential to be competing vocabularies, Kaiser Permanente's position is that ICD-10-CM/-PCS and SNOMED-CT are not competing vocabularies. As CMS noted in its NPRM, ICD-10 is a hierarchical classification system for billing and administrative purposes, whereas SNOMED is a knowledge-based ontology for clinical documentation and clinical decision-making purposes. SNOMED-CT is recommended for the US private sector and mandated for federal agencies for clinical documentation purposes as a result of its selection in the CHI initiative of OMB's e-Gov program. A one-way authoritative mapping from SNOMED-CT clinical documentation to the US ICD-10 billing codes is a current project and has been requested to be made official before the ICD-10 compliance date, i.e. published by an authoritative source such as NLM and cited by CMS, in comments on the NPRM from several multi-stakeholder organizations. Also, perhaps most importantly, for clinically-relevant analysis and clinical decision making the value of inference based operations such as subsumptive queries should not be underestimated. Therefore, KP would advise HITSP to make use of an authoritative mapping of clinical documentation (SNOMED) to administrative classification (ICD-10) when it is available and to include it as needed for its scenario solutions.
A further note on this was submitted to HHS by Kaiser Permanente as part of our public comments on the NPRM:
According to CMS, the benefits of transitioning to the ICD-10 code sets will include: 1) more accurate payments for new procedures; 2) fewer rejected or improper claims, i.e., fewer supplemental information requests will be required to support the medical necessity of claims and the details of procedures to be reimbursed; and 3) better understanding of new procedures. These improvements are aimed at providing more consistency in how conditions and treatment are captured for billing purposes because of the increased level of detail and specificity in the new code sets and are appropriately within the scope of the ICD-10 code sets adoption (73 FR 49821-23).
However, CMS has also identified potential benefits that go beyond the primary administrative purposes of the new ICD-10 code sets. These include improved disease management by payers, and better understanding of health conditions and health care outcomes. More specifically, CMS envisions using the ICD-10 codes within claims data to support a broad array of population health research and quality initiatives, such as: outcomes analysis, quality assessments, bio-surveillance, chronic care management, registries (including immunization registries), etc. (73 FR 49821, 49823-25). For these purposes, the SNOMED-CT is preferred because it is a knowledge-based ontology capable of inferences and subsumptive queries (e.g., “find all disorders that include “kidney””) whereas ICD is not, which among other reasons make SNOMED CT the coding system of choice for clinical documentation. Moreover, SNOMED CT codes can also be used for billing and reporting purposes without being inappropriately manipulated as CMS suggests (73 FR 49803). In fact, inference-based query systems render them more useful than billing classification systems for these reporting and analytical purposes related to population health and quality programs.
There is a distinction between coding for billing, which is relatively simple and coding for clinical documentation and decision-making, which is complex by comparison. As a result, we developed our clinical systems based on the SNOMED CT clinical terminology, which was specifically designed to support clinical decision-making and interoperability. For these reasons, we strongly support the continued use of SNOMED CT for these clinically relevant purposes and urge CMS to refrain from mandating the exclusive use of ICD-10 code sets for clinical purposes. We also note that using ICD-10 code sets for some of the cited purposes may conflict with the existing recognized federal standard, such as coding for the chief complaint or reason for visit. Those standards require SNOMED-CT in certain EHR and personal health record (“PHR”) systems, for electronic laboratory reporting, and for bio-surveillance, including public health reporting.
CMS also mentions that adoption will lead to harmonization of disease monitoring and reporting worldwide. However, these ICD-10 code sets are uniquely U.S. versions, so whether such harmonization is achievable is questionable.
HHS and OMB recommend adoption of SNOMED CT as the preferred coding system for clinical documentation in the Consolidated Health Informatics initiative within OMB’s e-Gov program, and SNOMED CT is the required clinical terminology standard in certain recognized HITSP Interoperability Specifications such as IS-01. "
Thus a strategy of using SNOMED CT for clinical observations such as problem lists while using ICD-10 for billing makes a great deal of sense. I imagine that the National Library of Medicine and vendors will develop products that will help turn SNOMED clinical documentation into accurate ICD-10 billing codes to streamline workflow and ensure appropriate coding.
Wednesday, October 29, 2008
Balance Testing - A New Gimmick With No Value
There are at least 5 things wrong with this offering that I (and presumably many other doctors) received in my mail this week. Perhaps you can think of more:#1. What is this thing? Balance is a big problem for seniors. A patient might think this is a high-tech, evidence based devise for diagnosis and treatment. Since the Medicare patient is far removed from paying the cost, it would be easy
The Transition to ICD-10
I'm always enthusiastic about the adoption of new standards that enhance semantic interoperability. The use of modern vocabulary standards such as ICD-10 improve administrative efficiency, enhance the ability of decision support systems to enforce guidelines, and enable a more granular reimbursement process.
The Centers for Medicare and Medicaid Services (CMS) circulated two Notices of Proposed Rulemaking (NPRM) on August 22, 2008 that require adoption of new standards for claims submission (X12 5010) and coding (ICD10)
The 5010 Proposed Rule - Health Insurance Reform; Modifications to the Health Insurance Portability and Accountability Act (HIPAA) Electronic Transaction Standards; Proposed Rule (73 Fed. Reg. 49742)
The ICD-10 Proposed Rule - HIPAA Administrative Simplification: Modification to Medical Data Code Set Standards To Adopt ICD-10-CM and ICD-10-PCS; Proposed Rule (73 Fed. Reg. 49706)
The first step in the transition to ICD-10 is the upgrade of the Electronic Transaction Standard (administrative data communications between payers and providers) from version 4010 to 5010. Once this upgrade is complete, the work on ICD-10 can begin. In the CMS NPRM, the deadline for 5010 implementation is April 1, 2010 and the deadline for ICD10 is October 1, 2011
As much as I support ICD-10, I also know that the change management effort to upgrade systems and train personnel will be huge. The Association of American Medical Colleges (AAMC) summarized the issues in a comment letter that was submitted to Secretary Leavitt.
Recently, the New England Health EDI Network (NEHEN), representing the payers and providers of Eastern Massachusetts, wrote comment letters to Secretary Leavitt recommending a longer transition timeline. By consensus, Massachusetts stakeholders recommended a 5010 implementation date of April 1, 2012 and an ICD10 implementation date of April 1, 2015.
Here are some of the issues NEHEN identified:
HHS expects that HIPAA 5010 and ICD-10 will run as concurrent projects. The supply of experienced and skilled resources to complete work on both efforts is limited. The accelerated implementation of both of these projects would create significant competition for scarce business and technical resources as well as project funding. This is not a recommended approach as it is a high risk, high cost implementation strategy.
The overall cost of implementing this change is technological and operational. For example, there must be modifications to existing training curriculum as well as claim submission and payment policies to ensure no adverse impact to the revenue cycle. I anticipate a real challenge to train, recruit, and retain ICD-10 savvy coders.
NEHEN also identified several unanswered questions:
When can covered entities expect to receive a complete mapping of ICD-9 to ICD-10 codes, both diagnosis and procedure?
What is the exact timeline for payers to be able to accept both ICD-9 and ICD-10 versus ICD-10 only? How does this impact the response transactions?
Should the code set used be validated based on the date of transmission? The start Date of Service or Discharge? The Payment date?
Are paper claim submissions required to use the ICD-10 code sets? If so, what is the timeline for this conversion and acceptance?
How does the change from the ICD-9 to the ICD-10 impact the other code sets used in the transactions (HCPCS, CPT-4, NDC, etc)?
ICD-10 is a needed change to replace the 30 year old ICD-9 coding vocabulary. As with any change, we need the time and resources to bring the people, processes, and systems to a future state while minimizing risks of business disruption. Hopefully CMS will revise its implementation deadlines based on all the comments from healthcare stakeholders so we can align the scope, timing and resources needed to do the project right.
The Centers for Medicare and Medicaid Services (CMS) circulated two Notices of Proposed Rulemaking (NPRM) on August 22, 2008 that require adoption of new standards for claims submission (X12 5010) and coding (ICD10)
The 5010 Proposed Rule - Health Insurance Reform; Modifications to the Health Insurance Portability and Accountability Act (HIPAA) Electronic Transaction Standards; Proposed Rule (73 Fed. Reg. 49742)
The ICD-10 Proposed Rule - HIPAA Administrative Simplification: Modification to Medical Data Code Set Standards To Adopt ICD-10-CM and ICD-10-PCS; Proposed Rule (73 Fed. Reg. 49706)
The first step in the transition to ICD-10 is the upgrade of the Electronic Transaction Standard (administrative data communications between payers and providers) from version 4010 to 5010. Once this upgrade is complete, the work on ICD-10 can begin. In the CMS NPRM, the deadline for 5010 implementation is April 1, 2010 and the deadline for ICD10 is October 1, 2011
As much as I support ICD-10, I also know that the change management effort to upgrade systems and train personnel will be huge. The Association of American Medical Colleges (AAMC) summarized the issues in a comment letter that was submitted to Secretary Leavitt.
Recently, the New England Health EDI Network (NEHEN), representing the payers and providers of Eastern Massachusetts, wrote comment letters to Secretary Leavitt recommending a longer transition timeline. By consensus, Massachusetts stakeholders recommended a 5010 implementation date of April 1, 2012 and an ICD10 implementation date of April 1, 2015.
Here are some of the issues NEHEN identified:
HHS expects that HIPAA 5010 and ICD-10 will run as concurrent projects. The supply of experienced and skilled resources to complete work on both efforts is limited. The accelerated implementation of both of these projects would create significant competition for scarce business and technical resources as well as project funding. This is not a recommended approach as it is a high risk, high cost implementation strategy.
The overall cost of implementing this change is technological and operational. For example, there must be modifications to existing training curriculum as well as claim submission and payment policies to ensure no adverse impact to the revenue cycle. I anticipate a real challenge to train, recruit, and retain ICD-10 savvy coders.
NEHEN also identified several unanswered questions:
When can covered entities expect to receive a complete mapping of ICD-9 to ICD-10 codes, both diagnosis and procedure?
What is the exact timeline for payers to be able to accept both ICD-9 and ICD-10 versus ICD-10 only? How does this impact the response transactions?
Should the code set used be validated based on the date of transmission? The start Date of Service or Discharge? The Payment date?
Are paper claim submissions required to use the ICD-10 code sets? If so, what is the timeline for this conversion and acceptance?
How does the change from the ICD-9 to the ICD-10 impact the other code sets used in the transactions (HCPCS, CPT-4, NDC, etc)?
ICD-10 is a needed change to replace the 30 year old ICD-9 coding vocabulary. As with any change, we need the time and resources to bring the people, processes, and systems to a future state while minimizing risks of business disruption. Hopefully CMS will revise its implementation deadlines based on all the comments from healthcare stakeholders so we can align the scope, timing and resources needed to do the project right.
Tuesday, October 28, 2008
Removing Complexity
"Fools ignore complexity. Pragmatists suffer it. Geniuses remove it."
Alan Perlis (Creator of ALGOL, one of the first programming languages)
Whenever I purchase something for myself or my home, I always think about the complexity that the purchase will add to my life. Adding more stuff to my life can lead to short term gratification, but it also can lead to long term maintenance headaches.
The same can be said of information technology. Here a few examples:
1. A few years ago, I had dinner with Steve Ballmer and explained that Microsoft should produce secure, reliable products with fewer features and lower cost. Who really wants their outline reformatted by the Outline Wizard in Word? Who really wants to apply the latest emergency patch that's required because of too much code supporting too many seldom used features? He explained that I was mistaken since most people use 95% of the features in Office and the average user prioritizes new features over everything else. We agreed to disagree and he returned to Redmond to manage the creation of Vista.
2. At BIDMC, we buy and build software. Every time we buy a commercial product we need to think about interfaces from our existing systems to the new product and from the new product to our existing systems. All those interfaces add significant complexity, makes recovery from downtime more difficult and increase the cost of support. Recently, a clinician commented that one of our new software purchases really surprised her, since it added complexity, fractured workflow, and inconvenienced many users for the benefit of a few.
3. When we build software, we are often tempted to add all the bells and whistles requested by the user. For each new custom feature there is a cost of maintenance, additional training, and potential bugs that could compromise stability/reliability. I've been involved in many development projects that eventually became so complex that the software had to be rewritten to ensure usability, security and maintainability.
4. Customizing commercial packages seems like a good idea to get the buy in of stakeholders. Over my past decade as a CIO, I've found that stakeholders come and go, and when they leave, all the esoteric customizations they designed are often retired. In fact, many upgrade projects include the retirement of all the previous customizations that became an impediment to life cycle management of software, added complexity, and over the long term were more hassle than benefit.
5. Best of breed seems like a good idea when you're comparing products based on narrowly focused requirements. We did that with our email system i.e. Exchange for general email functions, Brightmail for spam protection, McAfee for virus protection, Tumbleweed for secure email transmission, SendMail for SMTP gateways etc. The end result was a feature rich system that has been too challenging to maintain and debug. Our next purchase will be an appliance from a single vendor which consolidates Spam filtering and security into a single product.
In short, complexity is generally not a good thing. What am I doing to battle complexity?
I try to use the fewest number of vendors possible - one (or at most two) storage vendors, one desktop vendor, one network vendor, and a very few application vendors. The more vendors, the greater the integration effort, the increased support and maintenance burden and the higher the cost.
I aim to avoid customizing commercial software whenever possible. My experience is that customizations are rarely worth the investment. Once customizations are in place and the users really understand the implications to workflow, cost, and impediments to future upgrades, they are no longer so enthusiastic about them.
I use enterprise-wide generalizable tools whenever possible i.e. one content management system for the web, one means of authentication/single signon, one ERP system for all fiscal/administrative functions.
How are we seeing this "removing complexity" idea play out in the industry?
People are adopting Gmail, Google Apps, and Facebook as "good enough" productivity tools.
People are adopting commodity hardware, clustered together using basic Linux operating systems, instead of proprietary niche solutions.
People are using Software as a Service offerings with thin client computers running nothing more than a browser. Even Microsoft has embraced the new reality of cloud computing, demonstrating a willingness to eliminate the complexity of its current operating system and application environment.
In the world of IT, simplicity is often more reliable, more secure, and more usable. Whenever I'm tempted to add complexity to address the needs of a few customers, I remind myself that Less is More. Per the Alan Perlis quote above, we should all strive to be geniuses!
Alan Perlis (Creator of ALGOL, one of the first programming languages)
Whenever I purchase something for myself or my home, I always think about the complexity that the purchase will add to my life. Adding more stuff to my life can lead to short term gratification, but it also can lead to long term maintenance headaches.
The same can be said of information technology. Here a few examples:
1. A few years ago, I had dinner with Steve Ballmer and explained that Microsoft should produce secure, reliable products with fewer features and lower cost. Who really wants their outline reformatted by the Outline Wizard in Word? Who really wants to apply the latest emergency patch that's required because of too much code supporting too many seldom used features? He explained that I was mistaken since most people use 95% of the features in Office and the average user prioritizes new features over everything else. We agreed to disagree and he returned to Redmond to manage the creation of Vista.
2. At BIDMC, we buy and build software. Every time we buy a commercial product we need to think about interfaces from our existing systems to the new product and from the new product to our existing systems. All those interfaces add significant complexity, makes recovery from downtime more difficult and increase the cost of support. Recently, a clinician commented that one of our new software purchases really surprised her, since it added complexity, fractured workflow, and inconvenienced many users for the benefit of a few.
3. When we build software, we are often tempted to add all the bells and whistles requested by the user. For each new custom feature there is a cost of maintenance, additional training, and potential bugs that could compromise stability/reliability. I've been involved in many development projects that eventually became so complex that the software had to be rewritten to ensure usability, security and maintainability.
4. Customizing commercial packages seems like a good idea to get the buy in of stakeholders. Over my past decade as a CIO, I've found that stakeholders come and go, and when they leave, all the esoteric customizations they designed are often retired. In fact, many upgrade projects include the retirement of all the previous customizations that became an impediment to life cycle management of software, added complexity, and over the long term were more hassle than benefit.
5. Best of breed seems like a good idea when you're comparing products based on narrowly focused requirements. We did that with our email system i.e. Exchange for general email functions, Brightmail for spam protection, McAfee for virus protection, Tumbleweed for secure email transmission, SendMail for SMTP gateways etc. The end result was a feature rich system that has been too challenging to maintain and debug. Our next purchase will be an appliance from a single vendor which consolidates Spam filtering and security into a single product.
In short, complexity is generally not a good thing. What am I doing to battle complexity?
I try to use the fewest number of vendors possible - one (or at most two) storage vendors, one desktop vendor, one network vendor, and a very few application vendors. The more vendors, the greater the integration effort, the increased support and maintenance burden and the higher the cost.
I aim to avoid customizing commercial software whenever possible. My experience is that customizations are rarely worth the investment. Once customizations are in place and the users really understand the implications to workflow, cost, and impediments to future upgrades, they are no longer so enthusiastic about them.
I use enterprise-wide generalizable tools whenever possible i.e. one content management system for the web, one means of authentication/single signon, one ERP system for all fiscal/administrative functions.
How are we seeing this "removing complexity" idea play out in the industry?
People are adopting Gmail, Google Apps, and Facebook as "good enough" productivity tools.
People are adopting commodity hardware, clustered together using basic Linux operating systems, instead of proprietary niche solutions.
People are using Software as a Service offerings with thin client computers running nothing more than a browser. Even Microsoft has embraced the new reality of cloud computing, demonstrating a willingness to eliminate the complexity of its current operating system and application environment.
In the world of IT, simplicity is often more reliable, more secure, and more usable. Whenever I'm tempted to add complexity to address the needs of a few customers, I remind myself that Less is More. Per the Alan Perlis quote above, we should all strive to be geniuses!
Monday, October 27, 2008
Why Doctors Want To do Procedures Rather than Diagnose
The Happy Hospitalist wrote a blog that addresses many issues in health care. It answers why doctors are fleeing from primary care specialties into the procedure specialties (Derm, GI, Cardiology, Interventional Radiology, Urology, Anesthesiology, Surgery). It also gives a peak into the Byzantine coding requirements that are required of Physicians by Medicare and continued by every health
Subscribe to:
Posts (Atom)