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

30 yr Architects 10 yr Planners 5 yr Doers

• Think Tanks
• Universities
• Research Labs
• VCs
• Policy Makers
• Incumbents
• Challengers

iSPIRT Foundation: a non-profit Tech Think-and-Do Tank Driving 30-year Orbit Shifts

Powered by no-greed and no-glory volunteering!

National Health Stack Overview

5

NATIONAL HEALTH STACK [30th May 2020]

ELECTRONIC REGISTRIES

Doctor registry Facility registry Procedure registry Drug registry ...

PERSONAL HEALTH RECORDS

E-prescription E-discharge summary Diagnostic e-reports Consultation Records ...

ELECTRONIC CLAIMS SWITCH

E-claims Ayushman Bharat e-Vouchers ...

Plumbing Layer Streamlining flow of patients, health information and money OHSN: Open Health Services Network Interoperable Market Players GOVT & PRIVATE APPS & PLATFORMS Diverse user experiences & innovative solutions

JAM & INDIA STACK

JAM & INDIA STACK Cross domain generic building blocks PROTOCOL SERVER PERCEPTRON/ DIAGNOSTIC BOTS MATCHING ENGINE Augmentation Layer Enhancing capabilities

• f all actors

Digital Public Infrastructure Private Innovation

2 1

OHSN: Open Health Services Network Interoperable Market Players

CONSUMER APPS/PORTALS HEALTH PROVIDER APPS/PLATFORMS

Arogya Setu Other Apps HIMS/ LIMS Other Platforms e-Sanjeev ani

Tele-Consult/OPD Platforms In-Patient Care Fiduciary, Pharmacy, Diagnostics

OPD Apps Teleconsult Apps

3

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?

Lab 1 Lab 2 Gateway CM App 1 LIMS 1

Control flows (discovery, linking, consent)

Health Information Providers (HIPs) Clinic 1 Aggregator Software Hosp 1 Hosp 2 HIMS 1 Hosp 3 Data Bridge 1 Data Bridge 2 Lab 3 CM App 2 Consent Managers (CMs) Hosp 4 Hosp 5 HealthTech App Data Bridge 4 Clinic 1 Aggregator Software Hosp 4 Lab 5

Information flow

Health Information Users (HIUs) Lab 3 LIMS 2

Registry

Users HIMS 2

User Interaction

Vault 1 Vault 2

Store

Data Bridge 3

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?

HIGH LOW

Market Coordination

HIGH HIGH

Maintenance Cost

NONE LOW

Three Approaches

Schema Approach

Common Schema Embedded Schema Schema-Less

s

s s s s s

1 2 3

• 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: Open, Revocable, Granular, Auditable, Notice, Secure

<consentcollector> CC </consentcollector> <dataconsumer> DC </dataconsumer> <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> <revocable> YES </revocable> <access> VIEW| STORE| QUERY </access> </datatype> <datatype type=”profile”> </datatype> <loggingInfo> … </loggingInfo> <purpose code=””> LOAN </purpose> <signature> #@%%#@$$##$@ </signature> Identifier Section Data Section Logging Section Signature Section Purpose of Data Access 19

• Q6. Can validated health data be stored

in a more decentralised way on users device or user mapped cloud service ?

Lab 1 Lab 2 Gateway CM App 1 LIMS 1

Control flows (discovery, linking, consent)

Health Information Providers (HIPs) Clinic 1 Aggregator Software Hosp 1 Hosp 2 HIMS 1 Hosp 3 Data Bridge 1 Data Bridge 2 Lab 3 CM App 2 Consent Managers (CMs) Hosp 4 Hosp 5 HealthTech App Data Bridge 4 Clinic 1 Aggregator Software Hosp 4 Lab 5

Information flow

Health Information Users (HIUs) Lab 3 LIMS 2

Registry

Users HIMS 2

User Interaction

Vault 1 Vault 2

Store

Data Bridge 3

• 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: Open, Revocable, Granular, Auditable, Notice, Secure

<consentcollector> CC </consentcollector> <dataconsumer> DC </dataconsumer> <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> <revocable> YES </revocable> <access> VIEW| STORE| QUERY </access> </datatype> <datatype type=”profile”> </datatype> <loggingInfo> … </loggingInfo> <purpose code=””> LOAN </purpose> <signature> #@%%#@$$##$@ </signature> Identifier Section Data Section Logging Section Signature Section Purpose of Data Access 23

• Q8. How might public health researchers

(among others) be able to access appropriately anonymized individual-level data?

Types of Health Data

Personal Data

Data Linked with Users Identity SriKrishna Data Protection Bill

Non Personal Data

Data De-Linked from Users Identity MeitY Non Personal Data Committee

Open Data

Statistical Data NDSAP

1 2 3

• Q9. What is the use-case for time

limiting the access to data and how it be limited?

MeitY Consent Artefact v1

Compliant with the ORGANS Principles: Open, Revocable, Granular, Auditable, Notice, Secure

<consentcollector> CC </consentcollector> <dataconsumer> DC </dataconsumer> <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> <revocable> YES </revocable> <access> VIEW| STORE| QUERY </access> </datatype> <datatype type=”profile”> </datatype> <loggingInfo> … </loggingInfo> <purpose code=””> LOAN </purpose> <signature> #@%%#@$$##$@ </signature> Identifier Section Data Section Logging Section Signature Section Purpose of Data Access 27

• Q10. API Sequence Diagrams

Linking (with OTP-Based Auth)

Consent Flow: Consent Creation, part 1

Consent Flow: Consent Creation, part 2

Consent Flow: Sending artefact to HIP

Consent Flow: Sending Revocation notification to HIP

Data Flow

Health Stack Registries

30th May 2020

36

Health Stack Electronic Registries

Mechanism for managing master data about different entities in the healthcare ecosystem. Facility Registry: master data for all facilities that offer healthcare services Doctor Registry: master data for all medical professionals Beneficiary Registry: master data for all scheme beneficiaries like PMJAY, ESI

Trusted, non-repudiable data Self-maintainability Open APIs Consented data sharing

Data Store

With Added Features:

37

Entities that need to be identified in a Healthcare Interaction

The National Digital Health Blueprint outlines the following entities that will be part of various Registries / Directories

○

Person – Patient, Family Member, Beneficiary

○

Care Professional – Doctors, Nurses, Lab Technicians, ASHA workers etc.

○

Care Provider – Hospital, Clinic, Diagnostic Centre

○

Payer – Insurer, Health Plan, Charity

○

Governing Bodies – Ministry, Professional bodies, Regulator

○

Research Bodies – Researcher, Statistician, Analyst

○

Pharmaceuticals – Drug, Device Manufacturers and Supply Chain players

○

Health Technology Companies -- HIMS, LIMS Suppliers

38

Design Principles for Registries

Self Maintainable

Entities can enroll and update information in the registry

Non Repudiable

Source of every attribute is visible All changes are digitally signed

Layered Access

Clear demarcation of Public and Private data. Consent based access for Private data

Extensible Schema

Only minimal data in registries Ecosystem players provide extended data

Open APIs

Public data in registries will be accessible via Open APIs. Some APIs will be available to accredited partners

Incentive Aligned

Ensure adoption for use cases that keeps the data up to date

39

Designed to allow ecosystem to add Layered Information

Layer 1: Doctor Registry Demographics, Medical Registrations, Education Contact Info Managed by the Government Layer 2: Enhanced Doctor Registry Work Hours, Consultation Price, Ratings … Managed by an ecosystem player Application 1 Application 2

Consistent API Signatures Extensible Schema Structure

Ensuring High Quality Master Data takes effort

Doctor Registry

Demographics

• Name, Year of Birth, Gender

Contact Information

• Mobile, Email

PAN Card (for eSign issual)

• PAN Number

Medical Registrations

• Medical Council, Registration No, Issue Date

Medical Education

• College Name
• Degree / Diploma
• Year

…

Verified by using Aadhaar eKYC (UIDAI) Verified via OTP (SMS / EMAIL GW) Verified via NDSL APIs Initially verified using uploaded

• certificate. Integration with State

Medical Councils and establish verification process. Master List of Colleges required (Facility Registry) No Master List for Degrees / Diplomas

Incentive Alignment is key to Adoption

How does the entity benefit from the registry? What incentives will ensure they are motivated to keep information up to date?

Doctor Registry will enable doctors to easily participate in the digital health ecosystem

Digitally eSign prescriptions, diagnostic reports, discharge summaries and eClaim (Insurance documents) from their phone or web Verified Symbol in online apps Collect CME points online Get Online services from State Medical Councils eKYD (Know your Doctor) helps doctors obtain professional indemnity insurance digitally

Doctor Registry APIs as an example

APIs for Developers

Get Public Information APIs that applications can use to search and lookup public information and verification status of a doctor eKYD (know your doctor) APIs Applications that plan to have the doctor eSign documents via their application would use this API. Consented access from the doctor is required for any information to be shared. eSign APIs Allows partner applications to rapidly eSign Claim forms, discharge summaries, prescriptions, etc OnBoarding APIs Used to help doctors to enroll themselves into the registry from an application

Next Open House Discussion

Clarifications Doctor Registry, PHR

• 11:30 AM to 12:30 PM, 6th June 2020
• Please Register Here: https://bit.ly/NHS-OHD (Technical Session)

44

Thank You