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 App Market, Cerner Code App Gallery, Allscripts 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

Get new post notifications in your inbox


Subscribe to the blog

Latest from Nonstop Interop

![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.


The biggest news in interoperability isn't in healthcare - Nonstop Interop

The biggest news in interoperability isn't in healthcare

Child in a pink shirt and gray vest holding a book with a look of surprise on his face, with overlayed text that says "Warning: APIs may cause great excitement in minors"

![Child in a pink shirt and gray vest holding a book with a look of surprise on his face, with overlayed text that says "Warning: APIs may cause great excitement in minors"](/images/Surprised-child-1698382800.jpg)

"Is this hacking?" he asked.

Taken aback by the question, I ad-libbed, "Well—not really, but it's a little like legal hacking."

"This is so cool," he replied.

That was a snippet of a conversation with a middle schooler, as I introduced him to the world of APIs. I volunteered this week at a public middle school here in Nashville; it was Family STEAM Night, and a variety of businesses were showcasing careers and opportunities in science, technology, engineering, the arts, and math. A little surprisingly, Ashavan was the only tech company in attendance, but that didn't make us the biggest draw. The gentleman at the adjacent table had a live snake the kids could pet; it's tough to compete against that.

Nonetheless, a good time was had. I was there to teach kids about APIs and how you can make a career out of getting totally different software systems to talk to one another. The demo was simplistic, a couple of API calls between Postman and Salesforce, but it resonated with the students. They had no idea apps on a phone or computer could exchange data back and forth.

##### Connecting to more kids

The experience made me realize that we should be exposing our children to APIs in K-12 schools. We've made strides in incorporating computer science into curriculum, with the Code.org Advocacy Coalition [reporting](https://advocacy.code.org/stateofcs) that now over half of high schools in the US provide a computer science course. And [54% of the states](https://advocacy.code.org/2022_state_of_cs.pdf) require schools to offer computer science, with five of those (Arkansas, Nebraska, Nevada, South Carolina, and our home of Tennessee) implementing computer science courses as a high school graduation requirement.

Yet these courses focus heavily on hands-on-keyboard coding, and there's more to software and technology than simply building the tools. There's also design thinking, system architecture, and solutioning. There's security, performance, and data privacy. You can build a successful foundation of knowledge—and a well-paying career—without becoming an expert in a programming language.

APIs can be a powerful conduit for teaching all of these things. Now, granted, truly understanding APIs requires deep, high-level thinking skills that younger kids probably won't have developed yet. The [K-12 Computer Science Framework](https://k12cs.org/wp-content/uploads/2016/09/K%E2%80%9312-Computer-Science-Framework.pdf), developed by Code.org and a few other organizations, appropriately reserves API concepts for high schoolers. And APIs aren't exactly flashy and exciting to most people; writing a Python script that causes a toy robot to turn and move feels more rewarding.

However, I believe APIs have a place within computer science curriculum, and we can and must do a better job of introducing them at an early age. We can do this by relating API concepts to the real world and demonstrating the practical effects that arise when software is interoperable. Here's one idea: have younger students roleplay as apps and data points. The "apps" could call out commands to send or retrieve data points, and those "data points" could run back and forth between the connected apps. But if an "app" gives an invalid command, no data will move. It's a simple way to demonstrate technical communication while incorporating some physical activity.

##### Mix in some magic

Despite studying education in college, I'm by no means an expert on the best approach here. We have educators who are better suited for baking APIs into school curricula than an interoperability nerd like me. But what I do know is that we should do it. APIs are magical things; they break down barriers and spur innovation. Let's expose our kids to that magic in the right way and at the right pace, and hopefully we'll bring greater understanding and a brighter future to a few more (legal) hackers.

\---

Image by [Ben White](https://unsplash.com/@benwhitephotography) on [Unsplash](https://unsplash.com)


We should teach our kids about APIs - Nonstop Interop

We should teach our kids about APIs

Statue of lady justice holding scales. The beam of the scales is emblazened with the Epic logo, and one scale tilts lower than the other due to a weight labeled Partners & Pals.

![Statue of lady justice holding scales. The beam of the scales is emblazened with the Epic logo, and one scale tilts lower than the other due to a weight labeled Partners & Pals.](/images/Epic-lady-justice-1694494800.jpg)

If it seems the past month has been good to a certain company in Verona, WI, you would not be wrong. Fresh off Epic's annual Users Group Meeting, [UPMC announced](https://www.healthcareitnews.com/news/epic-gains-new-ehr-clients-intermountain-and-upmc-move-cerner) it will transition its hospitals off numerous EHRs (most notably, Oracle Cerner) and onto Epic. Shortly thereafter, news broke that Intermountain will ditch Cerner and roll out Epic across the health system within about two years.

The favorable press actually began in mid-August, when Abridge revealed it is the first startup selected for Epic's [Partners and Pals](https://www.modernhealthcare.com/digital-health/epics-launching-third-party-vendor-program-nuance-abridge) program (PPP). The PPP is a new initiative where Epic collaborates with vendors established ("Partners") and up-and-coming ("Pals") to build deep integration with the Epic EHR and take the combined offering to market. In the last four weeks, [Talkdesk has joined](https://www.healthcareitnews.com/news/epic-adds-talkdesk-its-partners-and-pals-program) as the second Pal, and Nuance and [Press Ganey](https://www.pressganey.com/news/press-ganey-announces-collaboration-with-epic-to-advance-integration-of-patient-experience-insight-into-electronic-medical-records/) are slated as the initial Partners.

The PPP clearly benefits Epic by allowing the company to complement its EHR with a suite of workflow- or capability-specific technologies, most of which are leaders in their respective areas. Such partnerships haven't been common—Epic has always preferred building over buying—but they demonstrate where Epic feels it can't afford to wait to develop equivalent functionality.

##### Not so buddy-buddy

But what's good news for Epic isn't necessarily good news for healthcare. Whereas the direction of our industry has been towards greater interoperability and greater choice, the Partners and Pals initiative threatens to throw everything into reverse. Now, the powers that be in Verona will be able to handpick their favored companies and christen the resulting solutions. They will be able to design, develop, and release new integration options only to particular vendors, leaving everyone else at a disadvantage. Given how influential a stamp of approval from Epic can be, making it into the PPP truly could make or break the fortunes of these companies.

I'll readily admit that I could be reading too much into the situation. Perhaps the PPP is simply a go-to-market strategy with no technology benefits. Or, perhaps any new APIs and interoperability methods will be designed with multiple vendors in mind and shared openly to all who want them. If Epic publicly commits to making all integration options equally available to all vendors, at the same time and the same cost, and with input from allied and non-partner companies alike—then I'll gladly admit I was wrong.

But Epic's public comments on the matter—which, as is typical, are limited—don't inspire much confidence. A key executive for the PPP said it will create "new value for health care by curating unique collaborations...[where] Epic works with [participating companies] to develop deep integration for their products and services, helping them innovate quickly...." That's nice, but it would be far better if Epic created new value for healthcare by opening deep integration points equally and fairly to all vendors. We don't need Epic to pick the winners and losers; its customers can do that just fine when they have a robust set of choices.

##### Freedom over favoritism

I see no issue in Epic collaborating with other vendors to offer a more complete set of products and services to its customers. Epic can partner with whomever it wants. The integration capabilities that these partners use, however, should be equally and concurrently available to non-partner vendors as well. No EHR should limit the availability of integration capabilities or charge extra fees to one company vs another.

Based on what we currently know, nothing about the PPP falls within the category of openness, access, and equal opportunity. This flies in the face of a core element of interoperability. I have no doubt that other EHR companies are watching what Epic does to see how they could mimic it. Absent public commitments to openness and fairness from Epic, the PPP risks making seamless integration with the EHR accessible to only a privileged few, and if that happens, it'll truly stink for interoperability.


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

The biggest news in interoperability isn't in healthcare

We should teach our kids about APIs

Epic's Partners and Pals smells like favoritism, and that stinks for interoperability

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

The biggest news in interoperability isn't in healthcare

We should teach our kids about APIs

Epic's Partners and Pals smells like favoritism, and that stinks for interoperability

Leaders often view interoperability as a headache