Interoperability

Oystehr is an API-first solution. You can invoke Oystehr APIs entirely a la carte. There is no data silo, no obligation to use any particular front-end. You can use our open-source EHR or not. You can maintain your own database or not. You can build an application entirely on Oystehr’s hosted infrastructure or interact strictly with the APIs you need statelessly. You can create inbound Zambdas (serverless hosted functions) that accept invocations from external systems, and you can create outbound Zambas that listen for Oystehr events and push data to external systems. You will not experience the restrictions on external integrations that monolithic EHRs impose.

Mockup of a web page labeled "FHIR R4/R5"

Unsilo your health data for connected care, regulatory standards, and better outcomes.

Single Sign On

We offer single sign-on capabilities, allowing you to streamline access to your systems.

‍

FHIR

We prioritize interoperability by leveraging modern healthcare language standards such as FHIR R4, R5, and SMART on FHIR*.

FHIR is the growing standard for modeling and exchanging healthcare data electronically. Many EHRs, payer systems, and other healthcare products either already support or are adding support for sending and receiving data following the FHIR standard.

FHIR has resources like Patients, Practitioners, Schedules, and Encounters. These resources store health information.

The standard was created to give disparate healthcare systems with proprietary data models a common language for communicating healthcare data to improve interoperability. Existing players have to maintain their proprietary data models as well as a mapping to and from FHIR to facilitate interoperability. With Oystehr, you use FHIR as your data model from the start, removing the entire cost center of mapping into and out of FHIR.

‍

Benefits of using FHIR

Oystehr is built on top of FHIR, meaning medical resources are stored in FHIR. This comes with many benefits:

If you are trying to import data from another source that uses FHIR, the process is much easier than if it is in another format.
If you are trying to work with another service that uses FHIR, the data is already in FHIR format.
No vendor lock-in. If you ever needed to, you could extract all of your FHIR resources and take them elsewhere.
If you are already familiar with FHIR, you don't need to learn a new way of storing data

‍

Check out our docs for more information.

‍

* SMART on FHIR Coming Q1 2024

back to product page

Read more about other solutions

Developer Console

Direct API access is great, and always available, but sometimes it’s nice to manipulate services and data via a user interface. The Oystehr Developer Console allows you to provision new users, applications, and environments, create and assign access policies and roles, monitor logs, create FHIR resources, and deploy Zambda functions.

computer screen with digital prescriptions

E-Prescriptions (beta)

Oystehr provides both an API and embeddable UIs for eRx. Our eRx service is unique in that we handle prescription issues without requiring intervention from a clinician in most cases. If a medication is out of stock, the pharmacy is closed, or there is a long wait time, we automate the process of communicating with the patient to re-route the prescription. This is a huge time-saver for many clinical use-cases.

Diagnostics (beta)

A simple diagnostic ordering API that allows your application’s users to directly place orders for laboratory and radiology with Quest, Labcorp, and thousands of smaller independent facilities.

Learn why healthcare orgs trust Oystehr as their health tech dev platform

Meet with our engineers

Our new behavioral health intake application, built on Oystehr, allowed us to build a solution that is customized for our use including scheduling, insurance validation, and direct integration with our eClinicalWorks EHR.

Mordechai Raskas

Chief Medical Information Officer at PM Pediatric Care