Chirp’s Promoting Interoperability Journey

Our journey to getting CEHRTified

Iora Health is thrilled to be a part of the Centers for Medicare & Medicaid Services (CMS) Direct Contracting Program. This program allows Iora’s patients to let CMS know that they are an Iora patient. This in turn allows Iora to continue to give its patients the same great care they are used to and provide Iora with more information about their care across the healthcare system.

One of the requirements for participating in the Centers for Medicare and Medicaid Services (CMS) Direct Contracting program is use of Certified Electronic Health Record Technology (CEHRT). For a commercial-off-the-shelf product, these requirements would have to be satisfied by the software vendor. At Iora, we believe that to deliver great care with an innovative model you need great software that supports that model. Chirp is Iora’s collaborative care platform built from the ground up to support our care model. To ensure we had the opportunity to take part in Direct Contracting, the Chirp team had to ensure our platform met the criteria for Promoting Interoperability (PI)/CEHRT.

Estimation is Hard

Several years ago we considered undergoing the certification process, but estimated it would take more than two years, so we postponed the work until the Direct Contracting program arose. During the summer of 2019, Iora’s engineering team provided a revised estimate that the work to make Chirp CEHRT certified would take half the time (a little over a year) to complete. We also believed that in order to meet that timeline, we would need to use all four of our delivery teams during the project, pausing any other development to Chirp.

Product Approach

In partnership with experts in Promoting Interoperability, our initial approach to build was to identify any critical or core aspects of the work, which was getting the Consolidated Clinical Document Architecture (C-CDA) built. Most of the work we needed to do (displaying, sending, receiving, or reconciling) was based around the C-CDA. Given that so much of the work was centered around the C-CDA, we had one team fully dedicated to completing the C-CDA work from the start. Throughout the project, our intention was to limit the amount our teams had to work around each other as they were trying to deliver on a given criteria. We also attempted to factor in the riskiness of a given criteria based on the size of the criteria, the complexity of the criteria, or our internal knowledge of the specific criteria.

We began with three teams. One team was focused on building out the C-CDA. Another focused on adding support for Direct Secure Messaging. The third team was responsible for integrating with a new medication management vendor, in part to help us meet the Promoting Interoperability requirements. From there, our teams moved on to support viewing the C-CDA, reconciling the C-CDA, and wrapped up with building out the APIs to support third party access in our patient application. Finally, we finished up with work to support the reporting, security and usability criteria.

The criteria we were certifying had two different testing modes, live proctor tests, and self-attestations. To prepare for and support the live proctor testing, the Chirp product team held mock testing sessions whereby the respective team’s product owner would demonstrate the steps required for the proctor test and would put together a playbook to support the testing steps. We utilized two full-day and one half-day live proctor test sessions to complete the respective criteria, and completed the remaining self-attested criteria with support from our vendor partners.

Technical Approach

Each of our three teams faced different technical challenges as they completed their part of the certification.

The team building out our C-CDA export spent their time mapping our data model to the C-CDA attributes. Because Chirp was built to meet the needs of our care teams, our data model and APIs were not originally designed for external inter-operability with specific standards like C-CDA or FHIR. The team spent time mapping the Chirp fields to C-CDA fields and when they identified gaps, they added those attributes to Chirp.

Chirp already contained the ability to communicate with patients using email or SMS. This made it easier for the team working on Direct Secure Messaging to extend that service to be able to send and receive Direct messages by integrating with our vendor’s API, as the service had already been generalized to handle multiple types of messages.

By using our partner’s certification for the medication module, we were able to simplify our CEHRT certification. However, we still had to pass the partner’s certification process. We had extensive medication information stored in Chirp and the greatest challenge was to migrate all that data into the partner’s system. We did several dry runs to verify we were mapping all the medications and pharmacies correctly allowing our providers to verify on individual patients before we went live across the entire company.

Conclusion

In the end, our two estimation efforts yielded time frames of greater than two years to about one year, and after almost 16 months to the day, on December 24, 2020 Chirp became Certified Electronic Health Record Technology (CEHRT). Turns out, we ended up somewhere in the middle.

We could not have done all of this work without great support from our vendor partners throughout the whole project.