The problem OPD One (EMR+NDHM) solves

Roughhly 40-60% of India's doctors are engaged in a private practice. However, MANY of these private doctors' clinics still do not maintain digital records for their patients and expect the patient to maintain a file full of papers. There are several reasons for this:

• There is no financial incentive for private doctors to digitize records.
• Current EMR softwares are very difficult to use and require expensive training.
• These doctors want everything under one software roof - but are met instead by a fragmented ecosystem.

This was the inspiration for OPD One. Our goal is to make digitizing private practice blindingly simple and empower this last 40% of doctors to contribute to the NDHM ecosystem. In the last few months, we have been in early access with 10 doctors with whom we have served 1000+ patients, completed 1300+ appointments (offline & telemed) and processed over Rs 10,00,000 via the platform. Our product suite includes practice management tools (appointment/patient databases), calendars & scheduling, payment processing, teleconsultation integrations and patient engagement tools.

Our focus at this Hackathon was an Electronic Medical Records product. As mentioned above, these doctors have traditionally ALWAYS used paper records. So, with our EMR product, we have set out to fundamentally alter user behavior. We have developed proprietary technology that allows to quickly build customized EMR flows in MINUTES. These flows are based on doctor's own paperwork developed over the years to reduce perceived switching cost.

Usually, the ease-of-use of this customizability comes by sacrificing interoperability. However, we made use of the NDHM APIs to create proof-of-concept ETL pipelines that can transform data from doctor-facing custom formats to the interoperable FHIR standard. We hope this empowers individual medical practitioners (not just large institutions) to contribute to and benefit from the NDHM ecosystem.

Challenges we ran into

Balancing the ease of use of our customizable EMR while maintaining the interoperability of FHIR and still retaining the ability to build these flows in minutes (else the idea wouldn't scale). This was extremely tricky and our solution was to come up with a sort of "tagging mechanism" where custom fields that are intended to be shared with the NDHM network are tagged with relevant resource types from the FHIR standards. Most of these are incredibly obvious - and thus we could preserve the speed at which we build these flows.

NDHM APIs were pretty tricky, time consuming to understand and a little unreliable. As such we were only fullly able to build out the HIP-initiated linking flow but are almost done with implementations of the actual data transfer from HIP to HIU (the encryption piece of this was very tricky), and are looking to build a doctor-facing HIU next to enable them to gather medical history and context much before their first minute with the patient.

Lastly, we are still figuring out the economic and financial piece of the puzzle. We believe the strong network effects of the NDHM ecosystem will be a motivating factor in driving adoption, but without proper economic incentive alignment we may never get to true universal health care. As such we were very encouraged by the direction outlined in NDHM Webinars about HIUs potentially paying HIPs and so on - and would love to see how that materializes. But until then, the lack of economic incentive allignment (doctor paying to host patient data) is a challenging obstacle.

NOTE: SEE DRIVE LINK FOR VIDEO