OCL Docs is a community-maintained collection of documentation about our software and about our community. You can browse OCL Docs anonymously. Volunteers create documentation and maintain this site, and we invite you to help by improving content, filling gaps, and correcting errors. To contribute, request access to the ocl-docs repository on GitHub.
The Open Concept Lab (OCL) is an open-source terminology management system to help you collaboratively manage, publish and use your metadata in the cloud alongside the global community.
Learn more about OCL, its tools and its core features:
Getting Started with OCL
Learn how to start contributing to OCL as a developer:
As a developer: Getting Started as a Developer | Developers Guide
Advanced Features of OCL
Learn more about these integrations and how you can interact with OCL.
Retrieving Content from OCL’s API : Visit our Swagger page for information about OCL’s API endpoints and examples for retrieving terminology content
Interface layer: The interface layer is a set of API endpoints customized to support PEPFAR use cases through OpenHIM mediators. Interface layer API Documentation
OCL software releases are being published to Dockerhub (tagged binaries) and to GitHub (tagged source code). We follow semantic release versioning i.e. the major.minor.maintenance-revision scheme e.g. 2.0.1-as435a47. Releases of oclapi2, oclweb2 and oclfhir are coordinated to maintain compatibility within the same minor version. We append a shortened Git SHA (8 characters) to each version so it is easier to track down specific commit used for that particular release. Release notes are available on GitHub for oclapi2, oclweb2 and oclfhir.
The user can check the version of software in the oclweb2 footer as well as in ‘x-ocl-api-version’ and ‘x-ocl-fhir-version’ response headers from API and FHIR REST services.
OCL service is scalable, fault tolerant and highly-available.
OCL is running on AWS infrastructure. Our services are currently deployed in the us-east2 AWS region. All our services are replicated in two separate data centers within the region providing fast responses and high-availability. All our services are behind a load balancer, which constantly monitors and instantly redirects traffic if anything goes wrong. We can survive a failure of a service, a server instance or the whole data center without any downtime.
The entire content is being backed up every 24 hours.
We have rolling upgrades in place so most upgrades do not cause any downtime. We will let you know in advance, if a major upgrade is required, which may cause even small downtime.
The whole infrastructure is being managed via code with Terraform, which alows us to apply upgrades and track or revert changes if needed. We are also in position to restore the entire infrastructure from scratch in any other AWS region when the whole region goes down.
We scrupulously gather logs to troubleshoot any issues you report us.