nha-abdm / abdm-enablers Goto Github PK

Ticket Contents

Why:
The last 3 years since the inception of ABDM have resulted in a lot of ABHA IDs getting created. While a lot of health records are getting linked, the efficacy of how much health data is actually visible to the user is still a question to be pondered upon. There are multiple challenges here: stability of gateway, lack of knowhow, technical challenges in implementation and so on. ABDM integration has been divided into 3 steps: M1- ABHA creation/ verification; M2- HIP initiated linking or user initiated linking and M3- Record fetch using consent management

However, implementing data fetch for a health information user (HIU) application has been observed to be a challenge. It takes a lot of time for the implementation and different integrators implement in different manners, which leads to inconsistency in user experience across systems. One of the reasons for uptake of UPI - was standardisation of payment, pay request and pin screens

What:
Standard consent management screens which could be rendered from any application via an iframe or using an API with a specific URL can be built which will make it easy for the integrators to implement M3 workflows.

How:
APIs in M3 workflows can be used from the ABDM integration process. For simplification, you can use the APIs as documented in the NHA ABDM wrapper workflows.

Goals & Mid-Point Milestone

Goals

• [1] Standard Consent Management Screen for a HIU
• [2] Show consent status and fetch the data from a HIU
• [3] Show the data in a structured format
• [4] Show analysis from the data obtained to the HIU
• [5] Dashboard to show consents raised vs approved vs data request sent vs data requests received for a HIU

Setup/Installation

Docker or JDK + Mongo DB
https://github.com/NHA-ABDM/ABDM-wrapper

Expected Outcome

1. Standardised consent management screen should be built which can be used by multiple entities (similar to UPI Pin screen)
2. The entire implementation should be specific to a consent which can be opened as a URL or an iframe kind of a solution
3. All the status should reflect as expected in the HIU solution
4. Data should be fetched and organized as per logical Health Information Types or Provider Information

Acceptance Criteria

1. consent management screen should be visible with all details as expected
2. One consent management screen is specific for a consent
3. Data should be fetched once consent is approved

Implementation Details

https://github.com/NHA-ABDM/ABDM-wrapper : The base of the system can be taken up from here.

Reference HIU from here can also be used. This can be built in any application programming language of the integrators choice.

Mockups/Wireframes

No response

Product Name

HIU consent management screens

Organisation Name

SamagraX

Domain

⁠Healthcare

Tech Skills Needed

Angular, cURL, Docker, JavaScript, Mockups, React, RESTful APIs

Mentor(s)

Venu Ajitesh
Raunaq Pradhan

Category

Analytics, Backend, Frontend, AI

Why:
60 Cr citizens of the country already have a digital health ID (aka Ayushmann Bharat Health Account). With India adopting UPI the way it did, the next goal is to simplify how citizens access and share health care data with their care providers. ABDM (Ayushmann Bharat Digital Mission) aims to provide the underlying framework or guidelines on how healthcare organisations can upgrade their systems to become ABDM compliant or new health tech startups can build their applications on top of ABDM. ABDM defines the framework for discovering services and enabling interoperability of data shared across systems. To enable this operability, FHIR (fast Healthcare interoperability resources) has been chosen as the standard for exchanging health data between two systems.

What it will accomplish?
2000+ integrators (i.e. healthcare organizations or technology service providers) are already on the verge of integration with ABDM. However, the number of successful integrations which are able to exchange data in a structured format is less than 3%. These entities find a lot of challenges in going through that learning curve of knowing about FHIR, and it takes a lot of time for the integration to get completed, or entities drop off in between when they encounter these challenges and don't get appropriate support.

The idea here is to build an open source tool for developers who can then use a template to send data, and the tool will automatically convert it into FHIR while sending data. While receiving data from any other ABDM compliant solution, the reverse flow needs to happen. Enabling data exchange in a structured format will ensure healthcare organizations are empowered to analyse the data - and provide better care to the patient.

Proposed Objective:
The objective of this project is to build a FHIR converter which provides the ecosystem an easy way to convert their data into a structured FHIR format (and reverse) along with values embedded from snomed CT.

Goals & Mid-Point Milestone

Goals

• [1] Understand and document the standard set of fields for each type of health record generated
• [2] Conversion of the template to FHIR formats as per ABDM
• [3] Validation of FHIR JSONs as per ABDM defined health information types (using a UI tool)
• [4] Reverse translation of the FHIR data into the template defined in step 1
• [5] Snomed CT codes for the data entered in FHIR JSONs to generate fully structured FHIR documents

Setup/Installation

https://www.nrces.in/standards/snomed-ct
https://www.nrces.in/ndhm/fhir/r4/profiles.html

Expected Outcome

The final product should have the following components:

1. Document entailing the standard set of fields chosen in each health information type defined by ABDM
2. Tool which can accept the data in the template of step 1 , and show the converted FHIR JSON or return it in an API format
3. UI for FHIR JSON validation

Acceptance Criteria

1. FHIR JSON converted should be fully visible in an ABDM compatible HIU or PHR App
2. Snomed CT codes should be present in the fully structured FHIR JSONs
3. These FHIR JSONs should also be validated in any of the tools mad available by NRCES, Amazon FHIR services or HL7 tools

Implementation Details

https://www.nrces.in/ndhm/fhir/r4/profiles.html
https://www.nrces.in/standards/snomed-ct
https://sandbox.abdm.gov.in/sandbox/v3/new-documentation?doc=PackagingHealthData

Mockups/Wireframes

NA

Product Name

FHIR converter tool

Organisation Name

SamagraX

Domain

⁠Healthcare

Tech Skills Needed

cURL, Database, Design, HTML, Java, JavaScript, Machine Learning, React, RESTful APIs

Mentor(s)

Venu Ajitesh
Raunaq Pradhan
(more to be provided from open source community)

Category

API, Analytics, Data Science, Documentation, Research, AI