Share this post

Get new post notifications in your inbox


Subscribe to the blog

Latest from Nonstop Interop

Modified image of Kevin McCarthy holding a sign that says Interoperability in place of the Speaker's gavel

![Modified image of Kevin McCarthy holding a sign that says Interoperability in place of the Speaker's gavel](/images/Kevin-McCarthy-interoperability-sign-1673244000.jpg)

Finally, we have a Speaker of the House. Whether you followed the political drama last week with amusement and fascination or despair and trepidation, it's a relief to know that it's over (for now). Congress is at full strength, and [work can begin](https://www.marketwatch.com/story/what-happens-while-theres-no-house-speaker-salaries-in-limbo-taxpayers-requests-turned-away-11672944906).

The new majority leadership in the House has outlined [a few priorities](https://www.newsweek.com/heres-what-kevin-mccarthys-gop-has-planned-america-1745522), much of which has been [recycled](https://www.politico.com/news/2020/09/14/mccarthy-gop-win-control-house-414585) from the prior election cycle and lacks specificity. Sadly, there's no mention of a focus on healthcare interoperability. You can't blame them—no one tunes into the evening shows on cable news to hear politicians sermonize about sharing medical records. And this is a long-time, bipartisan problem, with [Newt Gingrich](https://en.wikipedia.org/wiki/Contract_with_America) and [Nancy Pelosi](https://www.reuters.com/article/us-usa-congress-agenda-idUSN0448857520070104) ignoring the topic as well. (In fairness, both became Speaker well before Meaningful Use and the widespread use of EHRs.)

But if Republicans truly want to [finish strong](https://twitter.com/SpeakerMcCarthy/status/1611881280031051778) for America, a great way to do it would be to take the lead on advancing interoperability. It won't be sexy or attention-grabbing work, and it's going to take bipartisan compromise given that both chambers are closely divided, but it could be tremendously impactful. Here are some ideas for how Congress can use its legislative powers to be a force for good in interoperability.

##### National patient ID

We need to [eliminate the outdated ban](/blog/congress-whiffs-advancing-interoperability-20221229) on a national patient identifier. A well-designed national patient ID will provide something that we don't have today, a verifiable and consistent identifier that is valid and recognizable throughout our healthcare system but which is also changeable and better protected against fraud. The House has been warmer to a national ID than the Senate but bipartisan support is there. If Congress isn't ready to completely allow it, it should at the very least clarify the law in the next appropriations bill to allow for research and analysis into the issue while maintaining a prohibition on actual implementation.

##### Extend protections

A lot of Americans assume HIPAA is more powerful than it really is. While HIPAA applies to healthcare providers, clearinghouses, payers, and their business associates, a host of entities involved in digital health are not governed by its rules. Direct-to-consumer apps can collect our health data with far less scrutiny. The federal government has provided [guidelines for app developers](https://www.ftc.gov/business-guidance/resources/mobile-health-apps-interactive-tool) and clarified that the FTC can take enforcement action on wrongdoers, but Americans deserve HIPAA-like protections whenever their health data is stored and used. Introducing such assurances will spur greater trust in and adoption of digital health tools and accelerate the demand for seamless interoperability.

Any changes here should include codifying the FTC's [Health Breach Notification Rule](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-318). We have a right to know when our personal information is leaked, yet the protections that exist today could be removed in the future with simple rulemaking. Let's make these safeguards part of the law. 

##### Nonprofits under FTC purview

Speaking of the FTC, it's time to bring nonprofits under their jurisdiction. As the FTC Act is [currently written](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section45\&num=0\&edition=prelim), it applies [only to entities](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section44\&num=0\&edition=prelim) that "carry on business for its own profit or that of its members." This means that the FTC's consumer and competition protections don't apply to the vast majority of health systems in the US. There's been [interest in changing this](https://www.judiciary.senate.gov/meetings/09/17/2019/07/23/2019/oversight-of-the-enforcement-of-the-antitrust-laws) (fast forward to 53:20) yet no concrete modifications to the law have been proposed, and Congress will need to consider whether to limit the impact on other nonprofits such as religious institutions and community service organizations.

Will this change directly impact interoperability? Probably not, but it will bring a level field of oversight between nonprofit and for-profit entities in healthcare, and fostering a more competitive landscape could spur innovative providers to change how healthcare is delivered, with interoperability as a core principle rather than a secondary factor.

##### Push for HHS action

Congress doesn't have only lawmaking powers; it also has the power of oversight, and it should wield it to prod HHS towards action. For one, we need [penalties and disincentives](/blog/hhs-oig-past-due-info-blocking-20221006) for information blocking ASAP. It's been three months since the info blocking provisions reached their full effect—and nearly three years since the rules were finalized—yet HHS has not defined any disincentives for providers and the HHS OIG has not finalized its [proposed penalties](https://oig.hhs.gov/newsroom/news-releases/2020/infoblocking.asp). Congress should ensure they act quickly.

Secondly, electronic prior authorization is in the news thanks to CMS' recent proposed rule. However, [HHS' current rules](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-162/subpart-M/section-162.1302) hamstring interoperability by requiring payers to exchange referral and authorization information using the X12 278 standard, which relies on point-to-point interfaces and for which the adoption rate has been disappointing. The proposed rule [will not fix](https://www.federalregister.gov/d/2022-26479/p-715) this problem. While I recognize that APIs for electronic prior authorization are still maturing, HHS should update its rules to allow for an API-based exchange standard, and Congress should lean on it to do so quickly.

##### PI for post-acute

Federal funding spurred an enormous wave of digitization in healthcare beginning in 2009, and the government continues to issue incentive payments and penalties for [interoperability-related objectives](https://www.cms.gov/regulations-guidance/promoting-interoperability/2023-program-requirements). The current system, though, only applies to acute care and ambulatory providers. We need to close this gap.

Congress should allocate funds to HHS to establish a version of Promoting Interoperability for post-acute care providers such as home health, hospice, and skilled nursing facilities. I fully acknowledge that this won't be easy or cheap, but it's nonetheless necessary. We don't have to duplicate the initial Meaningful Use program; I would advocate for introducing penalties sooner and holding providers accountable to interoperability measurements from the get-go. Additionally, I strongly believe any such program should be paid for in full, rather than adding to our already massive national debt. But we can't allow for HHS to focus on only part of the healthcare continuum. As patients, we deserve stronger interoperability among all care providers.


Some ideas for how Congress can use its legislative powers to be a force for good in interoperability.

Mr. Speaker, let's finish strong for interoperability - Nonstop Interop

Mr. Speaker, let's finish strong for interoperability

![Personal identification card](/images/ID-card-1672293600.png)
The federal government didn't shut down this past weekend. That's always a positive, but the mad rush to pull together an appropriations package that can pass a polarized Congress inevitably leads to winners and losers. Interoperability has consistently fallen into the latter bucket and this time was no different.

How so? The annual spending bill perpetuates a nearly 25-year ban on using federal funds to establish a standard for a national patient identifier. Accurate patient identification is one of the most important yet challenging aspects of interoperability, and [advocates say](https://patientidnow.org/about) a national patient identification framework could reduce administrative burdens and improve care. On the flip side, it would no doubt be costly and difficult to get right.

To me, the fundamental flaw in the status quo is that it prevents any serious effort at trying to get it right. In healthcare technology—really, within any industry—there's a pattern to innovation where new solutions and concepts are introduced, scrutinized, and refined or discarded. The current law unnecessarily cripples this debate, and Congress missed another chance to correct its error.

##### A hot and cold relationship

The legislative branch has a history with national health identifiers; uncovering it requires much digging through the archives. If you thought interoperability was hard, try conducting congressional research!

The saga began with HIPAA, which [directed HHS](https://www.congress.gov/bill/104th-congress/house-bill/3103/text/pl) to "adopt standards providing for a standard unique health identifier for each individual, employer, health plan, and health care provider for use in the health care system." (Congressional records are hopelessly void of anchor links, so when I don't quote exact text, I'll share words you can search for within the page to find the relevant portion.)

The present-day restriction was born a couple of years later in the [omnibus funding law](https://www.congress.gov/bill/105th-congress/house-bill/4328/text/pl) for fiscal year 1999 (search for "health identifier"). Its author was Texas congressman Ron Paul, who took to the floor of the House on October 8, 1998 to advocate for inserting the language. Rep. Paul [expressed concern](https://www.congress.gov/congressional-record/volume-144/issue-140/house-section/article/H10137-1) that a national ID would "be used to create a national database containing the medical history of all Americans" and "would allow federal bureaucrats to track every citizen's medical history from cradle to grave."

Since that fateful legislation, the language has remained constant in the yearly appropriations bill, whether that's a standalone bill to fund the Departments of HHS, Education, and Labor or a consolidated appropriations act that bundles together the 12 bills that fund the entire government. (Note: the provision is colloquially referred to in the healthcare community as "Section 510" and I'll do the same here. However, the actual section number has varied over time. It was Section 514 in the [Consolidated Appropriations Act of 2001](https://www.congress.gov/bill/106th-congress/house-bill/4577/text/pl), for example, and Section 511 in fiscal year [2010's equivalent act](https://www.congress.gov/bill/111th-congress/house-bill/3288/text/pl). Search for "health identifier" in both.) Section 510 directly nullifies part of HIPAA's requirements, stating that no appropriated money can be used "to promulgate or adopt any final standard...providing for, or providing for the assignment of, a unique health identifier for an individual (except in an individual's capacity as an employer or a health care provider), until legislation is enacted specifically approving the standard."

After two decades of quiet, a hint of momentum emerged in 2019 when the House passed [a bipartisan amendment](https://www.congress.gov/amendment/116th-congress/house-amendment/286) to strike out Section 510. The House has made multiple attempts to remove it ever since. In the Senate, change has been slower but [the initial appropriations bill](https://www.appropriations.senate.gov/imo/media/doc/LHHS1.pdf) for FY2022 excluded Section 510 (search for "health identifier"). Old habits die hard, though, and Section 510 lives on. Not everyone wants to see it go, either; Sen. Rand Paul of Kentucky has expressed many of the same concerns as his father did, and he has worked with [like-minded colleagues](https://www.congress.gov/bill/117th-congress/house-bill/5812) to [introduce legislation](https://www.congress.gov/bill/117th-congress/senate-bill/3124) removing the original requirements from HIPAA. These proposals have not advanced in either chamber.

##### Fight club

I feel the players on both sides of this issue hold skewed and rigid viewpoints that don't survive rigorous scrutiny. For one, while patient misidentification is undoubtedly a problem, a national ID will not be a panacea for our woes. We already [see mistakes happening](https://psnet.ahrq.gov/web-mm/patient-identification-errors-systems-challenge) when healthcare workers have unique data points available to them, such as distinct names, dates of birth, and medical record numbers. Introducing an additional number in an electronic chart or on a patient armband won't stop fallible human beings from mixing up similar information or failing to follow the right process. To reduce the risk of patient harm due to misidentification, we are better served by implementing and religiously following a system for positive patient verification at every key point in the delivery of care.

What's more, a unique ID will be costly and time-consuming to roll out. Software will need to be updated and existing records will need to be matched to newly issued IDs. The federal government would need to define a process for assigning and managing IDs for unexpected participants in the health system, such as international visitors who need medical care. And a host of questions would need to be answered, like how to verify that an ID a patient provides is truly theirs and how to accommodate patients who are unable to provide theirs.

On the other hand, those resisting work on an identification framework miss the mark in several ways. Privacy and security are the most commonly cited apprehensions, but these are addressable. Opponents assume, as Rep. Paul did in his floor speech, that national IDs will automatically mean a nationalized database of all of our health information, but these are not inseparable. Congress can easily allow for an ID standard while prohibiting a national EHR.

Secondly, the fear of national IDs getting into the wrong hands is often cited. It'll be like Social Security numbers, they say, where you're doomed for the rest of your life once it's leaked. But I would argue this is shortsighted because we shouldn't design a national ID to be like an SSN. We should take a page from the banking industry and make it like a credit card. When my card number is stolen, the bank can easily render it useless and issue a new one. Credit cards also follow defined patterns with check digits to [ensure their validity](https://en.wikipedia.org/wiki/Luhn_algorithm), which reduces the chances of transposed numbers and ensures criminals can't use just any random one. We need to adopt these same principles when developing a unique patient ID.

##### Give it the green light (or at least a yellow one)

In my mind, the key advantage of a national patient ID for interoperability is that it allows us to move to a consistent, verifiable, and fungible value for every participant in our healthcare system. This is something our present-day identifiers can't match. Like an SSN, your name, date of birth, address, and phone number are demographics that are difficult or impossible to change, so their value to malicious actors remains high over time. MRNs provide a unique and (usually) changeable identifier, but they don't carry the same meaning outside of the walls of a single health system. A well-designed national identifier gives us the best of both worlds and reduces friction in the pursuit of seamless data exchange.

To be clear, there's room for meaningful compromise on this issue that allows for incremental progress. Section 510 could be amended to prohibit adopting a final standard while allowing the use of funds to conduct research on what a national patient ID framework could look like. Congress has taken similar steps [on other issues](https://en.wikipedia.org/wiki/Dickey_Amendment#Subsequent_history) by allowing research while preventing a wholesale change in policy. And as we work through if, how, and when we adopt a national patient ID, we shouldn't lose sight of an underappreciated fact: millions of Americans already have one. Every Medicare recipient has a 11-digit Medicare Beneficiary Identifier issued by CMS and recognized nationwide. Congress mandated the change from the old SSN-based identification numbers, and while the rollout required much planning and effort, it was ultimately successful because CMS was empowered with the time and resources needed to make it happen. The same can be true for a unique national patient identifier; it's time for Congress to end the quarter-century ban and advance interoperability by allowing much needed research and innovation.

\---

Image by [OpenIcons](https://pixabay.com/users/openicons-28911) on [Pixabay](https://pixabay.com)


It’s time for Congress to end the quarter-century ban on funding for a national patient identifier.

Congress whiffs again on advancing interoperability - Nonstop Interop

Congress whiffs again on advancing interoperability

Jigsaw puzzle with one missing piece in the center

![Jigsaw puzzle with one missing piece in the center](/images/Jigsaw-puzzle-with-missing-piece-1670997600.jpg)

Last time on Nonstop Interop, I wrote that [the time was ripe](/blog/himss-stage-8-20221114) for HIMSS to add an additional stage focused on interoperability to its two most popular maturity models, EMRAM and O-EMRAM. Doing so would incentivize healthcare providers to embrace modern integration methods and would provide a strong roadmap of interoperability best practices that they can follow. Today I'd like to continue the discussion by outlining the key pieces to include in a possible Stage 8.

##### Themes and workflows

The first recommendation I would make is to anchor Stage 8 around specific themes. HIMSS does a pretty good job of this already within the models, so it would be consistent with what's currently in place. For example, in the EMRAM benchmarks are divided between key themes such as patient satisfaction, clinical workflows, and data analytics. Governance is another area of focus that's thoroughly incorporated into the existing stages, with change management processes required in Stage 2 of the EMRAM and system-wide governance with "a demonstrable history of solving problems" expected in Stage 7 of the O-EMRAM.

In addition, however, Stage 8 should target particular workflows where interoperability could have a powerful impact. It should require using data exchange technologies to automate workflows and free up staff for more complex problems. The models thus far shy away from being so prescriptive, so I recognize this would be a significant shift from the status quo. Nonetheless, it's the right move to accelerate the adoption of interoperable solutions.

##### Themes

I envision three themes forming the backbone of HIMSS Stage 8.

###### *Governance*

Interoperability deserves dedicated focus and oversight. Stage 8 should emphasize governance around interoperability, perhaps by encouraging each health system to form an interoperability council or to incorporate responsibilities into an existing governing body. The council would define and maintain the organization's roadmap for embracing higher levels of interoperability and would work with executives, department leads, vendors, and standards bodies to identify solutions to key problems.

###### *Standards*

FHIR is the future for healthcare data exchange; we've seen the federal government mandate its use in certain cases as it seeks to establish a common foundation for integrations. Stage 8 should require that health systems make FHIR APIs available to external entities—this should be easily satisfied by organizations using an ONC-certified EHR. Moreover, it should encourage them to participate in the advancement of interoperability standards through ways such as submitting comments to the ONC, serving on an industry workgroup, or participating in a connectathon.

That said, I strongly believe Stage 8 shouldn't mandate the use of FHIR. Not only is that a better role for regulators, but also it's important to give providers the flexibility to find the best solution for their circumstances and needs. Many would likely gravitate to FHIR wherever it could work, but there are a host of workflows where HL7v2, X12, or another standard may be the better fit.

###### *Transparency*

It should be easy for the public to understand how to integrate with a health system and to what extent it is integrating with others. To answer the how question, a Stage 8 organization should publish full specifications for the APIs, web services, and interfaces it can support. (These could be as simple as linking to documentation hosted by its EHR vendors.) It should also outline the steps a patient, peer institution, or vendor must follow to establish a connection and provide a way to get in touch with an interoperability point person.

To shed light on the extent of interoperability, Stage 8 could encourage providers to post metrics annually on its public website. Perhaps a particularly enterprising health system could host a dashboard that updates on a regular basis and allows for deeper analysis. While health systems should retain some discretion on what to share, I would love to see them outline the number of unique systems they are connected to, a breakdown of connections by type (e.g., FHIR API, non-FHIR API, HL7v2 interface), the average daily transaction volume per month, and a list of the most common data types exchanged (e.g., a list of FHIR resource types or HL7 message types). Having this data would not only be informative but could also expose gaps and stimulate ideas for future innovation.

##### Workflows

In terms of workflows, the below isn't an authoritative list; there are plenty of other possibilities that could make the cut. The emphasis, however, should be on workflows where the necessary technology and standards exist or will exist soon and where the benefits of interoperability and automation will reduce costs, alleviate burnout, and improve clinical care the most.

###### *Virtual care*

Even if in-person care continues to be the norm, virtual care should be embraced and offered by Stage 8 organizations. Video visits and messaging services that are tightly integrated with the EHR can make healthcare more convenient and accessible, especially for underserved populations and those without reliable transportation.

###### *Patient data submission*

Stage 8 should spur providers to allow patients to contribute to their clinical record. This could take the form of remote patient monitoring, patient-entered questionnaires, or integrations with consumer devices. I acknowledge that we'll need to balance this against the potential burden for clinicians, who should not have to review and reconcile enormous amounts of submitted data.

###### *Electronic payments*

This is a unique suggestion because the HIMSS maturity models have typically focused on the clinical side of healthcare. We can't ignore the financial side, though. This should be an easy win as the standards and technology for taking payments electronically have been available for more than a decade and most health systems do this already. Let's formalize it as a requirement in Stage 8; it should, however, only be required for organizations in countries where accepting patient payments is customary.

###### *Electronic prior authorization*

Like the previous one, this workflow is likely not as applicable outside of the US and a few other countries, but it's particularly timely given [CMS' recent proposed rule](https://www.cms.gov/newsroom/fact-sheets/advancing-interoperability-and-improving-prior-authorization-processes-proposed-rule-cms-0057-p-fact). Prior authorization is a laborious and inefficient undertaking today, but we have the fundamental pieces to make it much better.

###### *Automated release of information*

I'll admit I'm casting a wide net here, because release of information encompasses so many potential request types, requesters, and data needs. It's unlikely that interoperability can allow us to automate every release request in the near future, but HIMSS Stage 8 could focus on pushing health systems to digitize the easiest use cases, such as delivering clinical abstracts to patients, releasing notes and lab results to life insurance companies, or allowing specialty providers to obtain complete patient and encounter summaries when they receive a new patient referral.

\---

Photo by [Pierre Bamin](https://unsplash.com/@bamin) on [Unsplash](https://unsplash.com)


Outlining the key pieces to include in a possible HIMSS Stage 8

Defining a possible HIMSS Stage 8 - Nonstop Interop

Defining a possible HIMSS Stage 8

Boy standing on a ladder in a lake surrounded by mountains

![Boy standing on a ladder in a lake surrounded by mountains](/images/Boy-on-ladder-in-lake-1668405600.jpg)

To reach new heights, it's helpful to have a ladder. Each step brings steady progress towards the destination, though the last couple of rungs are the hardest to scale and require ample patience and balance. And if what you seek remains out of reach, you'll wish that ladder was just a bit longer.

We use ladders in health IT—figurative ones at least. Top of mind for me are the [maturity models](https://www.himss.org/what-we-do-solutions/digital-health-transformation/maturity-models) developed and administered by HIMSS. These frameworks offer healthcare providers stepping stones for greater adoption of digital tools and processes; best-known and most popular are the EMRAM and O-EMRAM, which respectively define roadmaps for maximizing EMR use in hospitals and outpatient clinics. It's a laudatory achievement to attain the pinnacle of Stage 7, and providers who do so benefit from digitized workflows and (hopefully) increased patient and clinician satisfaction.

As important as the goal of maximal EMR utilization is, however, it's increasingly insufficient. The burning priority for healthcare IT isn't the ability to punch orders into a computer but rather to exchange data beyond your four walls. Interoperability has become a key focus for practically every stakeholder, including patients and regulators, and it deserves a more prominent role within the EMRAM and O-EMRAM. We need a new HIMSS Stage 8 to guide providers in their interoperability journeys and to help the most integrated ones stand above the rest.

##### A little short

In fairness to HIMSS, it has baked a hint of interoperability into its offerings already. The [Continuity of Care Maturity Model](https://www.himss.org/what-we-do-solutions/digital-health-transformation/maturity-models/continuity-care-maturity-model-ccmm) (CCMM) calls for "multiple entity clinical data integration" at Stage 3, e-prescribing at Stage 4, and a rather vague benchmark of "mobile tech engages patients" at Stage 5. Unfortunately, it seems that the CCMM hasn't caught on, as [not a single health system](https://www.himss.org/what-we-do-solutions/digital-health-transformation/achievement-list) has reached at least Stage 6 after [nine years](https://www.beckershospitalreview.com/healthcare-information-technology/himss-unveils-continuity-of-care-maturity-model.html) of existence.

Within the EMRAM and O-EMRAM, there are guidelines for participating in an HIE, exchanging discrete and unstructured data, and taking in lab results electronically. This is a decent baseline but doesn't push providers to adopt the latest and greatest. There's no mention of using APIs to release clinical information to payers and patient-authorized digital health apps. There's no declaration that providers should have a governance body overseeing implementation and auditing of integrations with third-parties. These gaps leave providers to figure out best practices on their own and slow down the adoption of new innovations.

##### A necessary step?

You may be questioning whether it makes sense to add interoperability to two tried-and-true maturity models. Wouldn't this be moving the finish line after the runners completed the race? And isn't it enough that the ONC is issuing regulations around info blocking and certified HIT that already promote interoperability? Fair points, but allow me to counter.

First, the ONC's approach has favored sticks over carrots. For an organization empowered to define the rules of the road, this isn't unexpected, but it would be valuable to have rewards as well. Incorporating interoperability more strongly within the EMRAM and O-EMRAM would incentivize providers who seek to be best-of-breed without introducing mandates on hospitals and practices with limited people or resources. Second, most of the recent ONC regulations for interoperability have been targeted at health IT developers, not healthcare providers. It's the developers, for instance, [who must ensure](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315) their products integrate with immunization registries and support bulk FHIR API requests. Instead, what I'm proposing addresses the provider side of the equation.

I also wouldn't think of this as an exercise in moving the goalposts. The achievements of a Stage 7 organization would not go away; Stage 7 would still be a gold standard for the effective use of information technology in healthcare. We all recognize, though, that technology evolves and advances, and how we measure our progress with technology should evolve and advance as well. We have an opportunity here for continuous improvement, something that can take organizations from the gold level to platinum.

##### Building a better ladder

Okay, that's the why behind a new Stage 8, but what should be the specific criteria within it? Given the numerous possibilities, that warrants a separate post to discuss. Look for my thoughts and examples in the next edition of Nonstop Interop.

\---

Photo by [Armand Khoury](https://unsplash.com/@armand_khoury) on [Unsplash](https://unsplash.com)



We need a new HIMSS Stage 8 to guide providers in their interoperability journeys and to help the most integrated ones stand above the rest.

It's time for HIMSS Stage 8 - Nonstop Interop

It's time for HIMSS Stage 8

Jack-o'-lantern on the head of a shadowy figure

![Jack-o'-lantern on the head of a shadowy figure](/images/Jack-o-lantern-head-1667192400.jpg)

If you’ve been in health IT circles for a while, the description of “beings who roam the world at night searching for people whose blood they feed upon” may make you think of both [vampires](https://www.history.com/topics/folklore/vampire-history) and EHR companies. The comparison is grossly unfair, though you’ll certainly [bleed money](https://www.healthit.gov/faq/how-much-going-cost-me) over EHR implementation and maintenance. EHRs are not ghouls, but that doesn’t mean they’re perfect either.

Case in point: in the interoperability world, EHRs have historically been very skeptical of middleware applications. By middleware I mean not only your traditional interoperability engines that serve as an integration layer between multiple software systems, but also digital platforms that strive to provide an all-in-one experience for patients and providers (and therefore make the EHR’s UI irrelevant). Middleware providers have struggled to get listed on EHR app marketplaces and to gain access to the full suite of integration options.

EHRs have had some understandable concerns regarding middleware. One is that middleware applications often serve as a pass-through to other software. EHRs can’t truly know where the data sourced from their databases is ending up and how it’s being used. Is that iPaas feeding data only to a CRM to boost patient engagement, or is it also shipping demographics to marketers, data brokers, or worse?

Hand-in-hand with that is the criticism that middleware seeks the interoperability kitchen sink. By connecting to every API and pulling every data point, middleware provides a primordial soup of integrations, rather than a standardized, tightly defined product with prescriptive use cases. This is particularly problematic in an industry whose daily operations revolve around clear, structured workflows. EHRs don’t want to risk blowback from their customers for sanctioning second-class software, and they are not alone. Apple, for example, places [26 printed pages](https://developer.apple.com/app-store/review/guidelines/) of requirements upon App Store developers to prevent a bad experience for its customers.

Yet if a third-party vendor has developed inferior software, shouldn’t it be up to its customers—both prospective and actual—to make that judgement for themselves? What EHRs miss in their trepidation is that middleware companies sell pretty much exclusively to other businesses, not directly to consumers. These businesses—whether they are health systems, technology companies, or researcher organizations—are savvy buyers who should own the responsibility and power to choose the best products for their needs. Likewise, rather than EHRs being the arbiters of who should and shouldn’t receive data, middleware’s customers should retain the authority to determine the right recipients.

Unsaid by EHRs is the challenge that middleware presents to their revenue models. App developer programs often mandate an annual fee just to participate in the official marketplace; Oracle Cerner, for instance, [pulls in $15,000-25,000](https://code.cerner.com/apiaccess) annually per application validation, with only the higher tier earning you the ability to market the app on the App Gallery. If a middleware system lists itself and integrates on behalf of 15 destination systems, that’s 15 lost sources of annual recurring revenue for the EHR. I can’t help but suspect that this is a major cause of the quaking in their boots; as sympathetic as I am about the loss of revenue, the primary objective of interoperability is seamless data exchange, not higher profitability.

Middleware has been a scary concept for EHRs; thankfully the information blocking regulations’ new, broader reach has lessened their fear—or at least, their resistance—though [the lack of penalties](https://ashavan.co/blog/hhs-oig-past-due-info-blocking-20221006) is holding back the rules’ full effect. The fears are misplaced, however, and interoperability would be better served if all varieties of software had access to EHRs’ integration options. Let’s open up the playing field and let providers decide what’s a trick and what’s a treat.

\--- 

Photo by [Kenny Eliason](https://unsplash.com/@neonbrand) on [Unsplash](https://unsplash.com)


Middleware has been a scary concept for EHRs; the fears are misplaced, however, and interoperability would be better served if all varieties of software had access to EHRs’ integration options.

Dear EHRs, don't be spooked by middleware - Nonstop Interop

Dear EHRs, don't be spooked by middleware

Person preparing a syringe from a vial of influenza vaccine

![Person preparing a syringe from a vial of influenza vaccine](/images/Vaccine-1666760400.jpg)

It's vaccine season. Not necessarily in an official sense, but with the approach of winter comes the [invariable](https://www.cdc.gov/surveillance/nrevss/rsv/natl-trend.html) rise in [respiratory](https://www.cdc.gov/flu/weekly/index.htm) [illness](https://www.cdc.gov/coronavirus/2019-ncov/covid-data/covidview/index.html) and the shots designed to prevent the worst outcomes. (Quick PSA: go get your flu shot and COVID booster. Both are important, and it would actually make me happy if you stopped reading this to [schedule an appointment](https://www.vaccines.gov/).)

Vaccines are pretty amazing things; they can prevent infection—though the rate varies and practically no vaccine blocks all infections in everyone—and even when they don’t, they reduce the chances of severe illness, hospitalization, and death. A small amount of substance—sometimes less than a milliliter—added to your body provides a wealth of protection. We have vaccines to thank for the eradication of [smallpox](https://www.who.int/health-topics/smallpox) and the great reduction in [measles](https://www.cdc.gov/measles/about/history.html) and [polio](https://polioeradication.org/polio-today/history-of-polio/) worldwide.

Those jabs take more than just a biological journey, however. Healthcare IT has played an important role in vaccine administration and monitoring for years, and we should acknowledge and applaud the success of vaccine-related integrations.

##### Through vessels and VPNs

A vaccine visit tends to be pretty straightforward. A qualified clinician will identify and prep the correct products, ask about any allergies or previous reactions, and administer the dose. From there, your immune system picks up on the new entrant and [begins its response](https://www.uchicagomedicine.org/forefront/coronavirus-disease-covid-19/demystifying-vaccines-1). Special white blood cells called [B cells](https://www.immunology.org/public-information/bitesized-immunology/cells/b-cells) produce antibodies to protect against the antigen, and another kind of white blood cell called [T cells](https://www.ncbi.nlm.nih.gov/books/NBK10762/) "memorize” the pathogen so that they can recognize it in the future and respond more quickly.

While all of this goes on, the clinician has likely documented the vaccine administration in your electronic medical record, which triggers its own call to action. Public health agencies in every state maintain immunization registries to keep track of who has been vaccinated and with which product, and every certified EHR is [required to be interoperable](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315#p-170.315$f$) with those registries. The EHR compiles information about you and the vaccine you received, such as the lot number and where on the body it was administered, and organizes it into an HL7v2 interface message designed just for vaccines. This VXU message is then sent to the appropriate registries to update them on your new shot.

It isn’t just a one-way street, either. Certified EHRs must also be able to query an immunization registry for a patient’s vaccine history. Imagine that you stepped on a nail and received a tetanus booster at an urgent care center. You’d want your chart at your PCP’s office to include all of your immunizations, so when your PCP logs in, they can trigger a request to download the latest details. A QBP message fires off to the registry, which will verify it can find you in the database, and if successful, an RSP message will venture back with data to review and reconcile into the medical record.

##### Integration tribulations

These vaccination integrations provide significant value, but they aren’t necessarily simple or perfect. For one, the lack of a centralized immunization registry means numerous connections are needed. Thankfully the CDC has [encouraged standards](https://www.cdc.gov/vaccines/programs/iis/technical-guidance/index.html) to minimize variation across the states, but these standards rely on older, tried-and-true HL7v2 messaging. We’re still years away from seeing FHIR APIs as the go-to technology for connecting to immunization registries.

Secondly, guarding against duplicate records is a persistent challenge. Since the registries typically cover an entire state, they receive messages from thousands of sources and maintain databases with millions of patients. They must parse through the demographics to determine if a particular message represents a brand-new patient or someone already in the system. Likewise, the vaccine administration details require diligent analysis to ensure nothing erroneous gets through.

The stakes are high. Public health officials rely on the registries to understand regional vaccination coverage and trends in reactions. Providers and patients rely on registries to identify missed vaccines and ensure children get the right shots on the right schedule. Underlying all of this is a system of interoperability that must be efficient and effective—and it is. While those B cells and T cells silently do their biological duty protecting you from harm, the bits and bytes of vaccine integrations are keeping digital systems up-to-date, and that enables everyone to live safer and healthier lives.

\---

Photo by the [CDC](https://unsplash.com/@cdc) on [Unsplash](https://unsplash.com)


Healthcare IT has played an important role in vaccine administration and monitoring for years, and we should acknowledge and applaud the success of vaccine-related integrations.

Vaccines move through more than just your body - Nonstop Interop

Vaccines move through more than just your body

Two coins partially stacked on a brown table

![Two coins partially stacked on a brown table](/images/Two-coins-on-table-1665637200.jpg)

"Can you explain OAuth to me?" A customer posed this question recently and I happily obliged, describing how tokens are its currency, how it differs from [basic authentication](https://en.wikipedia.org/wiki/Basic_access_authentication), and where you can see it in use in everyday life. Then, I thought nothing of the conversation for a few days.

I realized later that I probably gave the customer an incomplete answer. I offered a decent lesson on the basics of OAuth and how it works, but I don't think I did justice to why it's so valuable. In the world of healthcare interoperability, our hearts start pounding over concepts like USCDI and TEFCA. FHIR is likely the greatest source of excitement and it no doubt holds great potential. But if I had to vote tomorrow for the most impactful idea thus far for 21st century interoperability, I would choose OAuth.

##### A standout standard

Before I expand upon my opinion, let's go over some of the facts. The most basic thing to know about OAuth is that it is a standard. If you work in healthcare, you live, breathe, and eat standards. There are standards for how medications are coded, how quickly stroke patients should receive treatment, and which diagnoses can be used on claims. ("Burn due to water skis on fire" somehow makes the cut.) In healthcare IT it's no different. We have a veritable alphabet soup to guide us on exchanging data over point-to-point interfaces (HL7v2, X12) and protecting information and managing risk (HITRUST), among countless other things.

OAuth is a standard that allows apps to connect to one another in a secure fashion by proving that a user is really who they claim to be and that they have permission to do the things they want to do. Like any good standard, it has improved over time, and [OAuth 2.0](https://oauth.net/2/) is the latest version. There are a few flavors but I'll focus on what's known as the "[authorization code grant](https://www.rfc-editor.org/rfc/rfc6749#section-4.1)."

You probably have used OAuth in your life without realizing it; if you've ever visited a website and created an account by clicking a button that says "Log in with Google" or "Log in with Facebook," that's OAuth. When you click that button, app #1 (the website) communicates with app #2 (the "identity provider," such as Google or Facebook) and says "Hey, this user wants to log in with their account." If you aren't already signed in, the identity provider will ask for your username and password to prove your identity, and it may ask you for permission to connect your account to the website and to share a few details.

Does this mean Google and Facebook are leaking your username and password to other apps? Not at all. The language of OAuth is tokens; when these apps talk to one another, they exchange long combinations of numbers and letters called tokens, which serve as a passport of sorts to uniquely identify you and what you're trying to do. These tokens allow app #2 to tell app #1 "You have permission to use this user's account with your website. Just be sure to show this passport when you send a request to me, so that I know it's legitimate."

##### Reducing the friction

This use of tokens is a key aspect of OAuth's value to healthcare interoperability. First and foremost, from a patient's perspective, OAuth simplifies the experience of connecting apps to your medical records. When you can log in and pull data securely using an existing account—say, a patient portal account—you have a user experience with less friction, not to mention fewer usernames and passwords to remember. Tokens also expire and become useless relatively quickly, usually within an hour, so they provide a greater layer of protection in case someone malicious gets ahold of one.

The benefits are equivalent for the developers of healthcare apps, because they can design their app without needing to manage and secure an extra set of login credentials and without needing to accommodate unique authentication workflows for every EHR. Think back to 2015 when Meaningful Use Stage 3 first [mandated patient access](https://www.federalregister.gov/d/2015-25595/p-1501) to their health information through APIs. Could this endeavor have ever been successful if app developers needed to support a dozen authorization schemes in order to support a critical mass of EHRs? I am skeptical.

##### Winner

I do not intend to downplay the importance of FHIR or any other standard relevant to healthcare interoperability. Really smart, passionate people have created these essential frameworks, and we need all of them to accelerate our progress. But FHIR, USCDI, and TEFCA are too new in my mind to have had the greatest impact to this point, and more mature standards like HL7v2 and X12 are hamstrung by their dependency on event-driven point-to-point interfaces, which aren't conducive to an app-based ecosystem. OAuth provides a simple, secure structure to enable software systems to communicate, and from my point of view, it has been the most important standard thus far for modern healthcare interoperability.

\---

Photo by [Erdenebayar](https://pixabay.com/users/erdenebayar-740663/) on [Pixabay](https://pixabay.com)


OAuth provides a simple, secure structure to enable software systems to communicate, and it has been the most important standard thus far for modern healthcare interoperability.

OAuth - not FHIR - has been the most important standard for modern interoperability - Nonstop Interop

OAuth - not FHIR - has been the most important standard for modern interoperability

![Pile of one hundred dollar bills](/images/100-dollar-bills-1665032400.jpg)

Today's a big day. The information blocking regulations have now reached their full scope and cover all electronic health information, rather than the limited subset of data points from USCDI version 1 as has been the case for 18 months. This is a positive step forward; while I wish the government didn't need to get involved, it's clear that rules of the road are needed to advance interoperability, and Congress empowered the ONC to establish these guidelines.

The work isn't done, however. The ONC was responsible for defining the info blocking rules and it has fulfilled its obligations. The Office of the Inspector General for Health and Human Services, as well as HHS itself, were tasked with outlining the penalties and disincentives for info blocking violations, and both are late to the party.

##### Where we stand

There are a few different characters in the info blocking saga, so let's do a quick review. [Three kinds of entities](https://www.healthit.gov/sites/default/files/page2/2020-03/InformationBlockingActors.pdf) are subject to the regulations—healthcare providers, health information networks/exchanges, and certified health IT developers, which collectively the ONC terms "IB actors." [Congress empowered the OIG](https://www.healthit.gov/sites/default/files/page2/2021-11/Information-Blocking-Portal-Process.pdf) to investigate all claims of info blocking, and the OIG retains most of the enforcement authority as well. For healthcare providers, though, HHS takes the lead on establishing and applying disincentives.

The OIG [issued a proposed rule](https://oig.hhs.gov/newsroom/news-releases/2020/infoblocking.asp) for the civil monetary penalties it can levy, and it gave a 60-day comment period. It also stated its goal of not enforcing any penalties until at least 60 days after the final rule is published. Trouble is, this all happened back in April 2020. Since then, there have been few public updates other than that they are prepping a final rule and that [it's a priority](https://oig.hhs.gov/documents/speeches/314/hcca-04292021-handout.pdf). HHS has similarly said it is [hard at work](https://www.healthcareitnews.com/news/hhs-secretary-cures-act-enforcement-long-overdue) on rule-making.

While no clear reasons have been given for the delays, understandably both departments have had a lot on their plates. The Senate didn’t [confirm Inspector General Christi Grimm](https://www.congress.gov/nomination/117th-congress/750) until February and the office lacks a confirmed Principal Deputy Inspector General. Additionally, the COVID-19 pandemic has rightfully been a top focus area that has taken resources and attention from other initiatives.

##### Why it matters

Finalizing the penalties and disincentives has the obvious benefit of putting teeth into the info blocking regulations. Rules aren't potent without a means of holding bad actors accountable and discouraging future bad behavior. HHS' rule-making would be especially valuable since [more than three-quarters](https://www.healthit.gov/data/quickstats/information-blocking-claims-numbers) of info blocking complaints submitted thus far have been about healthcare providers.

Yet final rules would also help the IB actors by providing clarity on what to expect. It is not fair to subject these groups to new rules without clearly outlining the consequences of their violation. As it stands, everyone is in the dark about the severity of punishment (outside of the limits Congress wrote into the Cures Act), and uncertainty is no one's friend.

It's time for both HHS and the OIG to step up and complete the rulemaking process on penalties and disincentives. Only then can we say that all the tools to combat info blocking are in place.

\---

Photo by [Giorgio Trovato](https://unsplash.com/@giorgiotrovato) on [Unsplash](https://unsplash.com)


The information blocking regulations have reached their full scope, but they cannot be considered complete until HHS and the OIG define the necessary penalties and disincentives.

HHS and the OIG are past due on the info blocking penalties - Nonstop Interop

HHS and the OIG are past due on the info blocking penalties

Yellow road sign that says "Speed humps ahead"

![Yellow road sign that says "Speed humps ahead"](/images/Road-sign-speed-humps-ahead-1664514000.jpg)

Today is the final day to [submit feedback](https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi) to the ONC on version four of the USCDI. Since USCDI first came out in 2020, the ONC has made several useful updates and regularly raised the bar on the data that Certified Health Information Technology must be able to exchange. For example, version 2 added sexual orientation and gender identity as constituent data elements to better support care for LGBTQ+ patients, and version 3 brought the first billing-related data class of health insurance information. No doubt USCDI is an important standard that moves healthcare interoperability forward.

Yet USCDI can't reach its full potential as long as the regulations for CHIT continue to focus on read and search capabilities. Currently, vendors are required only to provide a standard API that can "[respond to requests](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315#p-170.315$g$$10$)" for the mandatory data points. This solves only one half of the interoperability equation. The ability for external systems to create and update data in a patient's chart is equally important in the pursuit of a competitive app-based ecosystem.

##### Write about that

Why is write access as important as read? For one, the ability to write data into an EHR opens up a large number of workflows for digital health companies. Remote patient monitoring, insurance verification, diagnostic questionnaires, and clinical research immediately come to mind, but the possibilities go well beyond such a short list.

Secondly—and just as importantly—write access better enables innovators to challenge the dominant position of EHRs as the guardians of our health information. Prioritizing read and search implies that the EHR knows all and you should just accept that. Anyone with experience in this industry, however, recognizes that the fragmented nature of health IT means the EHR can't be everywhere and know everything. There are numerous sources of data—from patients to wearables to insurance payers—that could meaningfully contribute to a patient's health record if they just had an easy, standards-based way to do so.

Plus, establishing a floor for CHIT to accept data over RESTful APIs will accelerate our shift to modern standards and technologies. Nowadays plenty of write operations occur, but vendors must work around limited API support and leverage options such as HL7v2 interfaces and file imports. These can work well in many instances, but they can take longer to implement, are harder to scale, and come with extra baggage such as the need for a VPN. The technology for 21st-century data exchange exists; we just need to nudge CHIT developers towards robustly supporting it.

##### Do it the write way

To be clear, federal rules don't need to require unlimited write access. They could take an incremental approach, first obligating updates and then create operations, and it may not make sense to mandate delete access via APIs. I acknowledge too that mandating write access will create additional burdens for CHIT developers, since validating, sanitizing, and ingesting data from an external source is inherently more complex and riskier than responding to a request. Yet another reason why slow and steady is likely best here. Nevertheless, it's important that we begin this journey now; otherwise the power of USCDI will continue to be stifled.

\---

Photo by [Michael Anthony](https://www.pexels.com/@michaelanthony/) on [Pexels](https://www.pexels.com)


USCDI can’t reach its full potential as long as the regulations for CHIT continue to focus on read and search capabilities.

USCDI's power will be stifled until write access is required - Nonstop Interop

USCDI's power will be stifled until write access is required

Nonstop Interop is a when-the-moment-feels-right blog focused on interoperability and data integration within healthcare. Our goal is to provide educational and insightful content for technical and non-technical audiences.

Nonstop Interop

Satellite image of lights in the United States at night

Nonstop Interop is a when-the-moment-feels-right blog focused on interoperability and data integration within healthcare

Our goal is to provide educational and insightful content for technical and non-technical audiences. Please forgive any digressions, bad analogies, or shameless self-promotion.

##### Spread the word
