You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
v0.9.6 updated CM spec, made the HIU and HIP specs as obsolete (#20)
* Updating spec for CM. Also marked HIP and HIU spec as redundant.
* strikethrough the documentation links for HIU and HIP
* Adding flow sequence diagrams and adding a page for Codes
* Updating content and diagram.
* adding a blank page for HI data documentation
Various errors and meta codes that are documented below.
6
+
7
+
## Error Codes
8
+
The response callback APIs (e.g. /on-discover), have an error attribute, which have a code and a message. The codes are described below. Note, only the ones relevant to the network are documented here, for application/system specification error codes (e.g. Patient App), please refer to the reference implementation documentations.
9
+
10
+
##### Consent Manager Error Codes
11
+
TBD
12
+
13
+
14
+
##### HIP Bridge Error Codes
15
+
TBD
16
+
17
+
18
+
##### HIU Bridge Error Codes
19
+
TBD
20
+
21
+
22
+
23
+
24
+
## Meta/Concept codes
25
+
These are codes that are used within the contract to express specific concepts.
26
+
Reference implementations only demonstrate the means and usages of the codes, and not establish a standard. The standards themselves are to be defined by a competent authority, available publicly, and the codes in the reference systems should only reference/use such defintiions.
27
+
28
+
##### Purpose of Use codes
29
+
The following codes are referenced from [FHIR Purpose of Use](https://www.hl7.org/fhir/v3/PurposeOfUse/vs.html) Value Set, which in turn includes codes from HL7 ActReason.
30
+
The reference CM exposes [an API](https://github.com/ProjectEKA/consent-manager/blob/master/src/main/resources/static/ValueSet/purpose-of-use.json) to express the Purpose of Codes in FHIR Value Set standard.
31
+
32
+
Please see below for examples:
33
+
```
34
+
{
35
+
"code": "CAREMGT",
36
+
"display": "Care Management"
37
+
},
38
+
{
39
+
"code": "BTG",
40
+
"display": "Break the Glass"
41
+
},
42
+
{
43
+
"code": "PUBHLTH",
44
+
"display": "Public Health"
45
+
},
46
+
{
47
+
"code": "GOV",
48
+
"display": "Government"
49
+
},
50
+
{
51
+
"code": "HPAYMT",
52
+
"display": "Healthcare Payment"
53
+
},
54
+
{
55
+
"code": "DSRCH",
56
+
"display": "Disease Specific Healthcare Research"
57
+
}
58
+
```
59
+
60
+
61
+
##### Health Information (HI) type codes
62
+
The following codes are defined as the exchangeable Health Information (HI) types. In the reference implementations, they are synonymous to the FHIR resource types. It is expected that a competent authority will define such HI types that are accepted within the affinity domain.
63
+
64
+
The reference CM implementation [exposes an API](https://github.com/ProjectEKA/consent-manager/blob/master/src/main/resources/static/ValueSet/health-info-type.json) using FHIR Value Set specification to express the HI Types.
Copy file name to clipboardExpand all lines: content/components.md
+11-7Lines changed: 11 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -3,14 +3,18 @@ layout: home
3
3
---
4
4
5
5
### Components
6
-
There are 4 essential components of the architecture, which must conform to the protocols of National Health Stack.
6
+
There are 4 essential components of National Health Stack Architecture. Three are representative of entities that are involved i) Patient herself ii) Healthcare Services who act as Information Providers iii) Users of the health information (practitioners, payers etc) and iv) a fiduciary/trustee that facilitates the discovery, linking of patient within the network and consented means of exchange of patient's health information.
7
7
8
-
8
+
9
9
10
-
- Health Data Consent Manager (HDCM): A fiduciary/trustee that manages patient consents, to facilitate information flow between HIP and HIU and Patient App(s)
11
-
- Health Information User (HIU): A web application to request/fetch/view Patient's Health Information.
12
-
- Patient App: An Android application for patient's to signup with a HDCM, link accounts with providers, grant consents to HIU request of Health Information, and view patient Health records. In future, more access channels (e.g a Web Portal) may be introduced.
13
-
- Health Information Provider (HIP): A set of useful toolings, like shared Libraries, handling the common workflow/interactions, while providing extension means for plugging HIP specific Health Information System
10
+
1. Health Data Consent Manager (HDCM): A fiduciary/trustee that manages patient consents, and facilitates discovery, exchange of health information exchange between HIP and HIU as consented by the Patient.
11
+
- HDCM provides a reference Patient App - with which a patient can signup with HDCM, linkup with providers, grant consents for health information acccess, and view patient Health records. In future, more access channels (e.g a Web Portal) may be introduced.
12
+
2. Health Information Gateway (Gateway): A hub that mediates and connects HDCMs and Bridges (HIU and HIP) in this network. Its primary job is to allow for discovery, routing in the network. Bridges and HDCMs register themselves with the Gateway, and gateway includes them ontto the networks post validdation.
13
+
3. Health Information User (HIU) Bridge: A system that acts as bridge/connector as a bridge/connector of the HIUs to the network.
14
+
- Reference implementation has a HIU server backend system, that does the interfacing with the Gateway, thereby providing a starter point of HIU Bridge, and a simple Doctor's interface.
15
+
4. Health Information Provider (HIP) Bridge: A system that acts as bridge/connector as a bridge/connector of the Health Information Providers to the network.
16
+
- Reference implementation is a headless service, handling the common workflow/interactions, while providing extension means for plugging HIP specific Health Information System, and has sets of useful toolings, shared Libraries etc. Its purpose is to act as starter material for HIP Bridges and act as example/references of HIP integration.
14
17
18
+
In most cases, the HIU and the HIP may be the same, connected to the same Bridge. The distinction of the bridges above is made so as to maintain the representations of the involved entities. Bridges represent one or more HIU/HIPs in the ecosystem, and registers so with the Gateway.
15
19
16
-
For more info, please check out Niti Aayog's National Health Stack [consultation paper](https://niti.gov.in/writereaddata/files/document_publication/NHS-Strategy-and-Approach-Document-for-consultation.pdf)
20
+
The reference implementation stack has 5 distinct solutions/applications, reflecting each primary purpose.
The documentations are maintained in OpenAPI Specification (OAS), commonly known as swagger API documentation format. To view the documentation on the browser, you may follow the following steps.
17
14
- Install Swagger Viewer Chrome plugin: add this [extension](https://chrome.google.com/webstore/detail/swagger-viewer/nfmkaonpdmaglhjjlggfhlndofdldfag). Once installed, you may open the above API links, and click the swagger button on the toolbar/addressbar of the browser, usually located on top right.
15
+
16
+
17
+
Many of the contracts have errors and meta codes. Which are documented [here](./codes.html)
18
+
19
+
20
+
Health Information is exchanged via FHIR bundles. [FHIR](https://www.hl7.org/fhir/index.html) is a standard for health care data exchange, published by HL7. The intent of using FHIR is towards standardization of schema, i.e machine readable, rather than addressing or enforcing semantic standards for interoperabilty. See [here](./hirepresentation.html) for health data representation in FHIR in the reference implementation stack.
0 commit comments