...
During onboarding, 2 DNS names and one set of credentials will be provided to you. One is the DNS name of your dedicated bastion host to access the replica via SSH. And the other is the DNS name of the read replica itself with the AWS VPC. For this example, let's pretend these DNS name are as follows:
| Customer Bastion Host | customer-replica-bastion.clinspark.com |
|---|---|
| Customer Read Replica (private DNS) | customer-replica.crs8xf7ezw7g.us-east-1.rds.amazonaws.com |
| Read Replica Username | <username> |
| Read Replica Password | <password> |
To connect to his replica via the command line, the steps are as follows:
- Create a SSH key you will use to access the DB through the bastion. If you already have one that's fine. Here are instructions for doing this and also adding the key to the ssh-agent.
- Provide Foundry Health with the public SSH keys of users who need access to this database. We will place this on the bastion, allowing these users to tunnel into the replica. Open a service ticket with the public key attached and we'll get this installed quickly.
- Verify you have access by connecting to the bastion and replica as follows from the command line:
__| __|_ ) _| ( / Amazon Linux AMI ___|\___|___|[ec2-user@ip-172-31-17-113 ~]$ mysql -u <username> -h customer-replica.crs8xf7ezw7g.us-east-1.rds.amazonaws.com -p<password>Warning: Using a password on the command line interface can be insecure.Welcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 262Server version: 5.6.22 MySQL Community Server (GPL)Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql> |
The above shows a terminal session where the user has first added the private ssh key to the ssh-agent as described in the previous link. The user connects to the bastion, and from there is able to use the mysql client to interact with the replica directly from the bastion.
You
...
may want to establish a SSH tunnel between your local workstation and the replica through the bastion. This is a common usage pattern, see your SSH client of choice documentation for instructions on how to configure this.
| Info |
|---|
The above approach is appropriate if only one or two trusted users will access the bastion. It is secure as long as the private keys are secured. Customers with more users will want to find more scalable ways to access the replica data. One could be a SSH persistent tunnel on the customer site, and used by other users at the site. AWS has a variety of options for this. See AWS VPNs and Direct Connect, which are two mechanisms to securely connect your sites to your own AWS account. From there a variety of options exist, including AWS PrivateLink to create secure connections between AWS accounts. It is the customer's responsibility to select and configure any options such as the above. Foundry Health will assist by suggesting approaches and making required configurations on our end. But the majority of the setup is in customer-owned infrastructure, and for this the customer is solely responsible. |
Clinical Data Interchange Standards Consortium Standard (CDISC)
<TODO: Round this part out>
To the maximum extent possible, the ClinSpark data model is based on the CDISC Operational Data Model (ODM) standard. Introduce CDISC ODM.
...
The following section highlights a series of key subject areas within the ClinSpark data model. Where elements are defined within the CDISC ODM standard, the descriptions from this documentation are used.
These entity diagrams and the relationships between them should help readers understand what can be found in tables and also how tables can be joined using SQL.
Study Design
...
The following subject areas are involved with study design.
Org, Volunteer, Study, Sites, StudySites an Subjects
| Table | From CDISC? | Notes | ||
|---|---|---|---|---|
| 1 | studyorg | Yes | No | An org represents an entity performing clinical research (CRO / CRU). Orgs can have multiple sites that execute studies. |
| 2 | study | Yes | This element collects static structural information about an individual study. A study is related to a given clinical trial protocol.2 | |
| 3 | site | No | A site is a physical place belonging to an organization. An organization having multiple physical clinical sites will have multiple site rows. | |
| 4 | study_site | No | An association between a physical site and a study. A study site is different than a physical location. Often, pharma sponsors will specify sites with arbitrary codes and those codes must pass through during data export time. In addition, this domain encapsulates recruitment efforts for a given study / site. | |
| 35 | sitevolunteer | No | A site is a physical place belonging to an organization. An organization having multiple physical clinical sites will have multiple site rows.4volunteer is someone who indicates that they are interested in participating in clinical research for the given org. | |
| 6 | subject | No | Someone participating in clinical research within the context of a given study. Creates glue between the volunteer and the participation. |
...
An activity plan is a schedule of events for a given cohort. Activity Plans do not appear in CDSIC, there is no similar construct in the ODM to capture this concept. Activity Plan, Segment and Scheduled Activity are ClinSpark specific.
| Table | From CDISC? | Notes | |
|---|---|---|---|
| 1 | Study | Yes | This element collects static structural information about an individual study. A study is related to a given clinical trial protocol. |
| 2 | Activity Plan | No | A schedule of events for a given cohort. Plans can be assigned to multiple cohorts. A timed plan must have a reference time in order to properly provide UI feedback as segments and scheduled activities are set. Untimed Activity Plan:
|
| 3 | Segment | Partially | Holds a group of scheduled activities in an activity plan. The segment's offset seconds is essentially the time of the reference event, all scheduled activities are relative to this. Modeled somewhat of off CDISC SDM: "Segments are often seen as the basic building blocks of study design. A segment usually specifies a combination of planned observations and interventions, which may or may not involve treatment, during a period of time." |
| 4 | Scheduled Activity | No | Wraps a form, but adds metadata including timing. |
| 5 | Form | Yes | A form is basically a container for item groups. |
| 6 | Study Event | Yes | A study event represents a given 'visit'. In phase 1 trials this will commonly simply refer to a 'day'. When scheduling forms for a given schedule, the builder must associate the study event. Note: there are common study events that are typically reserved for special events: unscheduled, common (AE, CM), etc |
...
| Table | From CDISC? | Notes | |
|---|---|---|---|
| 1 | item_data | Yes | A piece of collected data. Note that lab orders and all results are associated to a given Item Data. You will need to join through Item Data when working with lab data. |
| 2 | base_specimen | Yes | Modeled off of CDISC Lab. A specimen is collected from a subject and assigned to a given item data instance. There can be multiple batteries (test groups) associated to a given specimen. Combines Accession Level and Base Specimen from spec. |
| 3 | base_battery | No | A panel related to a specimen - typically this is just a 1:1. |
| 4 | base_test_result | Partially | Combines CDISC Lab BaseTest and BaseResult. These are the results from the lab. |
| 5 | lab_order | No | When specimens are collected, this domain represents that an order is generated. It causes a manifest file to be created (PDF) and potentially a file order to be dumped on to the file system and made available to web services. |
| 6 | lab_interface | No | Encapsulates how to send and receive orders and results from a particular safety lab. Sites may have multiple labs, and if so each of these will have their own lab interface instance. |
| 7 | study_lab_panel | No | Something that can be ordered from item level |
| 8 | specimen_container | No | When setting up samples or labs, users can optionally choose a container. |
| 9 | lab_repeat | No | A domain that allows for the management of lab repeat workflows |
Volunteers
Volunteers are not a part of the CDISC. We need to show a path to volunteer data and associated medical histories, medications, etc.
| Table | From CDISC? | Notes | |
|---|---|---|---|
| 1 | volunteer | No | Someone who indicates that they are interested in participating in clinical research for the given org.Someone who indicates that they are interested in participating in clinical research for the given org. |
| 2 | volunteer_medical_condition | No | Associates a given condition to a given volunteer |
| 3 | volunteer_note | No | A simple note that can be attached to the volunteer record |
| 4 | volunteer_correspondence | No | Represents a call or text to / from a volunteer by way of Twilio |
| 5 | volunteer_substance_use | No | We purposely don't track SUOCCUR, it allows us to indicate that the vlunteer is not using the substance. |
| 6 | recruitment_appointment | No | Allows for a given volunteer to be assigned to a given time slot |
| 7 | study_site | No | An association between a study and a site |
| 8 | subject | No | Someone participating in clinical research within the context of a given study. |
...