Overview

Site entities represent the physical study site location where subject enrollments and data collection will take place. This same site will also be added available in other areas of the system, such as adding to certain user configurations to establish site restrictions, to ensure those users can only access specific site(s) datadata restrictions, associations on volunteer records, and use within study setup and cohort management workflows.

Sites that are setup via Administration > Sites are expected to be setup and used as global entities. They exist with the purpose/expectation of being established and maintained across one or more studies.

...

If a site is expected to participate in one or more studies, that site should not be created multiple times in Administration > Sites. Instead, the site would simply be added to study configurations established where that site is participating.These are the recommendations for setting up sites

...

Permissions for adding sites

For our early phase customers, sites can only be added by ‘superadmin’ users through the assistance of our support team via service desk ticket. This is by design, due to the potential cost implications for adding and collecting study data against external (non-core) sites. More details about those costs are noted here: https://foundryhealth.atlassian.net/wiki/spaces/DOCS/pages/3897294849/ClinSpark+Pricing#ClinSpark-Extra

For our customers who use ClinSpark setup for an operational model supporting later-phase multi site trials, users with the Administration > Sites role action on their account will be able to add sites without ‘superadmin’ intervention. We have a more detailed guide for our customers who setup and use sites for this purpose: Setting Up Sites

Sites are also only allowed to be added into a ‘MAIN’ environment (such as PROD MAIN). Sites cannot be added into any environments that are running in Test Mode. Through study design import functionality, sites are added and synchronized into matching TEST environments. Site attributes remain in synch between MAIN/TEST environment through the import mechanism over time. More details about this process are here: https://foundryhealth.atlassian.net/wiki/spaces/DOCS/pages/3708944593/Notes+on+Study+Design+Export+and+Import#Site-configurations

Site details

When setting up a new site, these are our recommendations:

• Fill out as much of the site details as possible including address, phone, and investigator details. Once a site has been added to a study configurations, the investigator details can be modified per study.

• Always select a timezone setting that appropriately matches the physical location (closest city or region). More details on timezones are listed below.

• Establish height/weight unit of measure appropriate to the site geographic location and study preferences.

• Ensure proper volunteer display patterns to meet site regional privacy laws

...

If customers have any questions about establishing site entities, they are encouraged to reach out to Foundry Health via service desk ticket.

Site timezones

The proper selection of site timezone is critical for supporting data collection workflows and certain logic built into device configurations, reports, and dashboard components that rely on the site setting.

ClinSpark offers timezone options based on what is built into the Java Virtual Machine (JVM). The JVM however supports a wide selection of ‘deprecated’ timezones for compatibility reasons, but not all are appropriate for use. A majority of the selections of the JVM are built around this pattern:

• Abbreviation-based identifiers (GMT, AST, UTC)

• Administrative zones and GMT offsets (Etc/UTC, Etc/GMT+6)

• Country/StateOrRegion (US/Pacific, Cuba)

• Area/Locality (America/New_York, Europe/London)

• Area/Region/Locality (America/Argentina/Buenos_Aires, America/Indiana/Knox)

Whenever possible, the most accurate and appropriate selection of timezone follows the pattern of Area/Region/Locality or Area/Locality. This ensures that the most regionally accurate timezone is selected in order to properly observe timezone rules (such as daylight savings) in that physical area.

Selections of Country/StateorRegion, or, abbreviation based identifiers such as GMT offsets is typically less accurate and generally not recommended. Selection of GMT offsets do not properly observe regional requirements for daylight savings time. Additionally, certain Country/StateorRegion selections are less accurate than Area/Locality, because countries and state regions span multiple physical cities and areas that can observe different rules for daylight savings time.

It’s therefore important to search the timezone list for a selection of the proper locality for a given site, or, the locality that matches the closest city.

As an example, let's consider a site located in Puerto Rico. Puerto Rico observes Atlantic Standard Time (AST). AST however spans multiple regions where only some locations observe daylight savings time. However, Puerto Rico does not observe daylight savings. While it would seem appropriate to select the AST timezone based upon what most documented sources would suggest, in practice, it is best to select America/Puerto_Rico as the timezone to ensure the correct observance of daylight savings.

Other notes

...

• .

...