Monthly Archives: August 2017

Building on the drchrono iOS API through Deep Linking

What is deep linking on iOS?

Deep linking in iOS is using hyperlink URLs to launch an app with specific content. The specific content can be a particular section of an app page, or a certain tab or specific view. To test this out you can download the Twitter app, login and then close the twitter app. Next open twitter://timeline in your Safari mobile iOS browser and wallah, iOS will switch to the Twitter app and go directly to your timeline. You can even do more sophisticated app switching like this – in your, iOS Safari Browser enter this, twitter://post?message=learn%20deep%20linking and the native twitter app should open up with a draft message composed “learn deep linking”.

You can use deep linking for:

  • Moving data between the apps from launching an app from another app and passing information
  • Building a web-like URI based navigation scheme within your app
  • And of course integration with other apps like drchrono EHR by letting them launch your app directly
  • Also recording and reviewing user behavior to learn where your users launch your app from

How to use deep linking on Apple iOS iPad?

To link back into drchrono, it can now be done, you can Deep Link into the iPad iOS appointment page. This is the code to do it, it is super simple to do –

 Deep link to an appointment drchrono://appointment/<appointment_id>

You can Deep Link into the iPad iOS patient chart as well –

Deep link to a patient drchrono://patient/<patient_id>
You can Deep Link A great example of a partner show has built into drchrono is our partner Physitrack

How to Login to EHR via oAuth?

If you wanted to setup login on iOS, it can be done, the team at Eko Devices did an amazing job. They leveraged the drchrono Healthcare Doctor API which can be found here, https://www.drchrono.com/api-docs.

You can see a video here –

 

Building on Fast Healthcare Interoperability Resources / FHIR

MISSION

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.

FHIR HISTORY

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.

BUILDING ON FHIR

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 – https://onpatient.com/api_fhir/api-docs/documentation/

  • 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 drchrono.com
  2. Add test patient in drchrono at drchrono here after you signed up and logged in.
  3. Invite the patient to onpatient.com within drchrono here, use your email address so you get the patient email.
  4. Create an onpatient.com 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[@]drchrono.com 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. )