Account Management Overview
LifeOmic is a software-as-a-service (SaaS) platform hosted on Amazon Web Services (AWS). LifeOmic uses a multi-tenant architecture to offer near-infinite resource capacity when using the platform through the Application Programming Interface APIs.
In multi-tenant architecture, customer data is logically partitioned and segregated by software into the database via a Unique Account Identifier (Unique Identifier) associated with every piece of data.
Access to an account’s data is restricted to permissions granted to users.
Billing and usage tracking is rolled up by account.
This is a standard pattern used by cloud infrastructure and SaaS providers.
Account (organization) and User Entity Relationship Diagram
Terms
Person - A Person is a human being who uses the platform (such as a researcher, clinician, administrator, or patient).
User - Users represent people who are using the platform and provide authentication, demographic, and contact information. Users are not owned by accounts, and a single user may have access to multiple accounts via group membership.
Account - An account is the top level organizational structure for the platform. Typically each organization would have a single account. Accounts store the billing/payment method for an organization and are used by the platform to bill for usage.
Group - Groups live inside an account and are the primary mechanism of binding a user to an account and giving the user access to data in the account.
Policy - ABAC (Attribute Based Access Control) policies control what groups have access to what projects in an account. Policies live inside an account.
Project - Projects form an organizational structure under an account and also provide a finer grained breakdown of usage for internal accounting inside an organization. Projects are the typical granularity for access control. Projects are also used to aggregate storage costs up to an account. In our APIs, "dataset" is synonymous for "project".
Cohort - Cohorts are basically a saved search. They provide a way to pull in data from multiple projects and subsets of projects. Typically, cohorts do not result in data copies or extra storage costs (except for ephemeral data used for analysis).
Data - Data are all the various pieces of data about patients that are stored in the platform. Data can be just about anything. Some examples: Patient, Observation, Condition, Procedure, Medication, Image, ClinicalReport, BAM File, VCF File, and others. Data is stored inside a project within an account.
Patient - A Patient resource is a type of data that stores the demographic information for a Person as a research subject, patient, customer or employee in a project within an account.
User and Patient Mapping
The Precision Health Cloud has two representations of people:
- Users - these are people who can log into the PHC and interact with it: employees, partners, or customers/subjects/patients.
- Patients (aka Subjects) - these are people whose health data is tracked by the PHC. A Patient resources does not, by itself, give a person any access to the PHC.
A User can be mapped to a Patient (via an invitation, see below) so that you can have a person who both signs into the PHC and has their health data stored in the PHC. When a User is mapped to a Patient, this grants the User access to the data for the Patient via an ABAC policy associated with the Subjects group. The Subject Access policy and Subjects group are created automatically by the PHC. When a User is mapped to a Patient the User record also provides a way to send notifications to the person via email (using the email address on the User record) or push notifications (via the LIFE Extend mobile application).
User records are created automatically when someone signs up for the PHC and can be associated with an account via an invitation. The two types of invitations are:
- Account Invitation - This simply adds a User to a Group when the person accepts the invitation. The User has whatever access is granted to the group via an ABAC policy.
- Project Invitation - This works like an Account Invitation but also maps the User record to a Patient record in a particular Project. The group for Project Invitations is always the Subjects group.
For both types of invitations the person being invited will receive an email directing them to signup or login and accept the invitation. See Groups for a step-by-step guide to inviting users.
Masked Mode
Masked Mode allows users to review genotype and phenotype data for patients/subjects while making it reasonably difficult to violate the subject's privacy.
- By default, most personally identifiable information is masked from view.
- Masked Mode can be toggled on with icon and off with icon using the eye button in the top right corner of the screen.
- The ABAC privilege named
Read Masked Data
can be used to force a set of users into masked mode.
Masked mode is not de-identification. Instead masked mode is a "reasonable effort" at making it difficult to determine the identity of a subject and to maintain the privacy of the subject from casual observers. Masked data should still be consider Personal Health Information under HIPAA.
Masked mode specifically does the following to Patient records:
- Human names are converted to initials.
- All fields other than use, type, district, state, postal code, and country are removed from all addresses.
- All identifiers are removed other than ones labeled
ANON
under thehttp://hl7.org/fhir/v2/0203
system. - Day of the month and times are removed from all birth dates, and month is removed from all birth dates for subjects over two years of age.
- Text narrative, telecom, photo and contact person information are removed.
- The following top level extensions are removed:
hl7.org/fhir/StructureDefinition/birthPlace
hl7.org/fhir/StructureDefinition/geolocation
hl7.org/fhir/StructureDefinition/patient-birthTime
hl7.org/fhir/StructureDefinition/patient-mothersMaidenName
http://standardhealthrecord.org/fhir/StructureDefinition/shr-entity-FathersName-extension
http://standardhealthrecord.org/fhir/StructureDefinition/shr-entity-SocialSecurityNumber-extension
http://standardhealthrecord.org/fhir/StructureDefinition/shr-entity-DriversLicenseNumber-extension
http://standardhealthrecord.org/fhir/StructureDefinition/shr-entity-PassportNumber-extension
http://standardhealthrecord.org/fhir/StructureDefinition/shr-demographics-FathersName-extension
http://standardhealthrecord.org/fhir/StructureDefinition/shr-demographics-SocialSecurityNumber-extension
http://standardhealthrecord.org/fhir/StructureDefinition/shr-demographics-DriversLicenseNumber-extension
http://standardhealthrecord.org/fhir/StructureDefinition/shr-demographics-PassportNumber-extension
- All other data on Patient records and other record types are not altered.
Access Control
For information on Access Control, see Access Control.
Account Deletion
The LifeOmic Core API exposes an endpoint for deleting an account and all data
associated with the account. This operation can only be requested by a user that
has the accountAdmin
ABAC action for the given account. The account data will
not be deleted until after a 14 day grace period. The account API resource
will be updated to indicate the date timestamp for when the deletion will occur.
{
"id": "lifeomic",
"name": "LifeOmic Research",
"owner": "research@email.lifeomic.com",
"type": "ENTERPRISE",
"status": "ACTIVE",
"deletionDate": "2018-07-02T19:36:00.683Z"
}
During the 14 day grace period, a user will be able to continue accessing data from the account and can also remove the pending deletion from the account.
After the 14 day grace period, the following is a list of all known account related data that will get deleted as part of this operation:
- Files, projects
- FHIR resources
- Invitations
- Account, Custom Auth Clients, ABAC policies
- Variant Sets, Read group Sets, Expression data sets
- Analytics data
- ML data
Project Deletion
The LifeOmic Core API exposes an endpoint for deleting a project and all data
associated with the project. This operation can only be requested by a user that
has the projectAdmin
ABAC action for the given project. The project data will
not be deleted until after a 14 day grace period. The project API resource
will be updated to indicate the pending deletion along with a date timestamp for
when the deletion will occur.
{
"id": "uuid",
"name": "Germline Sequencing",
"description": "Indexed VCF and BAM files from a sequencing project.",
"status": "PENDING_DELETION",
"deletionDate": "2018-07-02T19:36:00.683Z"
}
During the 14 day grace period, a user will be able to continue accessing data from the project, and can also remove the pending deletion from the project. Applications like the PHC web app will display warnings for projects that are pending deletion by showing the time remaining in the 14 day period.
The following is a list of all known project related data that will get deleted as part of this operation:
- Files
- FHIR resources
- Variant Sets, Read group Sets, Expression data sets
- Analytics data
- ML data
The delete project API will provide an override that will forgo the 14 day grace period, and all project related data will be deleted as soon as technically possible.
User Deletion
The LifeOmic Core API exposes an endpoint for deleting a user. This operation
can only be requested by the same user. If the user is pending deletion, clients
can decode the access token and check for the deletion_date
claim to see if
the user is pending deletion and display the appropriate warnings to the user
and allow them to remove the pending deletion.
{
"sub": "uuid",
"cognito:groups": ["us-east-uuid_Google"],
"token_use": "access",
"scope": "phone openid profile email",
"auth_time": 1527763897,
"iss": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_uuid",
"exp": 1527767497,
"iat": 1527763897,
"version": 2,
"jti": "f4766f73-b376-48de-b6e3-38857d63uuid",
"client_id": "id",
"username": "Google_username",
"deletion_date": 1527763897
}
After the 14 day grace period, the following is a list of all known user related data that will get deleted as part of this operation:
- User group memberships
- User profile in Cognito
- LIFE data
Notifications
For each of the delete scenarios, email notifications will be sent at the following times:
- When the account/project/user delete request was initiated.
- A few days before the account/project/user will be deleted.
- After the account/project/user has been deleted.
For deleted accounts and projects, emails will be sent to the address specified
in the owner
field of the account resource. Users will be emailed directly for
user deletions.