Summary

ClinSpark includes a significant body of standard reports and dashboard components out of the box. They have been designed to meet an variety of regulatory and operational needs across customers. It is the intent of Foundry Health and expectation that the majority of reporting needs can be met through standard reports OR direct access to the same information using ClinSpark’s user interface. Additionally, Foundry Health offers customers access to a Read Replica database to enable self-serve report development in order to meet certain site-specific needs.

Foundry Health will however perform limited custom development at the request of customers. This may include minor enhancements to existing ‘out of the box’ reports/components or requests to develop something new.

Requirement Specification

The requirements specification should at a minimum contain the following:

• Share existing examples as a reference (if available)

• The requirements are written referencing test data in the customer TEST environment. Specify where in the ClinSpark user interface each field comes from.

• Share an example output referencing test data. PDF report outputs can for example be mocked out using Google Docs or similar.

• Clear description of the report / component’s full functionality

• A clear description of all permutations of test inputs and expected outputs

For each report or dashboard component that Foundry Health needs to develop or adapt for the customer, the below information is expected to be delivered by the customer before the engineering team can take a start:

• Request Goal: the customer should describe is sufficient detail what the use case for the report/dashboard (amendment) is. It is important for the Foundry Health team to understand under which circumstances the report/dashboard is used, what the customer is trying to achieve with it.

• Inputs: if it is required to limit the extraction of the report or component to specific cohorts, epochs, subjects, or other filters; this needs to be defined. This information will be guiding for Foundry Health to define the corresponding input fields in the Reports interface or Dashboard, like in this example shown below:

• 

  Logic: Describe in dedicated points what the report or component needs to do, including which data points need to be visualized and if applicable, what the status of the data should be in.

• Example Output: create or provide a near look-a-like example of how the report should look. This can be done in Google Docs/Sheets, Microsoft Word/Excel, etc. Any format is applicable, so that it is clear for the Foundry Health team how you want the report or component to look like.

• Test Data: Provide sufficient test data in your TEST or Sandbox environment, and make it clear where to retrieve the data (including study, cohort, subject, timepoint details as needed). Any details regarding test data will be used by Foundry Health to perform internal QC, and establish success criteria.

The Foundry Health team also encourages the use of screen recordings or screenshots as needed to help define any of the above specifications.

Development Fees

Fees/charges for the development of new reports/widgets or changes to existing are subject to terms to be discussed and agreed upon in service desk tickets.

Changes which do not incur fees

Any changes to existing reports which are required to satisfy certain regulatory requirements, or, to correct errors/bugs in an existing implementation will be made without charge. These sorts of ‘no cost’ changes should be discussed and agreed upon in the applicable service desk ticket requesting the changes.

Contractual agreements that specify custom report development tasks may supersede stated fees in this document. If there are questions regarding scope of agreed custom development based on contract terms, customers should reach out to Foundry Health ahead of custom development requests to confirm scope and cost.

Requests which may not be accepted

We reserve the right to deny development requests. Reasons for this may include:

• Requests which are very specific to a given customer. We strive to invest development efforts into solutions which are of use and value to the entire ClinSpark community.

• Requests which depend up on specific study designs/protocol criteria or naming conventions. These types of requests have challenges with use over time, are difficult to support, and are at a higher risk of regression.

• Cosmetic changes to standard reports or components.

• Alterations to existing reports due to customer operational process changes or study design practices.

• Requests where a customer is several versions ‘behind’ the current ClinSpark release. We want to help our customers stay current with ClinSpark versions, which inherently enables better support for the latest set of standard ‘out of the box’ reports/components and features supporting their use.