Security guidance to use the CCRI

Security guide

This page provides an overview of the security guidance and access mechanisms to the Care Connect Reference Implementation (CCRI).

Security architecture

The OAuth2 Secured resource endpoint is located at

A brief summary of the Notes on secured CCRI access:

  1. The data exposed by the secure Requests are identical to the standard REST Requests of the FHIR Care Connect API. The scopes demonstrated within the security demonstrate profile restriction on the HTTP REST API of a specific user/system/role. This will depend on specific systems.

  2. The CCRI provides examples based on restricted Users. Each User has a set of Scopes and in order to access certain Profiles the user requires a specific Scope on their profile.

  3. The security is managed by a OAuth2 Server. The OAuth2 Server is currently configured on a separate server or you can follow the instructions provided by the Care Access Service (coming soon).

Before your application can access secured CCRI API data, it must obtain an access token that grants access to that API. A single access token can grant varying degrees of access to multiple APIs. A variable parameter called scope controls the set of resources and operations that an access token permits. During the access-token request, your application sends one or more values in the scope parameter.

If you know how to access an OAuth2 secured endpoint via tokens (server based interaction) or OAuth2 (web/app hosted interaction). There are currently two themes described to help users use a secure API with the CCRI, these are described in the following links:

Security Quickstart

Security Authentication will eventually allow a Care Connect API to be deployed into a live environment where data is hosted and shared across system and organisational boundaries. Two step by step guides have been included in the Security Authentication section which demonstrate OAuth2 :

  1. Access via Postman to Authenticate and connect with the Care Connect Reference Implementation. This access mechanism would often be found between systems
  2. Access via an OAuth2 negotiated server. This access mechanism would often be found between a website / mobile app and an end user

Security Scopes

Security Authorisation can be managed in different ways inside Care Connect and FHIR. Within the RESTful version scopes can be defined which restrict access to profiles depending on the defined system or end user. Currently the Security Authorisation provides an example of restricting access to certain Resources. However, in the future it might be possible to dynamically create Scopes on Resources. The CCRI provides a demonstration of OAuth2 Users & Scopes.

Resource scopes

To access any resource when security is enabled requires the definition of Resource scopes. Within FHIR the following list provides the starting point to access the CCRI.

Resource name Permitted scopes
Patient user/
Observation user/
Encounter user/
Condition user/
Procedure user/
AllergyIntolerance user/
MedicationRequest user/
MedicationStatement user/
Immunization user/
DocumentReference user/DocumentReference
Binary user/Binary

Current Version

Check out Versions for more information about the current released version, downloading options, use and future verions.


This site is structured around Care Connect stakeholders including API users, developers and architects. Please get involved in the journey.

guide Engage Clinical scenarios User stories Case Studies Benefits Clinical inspiration Explore Impl Guide Resource Profiles API definitions Search parameters Value sets Design & Build Build APIs Search Ex. Code examples Validation tools Security examples Test Test data Security tests Reference servers Secure store Example data Assure Automated tests Test Reports Test Evidence Conformance reports Assurance checklist Deploy (Pilot) API harness Warranted environment IG / IS Spine comms Record locator Deploy (Live) Registry Monitor Support Conformance statement Extensions