Repository housing all code responsible for handling the Clinical Data Gateway APIs. This repository houses the various Python modules responsible for managing logic within the APIs, as well as all the Terraform code responsible for deploying the APIs within an environment.
The Clinical Data Gateway APIs look to provide the GP Connect APIs over the internet, via the API Management platform. More details on the GP Connect specifications can be found on the GP connect specifications for developers page.
Clone the repository.
git clone git@github.com:NHSDigital/clinical-data-gateway-api.git
cd clinical-data-gateway-api.gitThis project depends on the clinical-data-common library, which provides shared code and utilities used across various clinical data API products. The dependency is managed via Poetry and installed directly from the GitHub repository.
The library is referenced in gateway-api/pyproject.toml as a git dependency. The CI/CD pipeline is currently configured to pull the latest version from the specified branch automatically.
The project can then be built within a Dev Container as defined within the file outlined under .devcontainer/devcontainer.json. When opening the project within Visual Studio Code, if the Dev Containers extension is installed, you should be prompted to re-open the folder within a Dev Container if you wish. If accepted, this should build the Dev Container locally which will include all required libraries and tools for development.
Note
If any additional certificates need to be trusted when building locally, these can be added to the infrastructure/images/build-container/resources/dev-certificates directory. These certificates will then automatically be trusted by the build container when the INCLUDE_DEV_CERTS docker build argument is set to true.
If running in Windows Subsystem for Linux (WSL) on Windows the vscode Dev containers extension should be configured to use WSL {"dev.containers.executeInWSL": true}. It is also necessary for the repository to be cloned into the WSL filesystem and on the first build of the container (and any subsequent complete rebuilds without cache). vscode should then be connected to WSL, before subsequently opening the repository folder. The container can then be built as described above.
The following software packages, or their equivalents, are expected to be installed and configured:
- A container manager for running containers locally, such as Colima on Mac OS, or Docker within WSL on Windows or Linux natively.
Installation and configuration of the toolchain dependencies is completed as part of building the Dev container as described above.
Once the build container has been built and is up and running, A few different make targets are provided for installing dependencies and building the codebase.
dependencies- installs all dependencies required for the projectbuild- builds the codebase so that it is ready for deploymentdeploy- builds the codebase and deploys it within a separate container locally.clean- stops and removes any containers outside of the Dev container locally.
There are make tasks for you to configure to run your tests. Run make test to see how they work. You should be able to use the same entry points for local development as in your CI pipeline.
More documentation on the GitHub actions utilised to support continuous integration can be found on the Continuous Integration page.
The C4 model is a simple and intuitive way to create software architecture diagrams that are clear, consistent, scalable and most importantly collaborative. This should result in documenting all the system interfaces, external dependencies and integration points.
The source for diagrams should be in Git for change control and review purposes. Recommendations are draw.io (example above in docs folder) and Mermaids. Here is an example Mermaids sequence diagram:
sequenceDiagram
User->>+Service: GET /users?params=...
Service->>Service: auth request
Service->>Database: get all users
Database-->>Service: list of users
Service->>Service: filter users
Service-->>-User: list[User]
Most of the projects are built with customisability and extendability in mind. At a minimum, this can be achieved by implementing service level configuration options and settings. The intention of this section is to show how this can be used. If the system processes data, you could mention here for example how the input is prepared for testing - anonymised, synthetic or live data.
Describe or link templates on how to raise an issue, feature request or make a contribution to the codebase. Reference the other documentation files, like
- Environment setup for contribution, i.e.
CONTRIBUTING.md - Coding standards, branching, linting, practices for development and testing
- Release process, versioning, changelog
- Backlog, board, roadmap, ways of working
- High-level requirements, guiding principles, decision records, etc.
To be able to contribute to the repository, any commits created need to be signed. See the commit signing setup guide page for guidance on setting up this up.
Provide a way to contact the owners of this project. It can be a team, an individual or information on the means of getting in touch via active communication channels, e.g. opening a GitHub discussion, raising an issue, etc.
The LICENCE.md file will need to be updated with the correct year and owner
Unless stated otherwise, the codebase is released under the MIT License. This covers both the codebase and any sample code in the documentation.
Any HTML or Markdown documentation is © Crown Copyright and available under the terms of the Open Government Licence v3.0