Integrating with TMP means implementing two things: a webhook endpoint that receives session requests, and calls to TMP Hub API to manage session state and post results back to the EHR.
The integration is built on two pillars: receiving structured session context from TMP, and returning results back through TMP to the EHR.
TMP calls your HTTPS endpoint when a healthcare professional starts a session. You receive structured patient context and respond with accept, redirect, or reject.
Your solution owns the session state. Use TMP Hub API to push status updates (Accepted, In-Progress, Completed) as the care episode progresses.
Post results at any point during or after a session. TMP routes them directly into the patient's EHR record. Supported types: PDF report, structured data, dashboard link.
All calls to TMP Hub API use an OAuth2 Bearer token obtained with your client credentials. One token request covers all Hub API operations.
Five steps from first contact to a live, billable integration in production.
Contact
support@transmuralplatform.eu
to receive your sandbox credentials: a client_id,
client_secret, and access to the TMP sandbox
environment. Sandbox sessions are never billed and allow you to
run the full lifecycle before any live patient is involved.
TMP Portal calls your configured HTTPS endpoint whenever a healthcare professional initiates a session with your solution. The POST body contains structured patient context: patient identifier, prescribing professional, organisation, requested care path, and any supplementary fields you have configured.
Based on the response your endpoint returns, TMP decides how to proceed with the session using one of the three options below.
Return HTTP 200 with an empty body. TMP
confirms the session and marks it as Accepted. No further
HCP interaction is needed.
Return HTTP 200 with
{"url": "https://..."}. TMP routes the HCP to
your flow where the missing information is collected before
the session continues.
Once you have collected everything you need, the session is
not accepted automatically. You must explicitly accept it
yourself with a PUT /prescription call that
sets status to accepted.
Return a non-200 status such as 401 or
404. Optionally include
{"message": "..."} to explain why the request
was not accepted.
The full request shape is documented in the provider request OpenAPI spec.
Your solution owns the session state throughout the care episode. Authenticate once using your client credentials to obtain a Bearer token, then use that token on all TMP Hub API calls.
| Action | Method & path | Notes |
|---|---|---|
| Obtain access token | POST /auth/providers |
Basic auth (base64 client_id:client_secret); returns a Bearer token |
| Update session status | PUT /prescription |
Body contains telemonitoringId,
status, and optional
attachments and carepath
|
All status updates and result postings use the same
PUT /prescription endpoint. Include the desired
status, any attachments, and an optional carepath in the body.
The telemonitoringId in the body identifies the
session; there is no path parameter.
Results are included as attachments on any
PUT /prescription
call. You can post interim results mid-session and a final
result when you set status to completed. TMP routes each result
directly into the patient's EHR record.
Human-readable session summary. TMP shares only the metadata and URI; the EHR downloads the PDF directly from your storage. Include MD5 and content-length to prevent corruption.
{
"telemonitoringId": "tm-8f3ac2",
"status": "completed",
"attachments": [
{
"id": "pdf",
"name": "Telemonitoring Report",
"contentMD5": "f2fd2ddd34eebc9d039f5e693b95a61c",
"contentLength": 184320,
"uri": "https://your-storage.example.com/reports/8f3ac2.pdf?token=0ba1b31c"
}
]
}Structured attachment for carepath data and observations. Required for care paths so EHRs can parse, visualise, and re-use the information beyond a static document.
{
"telemonitoringId": "tm-8f3ac2",
"status": "in-progress",
"carepath": "diabetes-followup",
"attachments": [
{
"id": "summary",
"name": "Patient Observation",
"contentType": "application/fhir+json",
"contentMD5": "9b3f1a7c2e6d4408b1c6a2f9d0e5b3aa",
"contentLength": 4096,
"uri": "https://your-storage.example.com/fhir/8f3ac2/observation-1"
}
]
}A provider-managed URI that the EHR can embed or open for a richer, live view of the patient data. Useful when static reports are insufficient.
{
"telemonitoringId": "tm-8f3ac2",
"status": "in-progress",
"attachments": [
{
"id": "dashboard",
"name": "Patient dashboard",
"contentType": "x-tm-dashboard",
"uri": "https://your-storage.example.com/dashboard/8f3ac2?token=9c21ffa0"
}
]
}Once the webhook and Hub API flows are validated in sandbox, TMP activates your provider based on a compact configuration set. After activation, your solution appears in TMP Marketplace across all connected hospitals.
| Configuration field | What TMP needs from you |
|---|---|
| Name & description | Application name and short description shown to HCPs in TMP Marketplace |
| Care paths | Supported HL7-defined care paths your solution covers |
| Context fields | Which patient and prescriber fields your webhook needs to receive |
| Webhook URI | Your HTTPS endpoint that TMP calls when a session is started |
| Fixed headers | Any static authorization or routing headers TMP should include on webhook calls |
| Action URI (optional) | Endpoint for TMP to send stop or cancel actions, if supported |
| Patient authentication (optional) | Whether TMP should generate a patient token and whether you support a deep-link |
Every session moves through a defined set of states. Your solution drives the transitions; TMP makes the current state visible to the healthcare professional in real time.
Initiated by the HCP from TMP Portal. TMP can forward the action to your action URI if configured.
Initiated by the HCP from TMP Portal. Same action forwarding as cancel, if you support it.
Beyond the core request and results flow, TMP supports deeper integration patterns for providers that need them.
TMP can generate a unique patient token linked to a session. Your solution verifies that token with TMP via the patient authentication API, avoiding SSIN-based login while staying GDPR-compliant.
Configure a deep-link template that includes the
telemonitoringId and patient auth token. TMP Portal
can display it as a QR code so the patient continues directly into
your app or onboarding flow.
Expose an endpoint that TMP calls to retrieve an authenticated dashboard URL for the HCP. TMP opens that URL in context so the clinician gets a live, provider-managed view without leaving the EHR workflow. See the dashboard URL spec.
When an HCP cancels or stops a session, TMP can forward that action to a configured action URI on your side. You apply your business rules and push the resulting new state back via TMP Hub API.
Request sandbox credentials and we will guide you through the webhook and Hub API setup.