Access Control (Roles)

Participating systems in the Claims information exchange ecosystem may possess one or more of the following roles. These roles are based on the base set of organisation roles defined in hl7 specifications here. Namespaced coding is used to further qualify the role in the context of the claims exchange process.
1.provider: Health Service Provider
2.payer: Insurance service provider
3.agency.tpa: Third party administrator acting on behalf of the payer. In the current version, this role is expected to behave like a payer from the data exchange perspective.
4.agency.regulator: IRDAI and IIB like regulatory bodies.
5.research: Research groups, etc.
6.member.isnp: eCommerce platforms facilitating insurance adoption
7.agency.sponsor: Scheme owners of specific programs, e.g. NHA for Ayushman Bharat
8.HIE/HIO.HCX: Other HCXs
The following table further describes these roles for their corresponding access rights and scenarios for version 1 of the claims exchange process:
Role
Allowed actions
Comments
provider
1.Eligibility check
1.Send request
2.Receive response
2.Pre Auth
1.Send request
2.Receive response
3.Claims request
1.Send request
2.Receive response
4.Payment
1.Receive notice
2.Send Acknowledgement
5.Search/Status
1.Pre auth
2.Claims status
Providers can make search/status requests for multiple requests that originated from them.
payer/
agency.tpa
1.Eligibility check
1.Receive request
2.Send response
2.Pre Auth
1.Receive request
2.Send response
3.Claims request
1.Receive request
2.Send response
4.Payment
1.Send notice
2.Receive Acknowledgement
5.Search/Status
1.Payment confirmation
Payers can make search/status requests for multiple payment notices that originated from them.
agency.regulator
1.Search
1.Claims
Data exchange switch will forward the search request to all payers who are expected to return the claims data in the proposed FHIR structure as per regulator’s policies.
research
1.Eligibility check
1.Receive request
2.Send response
2.Search
1.Pre Auths - aggregate and/or anonymised
2.Claims - aggregate and/or anonymised
All data exhausts for these roles would only have aggregate and anonymised data. Key aggregations for eligibility requests, preauthentication, claims and payments information will need to be further defined.
member.isnp
1.Eligibility check
1.Receive request
2.Send response
2.Search
1.Pre Auths - aggregate and/or anonymised
2.Claims - aggregate and/or anonymised
3.Claims - Individual claims data as per beneficiary consent
As facilitators of insurance eCommerce, it is proposed to provide ISNPs access to the data available to research role as well as individual beneficiary queries (preauth, claims) based on beneficiary consent. This consent flow is expected to work with existing consent management infrastructure and ISNPs are expected to submit the acquired consent as part of the domain header.
agency.sponsor
​
As planners of the insurance schemes, sponsors are proposed to be given access equivalent to payer role.
HIE/HIO.HCX
​
As an HCX this participant is expected to play different roles as per the need of the use case. However, due to the data privacy and security measures prescribed in the Open Protocol, it will not be able to view the actual payload.
Questions for Consultation
Question 1
The primary stakeholders/roles in the HCX ecosystem are mentioned in the section Access Control. Are there any other primary or secondary stakeholders that should be considered as HCX participants? If yes, please outline their role in the HCX ecosystem.
Question 2
This section also mentioned allowed actions for the current set of stakeholders, please review these actions and suggest any changes needed for those actors.
Instructions to send responses to the consultation questions are available here.

Healthcare Operations Policies

Guidelines for Participant Onboarding

Last modified 11mo ago

Role	Allowed actions	Comments
provider	1. Eligibility check 1. Send request 2. Receive response 2. Pre Auth 1. Send request 2. Receive response 3. Claims request 1. Send request 2. Receive response 4. Payment 1. Receive notice 2. Send Acknowledgement 5. Search/Status 1. Pre auth 2. Claims status	Providers can make search/status requests for multiple requests that originated from them.
payer/ agency.tpa	1. Eligibility check 1. Receive request 2. Send response 2. Pre Auth 1. Receive request 2. Send response 3. Claims request 1. Receive request 2. Send response 4. Payment 1. Send notice 2. Receive Acknowledgement 5. Search/Status 1. Payment confirmation	Payers can make search/status requests for multiple payment notices that originated from them.
agency.regulator	1. Search 1. Claims	Data exchange switch will forward the search request to all payers who are expected to return the claims data in the proposed FHIR structure as per regulator’s policies.
research	1. Eligibility check 1. Receive request 2. Send response 2. Search 1. Pre Auths - aggregate and/or anonymised 2. Claims - aggregate and/or anonymised	All data exhausts for these roles would only have aggregate and anonymised data. Key aggregations for eligibility requests, preauthentication, claims and payments information will need to be further defined.
member.isnp	1. Eligibility check 1. Receive request 2. Send response 2. Search 1. Pre Auths - aggregate and/or anonymised 2. Claims - aggregate and/or anonymised 3. Claims - Individual claims data as per beneficiary consent	As facilitators of insurance eCommerce, it is proposed to provide ISNPs access to the data available to research role as well as individual beneficiary queries (preauth, claims) based on beneficiary consent. This consent flow is expected to work with existing consent management infrastructure and ISNPs are expected to submit the acquired consent as part of the domain header.
agency.sponsor		As planners of the insurance schemes, sponsors are proposed to be given access equivalent to payer role.
HIE/HIO.HCX		As an HCX this participant is expected to play different roles as per the need of the use case. However, due to the data privacy and security measures prescribed in the Open Protocol, it will not be able to view the actual payload.