Uzbekistan Digital Health Platform
0.3.0 - ci-build International flag

Uzbekistan Digital Health Platform, published by Uzinfocom LLC. This guide is not an authorized publication; it is the continuous build for version 0.3.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/vadi2/DHP-temp/ and changes regularly. See the Directory of published versions

Api Access

Endpoints

  • Playground: playground.medcore.uz/fhir
  • Production: fhir.medcore.uz

Security and authentication

To ensure security, confidentiality, and reliable access control within the National Digital Health Platform (DHP), an authentication and authorization system based on the international OAuth 2.0 standard has been implemented. Supporting both frontend and backend application scenarios. A centralized Single Sign-On (SSO) server ensures secure identification of all platform participants - from patients and healthcare providers to external systems.

DHP supports two main authentication scenarios:

  • Backend applications - via the client_credentials grant (no user interaction required),
  • Frontend applications - via the authorization code grant with redirect_uri support and optional PKCE.

Backend Integration

This section describes the process for obtaining an access token for backend applications using the OAuth 2.0 protocol with the client_credentials grant type. This flow is used when a service needs to access protected APIs on behalf of itself, not a user.

Client Configuration

The backend client must be registered on the SSO server. Upon registration, you will receive:

  • client_id - the identifier issued by the provider
  • client_secret - the secret key issued by the provider

Obtain token

Request

POST /oauth/token

Request body

Parameter Value
grant_type client_credentials
client_id <client_id>
client_secret <client_secret>

Error Responses

Frontend Integration

This section describes how frontend applications can authorize users via the SSO server using the standard OAuth 2.0 Authorization Code Grant. This flow ensures a unified login and secure user authentication within the DHP ecosystem.

Client Configuration

The frontend application must be registered with the SSO server. Upon registration, you will receive:

  • client_id - identifier issued by the provider
  • redirect_uri - URL provided by your application

Authorization Flow

1 Redirect the user to the SSO frontend:

GET sso.medcore.uz

Parameters:

Parameter Value
client_id <client_id>
redirect_uri <redirect_uri>

2 Authorization Code:

After successful login, the user will be redirected back to the redirect_uri with an authorization code.

3 Exchange the Code for a Token:

This exchange must be done on the backend to protect the client_secret. If your application does not have a backend, use PKCE instead.

4 Use the Token:

Include the access token in each request:

Authorization: Bearer <access_token>

Error handling

<to be filled in - describe error handling here>

Must Support

Must Support in this implementation guide is used in two contexts:

  1. UZ Core profiles: indicates that the element is expected to be populated when exchanged by systems within Uzbekistan.
  2. DHP-specific profiles: indicates that the DHP supports the element, and client systems must populate it with data should it be available.

In case an element cannot be populated because it is not available in the source system, if the cardinality rules allow it, the element can be left unfilled. In case the cardinality rules require an element to be populated, the Data Absent Reason extension SHALL be used.