Install Jentic One Beta

Connect the Medplum - OpenAPI 3.0 to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Medplum - OpenAPI 3.0, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fmedplum.com%2Fmedplum" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fmedplum.com%2Fmedplum" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

Capabilities

What an agent can do with Medplum - OpenAPI 3.0 API.

Search any FHIR resource type, such as Patient or Observation, with FHIR search criteria in the query

Create a resource, or create it conditionally with If-None-Exist so a matching record is not duplicated

Upsert a resource by search criteria with a conditional update, or update and patch a known id with If-Match concurrency checks

Validate a resource against FHIR rules with $validate before saving it

GET STARTED

Start building with Medplum - OpenAPI 3.0 API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Medplum - OpenAPI 3.0 API for, with concrete tasks.

★ Agent-maintained clinical records through Jentic

A healthcare agent can keep records current in a Medplum project through Jentic. It searches for the patient by identifier, validates a new Observation with $validate, and saves it, using If-Match on updates so it never overwrites a newer edit. Because the resource type is part of the path, the agent's access can be held to the resource types it actually needs.

Search Patient with criteria identifier=MRN-1001, validate an Observation for a blood pressure of 120/80 for that patient, then create it and return the new resource id

Idempotent data import into FHIR

Importing data from another system risks duplicates on retry. Medplum supports conditional create with If-None-Exist, conditional update by search criteria, and transaction Bundles that either apply every entry or none, so an import can be rerun without creating duplicate Patients or orphaned Encounters.

Post a transaction Bundle to /fhir/R4 that conditionally creates a Patient with identifier MRN-2002 and creates an Encounter referencing it

Audit and recovery from version history

Every FHIR resource on Medplum keeps its version history. Reading _history shows who changed what and when, and reading a specific versionId recovers an earlier state of a record, which supports clinical audit and rollback of a mistaken edit.

Read the _history of Patient 123, fetch the version before the latest, and report which fields differ between the two versions

Key Endpoints

11 endpoints — the medplum api exposes a standards-based hl7 fhir r4 server for storing and querying healthcare data, where any fhir resource type, such as patient, observation, or encounter, is addressed by name in the url path.

METHOD

PATH

DESCRIPTION

GET

/fhir/R4/{resourceType}

Search resources

POST

/fhir/R4/{resourceType}

Create a resource

GET

/fhir/R4/{resourceType}/{id}

Read a resource

PATCH

/fhir/R4/{resourceType}/{id}

Patch a resource

POST

/fhir/R4/{resourceType}/$validate

Validate a resource

POST

/fhir/R4

Batch or transaction Bundle

GET

/fhir/R4/{resourceType}/{id}/_history

Read resource history

GET

/fhir/R4/{resourceType}

Search resources

POST

/fhir/R4/{resourceType}

Create a resource

GET

/fhir/R4/{resourceType}/{id}

Read a resource

PATCH

/fhir/R4/{resourceType}/{id}

Patch a resource

POST

/fhir/R4/{resourceType}/$validate

Validate a resource

POST

/fhir/R4

Batch or transaction Bundle

GET

/fhir/R4/{resourceType}/{id}/_history

Read resource history

Why Jentic?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring Medplum by hand means picking among Basic, bearer JWT, OpenID Connect, and SMART OAuth flows, refreshing tokens, and handling If-Match and If-None-Exist headers yourself. Through Jentic you install once, import Medplum from the API Directory, store the credential once, and your agent calls it.

Permission scoping

Medplum puts the FHIR resource type and id in the URL path (/fhir/R4/{resourceType}/{id}), so a rule can limit your agent to specific resource types, such as Appointment, and the operations you pick. You choose the operations it may call, so destructive ones like deleting resources or posting transaction Bundles are not included unless you add them.

Credential isolation

Your Medplum credential is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'create a FHIR patient' or 'search observations', and Jentic returns the matching Medplum operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

FAQs

Specific to using Medplum - OpenAPI 3.0 API through Jentic.

What authentication does the Medplum API use?

Per its OpenAPI spec, Medplum accepts HTTP Basic, a JWT bearer token, OpenID Connect, or OAuth 2.0 with authorization code and client credentials flows following SMART App Launch, with scopes such as patient/*.rs and user/*.cruds. Any one of these schemes authenticates a request. Through Jentic the credential is stored encrypted on your own instance and injected at call time.

Is there a Medplum MCP server?

You don't need an MCP server to give your agent Medplum. Jentic connects it directly from the API Directory: import it, store your credential once, and your agent calls it. Operations are discovered on demand, so another server's tool definitions never crowd your agent's context.

Can I limit what my agent is allowed to do with the Medplum API?

Yes. For a scheduling assistant, write a rule that allows only GET and POST on /fhir/R4/Appointment and GET on /fhir/R4/Slot, so it can find slots and book visits but cannot read Observations or delete any resource. Every call it makes is logged.

What are the rate limits for the Medplum API?

The OpenAPI spec does not specify rate limits; check https://www.medplum.com/docs for current limits on the hosted service.

How do I avoid creating duplicate patients in Medplum?

Use a conditional create: POST /fhir/R4/Patient with an If-None-Exist header holding search criteria such as an identifier, and Medplum only creates the resource if nothing matches. Alternatively, PUT /fhir/R4/{resourceType} with criteria performs an upsert that updates the match or creates a new record.

How do I create a FHIR resource in Medplum through Jentic?

Search Jentic for an intent like 'create a FHIR patient', import the Medplum API, and store your client credentials once. Your agent then calls POST /fhir/R4/{resourceType} with the resource body, optionally validating it first with the $validate operation. To run it on your own infrastructure, install Jentic One from its GitHub repo.

Medplum - OpenAPI 3.0

AI ReadinessAI-Aware (B-)62/100

See full scorecard

Official vendor OpenAPI document · agent-readyHealthcareEhr Emrbasic, bearer, openIdConnect, oauth211 EndpointsREST

For Agents

Search, create, read, update, patch, validate, and delete any FHIR R4 resource on Medplum, run batch or transaction Bundles, and read a resource's version history.

Use for: Search for patients named Smith born in 1980, Create a new Observation for a blood pressure reading, Check whether this Patient resource is valid FHIR before saving, Retrieve the version history of a patient record

Not supported: Does not handle claims billing, e-prescribing to pharmacies, or video visits. Use for storing and querying FHIR R4 healthcare resources only.

The Medplum API exposes a standards-based HL7 FHIR R4 server for storing and querying healthcare data, where any FHIR resource type, such as Patient, Observation, or Encounter, is addressed by name in the URL path. It supports search, create, read, full and conditional update, JSON Patch, delete, and validation without saving, plus version history and reads of a specific past version. Batch and transaction Bundles post many operations in one request, conditional create with If-None-Exist avoids duplicates, and If-Match headers guard concurrent edits.

Jentic One on Github View OpenAPI Document

Show dimension breakdown

Foundational Compliance

Base layer of spec validity and structural soundness.

Grade: CSignals: 4

38%

Lint Results

Aggregated quality score from linter diagnostics, weighted by severity.

100%

Resolution Completeness

Percentage of `$ref` references that resolve successfully.

Specification Validity

Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).

75%

Structural Integrity

Structural correctness score based on schema issues using logarithmic dampening.

Developer Experience & Jentic Compatibility

Clarity, completeness, and ingestion readiness for developers and tooling.

Grade: C+Signals: 4

Example Density

How richly the API is illustrated with examples.

100%

Example Validity

Percentage of examples that conform to their schemas.

39%

Response Coverage

Percentage of operations with complete response definitions (success, client error, server error).

100%

Tooling Readiness

Health of API ingestion, bundling, and resolution within Jentic pipelines.

AI-Readiness & Agent Experience

Semantic breadth, depth, and agent comprehension for AI systems.

Grade: B-Signals: 4

98%

Description Coverage

Coverage of descriptions across API elements.

Error Standardization

Coverage of RFC 9457 Problem Details for error responses.

82%

OperationId Quality

Coverage, uniqueness, and casing consistency of operationIds for AI inference.

61%

Summary Coverage

Coverage of summaries across operations/tags/info.

Agent Usability

Functional utility, complexity comfort, and AI orchestration readiness.

Grade: A+Signals: 1

94%

Complexity Comfort

Agent comfort level based on API operational and structural complexity.

Security

Trust, risk posture, and security compliance.

Grade: B+Signals: 1

68%

Authentication Strength

Average quality of security schemes based on authentication method strength (weakest link for OAuth2).

AI Discoverability

Findability, semantic richness, and reasoning readiness.

Grade: DSignals: 1

44%

Descriptive Richness

Clarity and depth of descriptions across API elements.

Connect the Medplum - OpenAPI 3.0 to your agent

Capabilities

Start building with Medplum - OpenAPI 3.0 API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs

Medplum - OpenAPI 3.0

Jentic AI Readiness Score

Medplum - OpenAPI 3.0

Foundational Compliance

Lint Results

Resolution Completeness

Specification Validity

Structural Integrity

Developer Experience & Jentic Compatibility

Example Density

Example Validity

Response Coverage

Tooling Readiness

AI-Readiness & Agent Experience

Description Coverage

Error Standardization

OperationId Quality

Summary Coverage

Agent Usability

Complexity Comfort

Security

Authentication Strength

AI Discoverability

Descriptive Richness