Product: INSPIRE Platform

시작하기. 무료입니다
또는 회원 가입 e메일 주소
Product: INSPIRE Platform 저자: Mind Map: Product: INSPIRE Platform

1. Paradigms

1.1. Inspire Network Focus

1.1.1. **Product focus:** the emphasis is on building the platform?

1.1.2. **Research Focus:** "research question", "develop tools to support the research"

1.1.3. **Training Courses**: focus on developing and delivering training courses as a product?

1.2. Team topologies

1.2.1. **Collaboration:** working together for a defined period of time to discover new things (working on a common research question, data analysis, practices, technologies, etc.)

1.2.2. **X-as-a-Service:** one team provides and one team consumes something “as a Service”

1.2.3. **Facilitation:** one team helps and mentors another team

2. INSPIRE NETWORK COMPONENTS

2.1. Partners

2.1.1. APHRC

2.1.2. LSHTM

2.1.3. MUBAS

2.1.4. CODATA

2.1.5. SAPRIN

2.2. Research

2.2.1. Use of OMOP for C19

2.2.1.1. OMOP for IDSR data

2.2.2. Mental Health Research?

2.2.3. Gender and C19

2.2.4. HIV (ALPHA, IeDEA and clinical services

2.3. Data Services

2.3.1. ETL to OMOP

2.3.1.1. Data Standardization

2.3.1.2. ETL pipeline

2.3.2. Metadata and vocabularies

2.3.3. Data Preparation

2.3.3.1. Data anonymization

2.3.3.2. Data profiling

2.3.4. Data Quality tools

2.3.4.1. Data profiling

2.3.5. Data Analysis

2.3.5.1. Defining Cohorts

2.3.5.2. Characterisation studies

2.3.5.3. Prediction studies

2.3.6. Training

2.4. Infrastructure

2.4.1. Components

2.4.1.1. Database System

2.4.1.1.1. We use Postgresql which is powerful and open source, but it does require effort to deploy in a distributed manner

2.4.1.2. Data Storage

2.4.1.2.1. At the moment we use one dedicated server for data storage and applications.

2.4.1.3. Data Catalog

2.4.1.3.1. NADA catalog is being deployed?

2.4.1.4. Inspire Network Website

2.4.1.4.1. Website developed in house managed by MUBAS

2.4.1.5. Development environment

2.4.1.5.1. Sub-components

2.4.1.5.2. Current Setup

2.4.1.6. Security

2.4.1.6.1. Users and access

2.4.2. Options

2.4.2.1. Infrastructure

2.4.2.1.1. Self Managed Server

2.4.2.1.2. Cloud Based

2.4.2.2. IT Capacity

2.4.2.2.1. Capacity is developed within the Partners

2.4.2.2.2. The IT Development is outsourced

2.4.3. Best Practice

2.4.3.1. Services/end products determine the technology to be used

2.4.3.1.1. Does it support the project's workflow?

2.4.3.2. Order of Magnitude Rule

2.4.3.2.1. Is it scalable?

2.4.3.2.2. Does it require hardware management?

2.4.3.3. Experiment and Test

2.4.3.3.1. Small / piecemeal tasks are completed and made available through experimentation and testing

3. Platform Types

3.1. Data Platforms

3.1.1. **Principles**

3.1.1.1. Consist of storage space, managed databases, analytics notebooks, spark clusters and other apps to glue data together.

3.1.1.1.1. In-house

3.1.1.1.2. In the cloud

3.2. Platform as a Service

3.2.1. **Principles**

3.2.1.1. A platform and environment to allow developers to build applications, defined databases etc.

3.2.2. An alternative is **Data as a Service**

3.2.2.1. In the context of OMOP, it will provide data services such as: OMOP conversion, vocabulary mapping, development of analytical software

3.3. DATA MESH

3.3.1. **DATA MESH principles**

3.3.1.1. **Domain-driven ownership of data**: data is broken down specific domains, it is descentralised

3.3.1.1.1. Data meshes are organised in nodes which are data products (a database, a microservice, an application)

3.3.1.2. **Data as a product**: data producers are solely responsible of that data, its quality, its representation, its cohesiveness.

3.3.1.3. **A self-serve data platform**: data is available everywhere ion the platform pulled from where it resides to the database or a reporting system of a user

3.3.1.4. **A federated computational governance:** data is governed wherever it is

3.3.2. **Recommended Infrastructure**

3.3.2.1. Serveless Cloud

3.4. Hub-and-spoke

3.4.1. **Hub-and-spoke principles**

3.4.1.1. A central data team, or center of excellence (the “hub”). This team owns the data platform, tooling and process standards

3.4.1.2. The critical link is the Data Model

3.4.1.3. The user domain teams (the “spokes”) own the data products for their domains.

4. Users

4.1. Partners and funders

4.1.1. INSPIRE Network partners

4.1.2. INSPIRE Network members

4.1.3. IDRC / Wellcome Trust

4.2. Data Holders

4.2.1. HDSS

4.2.2. INSPIRE Partners

4.2.3. Ministries of Health

4.3. Data Consumers

4.3.1. Data Analysts

4.3.1.1. Derive insights from data using queries and visualisation

4.3.2. Data Scientists

4.3.2.1. Use and/or develop data models using statistics and ML

5. DATA MESH: "There is a fair bit of infrastructure that needs to be provisioned and run; the skills needed to provision this infrastructure are specialized and would be difficult to replicate in each domain. Most importantly, the only way that teams can autonomously own their data products is to have access to a high-level abstraction of infrastructure that removes complexity and friction of provisioning and managing the lifecycle of data products. This calls for a new principle, Self-serve data infrastructure as a platform to enable domain autonomy." https://martinfowler.com/articles/data-mesh-principles.html

6. Partners Profiles

6.1. Role

6.1.1. What role does it play in the network/projects?

6.1.2. What interests/expectations does the partner have in the network/projects?

6.2. Resources

6.2.1. What resources can the partner bring: data, systems, influence?

6.2.2. People: what kind of interests and skills?

6.2.3. Ensuring use of resources that safeguards ownership and intellectual property

6.3. Benefits

6.3.1. For the project?

6.3.2. For the partner

6.3.2.1. Visibility

6.3.2.1.1. Research output

6.3.2.1.2. Networking

6.3.2.1.3. Training and skills

6.3.2.1.4. Product deveopment

6.3.2.2. Research output

6.3.2.2.1. Peer reviewed publications

6.3.2.3. Capacity building