HEALTHCARE, CONNECTED
Connect your EHR.
Put theo to work.
Your team connects the system. A custom skill tells theo what to prepare. MCIR memory brings relevant history. Your people keep the decisions.
Selected referral documents
theo.01 / FOLLOW THE CONNECTION
From EHR to handoff.
Four simple steps.
Start with referral prep. The same pattern works with the systems your team uses.
“Prepare this referral for review.”
ILLUSTRATEDStart with the system you use.
Your developers connect the electronic health record (EHR) API and implement an authenticated, read-only tool for the permitted referral documents.
Read-only exampleread_referral_documentsSelected referral documentsLess copying between systems. A clearer starting point for staff.
Providers. Step 1: Start with the system you use. Your developers connect the electronic health record (EHR) API and implement an authenticated, read-only tool for the permitted referral documents.
Fictional walkthrough. No live connection, model call, or submission.
Read the full blueprints Connections, sources, and model roles
Authored example, not generated output. All content is synthetic. EXAMPLE RECEIPT / ASSEMBLED IN YOUR APPLICATION, NOT LIVE TELEMETRY. Policy result: Not evaluated in this illustration. Release state: draft, awaiting human review.
Referral prep
Prepare this referral for review.
- Start with the system you use. (Your developers)
Your developers connect the electronic health record (EHR) API and implement an authenticated, read-only tool for the permitted referral documents.
- Give the connection a job. (Your team)
Package the permitted tool, your reference material, and your instructions as a reusable skill. A skill does not create access by itself.
- Let theo do the preparation. (Your configured workflow)
theo uses the permitted tool, works with the returned context, and prepares a draft with the gaps left visible.
- Give your team a head start. (Your reviewer)
A prepared draft, its sources, and what still needs checking. Your team reviews and decides what happens next in your application.
Referral-prep skill: Use the team's implemented read_referral_documents tool only for authorized records. Declare permissions explicitly, compare the returned facts with the approved checklist, and cite sources. The handler enforces record access. Do not edit the EHR, send a referral, or make a clinical or coverage decision.
Connector ownership: Your team builds and authorizes the real handler. The illustrative tool name is not a shipped connector or an executable configuration. Verify system/API availability and stop when access is denied or a required source is unavailable.
Two steps, in sequence. Extract the supplied facts first. A separate reasoning call then compares them with the sample checklist. These engine choices are illustrative, not a guarantee of availability or permission to process patient data.
- theo Extract: Structure the administrative facts returned by the authorized EHR tool. Do not fill in absent information.
Signed order and intake form listed; receiving contact not provided. [E-01]
- theo Reason: Compare the structured facts with the supplied checklist, then prepare a source-linked cover note.
Verify the receiving contact. Document presence does not establish clinical suitability or approval. [E-01, E-02, E-03]
- [E-01] Illustrative EHR result
- This fictional read-only tool result lists a signed referral order and an intake form. No receiving contact is supplied. It contains no patient, diagnosis, or treatment information.
- [E-02] Your referral checklist
- The sample checklist asks for a signed order, an intake form, and a verified receiving contact. Document presence is not clinical validation.
- [E-03] Your skill instructions
- Use only the permitted tool result and checklist. Retain source labels, flag missing items, and leave clinical and coverage decisions to the responsible people.
Signed order and intake form are listed.[E-01]
Receiving contact still needs verification.[E-01] [E-02]
Human review: A referral coordinator verifies the source packet, recipient, and next administrative step in the application’s review queue.
No clinical or coverage decision. No EHR record is changed and no referral is sent or submitted.
Payer intake
Prepare this case for the reviewer.
- Start with the system you use. (Your developers)
Your developers connect the case platform API and implement an authenticated, read-only tool for the permitted submission documents.
- Give the connection a job. (Your team)
Package the permitted tool, your reference material, and your instructions as a reusable skill. A skill does not create access by itself.
- Let theo do the preparation. (Your configured workflow)
theo uses the permitted tool, works with the returned context, and prepares a draft with the gaps left visible.
- Give your team a head start. (Your reviewer)
A prepared draft, its sources, and what still needs checking. Your team reviews and decides what happens next in your application.
Case-prep skill: Use the team's implemented read_case_documents tool only for authorized submissions. Declare permissions explicitly. Prepare an inventory and source-linked brief; the handler enforces record access. Do not change the case, submit a determination, or decide medical necessity, approval, denial, or coverage.
Connector ownership: Your team builds and authorizes the real handler. The illustrative tool name is not a shipped connector or an executable configuration. Verify system/API availability and stop when access is denied or a required source is unavailable.
Two parallel passes, then synthesis. Both passes read the same approved packet independently. A third, separate call combines their findings after both finish. These engine choices are illustrative, not a guarantee of availability or permission to process patient data.
- theo Extract: Read the approved source packet and list the supplied and absent administrative documents.
Cover sheet present; signed request absent. This is an inventory, not a completeness certification. [C1]
- theo Reason: Independently compare the supplied packet with the sample intake checklist. Do not depend on the other pass or make a coverage judgment.
The sample checklist calls for a signed request that is not in the packet. The human reviewer must resolve the gap. [C1, C2]
- theo Flash: After both passes finish, combine their findings with source labels and unresolved items. Do not invent consensus if they disagree.
An administrative cover sheet is available. Obtain or verify the signed request before the reviewer proceeds. [C1, C2, C3]
- [C1] Illustrative case-tool result
- A fictional read-only tool result lists an administrative cover sheet. A signed request is not included. The packet contains no member or clinical information.
- [C2] Intake checklist
- This sample intake checklist asks for a cover sheet and a signed request before a reviewer assesses the case. It is not a payer policy or medical-necessity criterion.
- [C3] Review instructions
- List what was supplied and what is unresolved. Prepare a case brief only. Do not decide eligibility, medical necessity, approval, denial, or coverage.
Administrative cover sheet is present.[C1]
The sample checklist’s signed request is missing.[C1] [C2]
Human review: An authorized case reviewer verifies the materials and handles any determination through the organization’s own procedures.
No automated approval, denial, medical-necessity judgment, or coverage determination.
Member service
How does someone replace a member card?
- Start with the system you use. (Your developers)
Your developers connect the service platform API and implement an authenticated, read-only tool for approved guidance, not member accounts.
- Give the connection a job. (Your team)
Package the permitted tool, your reference material, and your instructions as a reusable skill. A skill does not create access by itself.
- Let theo do the preparation. (Your configured workflow)
theo uses the permitted tool, works with the returned context, and prepares a draft with the gaps left visible.
- Give your team a head start. (Your reviewer)
A prepared draft, its sources, and what still needs checking. Your team reviews and decides what happens next in your application.
Member-service skill: Use the team's implemented read_service_guide tool for approved guidance. Declare permissions explicitly; the handler enforces access. No account lookup, record write, or automatic reply is permitted. Create and authorize a real skill before using it.
Connector ownership: Your team builds and authorizes the real handler. The illustrative tool name is not a shipped connector or an executable configuration. Verify system/API availability and stop when access is denied or a required source is unavailable.
One drafting model, with a read tool. A configured read-only tool retrieves the approved guide; theo Flash drafts from that result. Tool use can involve additional agent-loop turns. The skill does not retrain the model or retrieve anyone’s account. These engine choices are illustrative, not a guarantee of availability or permission to process patient data.
- theo Flash: Use the attached service skill to explain the replacement-card process in plain language. Leave absent details unresolved.
Use the member portal’s card-request page to request a replacement. The sample guide does not specify timing. No account or benefit is checked. [M1, M2]
- [M1] Illustrative guide-tool result
- In this fictional plan, the read-only guide result says replacement cards can be requested through the member portal’s card-request page. No turnaround time or individual benefit is specified.
- [M2] Service instructions
- Explain only the provided process. Do not access a member account, confirm eligibility or coverage, promise a turnaround time, or send the reply automatically.
You can request a replacement card through the member portal.[M1]
The guide does not specify how long it takes.[M1] [M2]
Human review: A service representative checks that the guide is current and approves the wording and recipient before any reply is released.
No account lookup, eligibility confirmation, automatic reply, or live system connection.
02 / YOU DEFINE THE BOUNDARY
Connected.
Not unrestricted.
You choose the data. Your app enforces the limits.
Explore permissions and routing
What can it read?Application responsibility
Authenticate the user and supply only permitted, relevant context. Built-in MCIR memory recalls relevant history within the same owner scope, not across tenants. Keep patient and task boundaries explicit, review retention, and keep unrelated records out. A valid API key is not permission to read every document.
Where can it go?Arca protected-path architecture
The Arca report describes routing by effective data class, with no inference when there is no eligible target. Verify this boundary in the actual deployment. Ordinary routing preferences are not a PHI authorization policy.
explore the Arca boundaryWhat can it do?Application responsibility + configured permissions
Declare skill permissions explicitly and constrain each tool’s resources, recipients, and side effects. Skills without declared permissions can use legacy behavior. Enforce authorization in the application before any action.
read the permission contract (opens in a new tab)Who approves?Application responsibility
Your team owns the review queue in your application. The reviewer checks the source, draft, and recipient before release. These examples make no clinical or coverage decision and submit nothing automatically.
An eligible target. A path forward.
In the described Arca architecture, the effective data class determines which serving targets are eligible. An eligible route permits inference; it does not authorize every tool or guarantee the answer.
Eligible route illustrated. Model: May proceed. Tools: Separate scope checks.
A policy only works where it is bound.
Gateway Guardrails are opt-in per API key. Unbound keys and session callers bypass them. A logged flag is not a block, and limited PII detection is not comprehensive PHI protection.
03 / PLAN THE DEPLOYMENT
Before real records.
HIPAA is a deployment commitment. Not a model setting. Review these three pieces before introducing protected health information (PHI).
- Agreements
- Data boundaries
- Operating safeguards
Deployment details and sources
Agree on the real deployment.
Review applicable business associate agreements (BAAs), downstream processing arrangements, retention, deletion, and logging. Identify permitted data, authorized users, and model/tool recipients. Complete risk assessment and control testing; assign human review, incident response, and monitoring.
Build and authorize the actual connection.
Your team implements the EHR or system connector using an available, approved API. A tool definition does not create a backend handler, grant record access, or establish interoperability. Confirm the integration and PHI-eligible processing chain before use. Declare skill permissions explicitly; skills without declared permissions can use legacy behavior.
Check the result before displaying it.
Gateway output checks run after the full stream is collected. Raw tokens can reach a live-streaming client first. These illustrations show a final draft, not a live token stream. Use non-streaming responses or buffer until the final guarded content when pre-check output must not be shown.
Keep the protected path specific.
Arca’s report describes tokenization, an encrypted vault, data-class eligibility, scoped tools, and an evidence ledger. Availability of an Arca model does not establish that every general gateway request uses this full protected deployment.
Masking is not a HIPAA determination.
HHS describes Expert Determination and Safe Harbor methods for de-identification. Ordinary masking or tokenization alone does not establish either. Encryption alone also does not remove applicable BAA and risk-management obligations.
Evidence, not a compliance badge.
These examples are not a compliance guarantee, clinical validation, or a signed agreement. Confirm the approved processing chain and deployment-specific evidence with the responsible reviewers. No certifications or measured outcomes are asserted here.
Start with a bounded pilot.
Evaluate staff preparation time, corrections after review, and cost per reviewed case. Measures to evaluate, not reported results.
Start with your EHR.
One connection. One read-only skill. One workflow your team can review.