...
| Roadmap Planner | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Documentation and Architecture
The fundamental concept of Instant OpenHIE is that it can be extended to support additional use cases and workflows. This will be achieved through packages. A core package will be produced in this first phase which other packages will all derive from. A package will either extend directly from the core package or from another package.
Each package will contain the following sorts of technical artefacts:
- Docker compose scripts for setting up the applications required for this package’s use cases and workflows
- Kubernetes scripts for setting up the applications required for this package’s use cases and workflows
- Configuration scripts to setup required configuration metadata
- Extensions to the test harness to test the added use cases with test data
The diagram below shows how packages will extend off each other to add use cases of increasing complexity:
The following diagram shows a generic logical architecture showing the involved OpenHIE components for the first phase, covering the core and health workforce packages. Each of these components’ roles could be played by any application that supports the necessary OpenHIE workflows and component requirements. It would be possible to swap out applications for others as long as they conform to these specifications. In the future Instant OpenHIE could support multiple application options for each role.
...
For more information about Instant OpenHIE see the user documentation.
For an depth description of the architecture see to following links:
- For documentation and architecture relating to the first phase see the Instant OpenHIE Technical Architecture.
- For the generic architecture of Instant OpenHIE see the architecture section of the user documentation.
Contributing
Instant OpenHIE is designed to be extensible. There are two broad areas of contribution to the Instant OpenHIE stack:
...
App owner responsibilities | Description |
Tagged releases | Releases should be tagged in git or other version control system and in a public repository. |
| Environment variables | Configurations must be stored in or be able to be overridden by environment variables. See the Twelve Factor App: https://12factor.net/config |
Dockerfile | Create a publicly available Dockerfile used to build the image and a link to it. |
Container image | Make available a link to a public image of the application. A tagged release image should be available. |
Docker Compose | Provide a link to a versioned Docker Compose script. A Docker Compose file should exist for running the application stack, including databases or web servers or other needs. Where possible use existing containers for things like databases or web servers. Slim images (e.g. Alpine) are recommended as many images will be run concurrently. |
Automated configuration | Provide detailed information or scripts that can run in a non-GUI environment for automated configuration. |
...
Workflow owner responsibilities | Description |
Test data | Generate fake but realistic data for E2E tests and general functionality. |
Package test data | Make test data available or reproducible online. |
Tests | Write tests for the expected workflows supported using the containers, configuration, and fake data. |
Dockerfile | Tests can be written in any language. Provide a Docker container for tests so that they can be run easily (with environment variables) against any stack (not just Instant OpenHIE) |
Container image | Make available a link to a public image of the tests. A tagged release image should be available. |
Project Team
Engaging with Us
Please join us in the OpenHIE DevOps Community Call OpenHIE DevOps Community CallSubcommunity Calls
or, in the OpenHIE Architecture Community https://groups.google.com/forum/#!forum/ohie-architecture