Ashavan brings clarity, certainty, expertise, and ease to healthcare data integrations. We make the best choice the easiest one.™

Two red doors, then one gold door, and then one red door

We make the best choice the easiest one™

Healthcare Interoperability Consulting

We are interoperability experts for the leading EHRs

Bring on a fractional Chief Interoperability Officer to define an interoperability strategy, guide a team, and deliver exceptional results


Executive leadership

Framed white certificate with a red ribbon

Publish on the Epic Showroom, Oracle Healthcare Marketplace, Veradigm App Expo, and athenahealth Marketplace


Vendor certification

Workflow diagram with a blue, green, and red box connected by yellow arrows

Design comprehensive and efficient integration solutions


Solution architecture

Build and maintain scalable integrations to automate tasks, reduce double documentation, and increase patient and provider satisfaction


Integration development

Implement your integrations quickly and smoothly while minimizing the burden for customers


Project management

Two stacked books with a mortarboard on top

Prepare your team for success by providing a strong foundation in FHIR, HL7 interfaces, bulk integration methods, ONC regulations, USCDI, HIPAA, and more


Education & best practices

The healthcare technology industry is a jungle

We can help

Word cloud with various words and phrases, such as very knowledgeable, makes it look easy, thorough, listened to our needs, great communicator, helpful, detailed, and proactive

And we have the Net Promoter Score to prove it

Our customers praise our work

Share this post

Subscribe to the blog

Latest from Nonstop Interop

Poker scene from the movie Casino Royale with text overlaid

![Poker scene from the movie Casino Royale with text overlaid](/images/Casino-royale-1727931600.jpg)

Over the summer, ASTP (formerly ONC) released [HTI-2](https://www.federalregister.gov/documents/2024/08/05/2024-14975/health-data-technology-and-interoperability-patient-engagement-information-sharing-and-public-health), a massive proposed rule with widespread implications for stakeholders across the healthcare ecosystem. This regulation is focused on two important things. First, it broadens the interoperable capabilities of health IT to support a greater variety of workflows, and second, it increases the reliability and trustworthiness of the data exchanged. In some cases, new requirements will unlock brand new workflows and open the door to previously unavailable outcomes. More often, changes will increase the utility of data by improving its reliability or timeliness.

The word you will see often both in the rule and in this post is "standardize." Standardization is desperately needed across healthcare, and in HTI-2 ASTP has proposed to expand and update the code systems, protocols, and implementation guides that certified health IT systems would be required to adhere to. There are plenty of summaries out there to peruse, so this post will instead dive more deeply into a couple of the rule's key provisions and explain why we at Ashavan are so excited about their implications.

##### A combo draw for public health

HTI-2 packs many new public health data exchange requirements that concern not only provider-facing health IT like EMRs, but also Public Health Agency (PHA) health IT. This is an important acknowledgement by ASTP that both participants in a public health data transaction are responsible for its outcome and that efficacious bidirectional exchange of data will lead to the greatest utility of shared public health data. Our discussion will focus on the new certification criteria for the health IT used by PHAs.

HTI-2 proposes a baseline level of data exchange functionality for all certified PHA health IT systems. Important new requirements like a standardized data transport mechanism, data validation logic, and support for querying and filtering would be included in this baseline functionality. This would create much clearer expectations for external systems when sending data into or receiving it from PHA systems, leading to an environment in which stakeholders can better trust public health data quality and access it when needed.

Let's look at how HTI-2's proposed criteria would impact immunization data exchange as an example use case. Today, there is no standardized data transport mechanism that all PHAs must support to send and receive immunization data. This has led to mismatched, incompatible integration interfaces between EMRs and PHAs' Immunization Information Systems (IIS) and particular barriers to accessing immunization data from multiple states. HTI-2 would require PHAs' certified health IT systems to adopt SOAP-based data transport. We would prefer to see ASTP jump straight to FHIR APIs as it did for the public health FHIR API requirement for EMRs, but possibly more important than the chosen standard is the fact that a standard would now exist, allowing for more consistent and predictable connections with PHAs.

Equally important is today's lack of minimum validation logic required of PHA health IT when ingesting and storing immunization data. Data submission errors such as an invalid CVX code or missing required data like a vaccination date hurt data quality and erode users' trust. HTI-2 proposes that certified health IT for PHAs incorporate specific data validation, including data mapping, null value interpretation, and proper error detection, into the data ingestion process. This should create a baseline level of data quality that consumers of IIS data can expect.

Additionally, new requirements in HTI-2 mean that certified IIS would need to support a minimum level of querying and filtering. Say a patient comes to the emergency department after stepping on a nail, and their provider accesses the local immunization registry to determine the date of the patient's last tetanus shot. Without a way to filter down to only pertinent immunization data, the provider may see and need to hunt through a long list of vaccinations. But with HTI-2, that registry's software must be able to filter by a specific vaccine code, making it much easier for the provider.

While some of these changes may seem modest at first glance, ASTP's proposed requirements would finally establish clear baseline capabilities of PHA health IT systems to exchange public health data with a wide variety of stakeholders, including clinicians, researchers, and other health agencies. The COVID-19 pandemic highlighted the need for efficient exchange of public health data, including immunizations, disease transmission, drug prescribing, and lab results. This regulation would guide the US' public health ecosystem towards a future where public health data of verifiable quality can be exchanged through repeatable, secure integrations.

##### Showdowns through subscriptions

FHIR adoption in the U.S. healthcare system has been limited in supporting real-time workflows at the point of care, primarily because many EMRs have implemented FHIR without enabling external systems to detect data changes with [webhooks](/blog/webhooks-biggest-gap-interoperability-20230822). As a result, implementers often must rely on older integration modalities like HL7v2 for event-driven triggers. Some EMRs like athenahealth have implemented proprietary APIs to accommodate these types of workflows, and others like Epic and eClinicalWorks support the CDS Hooks specification, which allows the exchange of real-time data for clinical decision support in specific scenarios. That said, a standardized, API-based means of triggering real-time data exchange from within a source system has yet to be adopted across the health IT landscape, which has severely curtailed health IT innovation.

To address this gap, HTI-2 proposes the widespread adoption of the FHIR event subscription framework. This FHIR-based protocol would allow external systems to "subscribe" to notifications when a particular "event" occurs in a health IT system. For example, when a new lab result appears in an EMR, subscribers of that event would be notified, allowing them to retrieve those lab results from the electronic health record via a FHIR API request. Imagine if a patient's care team members could subscribe to each other's patient updates. Patients could identify new providers in pre-appointment questionnaires to allow for the exchange of EMR endpoint information. Then, when the patient's psychiatrist updates the dosage of a medication they are taking, the primary care physician's EMR would be alerted to this change. It could make a subsequent FHIR API request to the psychiatrist's system to get the medication update and notify the PCP of the change. This could all be implemented with a small fraction of the effort and cost needed to accomplish the same thing through an HL7v2 interface.

The proposed initial rollout of the FHIR event subscription requirement in HTI-2 focuses primarily on clinical data contained in key FHIR resources like Condition, DocumentReference, Immunization, MedicationRequest, Observation, and Patient. Subscribing health IT systems would be notified when a FHIR resource they are subscribed to is created or updated, allowing it to immediately retrieve those changes. We're pleased that ASTP incorporated filtering capabilities into the proposed subscription requirements; for example, Encounter subscriptions must be filterable on reasonCode, patient, and type.

The implications here are extensive. With better real-time data exchange, clinical decision support use cases expand dramatically. Contraindicated medications that a patient is on could be identified without relying on the patient properly relaying the changes to their care team. Public health agencies could be alerted in real time when a new case of a disease is identified, and details of the case could be made available in their systems immediately upon the diagnosis being documented in the provider's EMR.

In practice, use cases like these may be limited in the near-term, but the reason for this is much less likely to be technical in nature. These new requirements improve the repeatability and durability of event-driven data exchange by allowing us to finally move on from the HL7v2 standard and alter the cost-benefit analyses of decision-makers considering whether to invest in these types of integrations.

##### More ways to win

The proposed changes in HTI-2 are immense and this article has hit on only a subset of the changes that will take effect if the rule is finalized. We'll be following closely as HTI-2 makes its way through the finalization period. Given the impending presidential election and subsequent change in administration, it will be worth seeing whether ASTP is able to finalize HTI-2 in the near future. Overall, we applaud ASTP for proposing regulations that go all-in on advancing healthcare interoperability and improving patient outcomes.


With HTI-2, the feds go all-in on interoperability - Nonstop Interop

With HTI-2, the feds go all-in on interoperability

Get new post notifications in your inbox


Jason Kelce shirtless with word bubble that says "Only a 3-year wait for prior auth APIs!!!"

![Jason Kelce shirtless with word bubble that says "Only a 3-year wait for prior auth APIs!!!"](/images/Jason-Kelce-prior-auth-APIs-1706162400.jpg)

In recent weeks, HHS and its agencies have been anything but slackers. Each of the past three months has brought some kind of notable rulemaking that moves the needle on interoperability. In November, it was a proposed rule on [provider disincentives](https://www.federalregister.gov/documents/2023/11/01/2023-24068/21st-century-cures-act-establishment-of-disincentives-for-health-care-providers-that-have-committed) for information blocking. The ONC followed in December with its latest final rule for Health IT Certification, known as the [HTI-1 rule](https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program). And just last week, CMS issued its most important [interoperability-related rule](https://www.cms.gov/newsroom/fact-sheets/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f) since 2020, one that adds a host of requirements for prior authorization-related FHIR APIs.

But while our federal government no doubt moves, it doesn't necessarily move quickly, and it doesn't always ask others to move quickly either. The prior auth rule is a good example. Impacted payers—which include Medicare Advantage insurers, state Medicaid and CHIP programs, and payers who offer federal marketplace plans—have until January 1, 2027, to release their prior auth APIs, and these APIs only need to cover prior auth for procedures, not drugs.

Though I don't want to minimize the challenge of this task, three years is far too long a wait until prior auth begins to emerge from the Stone Age. If we want to rapidly improve prior authorization processes—and, more generally, accelerate the advancement of interoperability in healthcare—we should invest in financial incentives.

##### PA = Pretty Awful

Prior auth is basically a reality of life. If you have insurance and need a consultation with a specialist, a complex procedure, or an expensive medication, your insurance company will likely require pre-approval before agreeing to pay. This extra hoop to jump through doesn't please providers; 89% of respondents to [an AMA survey](https://www.ama-assn.org/system/files/prior-authorization-survey.pdf) said the prior auth process has negatively impacted their patients' care, and 88% feel it is a burdensome task.

Burden equates to wasted time and money. It's at such an extreme that [CMS estimates](https://www.federalregister.gov/public-inspection/2024-00895/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-advancing-interoperability) its final rule will collectively save practices and hospitals 230 million hours and $16 billion over 10 years. The Council for Affordable Quality Healthcare, which tracks adoption of electronic transactions for administrative workflows under HIPAA, is less generous, with its most recent estimate that fully electronic prior auth would save the industry (providers and payers) [$450 million annually](https://www.caqh.org/sites/default/files/2023-05/2022-caqh-index-report.pdf). (Note: CAQH defines electronic prior auth as X12 278 transactions, not API-based transactions, since HIPAA mandates the former.)

##### Moolah to get moving

Whichever estimate you believe, there's the potential to cut hundreds of millions of dollars in unnecessary spending by getting our industry to embrace modern technology—and that's for only one portion of a single workflow. But we're leaving that money locked up and out of reach if most payers (legally) delay deployment of the prior auth APIs until 2027. I don't begrudge CMS for setting that timeframe; insurance companies have a lot of work ahead of them, from [translating their prior auth criteria](/blog/cms-prior-auth-rule-20230302) into machine-computable rules to developing and testing their APIs, and no one wants to see a hasty and flawed rollout.

But that doesn't mean there aren't ways for public and private players to encourage the availability of prior auth APIs sooner. If payers release their APIs in 2025 or 2026, their billing providers will realize enormous savings sooner. One idea would be for providers and payers to arrange to share in these savings until the official deadline arrives. Another option could be for the federal government to temporarily increase payments or cost sharing for those leading-edge payers. Both approaches would reward innovation, speed, and efficiency and would still result in overall savings for our industry.

I will admit, this is an idea with holes and flaws. For one, any financial incentives from Washington will have to be paid for, because [our national debt](/blog/interoperability-debt-pie-20230525) isn't getting smaller. Second, the payers' prior auth APIs are less than helpful if EHRs don't support transacting with them, so some sort of benefit has to be considered for EHRs that provide early support.<sup>1</sup> And calculating, documenting, and exchanging the savings resulting from the prior auth APIs could be a burdensome process itself, negating some of the overall benefits.

Nonetheless, if we want to go big on prior authorization, we have to dream big. Thinking more broadly, I believe financial incentives should be regularly in play for high-value/high-impact interoperability initiatives. For example, [webhooks can add significant value](/blog/webhooks-biggest-gap-interoperability-20230822) and open the door to new innovations, so EHRs should be incentivized to offer webhooks until they are mandatory.

Right now the pace of change in interoperability is essentially the speed at which Congress passes new laws and HHS issues new rules—in other words, a slow, methodical grind. When greater interoperability can bring greater efficiency, lower spending, and healthier lives, we should be willing to commit money upfront to realize those benefits. In business, when you want something done, you invest not only time but also money into making it happen. Healthcare in America is a business, and interoperability must be one of its most important investments.

\---
###### Notes

**Note 1: EHRs and prior auth APIs**

CMS' prior auth rule does not affect EHRs in any way. Any rulemaking to require EHRs to support prior auth APIs would need to come from the ONC. It is widely expected that the ONC's next rule for Health IT Certification, the HTI-2 rule, will include this requirement when it is proposed this year.

It pays to incentivize interoperability - Nonstop Interop

It pays to incentivize interoperability

![Apple hearts Google](/images/Apple-hearts-Google-1701151200.jpg)

You might've missed Apple's big announcement this month. If so, you're forgiven. What should have been a wave felt more like a ripple, because news about interoperability—unlike news about Taylor Swift—rarely makes headlines.

Beginning in 2024, Apple will reverse years of resistance and [start supporting](https://www.theverge.com/2023/11/16/23964171/apple-iphone-rcs-support) Rich Communication Services (RCS) for messaging with non-Apple devices. If you've ever used a modern messaging app that works over Wi-Fi or that shows you when the other person is typing a response, it's possible that you were using RCS. This announcement doesn't mean Apple is suddenly an altruistic industry player—the company is likely responding to [European regulations](https://www.privacyworld.blog/2022/10/dma-eu-publishes-the-new-digital-markets-act/) and [scrutiny](https://www.theverge.com/2023/9/6/23861030/imessage-bing-european-union-commission-digital-markets-act-dma)—but it does portend a more complete, satisfying, and interoperable messaging experience for millions of people.

##### A tell-all on protocols

To appreciate why Apple's shift is a big deal, we need to dissect what it actually means. The word to know in telecommunications is "protocol," which you can think of as a standard that describes how devices and networks can communicate. Analogous to how APIs facilitate data exchange between software applications, communications protocols allow the happy birthday text you type out for your cousin to leave your device, traverse the globe, make it to the correct destination phone, and display accurately for the birthday boy.

Texting has been around for decades, but for most of that time, it's been based on SMS, a protocol from the 1980s. SMS has done its job well and is universally supported, but it has some drawbacks. For one, it sends messages over a cellular network, so you must have a phone plan. It technically only supports messages of 160 characters (even less than Twitter!), though carriers handle breaking up and reassembling longer texts for us. And SMS' support for sending images and videos, via an extension to the protocol known as [MMS](https://www.twilio.com/en-us/learn/messaging/what-are-sms-and-mms), is pretty limited in terms of the size and quality of the files.

In recent years, new kinds of messaging apps that use the Internet, rather than cell networks, have exploded in popularity. WhatsApp, WeChat, Messenger, and Signal are but a few examples. These apps provide numerous handy features like larger message sizes and the ability to see whether your message was sent, received, and opened. Phone carriers wanted to bring an equivalent experience to their subscribers, so they banded together and developed RCS as the industry-standard protocol to do that. Carriers and device manufacturers have 260 pages of [open specifications](https://www.gsma.com/futurenetworks/wp-content/uploads/2019/10/RCC.71-v2.4.pdf) to implement, and the end result allows you and I to do things like transfer files during a call or resize images and videos before sharing them.

##### Apple finally bites

RCS is not supported by everyone, however, and that brings us to the world's most valuable company. Apple is well-known for erecting a walled garden and locking users into its ecosystem. Its Messages app is available only on Apple devices and uses a proprietary protocol called iMessage. For messaging with non-Apple devices, Messages falls back to SMS/MMS. Those non-Apple users appear in a conversation with green bubbles, rather than the traditional blue, and up till now, Apple has stubbornly declined to provide a modern or commensurate experience. One of its go-to arguments has been that iMessage offers superior security, since RCS does not natively address encrypting messages end-to-end.

Google and Samsung, on the other hand, have embraced RCS and [publicly advocated](https://www.android.com/get-the-message/) for its adoption; Google has tried publicly shaming Apple into changing its mind, even making the rather [dubious claim](https://www.usatoday.com/story/tech/2022/01/10/google-imessage-iphone-text-messages/9155873002/) that the different colored bubbles represent a form of bullying. The effort was fruitless for years, however, until Apple's declaration on November 16 that RCS support is coming and that the company will work with industry stakeholders to improve the standard's security.

To be clear, this decision does not mean iMessage is going away or that Apple is opening up any new integration opportunities. Apple will continue to use the closed-source protocol for Apple device-to-Apple device communication. We the people will still be divided into blue and green camps. RCS will simply replace SMS/MMS as the primary protocol for communicating with non-Apple devices.

##### Slow and steady

It's a small step forward, but also a significant win for interoperability. The fundamental goal of interoperability is to be able to exchange data between systems and to have that data be equally usable and understandable regardless of where it lives. Apple's decision advances that aim, bringing greater parity to the exchange of messages across platforms and allowing everyone in the world who has or communicates with an Android device to enjoy texts, images, and videos in equal measure. And that is truly big news.


Healthcare Interoperability Consulting

We can help

Executive leadership

Vendor certification

Solution architecture

Integration development

Project management

Education & best practices

Our customers praise our work

We're passionate about interoperability

With HTI-2, the feds go all-in on interoperability

It pays to incentivize interoperability

The biggest news in interoperability isn't in healthcare

Leaders often view interoperability as a headache

Ashavan - Healthcare Interoperability Consulting

Healthcare Interoperability Consulting

We can help

Executive leadership

Vendor certification

Solution architecture

Integration development

Project management

Education & best practices

Our customers praise our work

We're passionate about interoperability

With HTI-2, the feds go all-in on interoperability

It pays to incentivize interoperability

The biggest news in interoperability isn't in healthcare

Leaders often view interoperability as a headache