Building on Fast Healthcare Interoperability Resources / FHIR


We started drchrono leveraging technology; our mission: to build something physicians and patients want, tackling hard problems and to fix healthcare.
As part of our mission and as the healthcare revolution is also happening we want to enable an open API for developers from around the world to work together. We see a future where physicians and patients can use wearables, Internet of Things (IoT) devices, other medical software and hardware to leverage our cloud-based EHR and API. Healthcare should not be siloed where data is locked into a non-cloud-based EHR. In that future developers will come together to build jointly to create a better healthcare experience for everyone, providers, patients, caretakers, and family.


The Argonaut project is a way to make healthcare more interoperability, drchrono is a part of this project. The idea is to get different players in the industry on to a simple to understand easy interface. (drchrono has also committed to Sync For Science)

There is a new data standard called FHIR or Fast Healthcare Interoperability Resources.

There are some core objects or classes called “resources” that show how we represent different pieces of data in health care. Things like what is a patient look like, what does a medication look like and what does an allergy look like.

In healthcare we are always asking, how do you package data, so things like patients, they have a first name, last name, date of birth, phone number, address.

EHRs are storing patient data in different ways and it looks totally different. But if we standardize the interfaces for transferring and for receiving, the can make sure all of these different systems can communicate when sending data back and forth in an easy way. Healthcare is been transferring data for years either by hand or electronically. This is important now because we have been transferring data through on scalable standards like HL7 version 2 and X12s format. X12 and HL7 formats are delimited file formats that have embedded information with a hierarchy to that data, but it does not pass it attribute names with it. So what that means is both parties beforehand have to agree and know exactly in the format and order of the data before transfer, explicitly knowing this information before e.g. Knowing names and the delimiters in great detail. This only allows them to develop for each other using those formats.

On the other Modern formats such as JSON and XML are using a lot in web development. They are agreed on apone standards that developers can all use that tag patient information so what you call a resource you know what you are calling.


drchrono just launched a version of the FHIR API for the 10 million patients on the drchrono platform. The personal health record platform called onpatient has the FHIR API documented here –¬†

  • Build an OAuth Login and Logout
  • Build a way to view all patient information that is available via FHIR.
  • Build a blood pressure tracker
  • Build a sleep tracker
  • Build a weight tracker
  • Build a hydrate tracker

If you are looking to join drchrono, build an app on top of onpatient’s FHIR API and impress us! The way to do this is to

  1. Create a drchrono account at
  2. Add test patient in drchrono at drchrono here after you signed up and logged in.
  3. Invite the patient to within drchrono here, use your email address so you get the patient email.
  4. Create an account with the email invite from drchrono, set a password.
  5. Sign in and go to the API page app page and start building.

Also post your code publically on Github as a resume builder and that the drchrono engineers can take a look at what you have built.

As you build please let daniel[@]drchrono[.com] and jian[@] know how things are working and if something is broken. This is a VERY new API so we are looking for real-time feedback.

This is a great project that someone built recently on the drchrono medical practice physician API and the onpatient patient API.

( This is a draft of a hackathon project to build on top of the onpatient FHIR API. I will be adding more over the next several days. )