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
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
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
The Return on Investment of EHRs
An experienced clinician recently emailed me, lamenting that Electronic Health Records do not have a return on investment i.e. doctors buy them, lose productivity, and do not get paid incrementally to justify the acquisition and use of EHRs.
This is indeed a complex issue. My answer to this clinician is below. I thought you'd find it interesting:
"The challenge is how to calculate Return on Investment i.e. who spends and who gets the return.
The literature suggests the e-prescribing reduces costs for pharmacies, payers, and providers (by reducing the burden on administrative staff to process renewals)
Decision support in an EHR results in better coordinated, appropriate, and less redundant care. However, it may be that the clinician pays for the decision support but the payer benefits from it through reduced claims.
To me, the Healthcare system (payers, providers, patients, employers, labs, pharmacies) achieves a substantial ROI through the use of EHRs which keep patients healthy and thus reduce costs.
To make the equation work, payers, hospitals, pharmacies and other beneficiaries of savings have to gainshare i.e. share the ROI with the providers. At BIDMC, I'm paying 85% of the implementation costs of EHRs for community physicians to better align incentives i.e. doctors do the work, the healthcare system benefits from care coordination and hospitals as one of those beneficiaries can subsidize costs.
Hopefully Medicare will start subsidizing EHRs so that the ROI is better aligned as I suggested in my letter to the President.
Soon, we'll have the outcome from the analysis of the Massachusetts eHealth Collaborative Project, the $50 million dollar BCBS pilot to implement medical records in 3 cities. I anticipate that it will conclude EHRs should be implemented to control costs, however the economics of how to pay for EHRs and encourage their ongoing use may require a novel scheme to 'redistribute the wealth'."
This is indeed a complex issue. My answer to this clinician is below. I thought you'd find it interesting:
"The challenge is how to calculate Return on Investment i.e. who spends and who gets the return.
The literature suggests the e-prescribing reduces costs for pharmacies, payers, and providers (by reducing the burden on administrative staff to process renewals)
Decision support in an EHR results in better coordinated, appropriate, and less redundant care. However, it may be that the clinician pays for the decision support but the payer benefits from it through reduced claims.
To me, the Healthcare system (payers, providers, patients, employers, labs, pharmacies) achieves a substantial ROI through the use of EHRs which keep patients healthy and thus reduce costs.
To make the equation work, payers, hospitals, pharmacies and other beneficiaries of savings have to gainshare i.e. share the ROI with the providers. At BIDMC, I'm paying 85% of the implementation costs of EHRs for community physicians to better align incentives i.e. doctors do the work, the healthcare system benefits from care coordination and hospitals as one of those beneficiaries can subsidize costs.
Hopefully Medicare will start subsidizing EHRs so that the ROI is better aligned as I suggested in my letter to the President.
Soon, we'll have the outcome from the analysis of the Massachusetts eHealth Collaborative Project, the $50 million dollar BCBS pilot to implement medical records in 3 cities. I anticipate that it will conclude EHRs should be implemented to control costs, however the economics of how to pay for EHRs and encourage their ongoing use may require a novel scheme to 'redistribute the wealth'."
Friday, October 24, 2008
Cool Technology of the Week
At BIDMC and other Caregroup hospitals, auditing is a critical component of HIPAA compliance and ensuring patient privacy. We currently have 1 billion rows of audit data from 146 mission critical clinical applications. Our comprehensive audits of every clinical lookup yield 300,000 – 500,000 transactions per day. HIPAA requires an audit system to record who is looking up what, where and why. We need to keep these audit logs for 20 years.The graphic above describes the unique approach we've taken with Microsoft SQL Server 2008 Enterprise Edition to implement a federated audit system that consolidates all our audit logs from multiple SQL Servers and non-SQL sources into one place. We use a SQL Server Integration Service (SSIS) package every 15 minutes to fetch through the Audit files and upload the data to Central SQL Audit DB Repository to capture:
i. Server level: all login in/out/failed events, and server configuration changes
ii. Database level: Create/Alter/Drop db events
iii. Object level: Create/Alter/Drop object events
iv. Data level: Insert/Update/delete and select events (we didn’t enable Select events in phase I)
Then, we use SQL Reports to query and view the audited data (i.e. who made this change, who modified a table, who insert/update/del a record)
Our next step is to process all audit data with SQL Server Analysis Services, create cubes to analyze the collected data, and build reports/alerts based on threshold (e.g. on average there are 10,000 logins/day, an alert will raise if we exceed the threshold)
Microsoft will be releasing soon a Compliance SDK on Security and Auditing based on their collaboration with BIDMC's SQL team. The SDK will be available for download so that other companies can use our Auditing solution as a model.
Creating an enterprise tool for consolidated storage, reporting and alerting of all application audit data - that's cool!
Thursday, October 23, 2008
Dear Mr. President
Technology Review, a great publication from MIT, asked me to write a letter to the incoming President, summarizing the healthcare IT agenda for the next administration. Here's what I wrote:
Dear Mr. President:
As you know, the United States is spending 16 percent of our gross domestic product on health care, a percentage that is likely to rise. That might be reasonable if we were getting correspondingly high quality, but we're not. While we have some of the best individual-care facilities in the world, our system does not rank well against other industrialized nations on basic health measures.
Health-care information technology is one of the major tools the United States can use to constrain cost increases and enhance quality. To date, the U.S. has adopted electronic health records (EHRs) at a much lower rate than most other industrialized nations, including Germany, Canada, the United Kingdom, and Australia. The U.S. spends 43 cents per capita on health-care IT, compared with $193 per capita in the U.K.
Incentives to introduce EHRs and a compelling business case for continuing to use them are crucial to getting the technology adopted on a wide scale. In the outpatient setting, implementing a system of EHRs that providers can easily share costs those providers $40,000 to $60,000. Yet most of the benefits go to payers and purchasers--often the U.S. government. To fix the misalignment, the government should offer incentives directly to providers.
We need to be careful, though, about what actions the government takes. A recent Congressional Budget Office report concluded that imposing penalties for failing to adopt health IT would be more cost effective than providing financial incentives. Primary-care physicians in the U.S. are already struggling with high costs and low reimbursement. Asking them to comply with another unfunded mandate based on penalties rather than incentives won't solve the problem, because it doesn't acknowledge the underlying economic misalignment that has discouraged adoption in the first place. The result won't be more EHRs; it will be fewer medical students choosing primary-care careers, which will fuel even greater increases in health-care costs.
I recommend a three-point plan for your administration:
(1) Provide incentives through Medicare for the adoption and use of EHRs. Target these incentives so that cost savings are shared with clinicians.
(2) Encourage insurers to provide incentives for hospitals to adopt CPOE (computerized physician order entry). This technology, which lets physicians communicate treatment instructions electronically, is the most important tool hospitals can introduce to improve their safety, quality, and efficiency of care.
(3) Continue to provide federal funding for technology and policies that encourage interoperability between health-care providers.
If we coordinate the care of all Americans and ensure that every person has a lifetime electronic record, we will enjoy safer care at a reasonable price.
Subscribe to:
Posts (Atom)
