Core provides open APIs so that your systems can be enhanced with data and capabilities from Core. These align with the NHS Open API Architecture Policy.
The capabilities offered and registration process required vary depending on what you wish to do.
1) Use case: Launch in context
As a third party with an existing system:
- I want to launch pip from my existing system and display a defined patient
- I am happy for my users to authenticate using Core Auth if they are not already authenticated using an identity provider trusted by Core
Registration
This workflow does not require a Core API Agreement.
2) Use case: Client app
As a third party with a web app:
- I want to use data from Core within my app
- I am happy for my users to authenticate using Core Auth if they are not already authenticated using an identity provider trusted by Core
- I expect that the owner of the Core service will trust my app
In development - contact us for more information.
3) Use case: API access with auto-enrolment
As a third party with a web app or service
- I want to use data from Core within my system
- I want to use identities from my own system
- I expect that the owner of the Core service will trust my app or service
Registration
This workflow requires an Extended Core API Agreement and API use is controlled by a Usage Plan.
You must contact Black Pear to request use of the Core API, providing the following information:
- organisation name
- ODS code for the third party
- name of the client application
- description of the purpose for processing the information
- required environment (beta, production)
- expected usage rate and volume
In order to link your identity provider for auto-enrolment, you must provide the following information:
- JWKS endpoint for the key used to sign the client assertion (Core Auth must be able to access the endpoint via internet)
- iss claim to be used within the subject token
- JWKS endpoint for the key used to sign the subject token (Core Auth must be able to access this endpoint via internet)
- Subject token schema. The subject token must meet the minimum information requirements in order to be linked.
The same iss claim and JWKS endpoint can be used for both client assertion and subject token.
You must specify the individual Core APIs that you wish to use:
API |
Purpose |
| metadata | read metadata |
| clinical | read clinical data |
| corecareplans | read legacy care plans from Core Care Plans |
| nhsmpi | search for patients in PDS |
| nhsods | search for organisations in ODS |
| emisweb | read clinical data from EMIS Web |
| tppsystmone | read clinical data from TPP SystmOne |
| vision | read clinical data from Cegedim Vision |
| command | share information with Core |
Request verification
Black Pear will verify that:
- the request originates from you
- you have a current DSPT submission with all standards met
- you have a legitimate purpose to process information using the requested APIs
Your request will not be unreasonably rejected.
Following verification, Black Pear will supply an Extended Core API Agreement for you to sign. This governs your use of Core API. Administration and usage charges apply.
Access information
Black Pear will provide the following:
- Client id
- API key
- Documented Usage Plan to allow fair and agreed use of Core APIs
- Link to API documentation for the agreed APIs
4) Use case: Launch with auto-enrolment
As a third party with an existing system:
- I want to launch pip from my existing system
- I want to use identities from my own system
- I expect that the owner of the Core service will trust my app or service
In development - contact us for more information.
0 Comments