A Transmural Data Provider delivers useful transmural data to a hospital, from PROMs and PREMs to measurements from connected medical devices. TMP gives providers one standard request flow and one results interface that works across connected EHRs.
TMP separates integration into two pillars. The first is request context: the patient, prescriber, and workflow data that a provider needs to start a remote monitoring session successfully.
The second is results: the data, attachments, and status updates generated by the provider that need to flow back to the hospital and its EHR.
TMP Portal standardises the request context. TMP Hub standardises the return path. That gives providers one way to receive requests and one way to publish results, regardless of the EHR in use.
Communication between TMP Portal and the provider happens through HTTPS calls. Each provider can choose one of the TMP supported security mechanisms and define the fixed headers TMP should send.
Providers can also define prescriber-specific configurable headers so hospitals can activate different instances of the same provider application with different settings.
TMP supports provider setups with one shared endpoint as well as setups where each prescriber has a unique provider endpoint or unique header values configured for their environment.
That keeps the integration standardised while still supporting the operational reality of different hospital deployments.
When an HCP clicks the prescribe button, TMP Portal sends a HTTPS POST request to the configured provider endpoint. The full request shape is documented in the provider request OpenAPI spec.
If the provider has enough information to start the session, it returns HTTP 200 with an empty body.
TMP then knows the request can move forward without any extra interaction from the HCP.
If more input is needed, the provider still returns HTTP 200 but
includes a body with a URL: { url: https://... }.
TMP can then route the HCP to the provider flow where the missing information is collected.
If the request cannot be confirmed, the provider should return a non-200 status code such as 401 or 404.
A body with a message like { message: '...' } can be
added to explain why the request was not accepted.
TMP can call one predefined provider endpoint, or use separate endpoints per prescriber when the provider is hosted inside the prescriber environment. Fixed headers and prescriber-specific headers can both be configured as part of activation.
All API calls towards TMP Hub require an Authorization header. Each provider receives a client and secret and requests an access token through the provider authentication endpoint.
PDF attachments provide a human-readable session overview. TMP Hub only shares metadata, not the file contents themselves, so the EHR downloads the PDF directly from the provider URI.
Adding MD5 and content length is strongly recommended to prevent data loss or corruption during download.
Structured FHIR attachments are required for carepath data so EHRs can parse, visualise, and re-use the information beyond a static document.
When specialised visualisation is needed, providers can expose a dashboard URI that the EHR can embed or open for a richer, provider-managed view.
TMP also supports deeper provider flows beyond the core request and results integration.
Instead of relying on SSIN-based patient login, which is not ideal to comply with GDPR, TMP can generate a unique patient authentication token linked to a telemonitoring session. The provider can later verify that token with TMP through the patient authentication API.
Providers can optionally configure a deep link that includes the telemonitoringId and patient authentication token. TMP Portal can show that link as a QR code so the patient can continue directly into the provider app or site.
Providers who support dashboarding can expose an endpoint that TMP calls to retrieve an authenticated dashboard URL for the HCP. Details are documented in the provider dashboard URL spec.
TMP can trigger stop and cancel actions towards the provider via a configured action URI. The provider then applies its business rules and updates TMP Hub with the resulting new status.
Once request context and (optionally) results integration are implemented, TMP can activate your provider based on a compact configuration set.
| Field | What TMP needs |
|---|---|
| Name | Application name shown to HCPs |
| Provider | Company or organisation name |
| Description | Short provider description shown in TMP |
| Carepaths | Supported HL7-defined carepaths |
| Fields | The request context fields your provider wants to receive |
| Headers | Fixed and prescriber-specific headers used during calls |
| URI and Action URI | Request endpoint and action webhook endpoint |
| Supported actions | Whether stop and/or cancel are supported |
| Patient authentication | Whether token support and a patient auth URI are enabled |