1. API Development and Sharing of Data

1. The main purpose of this SoP is to guide the individual or agencies on how to share and consume data from the datahub in a secure way to protect data privacy of individuals and citizens as a whole.
2. Each organisation must follow its own procedures regarding information security and confidentiality before sharing with consuming agencies.
3. This SoP is not designed to supersede existing policies but to enhance them by facilitating cross-agency dialogue and consensus by providing a context for information sharing.

---

1.1 Procedure to Follow in Staging Environment by Data Consumer,Data Owner and DITT

A. Data Consumer Responsibility
1. If agencies want information from other agencies (data owner), they must write formally to the data owner by clearly specifying the resources and get approval from the data owner.
2. Without the approval, the datahub team will not be able to share the information even if the API is available in datahub.
3. This gives the data owner the authority to maintain confidentiality and privacy of the information before they give approval to access the requested information by consuming agencies on a case by case basis.
4. The data consumer has to share the approved letter from the data owner to DITT to initiate the development of API.
5. DITT will in turn follow up with the data owner to provide with sql query and database details for API development.

B. Data Owner Responsibility
1. The data owner must review each incoming request from the data consumer based on resources and decide to give approval or not based on classification of datas. If the data owner approves the request to access its information via datahub platform.
2. Data owners have to provide the following details to the DITT datahub team to initiate the API development.
1. SQL queries with few input parameters to test the query.
2. Create a mirror of live database (data can be jumbled up)
3. Create a user for data hub with required privileges (execute the query)
4. Share the database details such as database name and type, port, IP address, and user created in no 3 above along with password.
5. White listing of IP from your firewall is configured.
3. It is also the responsibility of the data owner to maintain the list of agencies approved for access to their mirror database. This will give clear information about who is accessing what data for what purpose.

C. DITT Responsibility
1. The DITT upon getting the query and database details, we will first execute the query in a local machine, if there is no issue, we will continue to develop the API. If there is an issue, we will contact the data owners to resolve the issue.
2. The API development will take a minimum of 5 working days and will be pushed to the staging environment on the 5th day, ready for testing by the agencies.
3. DITT will inform the both data consumer and owner about it and share the API credentials with the data consumer to start integrating their system.
4. Agencies can share the staging API credentials with their consultant during the development phase to integrate the system with datahub and test if required data is being pulled from the data sources.
1. The following information will be shared with data consumers from the staging environment by DITT.
1. Access Token code, only in for testing purposes.
2. Client secret
3. Consumer key
4. API endpoints/url
5. SDK files as necessary
5. The procedure on how to develop API is an internal document within the Team.

---

1.2 Procedure to be followed in production environment by data consumer, data owner and DITT.

A. Data Consumer Responsibility
1. The data consumer has to inform the Datahub team about their successful test completion in the staging environment and ask us to push the same API to the production environment.

B. Data Owner Responsibility
1. Data owners have to provide the following details to the DITT datahub team to push the API to the production environment.
1. Create user in live database,
2. Give required privileges to above user (execute the query)
3. Share the database details such as database name and type, port, IP address, and user created in no 3 above along with password.
4. White listing of IP from your firewall is configured.
2. It is also the responsibility of the data owner to maintain the list of agencies approved for access to their live database. This will give clear information about who is accessing what data for what purpose.

C. DITT Responsibility
1. The DITT upon getting the query and database details of the live server from the data consumer, we will push the API to the production environment within 2 working days.
2. DITT will inform the both data consumers about it and ask the data consumer to come and sign NDA in person to DITT.
3. DITT will share the API credentials only with the person who signed the NDA.
4. Agencies can’t share the production API credentials with their consultant. It has to be configured by IT of the respective agencies.
5. If there is anonymous access to data using the API credentials leaked from this application, the person who signed NDA will be held accountable.
6. The following information will be shared with data consumers from the production environment ( following information will be shared via email etc.. person signing NDA has to take in flash drive or in secure way)
1. Client secret
2. Consumer key
3. API endpoints/url
4. SDK files as necessary
7. The focal person who signed up to this NDA is legally responsible for ensuring the safety and confidentiality of the production environment of the data hub API that is shared.
8. It has to be properly handed over to the next officer in charge, in case the focal person leaves for long term studies or on transfer to another organization.

---

1.3 Seeking Consent

1. If the agencies/data consumer has to share productionAPI information with their vendor for integration issues etc, then the consent has to be sought from DITT and the focal person from the vendor has to also sign NDA before sharing the API credential to ensure that he didn’t disclose or misuse the information.
2. The focal person who signed the NDA will be held accountable as per the law, if there is any compromise to the data, if they share the API credentials openly or they tried to access unauthorised database. The signing of NDA is to secure and protect the data from anonymous access with valid keys.

A. Important Note to Data Owner.
1. It is utmost important for the data owner to keep their database up and running. Also, ensure the user created for datahub is not changed or revoked.
2. If data owners are making changes to their database, the data owner has to inform the Datahub team, so that changes are made at same time without downtime.
3. The DITT datahub platform has an analytic tool that will show the number of downtimes for the database, which resulted in downtime of API and agencies not able to consume the data.
4. This will impact the data owner IT in their performance rating from the Department.

---

1.4 Responsibilities for API Development

A. API Development
1. To develop a new API, the data consumer, the data owner and DITT has to follow the following roles and responsibilities described below.

Stakeholders	Process
Data Owner	Data owner shall maintain documentation of API details with resources and data exposed. To check the API details using the below link: https://staging-datahub-apim.dit.gov.bt/store. It contains available resources within the API The data owner has to inform the datahub team, if data owner want to make any changes to their database such as ( change in database name, ip, fields in table, change in query, creation and deletion of existing user provided to datahub, access privilege to the user provided to datahub). Data owners shall authorise data consumers to use APIs and resources within the API. In case consumers need more data or resources within the existing API, Then data consumer has to formally request the data owner for access to additional resources. The data owner will choose to expose a new set of datas as either a new API or modify the existing API. Data owners has to officially inform DITT with following information: SQL Queries and data source informations (Database type, schema name, Server IP, and user credentials to access database ) Security concerns : The classification of the data/resources as either public, internal and sensitive information, so that API can be developed accordingly.
Data Consumer	First check the API store for existing APIs using the link below: https://staging-datahub-apim.dit.gov.bt/store. It contains available resources within the API. The data consumer shall get prior approval from data owners to consume their data through API from data hub. The data consumer has to spell out clearly which data field they want to access from the data owner when seeking approval. To initiate the API consuming process, Consumers shall write officially to DITT to consume API from the datahub platform with the following information. Client Application Details (Language, Web or mobile, whether it is hosted in the Govt Data Center or not) List of APIs necessary if known/ or list of data necessary Expected number of API calls (TPS) Is your application accessible by Citizens? If access is required by citizens, then it has to integrate with the single sign on (SSO) platform, in this case the agencies have to provide DITT with redirect URLs of the application (login and logout). Authorization letters from data owners In case API is not available in the API store or the required data are not available, then data consumers have to seek permission to consume data and request modification of existing API or to develop a new API with required data from the data owner. List of operations with input and output parameters
DITT	Interim Procedure Verify the SQL query with Input and output parameters with data owners and consumers. Develop and test API in 5 working days and publish in staging environment for data consumers to initiate integration If the API already exists, but requires additional data from the same API, then DITT will modify the existing API at resource level within 5 working days and publish in a staging environment for data consumers to initiate integration. Long Term DITT will provide a Git location to store the API source codes and development guidelines. Once the development is completed, test the APIs in the testing environment. Commit the source codes to the Git repository provided by DITT. Inform the DITT team to configure the CI/CD (Jenkins) and build the project using Jenkins and deploy to the datahub staging environment. Agencies will test the API in staging environment Once the test in staging is complete, agencies have to inform DITT to promote the API to production with details of live connection to their database. New API development will take a minimum of 5 working days upto 22 working days depending on the complexity of the API necessary DITT will not accept changes to modify the API that are tested and published in the production environment. Modification will be done with versioning of API every after 6 months.

---

B. Subscribing to Exposed APIs
1. To subscribe to exposed APIs, the data consumer has to get an approval letter from the data owner and send a request to DITT along with the approved letter.
2. The DITT will create a user for the agencies (data consumer) and with that user credential.
3. DITT will create an application in the API manager and provide access to the API. The DITT will provide data consumers or their consultants(developers) with the consumer secret, consumer key, access token and API endpoint url along with the SDK files ( jar files) to integrate the systems via data hub platform from staging environment only.
4. The production environment API details will be shared with the focal person of the data consumer in person after signing of this document and will not be shared with consultant or vendor in any case.
C. Moving APIs to Production
1. To move the API to the production stage, it has to first be tested in the local machine with the given input and output parameters by the data consumer. Upon successful test with given parameters, the same API is then pushed to staging production and DITT will share the consumer secret, consumer key, access token and API endpoint url to test and integrate their systems to the data hub platform.
2. Once it is fully tested in the staging server, then the agencies have to inform DITT to push the same API to the production environment.
3. Once the API is pushed to production, DITT will share the configuration information like consumer key, consumer secret, access token and API endpoint with the focal person and agencies have to configure without engaging outside consultants.
4. This is to ensure security and unauthorised access of APIs using the above credentials.

---

1.5 Requirements

A. Approval from DITT
1. List of resources
2. List of fields under each resource
3. Input parameters

1. Test environment with sample data to cater each scenario by direct connection to test DB from GDC Datahub servers.The staging url:https://staging-datahub-apim.dit.gov.bt/store

B. Non Compliance and Partner Disagreement
1. In the event of non compliance with this Agreement and the sharing of details of API to vendors or any outside entities, data consumers shall be liable for any data privacy loss and access tokens shall be revoked immediately.
2. The data hub analytics shall monitor the traffic generated from each application for every API published. Unexpected traffic will be apparent and DITT shall notify the data consumer and will monitor the issue and if unauthorized access is suspected, DITT shall promptly Revoke authorizations to suspected applications and other applications under the same network if necessary.
3. This will remain in effect until all necessary remedial actions are taken promptly and demonstrated to the DITT.

---

1.6 NON DISCLOSURE AGREEMENT

1. This agreement is entered into this 20 day of April, 2020 between ...................... (hereinafter "Recipient"), with offices at ...................., and Dawa Tshering, with offices at DITT (hereinafter "Disclosure").
2. WHEREAS Disclosure possesses certain ideas and information relating to API of production that is confidential and proprietary to the Disclosure (hereinafter "Confidential Information"); and WHEREAS the Recipient is willing to receive disclosure of the Confidential Information pursuant to the terms of this agreement for the purpose of integrating the system to data hub platform and consume the data; NOW THEREFORE, in consideration of the mutual undertakings of the Disclosure and the Recipient under this agreement, the parties agree to the below terms as follows:
1. Disclosure.The Disclosure agrees to disclose, and Receiver agrees to receive the Confidential Information.
2. Confidential
1. No Use.The Recipient agrees not to share the Confidential Information in any way with the consultant/vendor or manufacture or test any product embodying Confidential Information, except for the purpose authorized by the Disclosure.
2. No Disclosure.The Recipient agrees to use its best efforts to prevent and protect the API Information, or any part thereof, from disclosure to any person other than the Recipient's employees that have a need for disclosure in connection with the Recipient's authorized use of the production Information of API.
3. Protection of Secrecy. The Recipient agrees to take all steps reasonably necessary to protect the secrecy of the Confidential Information and to prevent the Confidential Information from falling into the possession of unauthorized persons.
3. Limits on Confidential Information.Confidential Information shall not be deemed proprietary, and the Recipient shall have no obligation with respect to such information where the information:
1. Was known to the Recipient prior to receiving any of the Confidential Information from the Disclosure;
2. Has become publicly known through no wrongful act of the Recipient;
3. Was received by the Recipient without breach of this agreement from a third party without restriction as to the use and disclosure of the information;
4. Was independently developed by the Recipient without use of the Confidential Information; or
5. Was ordered to be publicly released by the requirement of a government agency.
4. Ownership of Confidential Information.The Recipient agrees that all Confidential Information shall remain the property of Disclosure and the Discloser may use such Confidential Information for any purpose without obligation to Recipient. Nothing contained herein shall be construed as granting or implying to the Recipient any transfer of rights, any patents, or any other intellectual property pertaining to the API Information.
5. Term and Termination.The obligations of this agreement shall be continuing until the Confidential Information disclosed to the Recipient is no longer confidential. In the event of non compliance with this NDA and the sharing of details of API to vendors or any outside entities, data consumer shall be liable for any data privacy loss and access tokens shall be revoked immediately.
6. Survival of Rights and Obligations.This agreement shall be binding upon, inure to the benefit of, and be enforceable by (a) the Discloser, its successors and assignees; and (b) the Recipient, its successors and assignees.
7. Change of Focal Officials: If the recipient is no longer taking in-charge of this API, this NDA has to be re-signed with the new focal of the API. It is the responsibility of the Recipient to inform the Disclosure in writing, officially, of the change in focal officials.
3. IN WITNESS WHEREOF, the parties have executed this agreement effective as of the date first written above.
4. Discloser (Name of the Discloser)

Signed .......................................... Print Name :..................................... Title:........................................... Date :...........................................


5. Recipient (Name of the Recipient)

Signed ........................................... Print Name :...................................... Title:............................................ Date :............................................

.

---

The Nation with the Best Health

1. The Royal Government of Bhutan has accorded priority to tapping the potential of ICT in various sectors. Guided by the vision “the nation with the best health”, the health sector has emphasized the importance of using ICT-enabled solutions to improve the delivery of quality care to the people of Bhutan.
2. The ICD is originally designed as a health care classification system, providing a system of diagnostic codes for classifying diseases, including nuanced classifications of a wide variety of signs, symptoms, abnormal findings, complaints, social circumstances,and external causes of injury or disease.
3. The clause 5.4 of the National Health Policy of Bhutan, 2011 states that “The Royal Government of Bhutan shall provide 100% nationwide access to a health care professional through technology-enabled solutions.
4. Furthermore, Clause 7.2 of National Health Policy 2011 states that “Digitised Health record and information system shall be instituted in all the health facilities for faster and effective health information generation to support decision making.”

---

5. The ICT Division was established in the ministry to spearhead, review and manage all the ICT/eHealth activities and guiding the programmes in investing in the area in 2017.
6. This was followed by the development of the National eHealth Strategy and Work Plan which in 2017 with support from ADB and WHO which served as a lighthouse to ICT initiatives in the ministry.
7. This also established the National eHealth Steering Committee which served as the governing body for any ICT activities for the ministry and eHealth Technical Working Group was established to carry out review or carry out the ICT activities.

---

National eHealth Enterprise Architecture Blueprint

1. Bhutan has successfully come out with an National eHealth Enterprise Architecture Blueprint in December 2020 to ensure all the systems can exchange data seamlessly.
2. Bhutan's approach to implementing HIS is to have a standard HIS system across all the health facilities in the country and also get data from other stakeholders which has been successfully tested in the COVID19 system implementation.
3. Another advantage Bhutan has is that the country has information of any individual residing in Bhutan be it Bhutanese citizen or foreigner.
4. Therefore, it is only imperative for Bhutan to adopt such a system by any means which shall be expensive in the beginning but shall soon payoff in terms of efficiency and huge health care expenditure savings.
5. If Bhutan can roll out this project successfully, Bhutan will be one among few countries in the world to roll out standardized integrated healthcare IT solutions across the nation that include non-allopathic facilities (Traditional Medicine Hospital/Clinics).
6. This shall help Bhutan in achieving the goal of Universal Health Coverage (UHC) which every nation in the world is aspiring.
7. The details document can be found in the link shared below:
   
   1. National eHealth Strategy: (National_eHealth_Strategy.pdf).
   2. National eHealth EA Blueprint: (National eHealth EA Blueprint.pdf).
   3. National eHealth Standards: (National eHealth Standards.pdf).

The International Classification of Diseases (ICD)

1. The International Classification of Diseases (ICD) is a globally used diagnostic tool for epidemiology, health management and clinical purposes. The ICD is maintained by the World Health Organization (WHO), which is the directing and coordinating authority for health within the United Nations System.
2. The ICD is originally designed as a health care classification system, providing a system of diagnostic codes for classifying diseases, including nuanced classifications of a wide variety of signs, symptoms, abnormal findings, complaints, social circumstances,and external causes of injury or disease.
3. This system is designed to map health conditions to corresponding generic categories together with specific variations, assigning for these a designated code, up to six characters long. Thus, major categories are designed to include a set of similar diseases.

---

The ICD-11 Revision

1. The ICD-11 is the eleventh revision of the ICD. It replaces the ICD-10 as the global standard for coding health information and causes of death. The ICD-11 is developed and regularly updated by the World Health Organization (WHO).
2. Its development spanned over a decade of work, involving over 300 specialists from 55 countries divided into 30 work groups, with an additional 10,000 proposals from people all over the world. The stable version of the ICD-11 was released on 18 June 2018, and officially endorsed by all WHO members during the 72nd World Health Assembly on 25 May 2019.
3. The ICD-11 is a large ontology consisting of more than 80000 defined entities, also called classes or nodes. An entity can be anything that is relevant to health care.
4. It usually represents a disease or a pathogen, but it can also be an isolated symptom or (developmental) anomaly of the body. There are also classes for reasons for contact with health services, social circumstances of the patient, and external causes of injury or death.
5. The collection of all ICD-11 entities is called the Foundation Component.From this common core, various subsets can be derived; for example, the ICD-O is a derivative classification optimized for use in oncology.

---

The ICD-11 MMS Foundation

1. The primary derivative of the Foundation is called the ICD-11 MMS, and it is this system that is commonly referred to as simply "the ICD-11". MMS stands for Mortality and Morbidity Statistics.Both the Foundation Component and the ICD-11 MMS can be viewed online on the WHO's website.
2. The ICD-11 further includes extension codes that cover medicaments as defined in International nonproprietary names, chemicals, infectious agents, histopathology, severity, mechanisms of injury, or anatomy.
3. ICD-11 ontological structure provides advanced user guidance and assistance in code combinations.The technology can be accessed by any software via API or by humans using the coding tool.Print versions will be made available on demand.
4. The ICD-11 will officially come into effect on 1 January 2022, at which time member nations may begin reporting morbidity and mortality statistics using the ICD-11 nosology.The WHO has acknowledged that "not many countries are likely to adopt that quickly", i.e. begin using the ICD-11 by the time of its launch.
5. Bhutan as one of the active member countries of WHO has also adopted ICD-11 by defaults and has started implementing it starting from 2020.As the nation is in the process of digitizing healthcare services using ehealth and mhealth solutions, the adoption of this health standard could not be more timely.
6. Since the Ministry of Health has adopted this standard, any office, agencies or system planning to use such disease either built, collect or access disease data are mandated to use these standard coding.
7. More details are available at the WHO ICD-11 (https://icd.who.int/en) website or else please contact officials of the Health Information Management System Team under the MoH.