On October 1, 2013, the entire US healthcare system will shift from ICD9 to ICD10. It will be one of the largest, most expensive and riskiest transitions that healthcare CIOs will experience in their careers, affecting every clinical and financial system. It's a kind of Y2k for healthcare.
Most large provider and payer organizations, have a ICD10 project budget of $50-100 million, which is interesting because the ICD10 final rule estimated the cost as .03% of revenue. For BIDMC, that would be about $450,000. Our project budget estimates are about ten times that.
CMS and HHS have significant reasons for wanting to move forward with ICD10 including
1) easier detection of fraud and abuse given the granularity of ICD10 i.e. having 3 comminuted distal radius fractures of your right arm within 3 weeks would be unlikely
2) more detailed quality reporting
3) administrative data will contain more clinical detail enabling more refined reimbursement
Large healthcare organizations have already been working hard on ICD10, so they have sunk costs and a fixed run rate for their project management office. At this point, any extension of the deadline would cost them more.
Most small to medium healthcare organizations are desperate. They are consumed with meaningful use, 5010, e-prescribing, healthcare reform, and compliance. They have no bandwidth or resources to execute a massive ICD10 project over the next 2 years.
Vendors have told me such things as "I have been amazed at how much we (and our third-party partners) are spending on getting prepared for ICD10 – and it's not what you would expect (extending data tables, new code lookup tools, etc.) It's a whole host of clinician assistance tools, new documentation workflows, new kinds of provider-facing decision support to maximize coding revenue while guarding against RAC audits - all simply for billing!"
In my CIO role, not any state or federal role, I will continue to listen to concerns about ICD10, sharing them broadly on my blog and with government leaders who will listen.
The Wall Street Journal recently published an article about the granularity of ICD10.
One of my staff posted this response, which is very thoughtful:
While nice-to-have, ICD-10 comes at a time when substantial cuts await providers. The "super committee" is deliberating on these now for Medicare and Medicaid. Adding more administrative overhead to the U.S. healthcare system is untimely and will ultimately impact clinical care. Our health care system already has twice the administrative overhead of other advanced nations. We arguably have the most complex medical reimbursement system in the world. ICD-10 makes it worse.
When HHS published the requirement for ICD-10 in the January 16, 2009 Federal Register, they estimated transition costs for health care providers to be 0.03% of patient revenues. For a $1B medical center, this would be $300,000. Based on experience at our hospital and that of my colleagues at other hospitals, they missed it by a factor of 10 or more.
When a regulation of this magnitude is published, various laws and executive orders require a Regulatory Impact Analysis. Some requirements are intended to protect small businesses and non-profits from burdensome, unfunded federal mandates. The marginal cost estimate published in the Federal Register for ICD-10 was $2.966 billion over the period 2011 to 2025. Two-thirds of this was transitional cost. The benefits were estimated at $4.540 billion.
HHS has a tradition of low-balling cost estimates. Further evidence can be seen with recent estimates of HITECH privacy regulations.
If Congress was doing its job of regulatory oversight, they would sponsor hearings to learn what payers and providers are actually spending on ICD-10 conversion. Costs for consulting services alone run into the millions. This does not count the application software conversion, training and education, and other "in-house" costs. At our medical center, we would be paying $380,000 according to HHS estimates. Instead, the marginal cost of ICD-10 will be in excess of $5m. For multi-hospital systems, the costs may exceed $100m.
A Congressional review of transition costs would turn the regulatory impact assessment on its head. Costs could easily become double the estimated benefit savings.
With ICD-10, the government is perpetuating a reimbursement system that is far too complex. We spend more than any other country on healthcare administrative overhead. The Medicare Claims Processing Manual, for example, is over 4,000 pages in length. The reimbursement system needs simplification to bring the cost of this function in line with other industries.
Recently, HHS began promoting a "global payment" initiative. This had the potential for simplifying reimbursement, but they over-laid it on top of the existing system. Instead of substitution, it was additive. You bill as usual and then have a settlement process that adds one more layer of administrative overhead.
Unfortunately, there are too many activities within and outside the government whose livelihood depends on perpetuating this complex system. It is akin to the Internal Revenue Code. There are also groups who promote ICD-10 for its more granular health care research potential. This is laudable, but not affordable. There is no "free lunch". Every dollar spent on administrative overhead is one less dollar spent on clinical care.
What's needed is a fresh look at the reimbursement system. While ICD is used in other countries, it is not used for reimbursement purposes. Rather, it is used for health statistics and reporting. Using it for reimbursement adds an entirely different dimension. Because it is used for reimbursement, the U.S. version requires numerous extensions. Read this as more codes and more complexity.
Our health care system needs to change. If we are going to cut cost, let it be overhead, not clinical care.
Wednesday, September 21, 2011
Tuesday, September 20, 2011
Next Steps for Health Information Exchange in Massachusetts
Health Information Exchange (HIE) is challenging. As I've written about previously, several state HIEs have failed or are failing.
There are Federal HIE goals, State Medicaid goals, private sector goals, and many varied sources of funding. Each stakeholder has their own self interest.
The Harvard Program for Health Care Negotiation and Conflict Resolution teaches about the "Walk in Woods", moving from self interest, to enlarged interests, to enlightened interests, to aligned interests.
On September 19, the HIT Council and the HIT/HIE Advisory Committee of Massachusetts stakeholders took such a walk to review a straw man plan that aligns all the interests and optimizes available budgets.
Here's the idea.
There's an ONC-approved State Health Information Exchange plan. There's a State Medicaid plan. There are many existing regional health information exchanges in Massachusetts.
We created a Venn diagram of all these projects and identified their points of intersection.
Then, we developed objective criteria for what could be done now, what needs minor policy/technical work and what needs substantial additional work.
The end result was a phased plan making 2012 the year of connectivity to support push transactions, 2013 the year of databases to support analytics/population health and 2014 the year of the pull transaction.
We then worked on reconciling sources of funds.
There are two state programs with substantial federal matching grants - the Medicaid Management Information System (MMIS) and HITECH funds for State Medicaid Health Plans. Every dollar from state resources that is invested in these programs yields $10 of spending. A very wise use of state funds would be to leverage every dollar using federal matching programs. Since 100% of hospitals in Massachusetts receive Medicaid funds, Federal matching programs for Medicaid improvements are ideal for building the "information highway" to connect stakeholders as well as for state public health gateways to receive syndromic surveillance, reportable lab, and immunization data required by meaningful use.
However, what if we build the highway, but no one uses it? It's important to connect EHRs by overcoming technical and resource barriers. Our workgroups will devise a plan to create a grant or procurement program that leverages ONC HIE funds to accelerate EHR to HIE connectivity.
With senders, receivers, and a pipe connecting the stakeholders, we have a clear HIE plan.
With aligned federal, state and private resources, we can define the timelines and we've developed Gantt charts for all our FY12 projects.
To guide the projects, we'll have 3 "functionality" workgroups
Finance and Sustainability Workgroup,
Technology and Implementation Workgroup
Legal & Policy Workgroup
and 2 "engagement" workgroups
Provider engagement & Adoption Workgroup
Consumer and Public Engagement Workgroup
With clear goals that align the interests of all parties, a budget that optimizes every source of funds, and a multi-stakeholder Advisory Committee with community-wide participation in workgroups, we have the foundation to move forward.
As we proceed with a sense of urgency, our rallying cry to all stakeholders is "focus on making the HIE happen, not on the impediments and barriers that we'll encounter along the way."
I look forward to the work ahead and numerous go lives in FY12.
There are Federal HIE goals, State Medicaid goals, private sector goals, and many varied sources of funding. Each stakeholder has their own self interest.
The Harvard Program for Health Care Negotiation and Conflict Resolution teaches about the "Walk in Woods", moving from self interest, to enlarged interests, to enlightened interests, to aligned interests.
On September 19, the HIT Council and the HIT/HIE Advisory Committee of Massachusetts stakeholders took such a walk to review a straw man plan that aligns all the interests and optimizes available budgets.
Here's the idea.
There's an ONC-approved State Health Information Exchange plan. There's a State Medicaid plan. There are many existing regional health information exchanges in Massachusetts.
We created a Venn diagram of all these projects and identified their points of intersection.
Then, we developed objective criteria for what could be done now, what needs minor policy/technical work and what needs substantial additional work.
The end result was a phased plan making 2012 the year of connectivity to support push transactions, 2013 the year of databases to support analytics/population health and 2014 the year of the pull transaction.
We then worked on reconciling sources of funds.
There are two state programs with substantial federal matching grants - the Medicaid Management Information System (MMIS) and HITECH funds for State Medicaid Health Plans. Every dollar from state resources that is invested in these programs yields $10 of spending. A very wise use of state funds would be to leverage every dollar using federal matching programs. Since 100% of hospitals in Massachusetts receive Medicaid funds, Federal matching programs for Medicaid improvements are ideal for building the "information highway" to connect stakeholders as well as for state public health gateways to receive syndromic surveillance, reportable lab, and immunization data required by meaningful use.
However, what if we build the highway, but no one uses it? It's important to connect EHRs by overcoming technical and resource barriers. Our workgroups will devise a plan to create a grant or procurement program that leverages ONC HIE funds to accelerate EHR to HIE connectivity.
With senders, receivers, and a pipe connecting the stakeholders, we have a clear HIE plan.
With aligned federal, state and private resources, we can define the timelines and we've developed Gantt charts for all our FY12 projects.
To guide the projects, we'll have 3 "functionality" workgroups
Finance and Sustainability Workgroup,
Technology and Implementation Workgroup
Legal & Policy Workgroup
and 2 "engagement" workgroups
Provider engagement & Adoption Workgroup
Consumer and Public Engagement Workgroup
With clear goals that align the interests of all parties, a budget that optimizes every source of funds, and a multi-stakeholder Advisory Committee with community-wide participation in workgroups, we have the foundation to move forward.
As we proceed with a sense of urgency, our rallying cry to all stakeholders is "focus on making the HIE happen, not on the impediments and barriers that we'll encounter along the way."
I look forward to the work ahead and numerous go lives in FY12.
Monday, September 19, 2011
The CLIA/HIPAA NPRM - Patients’ Access to Test Reports
Can you access your lab test results directly via a non-tethered Personal Health Record like Microsoft Healthvault?
The Clinical Laboratory Improvement Amendments of 1988 (CLIA) requires that the ordering clinician receive the lab and then release it to the patient. HIPAA medical record access provisions excluded laboratories.
The September 14 Federal Register Notice of Proposed Rulemaking entitled CLIA Program and HIPAA Privacy Rule; Patients’ Access to Test Reports aims to change that:
"While individuals can obtain test results through the ordering provider, we believe that the advent of certain health reform concepts (for example, individualized medicine and an individual’s active involvement in his or her own health care) would be best served by revisiting the CLIA limitations on the disclosure of laboratory test results…
Therefore, in an effort to increase direct patient access rights, we are proposing that, upon a patient’s request, CLIA regulations would allow laboratories to provide direct patient access to completed test reports that, using the laboratory’s authentication processes, the laboratory can identify as belonging to that patient. "
Also, the HIPAA exemptions for laboratories would be removed
"In addition, this proposed rule would also amend the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule to provide individuals the right to receive their test reports directly from laboratories by removing the exceptions for CLIA-certified laboratories and CLIA-exempt laboratories from the provision that provides individuals with the right of access to their protected health information."
I believe this is a great NPRM and it's endorsed by many lab stakeholders including Quest.
On September 28, the HIT Standards Committee will discuss the content, vocabulary and transport standards that will enable HIEs to transmit labs to any stakeholder. With standards like HL7 2.51 for lab, LOINC, and Direct, a new generation of applications will be empowered as the NPRM becomes a final rule.
The Clinical Laboratory Improvement Amendments of 1988 (CLIA) requires that the ordering clinician receive the lab and then release it to the patient. HIPAA medical record access provisions excluded laboratories.
The September 14 Federal Register Notice of Proposed Rulemaking entitled CLIA Program and HIPAA Privacy Rule; Patients’ Access to Test Reports aims to change that:
"While individuals can obtain test results through the ordering provider, we believe that the advent of certain health reform concepts (for example, individualized medicine and an individual’s active involvement in his or her own health care) would be best served by revisiting the CLIA limitations on the disclosure of laboratory test results…
Therefore, in an effort to increase direct patient access rights, we are proposing that, upon a patient’s request, CLIA regulations would allow laboratories to provide direct patient access to completed test reports that, using the laboratory’s authentication processes, the laboratory can identify as belonging to that patient. "
Also, the HIPAA exemptions for laboratories would be removed
"In addition, this proposed rule would also amend the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy Rule to provide individuals the right to receive their test reports directly from laboratories by removing the exceptions for CLIA-certified laboratories and CLIA-exempt laboratories from the provision that provides individuals with the right of access to their protected health information."
I believe this is a great NPRM and it's endorsed by many lab stakeholders including Quest.
On September 28, the HIT Standards Committee will discuss the content, vocabulary and transport standards that will enable HIEs to transmit labs to any stakeholder. With standards like HL7 2.51 for lab, LOINC, and Direct, a new generation of applications will be empowered as the NPRM becomes a final rule.
Friday, September 16, 2011
Cool Technology of the Week
I've said that the paperless hospital is as likely as the paperless bathroom - an interesting goal but there are many practical barriers.
One of our approaches has been to use scanning of paper on our quest to create a single electronic location for all patient information, making the electronic record the only official record.
Putting scanners into our clinical areas is expensive and support intensive.
What if we could support scanning of documents and photographs by simply replacing the mouse on our desktops?
LG unveiled the world's first scanner mouse at CES 2011 that produces PNG, JPEG, TIFF, and PDF.
Here's a demonstration video.
It appears easy to use and saves on desk real estate.
A mouse with a built in scanner - that's cool!
One of our approaches has been to use scanning of paper on our quest to create a single electronic location for all patient information, making the electronic record the only official record.
Putting scanners into our clinical areas is expensive and support intensive.
What if we could support scanning of documents and photographs by simply replacing the mouse on our desktops?
LG unveiled the world's first scanner mouse at CES 2011 that produces PNG, JPEG, TIFF, and PDF.
Here's a demonstration video.
It appears easy to use and saves on desk real estate.
A mouse with a built in scanner - that's cool!
Thursday, September 15, 2011
Authority, Responsibility, and Risk
When I became CIO of CareGroup/BIDMC in 1998, I promised to listen to all my staff and collaboratively embrace technologies that would benefit patients while also enabling employee career growth. The IT team worked together to implement new infrastructure and new applications. Success led to an upward spiral of success. Other groups such as Media Services, Knowledge Services, and Health Information Management joined IS. We continued to grow in scope and capability.
My sense at the time was that additional authority, budget and span of control were great - more was better.
However, in my nearly 15 years as CIO, I've learned that while more authority may bring more opportunities to succeed, it also brings increased responsibility and with it, additional risk.
In a world of increasing regulatory pressures and compliance requirements, the likelihood of something bad happening every day in a large organization is high. The larger your role, the larger your risk.
Today in my BIDMC role I oversee
83 locations
18000 user accounts
9000 desktops/laptops/tablets
3000 printers
600 iPads
1600 iPhones
450 servers (200 physical, 250 virtual)
1.5 petabytes of storage
serving over a million patients.
If one employee copies data to a USB drive and loses it, a potential breach needs to be reported. If one workstation is infected with malware that could have transmitted clinical data to a third party, a potential breach needs to be reported. If one business associate loses an unencrypted laptop, a breach needs to be reported. 30,750 such breaches have been reported since HITECH took effect All breaches are the CIO's responsibility.
If one IT project is over time or over budget, it's the CIO's responsibility.
If one IT employee goes rogue, it's the CIO's responsibility.
If one server, network, or storage array fails, it's the CIO's responsibility
If one application causes patient harm, it's the CIO's responsibility
Life as a CIO can have its challenges!
At the same time that responsibilities are expanding, the number of auditors, regulators, lawyers, compliance specialists, and complex regulations is growing at a much faster rate than IT resources.
There are three solutions
1. Spend increasing amounts of time on risk identification and mitigation
2. Reduce your responsibility/accountability and thus your risk footprint
3. Find a nice cabin in the woods and homestead as far away from regulatory burdens as possible
I'm doing #1 - about 20% of my day is spent on matters of risk, compliance, and regulation. I'm doing #2 by transitioning my CIO role at Harvard Medical School to a successor. #3 sounds appealing but I'm not there yet!
As healthcare CIOs face new regulations for e-prescribing of controlled substances, FDA device safety requirements, 5010 implementation, ICD-10, new privacy rules, and Meaningful Use stages 1-2-3, the magnitude of the challenges ahead may at times seem overwhelming. I sometimes long for the days when all I had to do was write innovative software and create a nurturing environment for my staff!
There are 3 negative consequences that can result from overzealous regulation:
1. The joy of success can turn into a fear of compliance failure
2. Compliance can create such overhead that we lose our competitiveness
3. We'll become less entrepreneurial because the consequences of non-compliance, such as loss of reputation, penalties, and burden of responding to agencies enforcing regulations, become a deterrent to innovation.
For now, I have accepted the risks that come with all my responsibilities, but at some point, the balance may become more challenging to maintain. As we move forward, I hope that policymakers in Washington and at the state level will be mindful of the unintended consequences of regulatory complexity.
My sense at the time was that additional authority, budget and span of control were great - more was better.
However, in my nearly 15 years as CIO, I've learned that while more authority may bring more opportunities to succeed, it also brings increased responsibility and with it, additional risk.
In a world of increasing regulatory pressures and compliance requirements, the likelihood of something bad happening every day in a large organization is high. The larger your role, the larger your risk.
Today in my BIDMC role I oversee
83 locations
18000 user accounts
9000 desktops/laptops/tablets
3000 printers
600 iPads
1600 iPhones
450 servers (200 physical, 250 virtual)
1.5 petabytes of storage
serving over a million patients.
If one employee copies data to a USB drive and loses it, a potential breach needs to be reported. If one workstation is infected with malware that could have transmitted clinical data to a third party, a potential breach needs to be reported. If one business associate loses an unencrypted laptop, a breach needs to be reported. 30,750 such breaches have been reported since HITECH took effect All breaches are the CIO's responsibility.
If one IT project is over time or over budget, it's the CIO's responsibility.
If one IT employee goes rogue, it's the CIO's responsibility.
If one server, network, or storage array fails, it's the CIO's responsibility
If one application causes patient harm, it's the CIO's responsibility
Life as a CIO can have its challenges!
At the same time that responsibilities are expanding, the number of auditors, regulators, lawyers, compliance specialists, and complex regulations is growing at a much faster rate than IT resources.
There are three solutions
1. Spend increasing amounts of time on risk identification and mitigation
2. Reduce your responsibility/accountability and thus your risk footprint
3. Find a nice cabin in the woods and homestead as far away from regulatory burdens as possible
I'm doing #1 - about 20% of my day is spent on matters of risk, compliance, and regulation. I'm doing #2 by transitioning my CIO role at Harvard Medical School to a successor. #3 sounds appealing but I'm not there yet!
As healthcare CIOs face new regulations for e-prescribing of controlled substances, FDA device safety requirements, 5010 implementation, ICD-10, new privacy rules, and Meaningful Use stages 1-2-3, the magnitude of the challenges ahead may at times seem overwhelming. I sometimes long for the days when all I had to do was write innovative software and create a nurturing environment for my staff!
There are 3 negative consequences that can result from overzealous regulation:
1. The joy of success can turn into a fear of compliance failure
2. Compliance can create such overhead that we lose our competitiveness
3. We'll become less entrepreneurial because the consequences of non-compliance, such as loss of reputation, penalties, and burden of responding to agencies enforcing regulations, become a deterrent to innovation.
For now, I have accepted the risks that come with all my responsibilities, but at some point, the balance may become more challenging to maintain. As we move forward, I hope that policymakers in Washington and at the state level will be mindful of the unintended consequences of regulatory complexity.
Wednesday, September 14, 2011
BIDMC's Accountable Care Organization IT Strategy
No one really knows what an Accountable Care Organization is, but many provider organizations want to be one.
As a CIO, I've been asked to create the financial and clinical analytics needed to support high value care (low cost, high quality), population health, and care coordination across the community.
I believe that Accountable Care Organizations will be based on healthcare information exchange and analytics. BIDMC's approach is accelerate our health information exchange work and continue our existing work on financial and clinical data warehouses.
Here's how it will work.
There are over 1800 clinicians in the Beth Israel Deaconess Physicians Organization (BIDPO). Some are owned, some are private. The BIDPO Board of Directors mandated that a certified Electronic Health Record be in use at every BIDPO practice by December 2010 as a condition of participation in payer contracting efforts. Those payer contracts require "clinical integration" - all clinicians must be knit together by IT. To accomplish this goal, we implemented a cloud-based EHR which was offered to each practice that did not yet have a certified EHR. We required all clinicians, owned and private, to send a standardized, structured summary of each visit to a central quality registry.
As each encounter is completed and signed, eClinicalWorks, Altos Solutions, and webOMR, send a very specific Clinical Document Architecture (CDA) summary containing all the data necessary to compute quality and performance metrics to a statewide Quality Data Center, hosted at the Massachusetts Medical Society and operated by the Massachusetts eHealth Collaborative.
That warehouse is used to generate PQRI measures, the 44 meaningful use measures, and ad hoc reporting via web-based business intelligence tools.
For the financial data warehouse, all private payers claims from BIDPO patients are forwarded to a single financial data warehouse where Extract/Transform/Load tools are used to normalize the data into a single schema.
Data mining and reporting is done by Healthcare Data Services.
The interesting recent development is that all the clinical data transfers from heterogeneous EHRs pass through the New England Healthcare Exchange Network (NEHEN) gateway, such that the Quality Data Center is just a node on the HIE. Anyone can send any data from any EHR using the standards mandated by Meaningful Use.
NEHEN also transmits summaries to the next provider of care, ensuring clinical integration. We have live connections among Atrius, Childrens, BIDMC, and Northeast. In a few weeks, Partners Healthcare will go live with the ability to receive transactions.
As of last week, we have exchanged over 16,000 production clinical messages for care coordination and quality measurement.
All the Public Health transactions will soon be live on the NEHEN infrastructure.
Healthcare reform is causing hospitals, practices, payers, and government to align their healthcare IT efforts in support of the data sharing and analytics needed by new reimbursement models.
It's happening very fast in Boston/Eastern Massachusetts.
I'll continue to share all my lessons learned as BIDMC implements an entire suite of IT solutions on the road to Accountable Care nirvana.
As a CIO, I've been asked to create the financial and clinical analytics needed to support high value care (low cost, high quality), population health, and care coordination across the community.
I believe that Accountable Care Organizations will be based on healthcare information exchange and analytics. BIDMC's approach is accelerate our health information exchange work and continue our existing work on financial and clinical data warehouses.
Here's how it will work.
There are over 1800 clinicians in the Beth Israel Deaconess Physicians Organization (BIDPO). Some are owned, some are private. The BIDPO Board of Directors mandated that a certified Electronic Health Record be in use at every BIDPO practice by December 2010 as a condition of participation in payer contracting efforts. Those payer contracts require "clinical integration" - all clinicians must be knit together by IT. To accomplish this goal, we implemented a cloud-based EHR which was offered to each practice that did not yet have a certified EHR. We required all clinicians, owned and private, to send a standardized, structured summary of each visit to a central quality registry.
As each encounter is completed and signed, eClinicalWorks, Altos Solutions, and webOMR, send a very specific Clinical Document Architecture (CDA) summary containing all the data necessary to compute quality and performance metrics to a statewide Quality Data Center, hosted at the Massachusetts Medical Society and operated by the Massachusetts eHealth Collaborative.
That warehouse is used to generate PQRI measures, the 44 meaningful use measures, and ad hoc reporting via web-based business intelligence tools.
For the financial data warehouse, all private payers claims from BIDPO patients are forwarded to a single financial data warehouse where Extract/Transform/Load tools are used to normalize the data into a single schema.
Data mining and reporting is done by Healthcare Data Services.
The interesting recent development is that all the clinical data transfers from heterogeneous EHRs pass through the New England Healthcare Exchange Network (NEHEN) gateway, such that the Quality Data Center is just a node on the HIE. Anyone can send any data from any EHR using the standards mandated by Meaningful Use.
NEHEN also transmits summaries to the next provider of care, ensuring clinical integration. We have live connections among Atrius, Childrens, BIDMC, and Northeast. In a few weeks, Partners Healthcare will go live with the ability to receive transactions.
As of last week, we have exchanged over 16,000 production clinical messages for care coordination and quality measurement.
All the Public Health transactions will soon be live on the NEHEN infrastructure.
Healthcare reform is causing hospitals, practices, payers, and government to align their healthcare IT efforts in support of the data sharing and analytics needed by new reimbursement models.
It's happening very fast in Boston/Eastern Massachusetts.
I'll continue to share all my lessons learned as BIDMC implements an entire suite of IT solutions on the road to Accountable Care nirvana.
Tuesday, September 13, 2011
The NwHIN Power Team
At the September meeting of the HIT Standards Committee, we'll finalize the content, vocabulary and transport standards for Stage 2 of Meaningful Use.
I've written many posts and articles about the importance of specific implementation guides for transport standards. When every provider is connected to every provider, payer and patient, novel transactions will emerge and volume will increase per Metcalfe's law.
The NwHIN Power Team, a subcommittee of the HIT Standards Committee, has been working all Summer to analyze the NwHIN Exchange (SOAP) and Direct (SMTP/SMIME) specifications specifications using a truly brilliant methodology. Each specification (10 Exchange, 2 Direct) was scored against the following criteria:
Need for specified capability
Maturity of the specification
Maturity of the underlying technology used in the specification
Deployment and Operational Complexity
Industry adoption
Available alternatives
Initial scores were assigned by the ONC, with inputs from the NeHIN Exchange Coordinating Committee and the National Institute for Standards and Technology (NIST). The Power Team reviewed and refined these scores through several iterations, most recently after hearing testimony from individuals with first-hand experience implementing the Exchange specifications for the DOD and VA. From these scores, they identified specifications for which the business need is low. They also identified those specifications that are in early or moderate stages of development, and that use technologies which are in the declining phase of their life-cycle. Finally, they evaluated the specifications on deployment/operational complexity and industry adoption.
They considered alternatives using the same criteria as those used for NwHIN and Direct specifications.
Their detailed analysis will be presented on September 28, but there are two interesting conclusions in the draft report that I'd like to share now.
Industry adoption of the NwHIN and Direct specifications for health information exchange between organizations is low. Pilots have been successful, but large scale adoption has not yet occurred. So the scalability and workflow compatibility of these specifications have yet to be proven.
RESTful interfaces such as those used by Google, Facebook, and Amazon are appealing. However, REST is not a standard, but a style that uses the HTTP to provide a simpler alternative to SOAP for accessing web services. Not all RESTful implementations are implemented in the same way and thus we need a specification for secure RESTful transport of healthcare information. Such an implementation guide would ensure that RESTful implementations for healthcare information exchange are predictable and secured.
The Power Team has one more meeting to finalize its recommendation, but I am confident that they will present a thoughtful path forward that embraces the existing NwHIN and Direct specifications for some use cases and suggests further development for other use cases if we want large scale adoption and ease of implementation.
I'm truly impressed by the work of this team and look forward to their final recommendations.
I've written many posts and articles about the importance of specific implementation guides for transport standards. When every provider is connected to every provider, payer and patient, novel transactions will emerge and volume will increase per Metcalfe's law.
The NwHIN Power Team, a subcommittee of the HIT Standards Committee, has been working all Summer to analyze the NwHIN Exchange (SOAP) and Direct (SMTP/SMIME) specifications specifications using a truly brilliant methodology. Each specification (10 Exchange, 2 Direct) was scored against the following criteria:
Need for specified capability
Maturity of the specification
Maturity of the underlying technology used in the specification
Deployment and Operational Complexity
Industry adoption
Available alternatives
Initial scores were assigned by the ONC, with inputs from the NeHIN Exchange Coordinating Committee and the National Institute for Standards and Technology (NIST). The Power Team reviewed and refined these scores through several iterations, most recently after hearing testimony from individuals with first-hand experience implementing the Exchange specifications for the DOD and VA. From these scores, they identified specifications for which the business need is low. They also identified those specifications that are in early or moderate stages of development, and that use technologies which are in the declining phase of their life-cycle. Finally, they evaluated the specifications on deployment/operational complexity and industry adoption.
They considered alternatives using the same criteria as those used for NwHIN and Direct specifications.
Their detailed analysis will be presented on September 28, but there are two interesting conclusions in the draft report that I'd like to share now.
Industry adoption of the NwHIN and Direct specifications for health information exchange between organizations is low. Pilots have been successful, but large scale adoption has not yet occurred. So the scalability and workflow compatibility of these specifications have yet to be proven.
RESTful interfaces such as those used by Google, Facebook, and Amazon are appealing. However, REST is not a standard, but a style that uses the HTTP to provide a simpler alternative to SOAP for accessing web services. Not all RESTful implementations are implemented in the same way and thus we need a specification for secure RESTful transport of healthcare information. Such an implementation guide would ensure that RESTful implementations for healthcare information exchange are predictable and secured.
The Power Team has one more meeting to finalize its recommendation, but I am confident that they will present a thoughtful path forward that embraces the existing NwHIN and Direct specifications for some use cases and suggests further development for other use cases if we want large scale adoption and ease of implementation.
I'm truly impressed by the work of this team and look forward to their final recommendations.
Subscribe to:
Posts (Atom)
