Internal teams and vendors. We reply within two business days with a draft policy: which callers, which models, which data, under which agreements.
A person replies.
Your applications, teams, and vendors become registry entries. Teams get sandbox keys.
Which callers, which routes, which models, what gets replaced, what each budget is. You review it like any other change.
The container goes into your cloud account. The first team requests a real route; one vendor changes its URL.
From real traffic. Then monthly, and on every policy change.
Timeline illustrative. We're working with a small number of health systems through 2027.
The provider key moves into the gateway. The team gets a Miso key that reaches every provider the system holds an agreement with, on the routes the team is approved for, under a budget. Each call records the agreement that covered it.
Your program reviews each vendor and reaches a decision. Miso turns the model-and-data part of that decision into a registry entry and a route, then checks each request against it. The record shows each request matched the decision.
Probably true for the vendor's own traffic, and the registry holds that agreement as the vendor's entry. The model provider behind the feature also needs to be on your provider registry, with its scope, retention, and region. The console shows whether it is.
Your GRC platform holds the policy documents and the evidence people upload. Miso holds the routes that run on traffic and the record of the traffic. The monthly pack and the obligations ledger export into whatever you use.
It shows spend by team, route, and vendor from your own records, and a route can select the cheapest approved model. What you negotiate with providers is between you and them.
No. A route's candidate models are drawn from the provider registry, and a provider without a BAA on file is outside every route. Selection by cost, latency, or a score you set happens inside that set.
Yes, to a model provider, when a route allows it and the provider has a BAA on file. Miso itself runs in your account and decides which approved endpoints may receive which data. Identifiers the route says to replace are replaced before the request goes out.
Yes. Each request passes through it on the way to a provider. It runs as one container in your account; run two behind your load balancer. If the gateway is unreachable, the caller gets an error and nothing is sent.
It stores hashes, identifier types and counts, and the fields in the record. Prompt text is off by default, and the compose file says so.
Each model is pinned to a version the provider documents as fixed. When a new one is published, the console shows a comparison, old and new on your own samples, both in the record. The privacy officer approves, and the pin moves with a dated, hashed policy change.
As obligations on a route: disclosure, human review, subject identification. Miso returns them to the caller on every response and records the acknowledgment. The ledger shows which obligation on which route satisfies which state overlay, and where there is a gap. Whether a law applies to a route is a determination your counsel makes.
Your infrastructure team operates the deployment in your account. Miso maintains the software, ships releases, and supports the deployment; you apply releases on your schedule. Policy changes go through validation and are dated and hashed, including the ones that come from approved route requests.
A sandbox key the first day. A route request with purpose, data class, candidates, and a sentence about the data goes to the privacy officer with the validator's findings attached. Approval puts it live.
The base URL, a bearer credential, and a header naming the route. On routes that touch other patients' records, a header naming the patient.
Miso can run in a Miso-operated account under a BAA with you. Same policy file, same record. Move it into your own account later; callers keep the same endpoint.