Zoeticxは，現存する任意のプロバイダからのデータを，単一の共通フォーマットに統合可能なミドルウェアを開発した。新たにリリースしたAPIを使えば，このミドルウェアに簡単にアクセスすることができる。これによって，複数のデータベースに異なるフォーマットで格納されたレコードを扱うアプリケーションの開発が容易になる。
医療情報の電子的な格納には現在，350以上の競合するフォーマットが存在している。
ZoeticxのこのミドルウェアはPatient-Clarityプラットフォームという名称で，クラウド上に配置されている。ゲートウェイ経由でそれぞれのEMR(Electronic Medical Record)フォーマットにアクセスし，Zoeticxが提供する独自の共通フォーマットに変換する仕組みだ。現時点ではEpic, Cerner, Allscripts, Sunrise, Allscripts Professional, OpenVistAという，もっとも一般的な５つのフォーマットがサポートされている。ゲートウェイは共有スペースを対象に設計されているので，さらにフォーマットを追加することも簡単だ。
APIの公開リリースは今回が初めてだが，すでにZoericxの３つのアプリケーション – CareCompliance, CareIntelligence, CareSynergy – で使用されている。同社自身のアプリに使用することで，APIのパフォーマンスやスケーラビリティ，完全性を徹底的に検査することが可能になった。
今回リリースされたAPIでは， 患者の臨床データのサポートをおもな目的にしている。請求，スケジュール，支払いについては，サブシステムが医療サービスプロバイダ毎に大きく異なるため，現時点ではサポートされていない。Zoeticxの創業者でCEOのThanh Tran氏はInfoQに対して，現時点での計画の範囲内では，それらサブシステムのサービスを追加する予定はないと述べている。
APIの大きな問題のひとつが応答性だ。ミドルウェアレイヤはクラウド上にあるが，EMRは通常，医療施設でオンサイトに存在している。このような余分なレイヤの参照が，データ配信の遅延を引き起こす可能性があるのだ。ICUで15分間隔，他ではそれ以下というように，データ参照頻度が比較的低いので，遅延が小さければ許容される。この問題の対処を支援するためZoeticxでは，パフォーマンスを継続的に監視し，問題発生時には即座に警告を発するNewRelicアナリティクスを開発中だ。
ZoeticxのAPIは，分裂したEMR分野に従事する開発者にとっては大きな前進だが，同時にいくつかの課題も示している。潜在的ユーザにとって大きな障害となるのは， ドキュメントが不十分なことだ。現在のところ，利用可能なドキュメントは，Javadocに埋め込まれたものがあるのみだ。 エンドポイントを見つけ出すには，まず，どのJavaクラスがエンドポイントを実装しているかを見付け出さなければならない。これは必ずしも直感的なものではない。エンドポイントから受け取る可能性のある応答コードについても，資料には指示されていない。クエリパラメータやメッセージボディに関しても，属性名以上の説明はない。
APIは部分によって，Richardson Maturity Model(成熟度モデル)スケールのレベル０からレベル２の間で変動している。例えば，ひとつの機器を削除するには/api/gizmo/deleteにPOSTする必要がるが，これは明らかにRPCスタイルだ。動詞(verb)が適切に使用されている場合でも，エンドポイントはそれを信頼していない。大部分のDELETEが/resorce/deleteに対応する一方で，POSTのほとんどが/resource/addに対応する，という具合だ。APIの使用するエンドポイントフォーマットも一般的なものではない。エンドポイントURLに特定のEMRが含まれている場合，識別子はURLの最後ではなく先頭に指示される，といった具合だ。例えばあるEMRから機器を削除するには，/{emrId}/api/gizmo/deleteにPOSTする。
このような課題はあるにせよ，Patient-Clarity APIは複数の異なるEMRフォーマットを扱う上で，非常に便利なツールである。ひとつのEMRを処理するための複雑性が非常に大きい上に，同時に複数のフォーマットを使用する場合には面倒な点がある。 APIを学習するための相当なスピンアップ時間を加味しても，Zoeticxのミドルウェアは，医療関係アプリケーション開発者にとって相当な時間の節約をもたらしてくれるはずだ。