Follow us on Twitter: @GoAfricaNetwork
Zoeticx has written middleware which can unify data from any current provider into a single common format. Their newly released API provides easy access to that middleware, enabling developers to easily write applications against multiple databases storing records in different formats.
There are currently over 350 competing formats for storing medical records electronically.
Zoeticx’s middleware, known as the Patient-Clarity platform, resides in the cloud. It uses gateways to communicate with the different Electronic Medical Record (EMR) formats, and transforms them into a custom, common format provided by Zoeticx. Currently the five most common formats are supported — Epic, Cerner, Allscripts Sunrise, Allscripts Professional, and OpenVistA. The gateways are designed against a shared interface, making it easy to add more formats.
by Eric Stein on May 29, 2014
This is the initial public release of the API, but it already powers three Zoeticx applications –CareCompliance, CareIntelligence, and CareSynergy. Building their own apps against the API has allowed Zoeticx to thoroughly vet it for performance, scalability, and completeness.
The primary goal for this release of the API is to support patient clinical data. There is currently no support for billing, scheduling, or payment, because those subsystems vary greatly from one healthcare provider to another. Thanh Tran, CEO and Founder of Zoeticx, told InfoQ that it is unlikely that support for those subsystems will be added in the forseeable future.
One big challenge for this API has been responsiveness. The middleware layer lives in the cloud, but EMRs typically live on-site at a healthcare facility. That extra layer of indirection could cause slowdowns in data delivery. A small delay is acceptable given the relative infrequency of data readings — every 15 minutes in an ICU, less often elsewhere. To help combat this issue, Zoeticx is working with NewRelic analytics to continuously monitor performance and alert them immediately if an issue occurs.
While Zoeticx’s API is a big step forward for developers in the fractured EMR space, it does present some challenges. A major stumbling block for potential users is the lackluster documentation. Right now, the only available documentation is embedded in Javadoc. To find an endpoint, you first have to figure out which Java class in their implementation contains that endpoint, which is not always intuitive. The documentation also doesn’t indicate what response codes can be expected from an endpoint, or provide any description for query parameters or message bodies beyond the attribute names.
Different portions of the API float between level 0 and level 2 on the Richardson Maturity Modelscale. For instance, you need to POST to /api/gizmo/delete in order to delete a gizmo, which is distinctly an RPC style. Even when verbs are used properly, the endpoints don’t trust them: mostDELETEs hit /resource/delete, most POSTs hit /resource/add, etc. The API also uses an unusual endpoint format. When a specific EMR is part of an endpoint URL, the identifier occurs at the beginning of the URL rather than the end. To delete a gizmo from a specific EMR, you POST to/{emrId}/api/gizmo/delete.
Despite these challenges, the Patient-Clarity API provides a useful tool for working with multiple different formats of EMR. The complexity of interacting with any one EMR format is significant. Having to work with multiple formats at the same time can be onerous. Even factoring in a significant spin-up time to learn the API, Zoeticx’s middleware should save significant time for medical application developers.
