View source for Shelf Readiness

=Introduction=
The term "shelf-ready," and the broader concept of "shelf readiness," stem from the need to ensure that digital health global goods, particularly software, are ready to be deployed as stand-alone products which meet the primary data use needs of a tool. While not referring to a monolithic approach the concept of stand-alone refers to the tools being packaged and complete in the view of having available and installed all required dependencies and functions to achieve the intended feature sets. Shelf readiness aims to allow implementers and decision makers to have a higher level of confidence in the solutions as they would be well presented in their product information, ability to perform desired functions as well as interoperability workflows / metadata synchronizations and deployment aspects, to name a few areas. 

Digital Square has framed three tiers of shelves around the scaffolding of the OpenHIE architecture to describe conceptual groupings of tools within the space; with the first set of shelves framed around the (i) Business Domain Services, (ii) Metadata Management/Registry Services and (iii) Point of Services. 

[[File:Shelf Ready.png]]

Technologies and software that are shelf ready should strive to support the Installation Qualification (IQ), Operational Qualification (OQ), and Performance Qualification (PQ) of software validation, in both tool and implementation, and through this allow themselves to showcase their readiness for safe and effective use and function. Digital Square has outlined the following framework in guidance of technologies that are shelf ready. The framework flows around the following areas: 

==Global Goods Maturity Model==
Shelf-ready software and tools show a high level of maturity across the [https://wiki.digitalsquare.io/index.php/What_are_Global_Goods#Maturity_Model global goods maturity model]. While high scores across all dimensions are ideal, achieving the levels indicated below are prioritized: 

*Global Utility
**Digital Health Interventions (High)
**Source Code Accessibility (High)
*Community Support
** Software Roadmap (medium)
**User Documentation (medium)
**Multi-lingual Support (medium)
*Software Maturity
**Technical Documentation (medium) 
**Software Productization (medium)
**Interoperability & Data Accessibility (medium)
**Security (medium)
**Scalability (medium)

Further refinement of this model would see that software and tools exhibit strong features and functionality in the areas of: 

===Installation and Deployment=== 
Tools and technologies should not only follow international conventions to support industry and enterprise installation and deployment patterns but strive to support the [https://wiki.ohie.org/display/resources/Instant+OpenHIE Instant OpenHIE] deployment and configuration requirements to form part of the large infrastructure. This is inclusive of: 

*Harmonized containerization approaches with the Instant OpenHIE project. 
*Development of synchronization tools (e.g., OpenHIM mediators) between the software tool and metadata registries (facility, client, terminology) using appropriate IHE profiles of HL7 FHIR.   
*Scripted configurations and data sets (as required) to showcase the functionality of base use cases. 
*Existing documentation that allows implementers to validate that the initial installation of the tool has been completed successfully as per the Installation Qualification (IQ).  The Installation Qualification consists of two parts: the validation of the ICT infrastructure (power, connectivity, physical security) to ensure it meets the agreed system requirements; and the validation of the deployment of the software to ensure it is installed and functioning correctly.   The IQ reports produced by the execution of the test protocols should provide a complete record of the computer system installation validation at a point in time to provide assurance that all system services are operational.

===Quality Assurance and Testing=== 
Strong and empirical evidence of well-thought-out quality assurance patterns to validate functionality and provide a sustained and consistent base of evidence that the software both meets the functional requirements or feature sets but also is built as expected. Shelf-ready tools should strive towards having a documented testing strategy that covers any major risk areas and business critical functions and include testing strategies to mitigate failure in these areas. This testing strategy should be operationalized in a testing framework that is applied against the tool in a repeatable manner and the QA plans and reports, as well as available indicators outlining the level and coverage of testing should be available for review. 

===Product Information and Documentation=== 
Shelf-ready tools should differentiate the product information and documentation artifacts and cater to the required audiences. Product information should outline in a summary form the key functions and value proposition of the tool and serve as a quick access document for decision makers to understand the value proposition and value gained from the tool (the brochure, so to say). In addition, Product Documentation for shelf-ready goods should be comprehensive and inclusive of all aspects to support an effective and safe implementation and ongoing operations of the tool in the field. Product documentation should include not only developer documentation (software design, patterns, etc.), but also implementer documentation (installation guides, architectural implementation patterns for scale, implementation validation checks, etc.), administrator guides (configuration option and descriptions of all features and options, etc.), user guides and operation manuals (outlining the functionality of the system as well as how it operates). 

==Supports standards for data exchange as appropriate for the tool and aligned with the OpenHIE architecture==
Shelf-ready software tools are well categorized within the business functional domain or as a registry/metadata service or point-of-service solution and, as such, adhere to clearly defined data exchange patterns and flows. The solutions are well aligned to the OpenHIE architecture and facilitate the required interactions to support the key use-cases that are proposed and advertised as supported by the technology. As an example, Point of Services systems interacting with patients would be well suited to register and query patients and associated demographics with a client registry and should be able to synchronize health facility lists with a Facility Registry. 

==Aligns with DevOps and Cloud-Services Guidelines==
Shelf-ready tools and technologies look to ensure that they are aligning to emerging guidelines such as the [https://docs.google.com/document/d/1daVn-xxxuhQvFzA4sIY2vsDnJxh7AV8DxbB8wkvZNpg/edit?usp=sharing DevOps and Cloud-Services guidelines]. These look to provide guidance on some of the major areas of consideration for the deployment of implementations within and for countries. These considerations often require a migrating path from local hosting to international cloud services. Shelf-ready global goods should provide a change management path/guideline for the transition from local data centers to cloud, and take into account the need to harmonize on  a common approach to DevOps across digital health tools.