The following are recommended non-functional requirements for the OpenHIE component software depicted in the gray box of figure 2.1 and further defined in this document. OpenHIE supports the use of technology that is appropriate for the use case and does not preclude the use of proprietary tools but rather supports the use of tools that are built to meet the needs and support the implementation. OpenHIE does require that technologies do not create a “lock-in” scenario whereby the implementer has no access to their data and as such supports an approach to an open architecture.
OpenHIE Non-Functional Requirements
Technologies should provide standard means of accessing data within the system that does not lock the client into proprietary data formats or storage mechanisms.
The system should be well Documented: An OpenHIE reference system should include appropriate background, design, installation, configuration, and operational documentation to ensure it is easy to understand, maintain, and debug.
If the system is an open source tool the system should have open, easy access to source code: A standard version control system (e.g., GitHub) should be used to ensure that source code access is fast, easy to download, compile, and execute code.
The system should be built using common technology:
The source code should include unit tests that are based on the specific requirements of OpenHIE and that create a framework to validate functionality and that the system operates as designed.
OpenHIE does not preclude the use of proprietary solutions. If an open source solution is selected it is recommended that the component would, ideally, be distributed under an OSI approved open-source license that minimizes complexity and enables an implementer community to leverage the software in a broad variety of sustainability contexts.
The system should take into account the IT infrastructure of low resource settings where electricity, internet and/or technical literacy may be limited.