Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the PatientView, 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%2Fpatientview.org%2Fpatientview" | shStep 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%2Fpatientview.org%2Fpatientview" | sh
jentic register # connects your agent to your Jentic One instanceJentic 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.
What an agent can do with PatientView API.
Log in to obtain a session token and log out to end it
Read a patient's basic details
List the observation types available for a user
Read a user's observations, including patient-entered readings
Read patient management diagnoses and lookup types
GET STARTED
Save patient management records and surgeries for a user
Patterns agents use PatientView API for, with concrete tasks.
★ Agent-Driven Health Record Lookups
An AI agent connected through Jentic logs in, reads a user's basic details and observations, and summarises them so a clinician can ask for a patient's recent readings in plain language. The agent reads the available observation types first, then fetches the observations for the type requested.
Read this user's latest blood pressure observations and summarise the trend
Observation History Retrieval
An application reads a user's observations of a given type over time, including the readings the patient entered themselves, so it can chart a measurement's history. It uses the available observation headings to know which types exist for the user before requesting them.
List the observation types for this user and return the full history for their weight readings
Patient Management Records
A workflow reads and saves patient management data such as diagnoses and surgeries for a user within a group, so a care record stays current. It reads the lookup types first to use valid codes, then saves the record.
Read the diagnosis lookup types, then save a new diagnosis record for this user in their group
15 endpoints — the patientview api reads patient health records for the patientview renal patient portal, so an application can retrieve a patient's basic details and their clinical observations.
METHOD
PATH
DESCRIPTION
/auth/login
Log in
/patient/{userId}/basic
Get basic patient information
/user/{userId}/observations
Get observations for a user
/user/{userId}/observations/{code}
Get observations of a certain type
/user/{userId}/availableobservationheadings
Get available observation types for a user
/patientmanagement/diagnoses
Get patient management diagnoses
/auth/login
Log in
/patient/{userId}/basic
Get basic patient information
/user/{userId}/observations
Get observations for a user
/user/{userId}/observations/{code}
Get observations of a certain type
/user/{userId}/availableobservationheadings
Get available observation types for a user
/patientmanagement/diagnoses
Get patient management diagnoses
What agents get from Jentic-routed access to this vendor.
Setup
Wiring the PatientView API by hand means calling its login operation to get a session token, passing that token on later calls, and mapping observations by their type codes. Through Jentic you install once, import PatientView from the API Directory, and your agent calls it.
Permission scoping
PatientView puts the user id in the URL path, so a rule can limit your agent to reading one user's records. You choose which operations it may call, so you can allow reading observations while leaving the save operations out, and every call it makes is logged.
Credential isolation
PatientView authenticates through a login operation rather than a stored API key, so your agent obtains a short-lived session token at login and passes it on later calls. There is no long-lived key for Jentic to hold, and the login exchange stays inside your own instance.
Intent-based discovery
Agents search Jentic by intent such as 'read a user's observations' or 'get a patient's basic details', and Jentic returns the matching PatientView operation with its input schema so the agent calls the right endpoint without reading the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using PatientView API through Jentic.
Is there a PatientView MCP server?
You don't need an MCP server to give your agent the PatientView API. Jentic connects it directly from the API Directory: import it and your agent can log in and read a user's records and observations straight away, with no extra server to run and no tool definitions to load into the agent's context.
Can I limit what my agent is allowed to do with the PatientView API?
Yes. Because PatientView puts the user id in the URL path, you can write a rule that limits your agent to reading one user's records. You also choose which operations it may call, so you can allow the read operations while leaving the save operations out, and every call it makes is logged.
What authentication does the PatientView API use?
The PatientView API declares no security scheme in its OpenAPI spec. Instead it exposes a login operation that returns a session token, and later calls include that token to identify the user. There is no long-lived API key to hold.
Can I read patient-entered observations with the PatientView API?
Yes. The API reads a user's observations by type, including the readings the patient entered themselves, and it lists the observation types available for that user. So an agent can retrieve both clinical and patient-entered values for a measurement.
What are the rate limits for the PatientView API?
The OpenAPI spec does not specify rate limits for the PatientView API. For current guidance, see the PatientView documentation at https://www.patientview.org.
How do I read PatientView records through Jentic?
Import the PatientView API from the Jentic API Directory, then have your agent issue a request such as 'read this user's recent observations'. Jentic matches the intent to the right operation and returns its input schema so the agent builds the correct request. To run it on your own infrastructure, install Jentic One from its GitHub repo.
Know of an official OpenAPI document? Contribute it →
For Agents
Read a PatientView user's basic details, available observation types, and observations, and read or save patient management diagnoses and surgeries. Authenticates through a login operation that returns a session token; the spec declares no separate security scheme.
Use for: Log in and read a patient's basic details, List the observation types available for a user, Get a user's observations for a given type, Read the patient-entered observations for a user
Not supported: Does not handle appointment booking, messaging, or account registration. Use for reading PatientView user details, observations, and patient management records only.
The PatientView API reads patient health records for the PatientView renal patient portal, so an application can retrieve a patient's basic details and their clinical observations. You log in to obtain a session token, then read a user's basic information, the observation types available for them, and their observations, including patient-entered readings. Patient management endpoints read and save diagnoses, lookup types, and surgeries for a user within a group. The API is organised around a user id that identifies whose records are being read.
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
Base layer of spec validity and structural soundness.
Aggregated quality score from linter diagnostics, weighted by severity.
Percentage of `$ref` references that resolve successfully.
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
Structural correctness score based on schema issues using logarithmic dampening.
Clarity, completeness, and ingestion readiness for developers and tooling.
How richly the API is illustrated with examples.
Percentage of examples that conform to their schemas.
Percentage of operations with complete response definitions (success, client error, server error).
Health of API ingestion, bundling, and resolution within Jentic pipelines.
Semantic breadth, depth, and agent comprehension for AI systems.
Coverage of descriptions across API elements.
Coverage of RFC 9457 Problem Details for error responses.
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
Coverage of summaries across operations/tags/info.
Functional utility, complexity comfort, and AI orchestration readiness.
Agent comfort level based on API operational and structural complexity.
Trust, risk posture, and security compliance.
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
Findability, semantic richness, and reasoning readiness.
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>