Oystehr Platform Guide

What is the Oystehr platform?

The Oystehr platform is a headless cloud service for health tech developers. It provides FHIR R4B and R5 APIs as the data store, identity and access management, custom server code called Zambdas, and clinical services such as telehealth video, messaging, e-prescribing, labs and claims. Teams build their own user interface on top.

Headless means the platform ships no clinician or patient screens of its own. Oystehr points to sample apps and to Ottehr, which it describes as an open source EHR built on the platform, as starting points for the front end.

Oystehr says it charges published fees for compute, storage and bandwidth, in the style of a cloud provider, rather than a per-seat licence. Check the current pricing page before modelling costs, because usage pricing depends on traffic and storage patterns.

Which services does Oystehr document?

Oystehr's documentation lists thirteen services, from data and identity to clinical integrations. Each one replaces a component a team would otherwise build or contract separately.

• FHIR: The data store, with search, batch and transaction, asynchronous interactions, resource history, provenance and bulk data export.
• IAM and App: Developers, users, machine-to-machine clients, roles and applications, with authentication options the site lists as MFA, passwordless SMS, SAML and OAuth2.
• Zambda: Custom code deployed to the platform. The documentation lists authenticated, public, scheduled and subscription Zambda types, plus secrets and execution roles.
• Z3: File storage with access policies, for documents and images that sit beside FHIR resources.
• Telemed: Video visits, with audio recording documented as a feature.
• Messaging: Conversations and transactional SMS.
• eRx: Medication and pharmacy search, prescriber enrollment, prescription creation, drug interaction and allergy checks, and medication history.
• Lab: A test compendium, lab onboarding, order submission and results.
• RCM: Eligibility, claim preparation, claim submission and claim responses, with a payer list.
• Fax, Terminology and Project: Fax numbers and sending, CPT, HCPCS and ICD-10 search, and project-level configuration.

How does an app built on Oystehr fit together?

An app built on Oystehr is a client front end that calls the platform's APIs, with business logic in Zambdas and clinical data stored as FHIR resources. The team owns the screens and the workflow; the platform runs the infrastructure.

• Front end: A web or mobile app for patients, clinicians or both, written by the team or started from a sample app or Ottehr.
• Identity: Users sign in through the platform's IAM, and roles and access policies decide what each user and machine client can read or write.
• Data: Patients, encounters, appointments, observations and medications live as FHIR resources, so the data model follows HL7 FHIR rather than a private schema.
• Logic: Zambdas hold the workflow code, such as intake rules, scheduled reminders or reactions to FHIR changes through subscription triggers.
• Clinical services: Video, messaging, eRx, labs and claims are called as platform services rather than separate vendor contracts.
• Outside systems: Hospital EHRs, payers the RCM service does not reach and analytics stores still need their own interfaces, built as Zambdas or as a separate integration service.

The FHIR documentation shows example requests to a base path that ends in r4, while the homepage refers to R4B and R5 APIs. Confirm which version and which profiles each endpoint uses before writing mappings.

Work on the platform is organized into projects, and Zambda names are unique within a project. Keeping separate projects for development, test and production, with the same Zambda names in each, lets one front end target any environment while test data and secrets stay apart.

What does Oystehr's ONC certification cover?

Oystehr's documentation lists an ONC certification for its own product, Oystehr version 1, developed by MassLight and certified on 17 June 2024. The certification covers a specific set of criteria, not every feature of the platform.

• Criteria listed: 45 CFR 170.315 (b)(10), (g)(4), (g)(5), (g)(10), (d)(1), (d)(3), (d)(9), (d)(10), (d)(12) and (d)(13), covering EHI export, quality management, accessibility-centered design, the standardized API, authentication and access control, auditing, trusted connections, credential encryption and multi-factor authentication.
• Standardized API: Under ASTP/ONC rules, (g)(10) is a read API for patient and population services using US Core, SMART App Launch and Bulk Data. It is not a write API.
• Relied-upon software: The certification listing names Auth0 as relied-upon software.
• Data profile: The documentation says the FHIR API can persist US Core 6.1.0 resources and that TLS 1.2 or higher is enforced at the CDN level.

Certification attaches to a listed product and its criteria. Whether a product built on the platform can rely on that certification for a CMS program or a customer contract is a question to put to Oystehr and to the buyer's compliance team in writing.

When does a headless platform fit?

A headless platform fits when the product's value is in its workflow and user experience, not in running infrastructure. This decision list compares building on a platform such as Oystehr with building on your own cloud stack.

• Speed to first patient: A platform with FHIR storage, identity, video and eRx in place shortens the path to a first release. Your own stack means building or contracting each piece.
• Workflow control: Both options let you design your own screens. A platform limits you to the services and extension points it exposes.
• Data ownership and exit: FHIR data and bulk export ease a later move. Zambda code and platform-specific service calls would need rewriting.
• Compliance work: The platform covers its own safeguards and certified criteria. Your own policies, workforce training, risk analysis and app-level controls stay with you either way.
• Cost shape: Usage fees track traffic and storage. Your own stack trades those fees for cloud bills and the engineering time to run it.
• Integration reach: Platform services cover common needs. Hospital EHR interfaces, specialty devices and unusual payers still need custom work on either path.

The two paths can also be mixed. A team can keep clinical data and workflow on the platform and run heavy analytics or model training in its own cloud account, fed by bulk export, so each workload sits where it runs best.

How should a team plan a build on Oystehr?

Plan the build around one patient journey and test it on the platform before committing the roadmap. These six steps keep the platform decision reversible until it is proven.

• 1. Journey: Write one end-to-end journey, such as intake, video visit, prescription and claim, and list every service it touches.
• 2. Fit check: Map each step to an Oystehr service or a Zambda, and mark the steps that need an outside system.
• 3. Data model: Choose the FHIR resources and profiles for each step, and confirm the FHIR version and validation behaviour on the platform.
• 4. Contracts: Review the business associate agreement, the service terms and the pricing for the expected volume.
• 5. Prototype: Build the journey in a test project with synthetic data, including a bulk export, so exit is tested as well as entry.
• 6. Hardening: Add role design, audit review, monitoring, incident response and the app-level HIPAA controls the platform does not provide.

Under HHS guidance on HIPAA and cloud computing, a cloud service that stores ePHI for a covered entity or business associate is itself a business associate, even if it cannot view the data. Oystehr's site links to a business associate agreement; read it before any real patient data enters the platform.

Questions to put to the platform before signing

Ask these questions in writing before the contract, because the answers set the limits of the product. Each one maps to a risk that is costly to discover after launch.

• Versions and profiles: Which FHIR version and US Core profiles each endpoint validates against, and how upgrades are announced and scheduled.
• Hosting and recovery: Where data is hosted, how backups and restores work, and which recovery commitments appear in the contract rather than on a web page.
• Limits: Zambda quotas, API rate limits and file size limits at the expected peak, and what happens when a limit is reached during a clinic session.
• Service reach: Which pharmacies, labs and payers the eRx, Lab and RCM services can reach, and in which states.
• Audit access: How audit logs can be exported into your own monitoring, so your team can review access as the HIPAA Security Rule audit controls standard expects.
• Incidents: How incidents are reported to customers, and how the business associate agreement handles breach notice to you.
• Exit: What a full export includes, such as FHIR resources, Z3 files and user accounts, and in which formats.

How Agnotic can help

Choosing a platform is an architecture decision that shapes cost, exit options and compliance work for years. Agnotic Technologies builds telemedicine and EHR products for digital health companies and providers, and can build on a headless platform such as Oystehr or on the client's own cloud stack, depending on which fits the product.

Agnotic runs the fit check against one real patient journey, designs the FHIR data model, writes the front end and workflow code, builds the EHR and payer interfaces the platform does not cover, and tests export so the client can move later if needed.

Sources

• Oystehr: platform overview and pricing model
• Oystehr documentation: services index
• Oystehr documentation: ONC certification
• Oystehr documentation: writing Zambdas
• Oystehr documentation: FHIR basics
• 45 CFR 170.315: ONC certification criteria
• HHS: Guidance on HIPAA and cloud computing