beckn/dhp-specs

Decentralized Health Protocol (DHP) Open API Specifications. DHP is an ambitions open source project that aims to define interoperable protocol specifications for creating decentralized network of health and wellness services including tele consultation and various other services.

Decentralized Health Protocol (DHP) Open API Specifications

Latest Release

0.7.1 | December 28th 2021

Current Working Draft Version:

0.7.2-draft

Versioning Scheme

Semantic Version Scheme 2.0.0

Releases

DHP Specification Version	Beckn Protocol Core Specification Version
0.7.1	0.9.3
0.7.0 (Baseline Version)	0.9.3-draft

Decentralized Health Protocol (DHP) is an ambitions open source project that aims to define interoperable protocol specifications for creating decentralized network of health and wellness services including tele consultation and various other services.

DHP architecture allows someone to setup an open network of consumer side applications and provide side platforms using common protocol specifications. DHP is maintained by the open source community to create API specifications, schemas and taxonomy for health and wellness domain.

Please see documentation for understanding purpose, architecture, and the actual APIs.

Participate in the Github discussions and Discord Community to leverage DHP as well as to contribute towards development of DHP by providing ideas, reporting issues, contributing to documentation, and contributing code.

dhp-specs's Issues

Enhance specs to have a person as a fulfiller of item instead of agent

Allow dynamic consent to be transmitted to allow distributed data sharing between network participants

Enhance specs to have multiple fulfillers for single item to support group consult

Enhance specs to have multiple fulfillers for single item to support group consult

Add Design Principles

We need to add Specification Design Principles

Digital OPD flows have non-standard fields and errors in context header structure

Allow dynamic consent to be transmitted to allow distributed data sharing between network participants

Health and wellness service booking and fulfillment often require sharing of medical history and prescriptions. To allow consented sharing of such data, there is a need for a consent framework to be baked into the architecture of the protocol to allow transmission of a consent request from a data consumer containing the information needed and the purpose of the request. As a response, the data owner should be able to provide a consent token to the data consumer. Upon receiving the token, the data consumer should be able to access the requested information for a specified period of time.

Add Gateway setup documentation in Getting Started wiki

Setting up development environment

Name: Decentralized Health Protocol
Title: "Setting up development environment"
Labels: C4GT Community

---

Description

Problem:
Development environment not set up.

Goals
• Development environment should be set up and tested for below requirements.
o Open API 3.0
o JSON Schema
o NodeJS
o JavaScript
o TypeNative
o MongoDB
• A basic “Hello World” program to be created and executed successfully.
• Database access and CRUD operations to be performed.
• Any required plugin should be installed and tested.
• Postman to be installed and tested with dummy APIs. (https://dummyjson.com/)

Expected Outcome
• Development environment up and running without any errors.

Acceptance Criteria
• Sample program runs without error.
• Database is accessible and can be used for CRUD operations.
Implementation Details
Mockups / Wireframes

---

Project
Beckn

Organization Name:
Beckn Open Collective

Domain
Others

Tech Skills Needed:
• Basic level software installation
• Basic level programming

Mentor(s)
Faiz Mohammed

Complexity
Low

Uhi

[C4GT] Implement DHP Sandbox API for Health and Wellness - use cases and upgrade to core v1.1.0

Description

As part of this project, we require the developer to develop comprehensive use cases for health. These use cases will serve as essential building blocks for the development of the system, outlining its functionalities, user interactions, and expected outcomes. The use cases will play a crucial role in ensuring the project meets its objectives of empowering users to use the app by taking care of all possible outcomes.

Goals

• List down all the different workflow possibilities for health.
• For each possibility, come up with a use case and the parameters it depends on.

Expected Outcome

Create a use case document, with all the different different options that are available in the domain, along with the different scenarios in each use case.

Acceptance Criteria

• Create a use case document, with all the different different options that are available in the domain
• Note down the different scenarios in each use case.

Implementation Details

NA for this issue

Mockups / Wireframes

NA for this issue

---

[Please note that the below section of the ticket has to be in the format as mentioned as it is key to enabling proper listing of the project. Please only choose the options mentioned under the headings wherever applicable.]

Product Name

Beckn

Project Name

Beckn Mobility Sandbox

Organization Name:

Beckn

Domain

Healthcare

Tech Skills Needed:

[Required technical skills for the project]

Mentor(s)

@shenoyninad

Complexity

Medium

Category

Documentation

Sub Category

API

Add Documentation for Getting Started using DHP

Update Folder Structure for Network Participant (NP) Logs

Issue Details:

Problem Statement:

The current folder structure lacks organization for Network Participant's implemented examples, making it challenging to manage and locate specific workflows implemented by NPs.

Proposed Solution:

Update the folder structure to include a dedicated "NP Logs" directory, with subdirectories for each Network Participant. Each NP directory should contain subdirectories for specific workflows (e.g., search, select).

Benefits:

• Improved organization and clarity for NP examples.
• Simplified navigation and maintenance of NP-related workflows.
• Improved Collaboration: Any new Network Participant (NP) joining the project will have ready-made references available on how other NPs have implemented specific use cases.
• Enhanced Documentation: Documenting the logs will contribute to better spec governance, compliance, and transparency. It will also serve as a valuable resource for building test cases for Network Validation.
• Knowledge Transfer and Training: The documented logs can be utilized for training AI models in the future, aiding in the generation of use-case-specific JSONs. This promotes knowledge transfer and ensures a valuable resource for future development.

Current Folder Structure:

• API
• Docs
• Examples

Proposed Folder Structure:

• API
• Docs
• Examples
• NP Logs
  • Network Participant Name
    • search
    • select

Additional Information:

• Consideration for future NPs can be made by creating subdirectories accordingly.
• Ensure backward compatibility with existing examples during the migration.

Enhance specs to introduce track & on_track APIs

Add Protocol Governance

Enhance README with Folder Descriptions

Description:

We would like to improve the clarity and transparency of our repository by adding a small section to the README file that provides descriptions for the different high-level folders present. This will help users understand where to find specific information within the repository.

Required Changes:

---

Repository Directory

Below are the details about the different high-level folders present in the repository and content they have.

1. NP Logs

Description: Contains Network Participant's logs aimed at enhancing spec governance, compliance, and transparency. Explore this folder to gain insights into the implementation from network participants.

2. api

Description: Contains domain-specific API specifications in YAML format. This folder also includes a submodule that points to a particular version of the core specification. Developers and contributors can refer to this section for comprehensive API details and the underlying core specifications.

3. docs

Description: This folder serves as a documentation hub, covering various aspects of our project. It includes an introduction to the domain, related terminology, details about the project's scope and out-of-scope elements, implementation guides, and assets used across these documents. Users can refer to this section for a holistic understanding of our project.

4. example

Description: Contains JSON examples of all the APIs, including but not limited to search, select, init, confirm, etc. Each sub-domain is represented with its respective API examples. Developers can use these examples as templates or references when implementing specific features, ensuring consistency and accuracy across the project.

---

Expected Outcome:

Users visiting our repository should have a clear understanding of the purpose and contents of each folder, making it easier for them to locate the information they are seeking.

Additional Notes:

Feel free to contribute to this issue with any suggestions or improvements on how we can enhance the folder descriptions for better user navigation.

Add Protocol Governance

Need to Add Governance Model for DHP.

[C4GT] Implement DHP Sandbox API for Health and Wellness

[C4GT] Implement DHP Sandbox API for Health and Wellness

Project Details

Beckn protocol is a set of open specifications aimed to create a common language, that is machine-readable and enables interoperability for economic transactions between disparate platforms of any size and form - be it a cab reservation, or booking a stay, or confirming a doctor’s appointment, and many more. Thus it enables the creation of inclusive and equitable open networks offering a multitude of choices to the citizens, while at the same time negating the dependence on intermediaries to freely operate and generate economic transactions of value. It is akin to what SMTP is to E-mails or HTTP is to the Internet.

Since its inception in 2019 as a set of specifications, Beckn has been adopted across geographies in sectors such as mobility, retail, hyperlocal logistics, healthcare, skills, agriculture sectors, etc. Few notable examples of open networks built on the Beckn protocol are Open Network for Digital Commerce (ONDC), Namma Yatri at Bangalore, Kochi Open Mobility Network (KOMN), Unified Health Interface (UHI), etc.

Decentralized Health Protocol (DHP) Open API Specifications. DHP is an ambitions open source project that aims to define interoperable protocol specifications for creating decentralized network of health and wellness services including tele consultation and various other services. The Beckn Health Interface is an API that emulates the behaviour of an Open Health and Wellness Networks compliant to DHP Specifications. BAPs can build rich integrated experiences by combining services offered by multiple BPPs on the network. BPPs can build complex products by analyzing the nature of input from multiple BAPs. This is an important step in the set up and expansion of open networks. Businesses can test their implementations for protocol compliance by plugging into this sandbox.

Features to be implemented

• Beckn-protocol compliant catalogs across multiple health and wellness services
• BPP endpoints : search, select, init, confirm, status, update, track, cancel, rating, support
• BAP endpoint : on_search, on_select, on_init, on_confirm, on_status, on_update, on_track, on_cancel, on_rating, on_support
• BG endpoint : search
• Registry endpoints : lookup

What exists

• Beckn protocol sandbox at : https://github.com/beckn/beckn-sandbox

What needs to be built

• A fully functioning scalable health and wellness sandbox compliant to DHP Specifications
• A bot that emulates doctors, diagnostic services, ambulance services

Learning Path

Complexity

Medium

Skills Required

• Open API 3.0
• JSON Schema
• NodeJS
• JavaScript
• TypeScript
• MongoDB

Name of Mentors:

Product Understanding

• @ravi-prakash-v
• @faizmagic

Protocol Specification Design

• @ravi-prakash-v

Project Setup and Guidance

• @faizmagic
• @hemant-eminds
• @nikhil2128
• @ujjwal502

Product Setup

• @nikhil2128
• @ujjwal502

Product Architecture

• @ravi-prakash-v
• @nikhil2128

Frontend Development

• @ujjwal502

Backend Development

• @nikhil2128
• @emindsajay
• @zoyaashik

Deployment and Devops

• @prasad-takale-eminds

Testing and QA

• @SushanthKJ

Project size

8 Weeks

Project Setup Guide

To set up this project, please connect with the Project Setup and Guidance mentor for this project and follow their instructions

Product Set Up

To set up this project, please connect with the Product Setup and Guidance mentor for this project and follow their instructions

Acceptance Criteria

• End-to-end simulation of typical health and wellness use cases on a beckn reference application for health

Out of Scope

• UI development, (however contributions to existing UI implementations are welcome)

Milestones

• Understanding beckn protocol
• Understanding health and wellness ecosystem and use cases
• Developing knowledge model for health and wellness ecosystem
• Health and Wellness Knowledge model Adaptation to beckn protocol
• Development of search / on_search API
• Development of select / on_select API
• Development of init / on_init API
• Development of confirm / on_confirm API
• Development of status / on_status API
• Development of update / on_update API
• Development of track / on_track API
• Development of cancel / on_cancel API
• Development of rating / on_rating API
• Development of support / on_support API
• Creation of emulator for health and wellness agents

Enhance specs to introduce location attribute

Digital OPD flows have non-standard fields and errors in context header structure

The Digital OPD flow mentioned here has non-standard fields namely dhp_consumer_id and dhp_provider_url. They should be bap_id and bpp_url to preseve interoperability. Posting the context header below.

domain: nic2004:85110
country: IND
city: std:080
action: search
core_version: 0.9.3-draft
dhp_consumer_id: dhp_consumer.example.com
dhp_provider_uri: https://dhp_provider.example-hsp.com/api/v0/0.9.3-draft/
transaction_id: '1239890342'
message_id: '123793824'
timestamp: '2021-03-23T10:00:40.065Z'

Secondly, sending dhp_consumer_id (i.e bap_id) and dhp_provider_uri (i.e bpp_uri) in the context header makes little sense. Why would a BAP tell the BPP I am firing this to this uri. BPP already knows where it's supposed to receive requests. For example, you can't tell a server at IP address A.B.C.D that I am going to send you a message at P.Q.R.S. Therefore, the above context header is incorrect.

The correct fields should be

domain: nic2004:85110
country: IND
city: std:080
action: search
core_version: 0.9.3-draft
bap_id: dhp_consumer.example.com
bap_uri: https://dhp_provider.example-hsp.com/api/v0/0.9.3-draft/
transaction_id: '1239890342'
message_id: '123793824'
timestamp: '2021-03-23T10:00:40.065Z'

And thirdly, if a network is using Digital Signature authentication, then you don't event need to send the bap_id and bap_uri in the context. It will be contained in the Authorization : Signature ... header.

@abhimail can you please create a PR for this fix?

Setting up development environment

[C4GT] Implement DHP Sandbox API for Health and Wellness - use cases and upgrade to core v1.1.0

Getting Acquainted with Beckn

Name: DHP-Specs
Title: "Getting Acquainted with Beckn"
Labels: C4GT Community

---

Description

Goals:

Test out the sandbox APIs from the Postman.
https://github.com/beckn/beckn-sandbox
https://github.com/beckn/beckn-sandbox/blob/main/USER_GUIDE.md

Expected Outcome:
Understanding Beckn API calls for each user action made on the BAP application.

Acceptance Criteria:
A document explaining the user actions with their corresponding API calls and the sequence diagram of API calls.

---

Project:
Beckn

Organization Name:
Beckn Open Collective

Domain:
Others

Tech Skills Needed:
• Basic understanding of Beckn
• Basic documentation

Mentor(s)
Faiz Mohammed

Complexity
Low