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.
We offer single sign-on capabilities, allowing you to streamline access to your systems.
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.
Oystehr is built on top of FHIR, meaning medical resources are stored in FHIR. This comes with many benefits:
Check out our docs for more information.
* SMART on FHIR Coming Q1 2024
Get FHIR, USCDI, ONC, X12 and HIPAA from the start. Health-tech software is highly regulated. Multiple organizations govern complicated, overlapping standards. Legislative and statutory mandates change regularly. Payers, states, and exchanges have their own requirements. Oystehr does the heavy lifting to ensure your application maintains compliance in a shifting landscape.
Read MoreOystehr 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.
Read MoreOystehr offers a comprehensive read/write FHIR API and hosted storage for both R4 and R5. It’s almost table-stakes, but because so few EHR vendors actually offer full, unrestricted FHIR access, it’s important. FHIR is the native data model of Oystehr, not a bolt-on afterthought. We support multiple versions of FHIR and an upgrade path as new versions are released. However, we view Oystehr as “more than just a FHIR store.” Offering direct FHIR access is critical for interoperability and implementing many workflows, but the real power of Oystehr’s FHIR API is that it is directly integrated with all our other service offerings. So, if you want to do an insurance validation, claims submission, order a diagnostic test, initiate a video telemed call, or support SMS or text chat, you can do so directly from Oystehr APIs and appropriate FHIR records are created.
Read MoreOur 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.
Chief Medical Information Officer at PM Pediatric Care