Mock sample for your project: Health Data Consent Manager API
Integrate with "Health Data Consent Manager API" from ndhm.gov.in in no time with Mockoon's ready to use mock sample
Health Data Consent Manager
Version: 0.5
Integrate third-party APIs faster by using "Health Data Consent Manager API" ready-to-use mock sample. Mocking this API will help you accelerate your development lifecycles and improves your integration tests' quality and reliability by accounting for random failures, slow response time, etc.
It also helps reduce your dependency on third-party APIs: no more accounts to create, API keys to provision, accesses to configure, unplanned downtime, etc.
Description
Entity which provides health information aggregation services to customers of health care services.
It enables customers to fetch their health information from one or more Health Information Providers
(e.g., Hospitals, Diagnostic Labs, Medical Device Companies), based on their explicit Consent and to share such
aggregated information with Health Information Users i.e. entities in need of such data (e.g., Insurers,
Doctors, Medical Researchers).
Specifications
This document maintains only the Health Information Gateway relevant APIs.
Other APIs by ndhm.gov.in
Health Repository Provider Specifications for HIU
The following are the specifications for the APIs to be implemented at the Health Repository end if an entity is only serving the role of a HIU. The specs are essentially duplicates from the Gateway and Bridge, but put together so as to make it clear to HIUs which set of APIs they should implement to participate in the network.
The APIs are organized by the flows - identification, consent flow, data flow and monitoring. They represent the APIs that are expected to be available at the HIU end by the Gateway.
For majority of the APIs, if Gateway has initiated a call, there are corresponding callback APIs on the Gateway. e.g for /consents/hiu/notify API on HIU end, its expected that a corresponding callback API /consents/hiu/on-notify on Gateway is called. Such APIs are organized under the Gateway label.
Gateway relevant APIs for HIUs are grouped under Gateway label. These include the APIs that HIPs are required to call on the Gateway. For example, to request a CM for consent, HIU would call /consent-requests/init API on gateway.
NOTE, in some of the API documentations below, X-HIP-ID is mentioned in header (for example in /auth/on-init). These are the cases, when a particular API is applicable for both HIU and HIP (e.g an entity is playing the role of HRP representing both HIU and HIP). If you are only playing the role of HIP, then only X-HIU-ID header will be sent
The APIs are organized by the flows - identification, consent flow, data flow and monitoring. They represent the APIs that are expected to be available at the HIU end by the Gateway.
For majority of the APIs, if Gateway has initiated a call, there are corresponding callback APIs on the Gateway. e.g for /consents/hiu/notify API on HIU end, its expected that a corresponding callback API /consents/hiu/on-notify on Gateway is called. Such APIs are organized under the Gateway label.
Gateway relevant APIs for HIUs are grouped under Gateway label. These include the APIs that HIPs are required to call on the Gateway. For example, to request a CM for consent, HIU would call /consent-requests/init API on gateway.
NOTE, in some of the API documentations below, X-HIP-ID is mentioned in header (for example in /auth/on-init). These are the cases, when a particular API is applicable for both HIU and HIP (e.g an entity is playing the role of HRP representing both HIU and HIP). If you are only playing the role of HIP, then only X-HIU-ID header will be sent
Health Repository Provider Specifications for HIP
The following are the specifications for the APIs to be implemented at the Health Repository end if an entity is only serving the role of a HIP. The specs are essentially duplicates from the Gateway and Health Repository, but put together so as to make it clear to HIPs which set of APIs they should implement to participate in the network.
Health ID Service
It is important to standardize the process of identification of an individual across healthcare providers, to ensure that the created medical records are issued to the right individual or accessed by a Health Information User through appropriate consent.
In order to issue a Health ID to an individual, one only needs basic demographic details like Name, Year of Birth, Gender. In addition, citizens should be able to update contact information easily.
In order to issue a Health ID to an individual, one only needs basic demographic details like Name, Year of Birth, Gender. In addition, citizens should be able to update contact information easily.
Gateway
Gateway is the hub that routes/orchestrates the interaction between consent managers and API bridges. There are 5 categories of APIs; discovery, link, consent flow, data flow and monitoring. To reflect the consumers of APIs, the above apis are also categorized under cm facing, hiu facing and hip facing
Other APIs in the same category
eNanoMapper database
AMBIT REST web services [eNanoMapper profile] with free text & faceted search
Transport Department, Rajasthan
apisetu.gov.in
Driving License (DL) and Vehicle Registration Certificate (RC) of the State, as available on Parivahan Sewa (http://parivahan.co.in/) of Ministry of Road Transport and Highways, are available on DigiLocker. Citizens can pull these documents into their DigiLocker accounts.
CROssBAR Data API
ebi.ac.uk
About CROssBAR & data
CROssBAR: Comprehensive Resource of Biomedical Relations with Deep Learning Applications and Knowledge Graph Representations
CROssBAR is a comprehensive system that integrates large-scale biomedical data from various resources e.g UniProt, ChEMBL, Drugbank, EFO, HPO, InterPro & PubChem and stores them in a new NoSQL database, enrich these data with deep learning based prediction of relations between numerous biomedical entities, rigorously analyse the enriched data to obtain biologically meaningful modules and display them to the user via easy to interpret, interactive and heterogeneous knowledge graphs.
CROssBAR platform exposes a set of 12 endpoints to query data stored in the CROssBAR database. These endpoints help the user to find data of interest using different parameters provided by the API endpoint.
For example,
https://www.ebi.ac.uk/tools/crossbar/proteins?accession=A0A023GRW5 -> will provide protein information about accession 'A0A023GRW5' including its interactions, functions, cross-references, variations and more.
https://www.ebi.ac.uk/tools/crossbar/activities?moleculeChemblId=CHEMBL465983 -> will provide ChEMBL bio-interactions related information including targets and bio-activity measurements associated with molecule chembl id 'CHEMBL465983'
Knowledge graphs
Another use case of CROssBAR's API endpoints is in building knowledge graphs. These endpoints can be weaved together (output from one API endpoint fed as input to another API endpoint) programmatically to link nodes like protein, disease, drugs etc. as nodes of the graph. The endpoints are designed to be independent from each other which allows users the flexibility to drive biological networks from any facet e.g drug-centric, disease-centric, gene-centric etc. Our service for knowledge graph construction is available at https://crossbar.kansil.org.
An example for the part of the background queries on the CROssBAR API during the construction of a knowledge graph,
(with the aim of keeping the example simple, we have only included the processes related to pathways, genes/proteins and drugs/compounds)
In this example, we would like to find bio-active compounds (with a pChEMBL value threshold of at least 6.0) & drugs targeting all proteins belonging to "WNT ligand biogenesis and trafficking" pathway (based on Reactome pathway annotations).
This can be achieved by using endpoints listed on this swagger documentation as illustrated in following steps-
Find bio-active compounds (with a pChEMBL value threshold of at least 6.0) & drugs targeting all proteins belonging to "WNT ligand biogenesis and trafficking" pathway (based on Reactome annotations)
This can be achieved by using endpoints listed on this swagger documentation as illustrated in following steps-
Get all proteins from â/proteinsâ API endpoint which have a reactome pathway name equal to "WNT ligand biogenesis and trafficking".
From the collection of uniprot protein accessions collected from step 1 above, we query â/targetsâ API endpoint to obtain the âtargetchemblidâs of these proteins.
From the collection of targetchemblids collected from step 2 above, we query â/activitiesâ API endpoint with pChEMBL value >=6, to obtain the âmoleculechemblidâs of the molecules that we need.
From the collection of uniprot protein accessions collected from step 1 above, we find out Drug names and ids from the â/drugsâ API endpoint that targets our proteins.
From the collection of âmoleculechemblidâs obtained in step3, we query â/moleculesâ endpoint to get the compounds that are interacting with the genes/proteins belonging to the âWNT ligand biogenesis and traffickingâ pathway.
CROssBAR: Comprehensive Resource of Biomedical Relations with Deep Learning Applications and Knowledge Graph Representations
CROssBAR is a comprehensive system that integrates large-scale biomedical data from various resources e.g UniProt, ChEMBL, Drugbank, EFO, HPO, InterPro & PubChem and stores them in a new NoSQL database, enrich these data with deep learning based prediction of relations between numerous biomedical entities, rigorously analyse the enriched data to obtain biologically meaningful modules and display them to the user via easy to interpret, interactive and heterogeneous knowledge graphs.
CROssBAR platform exposes a set of 12 endpoints to query data stored in the CROssBAR database. These endpoints help the user to find data of interest using different parameters provided by the API endpoint.
For example,
https://www.ebi.ac.uk/tools/crossbar/proteins?accession=A0A023GRW5 -> will provide protein information about accession 'A0A023GRW5' including its interactions, functions, cross-references, variations and more.
https://www.ebi.ac.uk/tools/crossbar/activities?moleculeChemblId=CHEMBL465983 -> will provide ChEMBL bio-interactions related information including targets and bio-activity measurements associated with molecule chembl id 'CHEMBL465983'
Knowledge graphs
Another use case of CROssBAR's API endpoints is in building knowledge graphs. These endpoints can be weaved together (output from one API endpoint fed as input to another API endpoint) programmatically to link nodes like protein, disease, drugs etc. as nodes of the graph. The endpoints are designed to be independent from each other which allows users the flexibility to drive biological networks from any facet e.g drug-centric, disease-centric, gene-centric etc. Our service for knowledge graph construction is available at https://crossbar.kansil.org.
An example for the part of the background queries on the CROssBAR API during the construction of a knowledge graph,
(with the aim of keeping the example simple, we have only included the processes related to pathways, genes/proteins and drugs/compounds)
In this example, we would like to find bio-active compounds (with a pChEMBL value threshold of at least 6.0) & drugs targeting all proteins belonging to "WNT ligand biogenesis and trafficking" pathway (based on Reactome pathway annotations).
This can be achieved by using endpoints listed on this swagger documentation as illustrated in following steps-
Find bio-active compounds (with a pChEMBL value threshold of at least 6.0) & drugs targeting all proteins belonging to "WNT ligand biogenesis and trafficking" pathway (based on Reactome annotations)
This can be achieved by using endpoints listed on this swagger documentation as illustrated in following steps-
Get all proteins from â/proteinsâ API endpoint which have a reactome pathway name equal to "WNT ligand biogenesis and trafficking".
From the collection of uniprot protein accessions collected from step 1 above, we query â/targetsâ API endpoint to obtain the âtargetchemblidâs of these proteins.
From the collection of targetchemblids collected from step 2 above, we query â/activitiesâ API endpoint with pChEMBL value >=6, to obtain the âmoleculechemblidâs of the molecules that we need.
From the collection of uniprot protein accessions collected from step 1 above, we find out Drug names and ids from the â/drugsâ API endpoint that targets our proteins.
From the collection of âmoleculechemblidâs obtained in step3, we query â/moleculesâ endpoint to get the compounds that are interacting with the genes/proteins belonging to the âWNT ligand biogenesis and traffickingâ pathway.
Transport Department, Haryana
apisetu.gov.in
Driving License (DL) and Vehicle Registration Certificate (RC) of the State, as available on Parivahan Sewa (http://parivahan.co.in/) of Ministry of Road Transport and Highways, are available on DigiLocker. Citizens can pull these documents into their DigiLocker accounts.
Refuge Restrooms API
refugerestrooms.org
REFUGE is a web application that seeks to provide safe restroom access for transgender, intersex, and gender nonconforming individuals.
TheTVDB API v3
thetvdb.com
API v3 targets v2 functionality with a few minor additions. The API is accessible via https://api.thetvdb.com and provides the following REST endpoints in JSON format.
How to use this API documentation
You may browse the API routes without authentication, but if you wish to send requests to the API and see response data, then you must authenticate.
Obtain a JWT token by POSTing to the /login route in the Authentication section with your API key and credentials.
Paste the JWT token from the response into the "JWT Token" field at the top of the page and click the 'Add Token' button.
You will now be able to use the remaining routes to send requests to the API and get a response.
Language Selection
Language selection is done via the Accept-Language header. At the moment, you may only pass one language abbreviation in the header at a time. Valid language abbreviations can be found at the /languages route..
Authentication
Authentication to use the API is similar to the How-to section above. Users must POST to the /login route with their API key and credentials in the following format in order to obtain a JWT token.
{"apikey":"APIKEY","username":"USERNAME","userkey":"USERKEY"}
Note that the username and key are ONLY required for the /user routes. The user's key is labled Account Identifier in the account section of the main site.
The token is then used in all subsequent requests by providing it in the Authorization header. The header will look like: Authorization: Bearer . Currently, the token expires after 24 hours. You can GET the /refresh_token route to extend that expiration date.
Versioning
You may request a different version of the API by including an Accept header in your request with the following format: Accept:application/vnd.thetvdb.v$VERSION. This documentation automatically uses the version seen at the top and bottom of the page.
How to use this API documentation
You may browse the API routes without authentication, but if you wish to send requests to the API and see response data, then you must authenticate.
Obtain a JWT token by POSTing to the /login route in the Authentication section with your API key and credentials.
Paste the JWT token from the response into the "JWT Token" field at the top of the page and click the 'Add Token' button.
You will now be able to use the remaining routes to send requests to the API and get a response.
Language Selection
Language selection is done via the Accept-Language header. At the moment, you may only pass one language abbreviation in the header at a time. Valid language abbreviations can be found at the /languages route..
Authentication
Authentication to use the API is similar to the How-to section above. Users must POST to the /login route with their API key and credentials in the following format in order to obtain a JWT token.
{"apikey":"APIKEY","username":"USERNAME","userkey":"USERKEY"}
Note that the username and key are ONLY required for the /user routes. The user's key is labled Account Identifier in the account section of the main site.
The token is then used in all subsequent requests by providing it in the Authorization header. The header will look like: Authorization: Bearer . Currently, the token expires after 24 hours. You can GET the /refresh_token route to extend that expiration date.
Versioning
You may request a different version of the API by including an Accept header in your request with the following format: Accept:application/vnd.thetvdb.v$VERSION. This documentation automatically uses the version seen at the top and bottom of the page.
Open Policy Agent (OPA) REST API
OPA provides policy-based control for cloud native environments. The following endpoints (such as PUT /v1/policies) provide reference documentation for the OPA REST API.
API specification viewing options
View the specification in Redoc (default)
View the specification in Swagger UI
API specification viewing options
View the specification in Redoc (default)
View the specification in Swagger UI
Times Newswire API
With the Times Newswire API, you can get links and metadata for Times articles and blog posts as soon as they are published on NYTimes.com. The Times Newswire API provides an up-to-the-minute stream of published items.
State Transport Department, Telangana
apisetu.gov.in
Driving License (DL) and Vehicle Registration Certificate (RC) of the State, as available on Parivahan Sewa (http://parivahan.co.in/) of Ministry of Road Transport and Highways, are available on DigiLocker. Citizens can pull these documents into their DigiLocker accounts.
Statutory Instruments API
parliament.uk
An API exposing details of the various types of Statutory Instruments laid before Parliament.