The problem EHR.Network Health Repository Provider solves

For existing and new healthcare applications, integration with NDHM brings in another layer of complexity. NDHM integration introduces new challenges such as asynchronous APIs, encryption/decryption of data, FHIR resource mapping and Consent management. This is challenging for small and medium teams, whose resources are already stretched and many teams may not be in a position to prioritize this work immediately. This inturn will delay the wide scale adoption of NDHM APIs, thus limiting its potential impact to transform Indian healthcare.
We are proposing to build a cloud HRP service that allows such systems to integrate with NDHM using a small set of simple REST APIs that work with simple key-value JSONs. All the complexities related to NDHM integration are managed by this service, retaining applications largely unchanged. Our HRP service will bridge the new NDHM constructs with the existing features of the applications and also extend it where required. For inhouse solutions that are not connected to the Internet, this SAAS service will provide a cloud based proxy EHR repository to provide an always available cloud presence.
We will also be making a version of this available as a standalone application that can be integrated into standalone solutions for their NDHM integration.

Challenges we ran into

After deliberating on build versus reuse, we decided to reuse the EKA HIP Service. Though it gave us a head start, as it is developed in C#, we had to work on getting both development and deployment environments for .net. The EKA has encryption/decryption support, this turned out to be not interoperable when integrated with PHR, hence we had to replace it with EKA java library.
Technology - The sample codes involved a varied mix of technologies which required the teams members to be proficient in multiple technologies.
PHR app - Deploying PHR app on Linux android emulator was not an easy install.
Troubleshooting - In the absence of access to logs from the sandbox, integration and debugging could only be done through trial and error, which took a lot of time. While doing ‘get data’ from the PHR app, sometimes the data would not get displayed in PHR inspite of having validated the FHIR bundle for the ndhm FHIR profiles. It would have been helpful if there was a PHR test stub with just the data encrypt and display functionality. It was impossible to get to know which part of the FHIR was invalid.
Documentation - Although the documentation in sandbox.ndhm.gov.in was very elaborate, it missed giving the complete flow. e.g for a HIU initiated consent and data pull, the call flows in building both HIP and HIU stops at GM. So it was not clear as to how consent was shared across HIU, PHR and HIP.
Architecture - Using FHIR consent resource instead of Meity consent framework would have been simpler for implementers as a lot of documentation and expertise were easily available. It would also have made consent resolution to FHIR resources that are being exchanged much simpler.
Testing - PHR app has a 5 minute wait before another request could be initiated with no way to override it. This slowed down our integration to a large extent.