National Health Stack Open House Discussion #2 30th May 2020 - PowerPoint PPT Presentation

National Health Stack Open House Discussion #2 30th May 2020

iSPIRT Overview

iSPIRT Foundation: a non-profit Tech Think-and-Do Tank Driving 30-year Orbit Shifts • Think Tanks 30 yr Architects • Universities • Research Labs • VCs 10 yr Planners • Policy Makers • Incumbents 5 yr Doers • Challengers Powered by no-greed and no-glory volunteering!

National Health Stack Overview

NATIONAL HEALTH STACK [30th May 2020] GOVT & PRIVATE CONSUMER APPS/PORTALS HEALTH PROVIDER APPS/PLATFORMS APPS & PLATFORMS Diverse user experiences & Arogya e-Sanjeev Other HIMS/ Other OPD Teleconsult Innovation innovative solutions Setu Apps Apps ani Apps LIMS Platforms Private 3 OHSN: Open Health Services OHSN: Open Health Services Tele-Consult/OPD Care Fiduciary, Pharmacy, Network Network In-Patient Platforms Diagnostics Interoperable Market Players Interoperable Market Players Augmentation Layer PERCEPTRON/ Enhancing capabilities PROTOCOL SERVER MATCHING ENGINE DIAGNOSTIC BOTS of all actors Digital Public Infrastructure ELECTRONIC PERSONAL HEALTH ELECTRONIC CLAIMS Plumbing Layer REGISTRIES RECORDS SWITCH 1 Streamlining flow of Doctor registry E-prescription 2 patients, health Facility registry E-discharge summary E-claims information and money Procedure registry Diagnostic e-reports Ayushman Bharat Drug registry Consultation Records e-Vouchers ... ... ... JAM & INDIA STACK JAM & INDIA STACK Cross domain generic building blocks 5

National Health Stack Roadmap [30th May 2020] 1. Personal Health Records a. APIs and Sample Code - Released 23rd May b. Technical Q&A - 30th May c. HIP, HIU, Consent Manager Test Env go-live - 30th June d. Certifications start - start 27 July 2. Doctor Registry a. APIs - Release - 8th June b. Test Environment go-live - 15th June c. Registry go-live - 30th June 3. OHSN Teleconsultation a. APIs and Sample Code - 27th July b. Test Environment go-live - 5th Aug c. Certification start - 17th Aug

Personal Health Records Q&A, 30th May 2020

Q1. How does one connect to the network as an HIP, HIU, API Bridge, and Consent Manager?

Health Information Users (HIUs) Users Health Information Vault 1 Providers (HIPs) Vault 2 CM App 1 CM App 2 Data Bridge 3 Hosp 1 Hosp 4 Consent Managers (CMs) HIMS 1 HIMS 2 Data Bridge 1 Hosp 2 Hosp 5 LIMS 2 Lab 3 Lab 1 LIMS 1 Gateway Lab 2 HealthTech App Store Registry Data Bridge 4 Data Bridge 2 Clinic 1 Clinic 1 Aggregator Aggregator Software Software Hosp 4 Hosp 3 User Interaction Control flows (discovery, linking, consent) Lab 5 Lab 3 Information flow

Getting Started ● If you’re building an API Bridge for your HIPs and HIUs, you may adopt the following interfaces: https://github.com/ProjectEKA/projecteka.github.io/blob/master/contracts/bridge-v1.yml ● If you’re building a Consent Manager app for your Users, you may adopt the following interfaces: https://github.com/ProjectEKA/projecteka.github.io/blob/master/contracts/cm-v1.yaml ● You can get your own gateway up and running: ○ Open Source Codebase: https://github.com/ProjectEKA/gateway ○ Interfaces: https://github.com/ProjectEKA/projecteka.github.io/blob/master/contracts/gateway- v1.yaml ● You can use the Reference CM App as an API Bridge for HIPs & HIUs: https://github.com/ProjectEKA/Jataayu

Q2. How do the Registries for Consent Manager Apps and Bridges work?

Registries 1. Registries are a key building block for the Health Information Flows (HIFs) 2. Some registries are required for HIF as well as other use cases: a. Facility Registry (will include info about essential HIPs/HIUs like Hospitals, Labs) b. Health Service Provider Registry (will include info about HIPs/HIUs not covered in (a)) c. Doctor Registry d. … These are maintained by entities outside the HIF ecosystem 3. Some are required only for managing health information flows. These are maintained by gateway providers, one per gateway. a. CM App Registry b. Bridge Registry

Consent Manager (CM) App Registry Each Consent Manager App must register with a gateway to enable consented HIFs (e.g., personal health information sharing) CM registry schema: 1. CM ID: UUID used for addressing CM in all flows 2. CM Name: Name of the CM 3. CM Suffix: Suffix used by the CM in all User IDs issued by it (dns name format) 4. AccessURL: URL for sending API requests to this CM 5. PK Certificate: X.509 certificate w/ CM’s long-term public key; OCSP-enabled 6. isActive: Flag indicating whether CM is currently active or not 7. isBlacklisted: Flag indicating whether CM has been blacklisted from the network 8. Timestamp: registration time

Bridge Registry Each bridge must register with a gateway to participate in the HIF ecosystem Bridge registry schema: 1. Bridge ID: UUID used for addressing bridge in all flows 2. Bridge Name: Name of the Bridge Provider 3. AccessURL: URL for sending API requests to this Bridge 4. PK Certificate: X.509 certificate w/ Bridge’s long-term public key; OCSP-enabled 5. LinkedHIPs: List of HIPs who are connected to the bridge. // Private attribute 6. LinkedHIUs: List of IDs of HIUs who are connected to the bridge. // Private attribute a. When setting up link information, we need digitally-signed assertions from the HIP/HIU b. In future, we may add info about HITypes supported by HIPs 7. isActive/isBlacklisted: as defined for CM registry 8. Timestamp: registration time All CM Apps and Bridges must be certified before being included in registry.

Q3. What’s the approach for Schema Standardisation?

Schema Approach 3 1 2 s s s s s Three Approaches s Common Schema Embedded Schema Schema-Less Market Coordination HIGH LOW NONE Maintenance Cost HIGH HIGH LOW

Q4. Support for Multi-Lingual, Assisted Flows, Multiple Form Factors

Q5. With privacy in mind, are we planning to support use of Zero Knowledge Proof between HIPs and HIUs?

MeitY Consent Artefact v1 Compliant with the ORGANS Principles: O pen, R evocable, G ranular, A uditable, N otice, S ecure <consentcollector> CC </consentcollector> <dataconsumer> DC </dataconsumer> Identifier Section <dataproducer> DP </dataproducer> <user type=”UID” > 123412341ABC </user> <datatype type=”transactional” > <attribute-list> … </attribute-list> <duration> 6 months </duration> <datalife> 10 days </datalife> <frequency> YEARLY </frequency> Data Section <revocable> YES </revocable> <access> VIEW| STORE| QUERY </access> </datatype> <datatype type=”profile” > </datatype> Logging Section <loggingInfo> … </loggingInfo> Purpose of Data Access <purpose code=”” > LOAN </purpose> Signature Section <signature> #@%%#@$$##$@ </signature> 19

Q6. Can validated health data be stored in a more decentralised way on users device or user mapped cloud service ?

Health Information Users (HIUs) Users Health Information Vault 1 Providers (HIPs) Vault 2 CM App 1 CM App 2 Data Bridge 3 Hosp 1 Hosp 4 Consent Managers (CMs) HIMS 1 HIMS 2 Data Bridge 1 Hosp 2 Hosp 5 LIMS 2 Lab 3 Lab 1 LIMS 1 Gateway Lab 2 HealthTech App Store Registry Data Bridge 4 Data Bridge 2 Clinic 1 Clinic 1 Aggregator Aggregator Software Software Hosp 4 Hosp 3 User Interaction Control flows (discovery, linking, consent) Lab 5 Lab 3 Information flow

Q7. For a doctor who is my primary physician, shouldn't the person have access to my entire PHR rather than granularity? Or are both granular and macro scenarios taken care of?

MeitY Consent Artefact v1 Compliant with the ORGANS Principles: O pen, R evocable, G ranular, A uditable, N otice, S ecure <consentcollector> CC </consentcollector> <dataconsumer> DC </dataconsumer> Identifier Section <dataproducer> DP </dataproducer> <user type=”UID” > 123412341ABC </user> <datatype type=”transactional” > <attribute-list> … </attribute-list> <duration> 6 months </duration> <datalife> 10 days </datalife> <frequency> YEARLY </frequency> Data Section <revocable> YES </revocable> <access> VIEW| STORE| QUERY </access> </datatype> <datatype type=”profile” > </datatype> Logging Section <loggingInfo> … </loggingInfo> Purpose of Data Access <purpose code=”” > LOAN </purpose> Signature Section <signature> #@%%#@$$##$@ </signature> 23

Q8. How might public health researchers (among others) be able to access appropriately anonymized individual-level data?

Types of Health Data 1 2 3 Non Personal Personal Data Open Data Data Data Linked with Users Statistical Data Identity Data De-Linked from Users NDSAP Identity SriKrishna Data Protection MeitY Non Personal Data Bill Committee

Q9. What is the use-case for time limiting the access to data and how it be limited?