For more details on the Instant OpenHIE architecture, see Instant OpenHIE Technical Architecture.
Instant OpenHIE is designed to be extensible. There are two broad areas of contribution to the Instant OpenHIE stack:
When contributing new components/apps, the following artefacts are expected to be produced to support this:
App owner responsibilities
Releases should be tagged in git or other version control system and in a public repository.
Create a publicly available Dockerfile used to build the image and a link to it.
Make available a link to a public image of the application. A tagged release image should be available.
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.
Provide detailed information or scripts that can run in a non-GUI environment for automated configuration.
When contributing new workflows or implementation use cases, the following artefacts are expected to be produced to support this:
Workflow owner responsibilities
Generate fake but realistic data for E2E tests and general functionality.
Package test data
Make test data available or reproducible online.
Write tests for the expected workflows supported using the containers, configuration, and fake data.
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)
Make available a link to a public image of the tests. A tagged release image should be available.