TEFCA Response Drives ONC to Reconsider
Key Takeaways:The public response to ONC’s proposed Trusted Exchange Framework and Common Agreement (TEFCA) and U.S. Core Data for Interoperability (USCDI) underscores the pent-up demand for better healthcare interoperability. Required by the 21st Century Cures Act, TEFCA and USCDI could impact the future of healthcare data portability in the same way that the EHR Incentive Program shaped EHR adoption. The goal is to catalyze better data availability needed to modernize provider and payer IT application portfolios. Taken at face value, these regulations could profoundly change the way that healthcare stakeholders provide and use each other’s data.
This isn’t ONC’s first hands-on attempt to crack the interoperability nut. Years ago, it awarded a cooperative agreement to DirectTrust to oversee the rollout of secure messaging across the industry. In return, it got a slow but steady adoption curve that has moved the needle but fallen short of providing universal data availability.
TEFCA and USCDI could impact the future of healthcare data portability in the same way that the EHR Incentive Program shaped EHR adoption.
This time around, ONC has higher hopes for a more accelerated and effective result. While the former effort relied on established technology, this proposal leans heavily on technology that does not exist – in or out of healthcare – and an architectural approach with a checkered history. The DirectTrust effort combined carrot and stick incentives, while this one offers only the potential for protection from the stick.
TEFCA proposes to join clinicians, hospitals, payers, and others in a national network of networks. It would designate a set of organizations called “Qualified HINs” (QHINs) to facilitate a standardized “on-ramp” for nationwide healthcare connectivity. A separate organization called the Recognized Coordinating Entity (RCE), to be funded by ONC through a cooperative agreement, would manage and oversee this network of QHINs. Once a user or organization is on this national on-ramp, it will be able to exchange data for three different use cases across six permissible purposes.
USCDI defines the data types eligible – or required, depending on how you read it – for exchange. It builds on the Common Clinical Data Set (CCDS) and will expand the roster of exchangeable data types eligible based on maturity and market acceptance. In the short term, it proposes to add structured and unstructured notes, and data provenance to the list of CCDS data items.
The response to this proposed regulation was not only voluminous by the standards of ONC rulemaking, but also filled with questions, concerns, requests for clarification, and conflicting interpretations. The sheer number of distinct issues raised by commenters is evidence of the complexity of the topic, the difficulty of ONC’s task, and the problems with the proposal. Healthcare stakeholders want and need to leverage existing investments, but ONC’s new plan looks more like rip-and-replace. ONC’s insistence that TEFCA is voluntary and non-regulatory is cold comfort to any organization trying to forecast how much it will cost to comply.
Before delving into the specific concerns, it’s important to note that the general approach of TEFCA and USCDI moves the conversation in the right direction. It could turn out to be less costly for providers to sign up for one network than it is to enroll in the multiplying number of purpose-built clinical and financial networks. TEFCA also emphasizes query-based exchange of discrete data elements, which represents a desirable interoperability outcome.
ONC has to be pondering its options in the wake of such a stiff and unified response. The 21st Century Cures Act specifically requires it to develop TEFCA and establish rules for data blocking. The Senate HELP committee has already sought testimony on ONC’s progress on both fronts. Besides Congress, the highest levels of the current administration want action to solve the problem of data liquidity. ONC has to act, and soon.
Prior to the public response to TEFCA, ONC was on course to award the RCE cooperative agreement to the Sequoia Project on the strength of its handling of ONC’s transition of implementation and maintenance of the eHealth Exchange, and the governance muscle Sequoia showed as evidenced by Carequality’s adoption curve. This is relatively unsurprising since few other existing organizations have the independence, HIT expertise, scale, and track record that Sequoia has assembled.
ONC also seemed destined to declare that TEFCA compliance would provide a safe harbor against data blocking liability. ONC chose not to define data blocking and TEFCA in a single set of regulations. Instead, it asked the industry to accept new “rules of the road” for information exchange without knowing what happens when an organization can’t comply with those rules. ONC did not help its case by forcing the industry to conclude that TEFCA compliance is the only way to qualify for the data blocking safe harbor. Every conversation we’ve had about TEFCA since January is primarily about this linkage. Such a requirement is especially controversial among the smaller organizations that make up the bulk of healthcare, to the extent they are even aware that such a rule could happen. That ONC thought it could deal with data blocking in two regulatory steps is hard to understand.
Our prediction is that ONC will seek another round of public comments and revise TEFCA based on what it hears. It will then release a final version late this year that preserves the overall structure of TEFCA and USCDI from the current proposal. ONC will deal with objections by adding exemptions and exceptions that will phase in some of its more stringent provisions. Most of the exemptions and exceptions will concern TEFCA’s provisions for the data blocking safe harbor and population-level query. Effectively, it will delay the operation of these provisions to some later date. It will probably go ahead and award the cooperative agreement for RCE to the Sequoia Project once TEFCA is in final form late this year.
With all eyes on TEFCA, ONC has been mum about the fate of the “EHR reporting program,” also required by the Cures Act. This program is intended help hospitals, clinicians, and other users of health information technology to better understand how these products support interoperability and usability. ONC originally claimed it could not act on this requirement, pleading lack of budget. Then Congress rejected HHS’ request for a $22 million reduction in ONC’s budget, presumably enabling ONC to develop the program.
Matt Guldin · 2 years ago
Brian Murphy · 1 month ago
John Moore · 1 month ago
Brian Murphy · 2 months ago
Changing of the Guard: Implications to Health IT Market
After a brutal election cycle, we are now on the other-side. The Republicans have taken control of the Hill and the White House. The many healthcare programs rolled-out under the Obama administration will now be put under the microscope.
While we try to stick to IT-related topics, in healthcare one cannot divorce policy from technology adoption as federal policy has been and will likely continue to be one of the key macro-economic forcing factors to IT adoption in the healthcare sector.
Certainly, the ACA (Obamacare) will see an overhaul. It is unlikely that there will be a full-blown repeal of ACA as many of the programs within ACA have become part of the fabric of healthcare and would be too difficult to unravel (e.g. MACRA). But make no mistake; significant changes will be phased in over the next few years. It is also important to look beyond just the changes that will be made to ACA as the healthcare sector touches just about every sector of the economy.
During the election campaign, Trump rose to President-elect without divulging any real details as to how he would actually implement his proposals. One must look beyond Trump to the core Republican value of letting market forces lead the way with little government oversight to determine where we might be heading. The Chilmark Research team met collectively to discuss what are the implications of this new Republican leadership team in Washington on the healthcare sector. The Table below is a summation of those discussions of likely policy changes.
Table 1: Pending Changes in Healthcare Policy
As mention previously, in healthcare, IT adoption has been tightly linked to federal policies. That will not change going forward. Looking ahead, Table 2 provides a brief analysis of how the healthcare IT market will fare under this new administration.
Table 2: New Administration and Impact to Health IT Market
Looking Ahead Regardless of who ultimately took office in the 2016 election cycle, the overarching impact to IT adoption is modest. HCOs will still need to continue to increase their investments in analytics to reign in costs and improve quality. The move to a more consumer driven market will also herald yet another round of investments in new care delivery models and software to support. However, mandated models and regulatory approaches to solving some of the ills in healthcare will fall to the wayside. For example, data exchange/interoperability will pull back from being a social/medical need that is mandated to being a business/market need that is economically driven. Our advice to HCOs, do not wait for the dust to settle in Washington. The need to continue to improve costs and quality metrics will continue unabated requiring a long-term investment strategy in IT to facilitate cross enterprise care delivery.
CMS Drops MACRA Rules – 5 Things to Know About MIPS
Big news this week when on Wednesday CMS dropped the draft rules for MACRA, all 962 pages worth. These rules are the outcome of legislation that passed a couple of years back to replace the flawed SGR reimbursement model for physicians and hospitals. In its place, CMS is proposing two dominant reimbursement models:
In the conference call on Wednesday, acting head of CMS, Andy Slavitt, made it clear that the intent of MACRA is to move towards a model that provides flexibility for physicians to deliver quality care and enable the free flow of information across the sector in support of patient care and more broadly population health.
Plenty to talk about regarding both APM and MIPS, but for brevity’s sake, let’s focus on MIPS and we’ll do a follow-up post on APM in near future.
Five Things to Know About MIPS
Unpacking 962 pages of proposed rules in not for the feint of heart. No, we have not gone over every little nuance of the rules but in our cursory review we have identified five key points that really are the crux of the rules for EPs as it pertains to MIPS. These are the things that define the intent of MIPS and also where we are likely to see some push-back, after all, these rules are not quite set in stone – yet.
1) Quality and information exchange are top priorities. MIPS reimbursement will be based on a composite score of four key components: quality, resource use, clinical practice improvement activity, and advancing care information. Quality and advancing care information will be 75% of total weighting. Thus, it is quite clear where CMS wants physicians to focus in the near term – improving quality of care delivered and accelerating the use of IT to facilitate the flow of PHI in support of care quality.
2) Move from highly prescriptive to more flexible model. Under MIPS, MU is effectively dead for EPs under Medicare – the odd twist though is that MU is still in place for hospitals and Medicaid EPs, though CMS has expressed its intent to modify these areas as well in the future. CMS is giving quite a bit of flexibility to EPs in reporting out what measures are most important and relevant to their practice. Gone are the prescriptive, strictly defined measures that were part and parcel of MU, measures that often did not align with other CMS programs.
3) Be careful what you wish for – flexibility may breed complexity. While physicians now have a range of options as to what they will report out on as part of MIPS, this flexibility has a way of compounding itself in a nearly exponential way. Eligible physicians will need to wade through the many permutations of MACRA reporting requirements to settle upon what is best for their practice. This will create a lucrative opportunity for consultants serving this market. We also wonder how CMS will keep track of all of this as well – this is a non-trivial issue.
4) No time to waste – one year reporting period, begins January 1, 2017. Due to legislative requirements, CMS’s hands are tied as to when the switch to MACRA begins – but Jan. 1 2017 is only a short six months or so away from when rules will be finalized. What CMS does have flexibility on is the reporting period and they have chosen to go with one year, versus the more popular 90-day reporting period. CMS will get some heavy pushback here and likely acquiesce to 90-day. Would also not be at all surprised if the whole program gets push back a full year – just remember what happened to switch from ICD-9 to ICD-10.
5) Trust then verify is the mantra. Under MACRA’s new reporting requirements CMS recognizes that it will need to trust EPs to do the right thing. That being said, the proposed rules also have a significant amount of language pertaining to surveillance. How that surveillance will occur, how much will big brother be looking over a physician’s shoulder is up for interpretation,
While there are aspects to MACRA that have cause for concern, as outlined above, we are quite impressed with what CMS has put together. Clearly, a lot of hard work has gone into these proposed rules. CMS has reconciled many of the past ills – from the defunct SGR reimbursement model, to the oft-maligned MU program – with the desire to align the program to how physicians actually practice care that will lead to improvement in quality of care provided and value for the U.S. citizen. This is a Herculean task and for that CMS, Andy Slavitt, Karen DeSalvo, and countless others that have contributed to this effort deserve applause.
Some Additional Resources:
HHS Secretary Burwell’s take, with a pretty slick video giving high level overview of MACRA
The proposed rules, all 962 pages
Nice, digestable summary of MACRA
Similar to previous, but takes closer look at Advancing Care Information – the replacement to MU
Politico’s, Dan Diamond’s, interview/podcast with Andy Slavitt about MACRA
What Cerner’s DoD Win Means to Industry
So much ink, so little insight.
Quite a lot has been published on the awarding of the large Dept. of Defense (DoD) EHR contract, but almost all articles are simple rehashes of the press release and occasionally including some basic, on-the-record, public comments made by those in the upper echelons of the DoD selection committee. Once you have read 3 or 4 of these one gets frustrated with the lack of analysis, which I guess is a good thing for folks like us analysts, as that is our bread n’butter and keeps us in business.
So what is our take on this big win by Cerner, Leidos and Accenture…
But it is that third bullet point where the healthcare industry may see the biggest impact from this contract award.
Background:
The three EHR vendors bidding for the DoD contract where Allscripts, Cerner and Epic. Allscripts was never really in the running as their solution suite has had issues, especially on the acute side. That left Cerner and Epic duking it out for the contract and the war of words began.
That war of words centered on the relative “openness” of these two vendors’s solutions and in this case openness was not about open source software, but how easy did these solutions interoperate with solutions from other EHR vendors. Neither had a stellar record in this regard, but Cerner has worked hard to reposition itself as an advocate of open, interoperable systems and was a key founder and architect behind the CommonWell Health Alliance.
While Cerner was joining with several other vendors in the founding of CommonWell, Epic held fast to its integrated, ambulatory/acute solution strategy, encouraging customers to forgo the headaches of interoperating with other EHRs and simply go all in on Epic. This has been a very lucrative strategy for Epic. Even here in Massachusetts, senior officials at Partners Healthcare, which recently went live on Epic, have said that they intend to have all physicians working with Partners, including affiliates, on Epic. If those affiliates balk at moving to Epic, Partners will remove them from future contracts with payers. Talk about tough love. Epic also had some notoriety for not playing well with other EHRs and basically holding hostage patient data by charging hefty transaction fees for access to such, which Epic, under public pressure, rescinded this Spring.
What is particularly interesting is that our latest research on EHR vendor platform strategies found both Epic and Cerner to be roughly equal in providing access to their systems for third party developers, which is to some extent a proxy for interoperability. Who was one of the better ranked vendors? Yup, the third man out, Allscripts.
But we digress.
Looking ahead:
Epic may not have gotten a black eye from this loss, but they certainly took one on the chin. For the last several years, it appeared that Epic could do nothing wrong and was simply rolling up all the large academic medical centers and integrated delivery networks across the country. They were invincible. This loss will take away a little of their luster.
Cerner certainly gets big PR points for this win, but it is unlikely to be a highly lucrative contract for them. They won’t lose money (Cerner is extremely disciplined when it comes to finances) but they won’t make a lot either.
The contract will not significantly drain Cerner resources and existing and future customers of Cerner should not be too concerned. Leidos and Accenture will be doing the heavy lifting, Cerner just needs to provide the software capabilities that the DoD needs, and for that matter the industry.
The biggest impact on the market will be building out interoperability capabilities to support some fairly significant DoD needs. While the DoD has its own facilities, some 400+ located on military bases around the globe, 50%+ of care provided to military personnel and their dependents is from local healthcare providers via Tricare. The new system that Cerner will provide the DoD, must be able to interoperate with systems outside of DoD (those Tricare providers) to create a longitudinal patient record. Certainly Cerner will leverage the work it has done to date with other vendors that are participating in CommonWell but there are a number of EHR vendors that are still not a part of CommonWell, chief among them, Epic.
How Cerner addresses the interoperability needs of the DoD will have broad reaching implications across the industry and bears watching. Our long-term prediction is that Cerner, with DoD’s assistance, will successfully overcome many of the interop challenges we face today. No, it won’t happen overnight, but it will happen and it will be the biggest impact (and contribution) to the healthcare sector writ large.
New Insight Report on Moving to Open Platforms Now Available
[To skip the prelude and go directly to the report sales page, please click here: 2015 Platforms in Healthcare: EHR Vendors’ Capabilities for Interoperability]
Demand for interoperable technologies and platforms is increasing and enterprise technology vendors are responding. Cloud computing, composite applications, and open-source software with publicly available application programming interfaces (APIs) are liberating data to catalyze rapid innovation in nearly every sector of the economy. Vendors such as Amazon, Cisco, EMC, Google, HP, IBM, Microsoft, Salesforce and VMWare have adopted this Platform-as-a-Service (PaaS) approach to help their customers increase their pace of development and deployment, take advantage of more widely available development skills, broaden product and service portfolios, and achieve greater customer satisfaction.
But healthcare is stubbornly resistant. All of the factors driving the adoption of platform thinking in the wider economy across other industries — escalating demand for better user functionality, customers seeking an outcome rather than a transaction, rapidly changing payment models — are present in healthcare. Yet HCOs and their HIT vendors cling tenaciously to closed, transaction-based systems and methods of doing business that simply digitize pre-existing business and clinical processes, preserving an undesirable and costly status quo.
Our newest report, 2015 Platforms in Healthcare: EHR Vendors’ Capabilities for Interoperability, provides a broad overview of the current macroeconomic drivers that will foster the growth of platform thinking in the healthcare sector. Specifically, this research found that independent software vendors (ISV) have mixed opinions of the capabilities offered by EHR vendors. Some survive, and even thrive, but always at the sufferance of major EHR vendors. Others survive in the shadows, taking pains not to attract any attention from EHR vendors for fear of being shut out.
Meanwhile, healthcare end-users have elevated expectations based on consumer-facing application ecosystems or “app stores” – built on the technical foundation of open APIs in a cloud-based environment. Yet few EHR vendors admit that provider needs have long outstripped existing EHR feature sets.
This report addresses recent advances in interoperability trends that will help to support the transition to a PaaS model in healthcare – notably HL7 FHIR. The report surveys current EHR vendor strategies to enable PaaS with profiles of leading vendors including ratings on core functionality. After all, as the current hub for health IT in care organizations, this is their opportunity to lose – with other solution vendors happy and eager to innovate to create a true ecosystem for healthcare applications if EHR vendors fail to adapt.
HCOs and their HIT vendors will soon have to decide whether they want to be the platform or be a participant in some other entity’s platform. HCOs will need these platforms to interact with each other, with payers, and with patients if the triple aim is ever to be achieved.
For sales inquiries, please contact Sean Campbell, or go to the report sales page to purchase directly.
HIMSS Will not Have Dragons or Acrobats This Year: Clinician Network Management Watchlist
During the Middle Ages, London’s Bartholomew Fair grew from what we would call a trade show for cloth merchants into a full-blown annual exposition where merchants could conduct business in the presence of “sideshows, prize-fighters, musicians, wire-walkers, acrobats, puppets, freaks and wild animals.” HIMSS’15 in Chicago next week promises all that and more — hopefully without the wild animals. This year at HIMSS, I hope to talk to a lot of different companies and people about interoperability.
Since the publication of our CNM Market Trends Report at the end of last year, it has become clear that the market is seeking interoperability capabilities from EHRs and HIE/CNM that look remarkably similar. As the system of record within an HCO, the EHR is potentially current. As the system of record for the community-wide longitudinal record, the HIE/CNM is potentially comprehensive. These resources could, if they were rendered more accessible, provide the patient data to fuel a vast array of point-of-care, population level, care management, and administrative applications to help the healthcare system shed its fee-for-service blinkers.
Interoperability-related developments of the last few months have set the stage for my HIMSS’15 discussions: the MU3 NPRM, the trial balloon for ONC’s Interoperability Roadmap, a dramatic uptick in interest in HL7 FHIR, the establishment of the Argonaut Project. Healthcare’s interoperability issues have leaked out into general press coverage. The line between genuine interoperability issues and the heat generated by the machinations between EHR vendors and contractors over the impending DHMSM acquisition is cloudy. But radically improved interoperability is a pre-condition to a healthcare system that is patient-centric, population focused and value-driven.
A technology featured in all of these developments is API-based access to application data. This approach is old hat in every part of the economy except healthcare. Walgreens has an API to its photo print operations as well as for its clinic appointments and prescription refills. Bloomberg has APIs to its market data. Twitter provides an API to its vast store of tweets. Virtually any customer-facing operation has APIs for third party developers. Fueled by the rapid adoption of smartphones, enterprises are using RESTful APIs and Open Authorization (OAuth2) to capitalize on the value of their data to drive revenue, lower costs, and better serve customers – B2B or B2C.
The key word here is capitalize. Businesses are charging other businesses for access to this data. In a perfect world, every HCO could provide an API to its EHRs and other applications to support care coordination and population health and … you get the idea. Obviously, this was the idea behind HIE and its predecessor concepts. Proposed legislation circulating in Congress contains language that would require APIs as a condition of certification for EHRs. APIs have captured attention in the industry. They have so far not captured much market share.
APIs are not really all that new in healthcare. CarePass was a cloud- and API-based effort by Aetna to make data from applications and wearables more widely available to patients via applications from third-party developers. It closed at the end of 2014, a victim of patient and clinician disinterest and mixed support within Aetna. Despite this example, I think that broad-based API-based access is inevitable in healthcare. Lightweight, discrete data access can make exchange more financially palatable than the all-or-nothing datacenter-scale HIEs that struggle with funding. This year at HIMSS, I will be paying close attention to what vendors and HCOs are saying about APIs and their potential uses.
HL7’s FHIR will also be big in Chicago this year. It will be a set of Representational State Transfer (REST) web services APIs. It promises an easier-to-program, less resource-intensive alternative to the more widely deployed SOAP-based IHE profiles. It also promises discrete data access to supplement the various methods for document-centric data access now widely deployed around the healthcare system. I fully expect to see a lot of flame imagery around the McCormack Center this year as well as newly created FHIR marketing collateral. I hope also to find out about some concrete plans for incorporating FHIR profiles into existing EHR and HIE product functionality.
I also want to know more about Project Argonaut, which aims to move the industry toward widespread use of FHIR and APIs. This standards effort proposes to make rapid progress on use cases for clinician-to-clinician exchange and consumer access. How one define “rapid progress” in this industry is difficult to judge. For example, CommonWell Health Alliance launched at HIMSS’13 and only recently published its specification.
Eventually the powers-that-be shut down the Bartholomew Fair because it encouraged debauchery and disorder. HIMSS shows no such inclinations but I plan to talk to as many EHR and HIE/CNM vendors as possib
le and hear both legitimate and outlandish claims about APIs, FHIR, and better ways to support a more interoperable HIT infrastructure.
Didn’t Like MU? Brace Yourself for the Interoperability Version
Join us today at 3PM ET for a tweetchat about MU3 and what the proposed regulations portend. Just follow the #MU3 hashtag on Twitter to join the conversation.
For all of the dissatisfaction about the prescriptive nature of the EHR Incentive Program, it did put technology in the hands of a lot more clinicians. The next task is to make all of this technology and the data captured in EHRs more widely available for clinicians. The ability of the industry to make a successful transition to a value-based payment regime depends on better sharing of clinical data across a heterogeneous EHR landscape, otherwise known as interoperability.
Congress is mulling various options for incentivizing better interoperability. The Senate recently held hearings on how the EHR Incentive Program impacted interoperability. Many of the same Senator’s concerns were aired in a Health Affairs blog earlier this month. Last year, Congress urged ONC to consider decertification of EHRs that block interoperability.
Of the options under consideration, one — called the Discussion Draft — is extraordinary for its scope and specificity. However, if you blinked you missed it. It was issued around March 9th and the sponsoring legislator (probably not coincidentally the sponsor of the SGR Fix) took feedback via email until March 13th. Most of the press coverage was published after that deadline. There is also nothing about the draft on the legislator’s website. The entire process seems to have been conducted or publicized through some health IT and political reporters.
The Discussion Draft really has to be considered a trial balloon. There is plenty not to like about this plan for people who favor small government and for people who believe government should play a major role in the economy. Its major provisions require EHRs to provide open, unrestricted access to all patient data or risk decertification and civil penalties. It prohibits any vendor or provider from blocking access to data. It applies to both EHR vendors and providers. It adds published APIs as a requirement for EHR certification.
The Discussion Draft kills the HIT Policy Committee and the HIT Standards Committee but leaves the door open for some kind of replacement. It creates something called a Charter Organization that will recommend methods for measuring whether something is interoperable or not. The Charter Organization would consist of 12 members — 6 each to be appointed by the majority and minority leaders of the House and Senate respectively from providers, HIT vendors and others — as well as some members from various standards organizations. The job of the Charter Organization is to recommend ways to measure interoperability after a process consisting of hearings and a final report. HHS can take or leave recommendations from the Charter Organization.
The Draft also requires HHS to provide a lot of reports to Congress. By 7/1/16, it will expect one about the methods for measuring interoperability, strategies for achieving interoperability, assessments of how EHRs achieve interoperability, barriers, and plans to achieve better interoperability. By 12/13/17, it will need a list of EHR vendors and their progress towards interoperability, what the non-compliers are doing to be non-compliant, and penalties to be assessed after 1/1/2019.
Decertification is a draconian penalty and could have significant long-term consequences for affected providers. However, it is not at all clear that from this Draft that HHS will in practice be able to decertify many EHRs. Vendors or providers who, through “knowing and willing action” (financial, administrative, or technological) create barriers that limits, prevents, or disincents interoperability risk decertification. The key words “knowing and willing” mean that a vendor or provider can successfully defend an enforcement action by claiming that its offense was inadvertent. The defense goes something like: “I was unaware that my EHR was doing XX and promise not to do it in the future.” This also presupposes that enforcement actions will occur, an increasingly uncommon event.
This Draft will do nothing about the problem it purports to solve. It ignores the root cause of interoperability ills – the payment system rewards the behavior that it would punish. The Draft make the EHR Incentive Program vastly more prescriptive than it already is. It adds new attestations for providers and will undoubtedly produce Frankenstein-like measures of “openness”. It also imposes the threat, albeit weak, of fines and decertification for who might already have been penalized for not attesting.
Most importantly, it is fundamentally a provider-centric solution to a problem that is all too visible to patients. One way to accomplish the goal of better interoperability would be to focus more on how the problem is experienced by patients than on the mechanics of blocking access to data. By focusing exclusively on the activities of providers and their EHR vendors, this trial balloon of a proposed law overlooks the very real consequences outcomes of poor interoperability. The technical challenges of interoperability are well understood by everyone. All told, this would be a heavy-handed attempt that would serve only to further entangle the industry in red tape, reporting, and recriminations.
ONC Catalyzing a National Interoperability Plan
ONC’s first draft of a nationwide interoperability roadmap is ambitiously vast in scope, but ultimately constrained by the past. Its purpose is to initiate a discussion within healthcare about the ways and means to achieve interoperability in 10 years notwithstanding that the discussion is already the obsession of many. It hopes that this document will launch a process that results in a national private-public strategy for supporting the kind of interoperable data infrastructure that will enable a learning health system.
The roadmap focuses on several major policy and technical themes: the impact of FFS on vendor and provider attitudes to data sharing, the potential for private payers and purchasers to incentivize data sharing, the central importance of standards and incentivizing compliance. This long, comprehensive, and in places incredibly detailed, document is really three documents in one. For those lacking the time to read through its 160+ pages, we summarize:
Part I – Letter from ONC chief Karen DeSalvo and executive summary that lays out a set of questions intended to guide the response to the overall document as well as a series of “calls to action” to galvanize industry participation. (Pages 1-15)
Part II – Exhaustive presentation of the current and potential future state of interoperability, as well as the challenges and opportunities that lay between. (Pages 6-162)
Part III – The final appendix containing 56 “Priority Interoperability Use Cases” which ONC wants to winnow down. (Pages 163-166)
Part I gives a sense of which way ONC is leaning by focusing on select high-level issues: payment policy, data governance, semantic and transactional standards, measurement of results, and probably most important, the priority use cases. The language used within the roadmap is reflective of a sea change in thinking: “send and receive” has been replaced with “send, receive, find, and use” as a way to describe what individuals need from interoperable HIT.
Part II lays out the elements of what it hopes will become the national roadmap for interoperable HIT. The roadmap’s focus on measurement – tracking and gauging the metrics of interoperability – is eerily similar to the EHR Incentive Program’s MU measures right down to using various numerators and denominators. If we learned anything from the EHR Incentive Program it is that the industry liked the incentives but disliked the actual MU objectives. Absent the carrot of incentives and/or the sting of penalties, it is hard to see how ONC can catalyze providers to embrace yet another set of operational metrics.
ONC continues to struggle with patient matching. We know that Congress will not countenance so much as a voluntary (on the part of patients) national patient identifier. Even if it did, the costs to the industry of maintaining a dual system would only add complexity to an overburdened system. Unfortunately, we think that ONC and HHS is powerless to change this extravagantly costly element of the interoperability conundrum.
Who Uses What Data?
Embedded in ONC’s treatment of HIPAA, data governance, and data portability lies an essential, unresolved issue: The rights and responsibilities of the various stakeholders with respect to the data governance. How exactly can personal health information (PHI) that is captured by clinical applications be shared within the context of care delivery?
Today, such rules of the road remain unclear, ambiguous, and deeply complex. Existing laws, both state and federal, are a patchwork in which various participants hold back data fearing liability where most often no liability exists. At the same time, various participants claim outright to ”own” this data and use this patchwork to consolidate their competitive position.
ONC rightly points out that ATM networks and airline reservation networks provide interoperability for radically simpler use cases than the health system requires (they also don’t quite have the regulatory complexity of health data). While true, the data practices of consumer-focused transaction networks are effectively incomprehensible for the average consumer. So why should we assume that therefore somehow how we need to make it comprehensible for this use case of data?
Is it reasonable to expect any patient to understand the protections offered in the vastly more complex health data realm? Resoundingly no. ONC could be soliciting input about comprehensive reconceptualization of data rights and responsibilities with respect to patient data. Admittedly, only Congress can act to change the existing regime, and even Congress is limited by legislation enacted at the state level.
This is one aspect of interoperability that will aways confound those seeking true interoperability and data exchange in the context of health. It is also why some proponents believe that interoperability will only truly occur once the patient has full control of their data (health data bank) and defines access to their PHI. But even here, we have a very long way to go before the majority of citizens take upon that responsibility.
Standards and Compliance
Most of the ideas embodied in the JASON Report and the subsequent JASON Task Force are offered up for public comment. The roadmap suggests that HL7’s new standard, FHIR, could be effective in the 6-10 year timeframe, considerably longer than the time contemplated by the Argonaut Project. ONC also stops short of saying that element-centric interoperability will or even should replace document-centric exchange. But it talks about electronic sharing of summary care records – not documents – between hospitals, SNFs, and home health agencies.
The roadmap reinforces and effectively doubles down on the centrality of standards in any plan to foster better interoperability. Borrowing liberally if not literally from the Common MU Data Set, ONC wants to know how it can help make data more intelligible inside and between providers. As a companion to the roadmap it also released an “Advisory” on the most common standards in order to get opinions on where the industry’s best practices focus should be. ONC believes that standards-compliance and the elimination of non-conforming data representations will pay dividends.
The counterpoint to this emphasis on standards is the view held by many smaller, often start-up vendors that see standards as a means to preserve the status quo, serving more of gatekeeping function than an enabling function. Data networks in other industries, while admittedly simpler, do not rely on prescriptive application-to-application data representation standards. Healthcare is the only industry with such an ornate implementation of level 7 of the OSI stack. Smaller vendors would rather see simpler standards, published APIs, or more of a focus on the results of exchange than on how the result is to be achieved.
The reality is that major HIT vendors and major providers grumble about prescriptive requirements but by and large remain deeply committed to standards and compliance. We think that ONC could have at least offered up the prospect of achieving interoperability goals without specifying the mechanism down to specific data elements. Unfortunately, ONC appears to be continuing upon its questionable path of highly prescriptive guidelines – guidelines that ultimately hinder innovation rather than create opportunities for innovation to flourish.
Read the Priority Use Cases Right Now
Part III contains 56 uses cases, obviously culled from users, and are a dog’s breakfast of highly specific and extremely general interoperability complaints. ONC is asking the industry to help it order and prioritize the vast range of technical and policy question that they raise.
We recommend that if you read nothing else in the entire roadmap, you should read these use cases because they sound more like demands than actual use cases.
For example, Item #8 – certified EHR technology (CEHRT) should be required to provide standardized data export and import capabilities to enable providers to change software vendors. Every HIT vendor believes publishing database schemas is the last stop on the way to mob rule. In case vendors as a class were uncertain about their reputation among at least some providers, this “use case” provides unambiguous feedback.
A large number of the use cases are decidedly patient-centric despite the decidedly provider-centric orientation of the wider healthcare system and significant resistance to any kind of reorientation. A significant number of the use cases are related to payment and administrative uses even though the roadmap’s focus is on clinical data and clinical uses of the data. There are also a large number of use cases related to support for the public health system and clinical research. Both of these constituencies unfortunately take a back seat to immediate patient care and payment priorities.
Issues Remain
The roadmap mentions, without analysis, the fundamental problem of FFS-based disincentives to data sharing. HHS has recently announced new goals for progress on the way to VBR but ONC has little leverage to do much more.
Another important issue that the roadmap does not and likely can’t address is the level of investment in IT by healthcare providers. While many yearn for an interoperable infrastructure comparable to what banking or retail enjoy, those industries spend far more, as a percentage of revenue, on IT than healthcare providers. Progress on EHR adoption was not a result of provider’s reallocating resources to technology adoption, but federal incentives under the HITECH Act.
Therefore, can we really expect HCOs to increase IT budgets to support interoperability? Probably not. Moreover, ONC and more broadly HHS, do not have the funding to support interoperability adoption on the scale of EHR adoption via the HITECH Act, absent congressional action. Most HCOs are cash-strapped and struggling with a multitude of changes occurring in the marketplace and frankly have a fairly poor record in the effective adoption, deployment and use of IT in the context of care delivery. This is a knowledge intensive industry that has done a pretty lousy job at effectively harnessing that knowledge via IT.
The only leverage ONC and HHS have to improve interoperability is payment incentives via CMS. Recently, HHS announced that it will accelerate the move to VBR. Following closely on that announcement was the formation of the Healthcare Transformation Task Force, an industry association that sees its task as helping the industry migrate to VBR. It is far more likely that organizations such as this in conjunction with payment reform will do far more to achieve interoperability than any prescriptive roadmap.
It may be high time for ONC to step back and let the industry tackle this one on their own for only they will truly have a vested interest, via payment reform, to share PHI in the context of care delivery across a community in support of the triple aim and population health management.
