tencent cloud

Introduction

Download
Focus Mode
Font Size
Last updated: 2026-08-28 16:57:32
AI-Translated

Overview

This document is intended for developers, integration implementers, and business technology teams who access and use this platform's FHIR API. It introduces the standardized healthcare data storage and access capabilities provided by the platform and covers topics such as API calls, resource operations, search, transaction processing, and error responses.
This platform provides data service capabilities based on the standard FHIR API, supporting unified modeling, standardized access, and structured exchange of healthcare data. Callers can perform operations such as create, read, update, delete, patch, conditional search, and batch transaction processing on FHIR resources using standard HTTP methods, thereby meeting the requirements of scenarios like clinical application integration, research data governance, cross-system data exchange, and business service enablement.
The platform APIs are designed with a resource-oriented and RESTful style, and the resource content is organized according to the standard FHIR structure. This facilitates building business processes around core resources such as Patient, Observation, and Encounter. Additionally, the platform supports an access token-based authentication mechanism to ensure that identity verification and access control requirements are met during API calls.

Terminology

The table below summarizes the key concepts and terms commonly encountered when this platform's FHIR API is called, facilitating a common understanding before the subsequent sections are read.
Term
Description
FHIR
Fast Healthcare Interoperability Resources (FHIR), a data exchange and interoperability standard for the healthcare domain. The platform's APIs adhere to this standard for resource modeling and interaction.
baseUrl (Service Base Address)
The root access address of the FHIR service, for example, https://HOSTNAME/INSTANCE_ID/fhir, where HOSTNAME is the FHIR service access domain name and INSTANCE_ID is the FHIR service instance ID. For Tencent Cloud SaaS scenarios, obtain it in the Tencent Healthcare Data Services console > Instance Overview. For independently deployed scenarios, use the service access domain name and instance ID provided by the deployment party. Resource read/write, search, and Bundle submission all construct request URLs based on this address.
Content-Type
The MIME type of a request body or response body. Write-type requests typically use application/fhir+json; Patch requests typically use application/json-patch+json.
Resource
The fundamental unit for storing and accessing healthcare data on the platform, expressed in the standard FHIR JSON structure, such as patients, test results, and visit records.
ResourceType
The category name of a resource, used to distinguish different business entities, such as Patient, Observation, and Encounter. In a request URL, the resource type is typically used as a path segment.
id (Resource ID)
The unique identifier for a resource within the platform. Operations such as read, update, and delete typically access the target resource via [baseUrl]/[resourceType]/[id].
Reference
An association between resources, typically pointing to another resource in the format ResourceType/id, for example, Patient/199963.
ETag / versionId (Version Identifier)
Information that identifies the current version of a resource. After a successful creation or update, the ETag in the response header and the resource's meta.versionId can be used for version control and concurrent update determination.
_history
The suffix for accessing historical versions of a resource. A specified historical version can be read via [baseUrl]/[resourceType]/[id]/_history/[versionId].
Bundle
A special FHIR resource used to encapsulate multiple records or interactions. The search API returns a result Bundle; the transaction/batch API performs operations in batches by submitting a Bundle.
Placeholder ID
A temporary identifier assigned to resources not yet persisted in a transaction Bundle, typically in the format urn:uuid:{uuid}, used to establish resource reference relationships within the same request.
transaction / batch
The two processing modes of a Bundle.
- transaction: indicates an atomic transaction, where all entries either succeed together or fail together.
- batch: indicates batch processing, where each entry is executed independently.
Search Parameter
Query parameters appended to a resource type URL, used to filter resources based on conditions, for example, ?name=Zhang San&gender=male.
OperationOutcome
An FHIR resource used to describe operation results, validation information, or error details, commonly seen in scenarios such as deletion failures or business validation failures.
API Key
An identifier for the caller, used to request access tokens from the authentication service. It can be obtained on the API key management page after an FHIR service instance is created.
API Secret
The identity secret of the caller, used in conjunction with the API Key to calculate request signatures. Keep it secure to prevent leakage.
Signature
A signature value obtained by performing HMAC-SHA256 calculation on apiKey + timestamp based on API Secret, used for identity verification of the authentication API.
AccessToken
A JWT token returned upon successful authentication API call, used to access FHIR business APIs.
Bearer Token
The method of carrying the token in the HTTP request header when FHIR APIs are accessed, with the format Authorization: Bearer .

Content Description

This document primarily covers the following content:
API Overview: This section describes the overall capabilities of the platform APIs, the main API categories, an overview of invocation methods, and typical applicable scenarios.
Calling Methods: This section describes the general rules for request structure, common parameters, API authentication process, and returned results.
FHIR Operation-related APIs: This section describes capabilities such as Basic Resource Operations, Search Operations, and Bundle Request APIs.
Error Codes: This section summarizes common error codes and their typical triggering scenarios to facilitate issue troubleshooting by callers.
By reading this document, callers can quickly understand the platform's API architecture and complete API integration, resource access, data search, and batch processing in accordance with unified specifications.

Overall Invocation Flow

Before callers access FHIR resource APIs, the overall invocation process for callers is as follows:
1. Create an FHIR service instance and create a service API key. The caller should save the API Key and API Secret.
2. Generate a signature using the API Key, API Secret, and a timestamp.
3. Call the authentication API to obtain a JWT-based AccessToken.
4. Use the AccessToken to access FHIR RESTful APIs.
5. The AccessToken is validated by the FHIR service against the authentication service.
6. If authentication succeeds, the business result is returned; otherwise, the request is rejected.

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback