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.
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.