Smile CDR, a leading health data storage and integration company, today announced the successful implementation of its clinical data repository (CDR) platform across 20 U.S. payer databases.
The platform updates allowed customers to effectively meet the Centers for Medicare and Medicaid (CMS) Interoperability and Patient Access Final Rule (CMS-9115-F) compliance enforcement deadline of July 1, 2021. The new CMS rule addresses barriers to the secure exchange of health information that limit the ability of patients to access essential health information.
“We are grateful for the opportunity to help customers standardize data capabilities that improve patient access to their own health information,” said Duncan Weatherston, chief executive officer at Smile CDR. “It is critical that we keep our customers at the center of what we do as we move one step closer to creating a common information exchange playing field.”
In June, Smile CDR became the first company to receive the Drummond Certification of Compliance, certifying interoperability and compliance with CMS Final Rule standards and reducing the risk payers, providers, developers, and applications may not be truly interoperable or only partially interoperable in real-world settings.
Under the CMS Final Rule, U.S. government health plans must have an interoperable Patient Access Fast Healthcare Interoperability Resource (FHIR) API to provide patients easy and secure access to their records.
Last year, 2015, was a year of buildup, anticipation, and finally some bold moves to propel healthcare technologies forward, specifically regarding interoperability of data. The Office of the National Coordination, under the auspices of the department of Health and Human Services, released the long-awaited and much-debated meaningful use Stage 3 requirements in October. All the players in the health tech space were awaiting the final verdict on how Application Programming Interface (API) technology was placed into the regulations, and the wait was worth it, regardless of which side of the fence you were on. Before we get into the predictions, though, a little background knowledge about these technologies, and their benefits, will be helpful.
API Overview
An API is a programmatic method that allows for the exchange of data with an application. Modern APIs are typically web-based and usually take advantage of XML or JSON formats. If you are reading this article, you almost inevitably have used apps that exchange data using an API. For example, an application for your smartphone that collects data from your Facebook account will use an API to obtain this data. Weather apps on phones also utilize an API to collect data.
HL7 Overview
Next let’s take a look at the history of interoperability of healthcare data. HL7 2.x is a long standing method to exchange healthcare data in a transactional model. The system is based on TCP/IP principles and typically operates with Lower Layer Protocol (LLP) which allows for rapid communication of small delimited messages. The standard defines both the communications protocol and the message content format. No doubt about it, HL7 2.x is incredibly effective for transactional processing of data, but it has been limited in two key areas:
A pioneering developer of a successful HL7 interface engine once said: “Once you have developed one HL7 interface … you have developed one HL7 interface.” The standard exists, but there is nowhere near enough conformity to allow this to be plug-and-play. For example, a patient’s ethnicity is supposed to be in a specific location and there is a defined industry standard list of values (code set) to represent ethnicity. In reality, the ethnicity field is not always populated and if it is, it rarely follows the defined code set.
HL7 is an unsolicited push method, which means when a connection is made, messages simply flow from one system to another. If you are attempting to build a collection of cumulative data over time, this is a mostly sufficient method, but what you cannot do is ask a question and receive a response. Although some query/response methods have existed for years, their adoption has been very sparse in the industry.
2016: Year of the Healthcare API
If you are a physician with an electronic health record (EHR) system and you accept Medicare patients, you likely have gone through the process of becoming meaningful use (MU) certified, which means you have purchased an EHR software solution certified by the ONC. This EHR must follow guidelines of technical features, and physicians must ensure they utilize those features in some manner. In October 2015, the ONC released MU Stage 3 criteria (optional requirement in 2017, mandatory in 2018) which includes this game changer: A patient has a right to their electronic health information via an API.
