An implementation is a conversation, not a project

A laboratory going live on a new platform spends about six weeks on work that is almost entirely mapping: local codes to LOINC, locations to tenants, an agreement to release rules, sample messages to parsed observations. None of it is intellectually hard and all of it is slow, because it is a conversation held over email between someone who knows the laboratory and someone who knows the platform. This is a design for holding that conversation in one place, with an agent doing the transcription.

What the agent does not remove

This configures a deployment. It does not create a laboratory, and it does not move any of the obligations that make a laboratory a laboratory. Metaclinic does not perform tests, does not interpret results, does not modify a reference interval, and is not the laboratory of record for any test. The performing laboratory owns the result.

Two planes, and patient data stays on the old one

Configuration plane — what MCP touches

Local code sets and their mappings, unit conversions, organization and sub-organization structure, interface parameters, volume baselines, release scoping, grants, and test fixtures. Metadata about how a laboratory works. No patient data, in either direction, ever.

Data plane — unchanged

HL7 v2.5.1 ORU^R01 over TLS or SFTP, FHIR R4 read, bulk export, and webhooks. Results move exactly as they do today. No result is ever an argument to a tool or a token in a model's context window.

What the laboratory owner actually does

The four gates from the connections page do not change. What changes is who does the typing, and how quickly a mistake becomes visible.

1. Scope. The agent creates the organization, its locations and divisions, and the state of service, from the signed agreement. It cannot create one without a reference to that agreement on file, because scope is read from a document rather than from a conversation.
2. Compendium. The laboratory hands over its local code list, however incomplete, and the agent proposes a LOINC code, a UCUM unit, and a reference-interval source for each line with its evidence attached. Anything ambiguous is left unmapped in the review queue rather than resolved by a confident guess.
3. Interface. Transport, message types, acknowledgement expectations, and a volume baseline per message type and per source. The agent validates the configuration against de-identified sample messages and shows the observations each one produces, so the first surprise happens before go-live instead of during it.
4. Release. The default matrix is narrowed to match the agreement. Where the agreement is quieter than the default, the agreement wins and the platform is configured down, which is the same rule that governs a human doing this work.

The rules the tools obey

An agent with write access to a release model is the most dangerous object in this system. The surface is therefore built so that the dangerous action is unavailable rather than discouraged.

• No tool widens a permission. Every write tool can narrow, scope down, or propose. None can move a cell toward release. Widening requires a named human with authority and the agreement on file, through the console, recorded separately.
• Tools propose and humans commit. A mapping, an interface, or a release change is written as a pending proposal carrying its evidence. The approval names a person, and the approval is the thing that takes effect.
• No patient data crosses the tool boundary. Fixtures are synthetic or de-identified, and the server refuses an argument that looks like a live identifier rather than accepting it and logging a warning.
• Every call is an audit event: identity, tenant, tool, arguments, decision, and approver, in the same record that carries a disclosure. "The agent did it" is not an accountable answer to a regulator or to a customer.
• Refusals name the condition. A tool that will not do something returns the data class and the requirement that would satisfy it, in the same shape the API uses. An opaque error to an agent produces a retry loop instead of a fix.

The tool surface

narrow_release_rule(
  tenant:       "riverbend-pathology",
  data_class:   "molecular",
  stakeholder:  "attorney",
  to_state:     "conditional"
)

-> 403
{
  "resourceType": "OperationOutcome",
  "issue": [{
    "severity": "error",
    "code": "forbidden",
    "details": { "text": "refused: widening-not-available-to-tools" },
    "diagnostics": "molecular to attorney is withheld. A tool can only narrow.
                    Widening requires an authorization naming the category and a
                    human approver with authority on the agreement."
  }]
}

What arrives with the configuration

The reason to configure rather than build is that the configuration lands on top of something that already exists. On the day the interface goes live, the laboratory has the platform described across the rest of this site, scoped to its own agreement:

• The nine data classes and the full release matrix, with an explicit answer for every stakeholder pair rather than a blank access model to fill in later.
• A worklist per referring practice, with outstanding orders, unacknowledged criticals, pending send-outs, and unmatched results as visible conditions.
• Patient access on the CLIA and right-of-access clock, as a normal operation rather than a manual pull by whoever answered the phone.
• The audit record, which answers an accounting of disclosures without a special project, and which the laboratory's own administrator can read.
• Coding from report structure, coverage evaluation at accession and sign-out, and a denial evidence trail linking the claim to the requisition and the interface message that carried the result.
• The release matrix as an interface, which is usually the first time anyone at the laboratory has seen its own sharing rules written down in one place.

Connecting to it, once it exists

1. One HTTPS endpoint per environment, with the sandbox entirely separate from production and seeded with synthetic patients.
2. Authentication is the same token model as the API: a tenant, a role, and any active grants. An agent token carries configuration scopes only and cannot be exchanged for a clinical read scope.
3. Approval happens in the console, by a person, against the pending proposals the agent produced. It does not happen in the transcript.

{
  "mcpServers": {
    "metaclinic": {
      "type": "http",
      "url":  "https://mcp.metaclinic.com/mcp"
    }
  }
}