Transcript
[ Cheering ]
[ Applause ]
>> All right.
Welcome everyone.
Welcome to our session
connecting CareKit to the Cloud.
I'm Kelsey Dedoshka.
And I'm our software engineer
here on the CareKit team.
And so we'll start our session
off today with a brief CareKit
overview.
And then we'll introduce our
brand-new Bridge API where we'll
discuss in depth how to
integrate that API into a cloud
backend.
And in the process, we'll even
dive a little bit deeper and
walk-through understanding some
of the code.
Then I'll invite Akshay up to
the stage here to give you guys
a quick demo.
And we'll finish up by seeing
what you can all do with this
new feature.
So let's get started.
If you're interested in learning
what's new in the framework, you
can reference the earlier
session What's New in CareKit
and ResearchKit hosted by Sam
Ravka [phonetic].
Or to learn how CareKit came to
be and its underlying
architecture, I highly recommend
checking out last year's session
talk Getting Started with
CareKit hosted by Omar Kahn
[phonetic].
Now since its introduction last
year, CareKit has helped medical
groups improve the overall
quality of patient care by
providing at-home solutions for
tracking care activities and
assessments.
And allowing patients to take
more control over their care
through CareKit apps has
presented new insights and
opportunities to take that care
and technology one step further.
And so this year we're
introducing a new card for
patients to track care to-dos,
like these stretches post knee
surgery, alongside some
assessments they may need to
complete to track their progress
along their care journeys.
Now these adherence, symptoms,
and outcomes are key data points
in understanding not only how a
patient is feeling but how
engaged they are in their own
personal care.
And data from this card is also
crucial for care teams to
understand whether their
treatments are having their
intended effects or not.
Our CareKit Insights tab now
features threshold alerts, which
provides users with a nice
visual indication via widgets or
even text that really bring data
to the forefront of their
attention they may need to be
concerned about.
And last CareKit apps today
allow patients to share their
data in PDF form via our Share
Reports option on the Connect
View.
And we found that it was time to
upgrade this share experience.
And so after the launch of
CareKit, we were excited to hear
how valuable the data collected
via CareKit apps were, not only
to patients but to their care
team members.
However, providing that data
back to care teams is a manual
process.
And this can make it challenging
for care teams to update their
patient's care cards remotely
and even get a good sense of how
they're progressing through
their care.
And so these patient and care
team apps really have to work to
break down this data barrier
that exists between them.
And so we've seen some apps
create their very own backend
cloud solutions to help them
sync data between their patient
and their care team apps.
However, this isn't an easy
task.
And it really requires the
developers to handle doing a
majority of the work.
They have to handle interfacing
directly with the apps data
store as well as with the
backend cloud system.
And so we saw this growing need
to help break down this data
barrier and help patient and
care team apps securely sync
data between them if they
desire.
And so this presented us with
the opportunity to improve the
CareKit framework by building
hooks directly in the framework
architecture so that current and
new applications can accomplish
their data syncing needs in a
much easier and cleaner way.
And moving forward, we hope to
improve the data pipeline with
the creation of this new feature
and, in turn, reducing the
required effort by the
development team.
Now this cloud-based data
sharing means patients who use
CareKit apps at home to track
their care can now share that
care data in real time.
And this is great because it
allows their care teams to see
their patient's results as
they're being recorded and gives
them the opportunity to make
adjustments in their care plan
or even to reach out directly if
they desire.
And so throughout this process,
we've been really inspired by
many CareKit apps, especially
the work being done at Sharp
Healthcare in Southern
California.
And so let's create our own use
case inspired by their users,
for patients undergoing eye
surgery that takes advantage of
our new CareKit features and the
Bridge API.
And it really showcases this
importance of data syncing.
And so, in this case, the two
weeks post surgery are crucial
to a healthy recovery.
And patients must religiously
take antibiotic eye drops to
prevent infections that could
ultimately lead to blindness if
they're not treated early.
And then in our scenario here,
care teams can monitor their
patient's results as they're
being recorded.
And if they aren't progressing
through their care, they can
make adjustments in their care
plan if they need to.
And patients can also see their
eye drop adherence and their
results via the Insights tab
and, again, so can their care
teams.
Care teams can monitor their
patient's results.
And if they aren't progressing,
they can make adjustments in
their care plan if they need to
or even reach out directly if
they desire.
And so this use case really
showcases this importance of
data syncing and why we, as a
team, found it so crucial to
begin integrating a solution.
And so with that, I'd like to
introduce our brand-new Bridge
API.
The Bridge API is an abstract
cloud API that conforms to the
CareKit schema and enables data
syncing without any additional
configuration.
It's designed to allow CareKit
apps to seamlessly integrate
with backend cloud solutions.
And it's built upon our current
CareKit data model and
architecture.
The Bridge API provides all of
the necessary hooks for cloud
solutions to seamlessly hook
into the CareKit framework.
And this removes the need for
third-party developers to dive
deep into the code and extend
the CareKit framework to their
specific needs.
The API abstracts that away and
provides delegate functions for
cloud solutions to utilize
instead.
And along with the Bridge, we've
added some additional UI modules
to make it even easier for
developers to integrate and use.
So let's take a look at how it
works.
Care plan activities are created
using the OCKCarePlanActivity
object as either an assessment,
an intervention, or even a
custom type created by the
developer.
These activities are then added
to the OCKCarePlanStore via our
current CareKit framework
functions.
Now this is where a Bridge API
really comes into play.
It sits between the care plan
store and the cloud backend and
it listens to changes in state
in the store.
And when a change is detected,
the API reacts accordingly and
allows cloud solutions to pick
up those changes and sync the
necessary data differentials to
and from the cloud.
It interfaces with both the
local care plan store and the
remote cloud store to ensure
that any changes in state are
handled accordingly.
Activities can be added,
removed, and updated.
And the Bridge API hooks allow
cloud solutions to pick up those
changes and perform the
necessary data syncing.
And as data is changed, updates
to the store pull down and
stored in our local care plan
store to ensure the last data
sync is still available to the
user even if their device can't
connect to the cloud at that
time.
So let's take a look at how this
is accomplished.
You can continue adding and
removing OCKCarePlanActivities
just as you always have.
And this means that no
additional configuration needs
to be made to your existing
CareKit app activities to
utilize the functionality of the
API and actively sync data.
But how does that actually work?
The API handles changes in the
care plan store by both
notifying the delegate when the
activity list has changed as
well is when it receives an
event update.
And these Bridge API hooks and
these methods that you see here
allow our cloud solutions to
hook into this framework and
handle care plan store state
changes.
And all of this happens behind
the scenes to allow your CareKit
apps to access live updates in
the care plan store.
And so these methods allow
developers, like all of you, to
build out your very own backend
cloud solutions that hook
directly into our Bridge API and
that allow you to handle care
plan store state changes that
fit your desired use case.
However, if you're interested in
using a third-party solution,
you can utilize one of the
existing solutions that have
already taken advantage of the
Bridge API and have available
CareKit implementations ready to
use off the shelf.
And so we've worked with both
Medable and CloudMine to help
them design and create HIPPA
compliant backend cloud
solutions that use their
existing HIPPA compliant backend
cloud systems.
And utilizing one of these
solutions can help expedite the
process of getting your CareKit
app up and running with the
Bridge API and actively syncing
data to the cloud.
So let's take a look at one of
the existing solutions developed
by Medable and demonstrate how
to utilize the Bridge API hooks
to sync data with their cloud
solution.
And so here you can see how to
start the client.
And this is going to reference a
few necessary keys in your
project's plist to ensure that a
connection can be established
and data can be in syncing with
your provisioned account.
From there, you can login with
your configured username and
password and proceed by either
handling the fault if there is
one or retrieving the return to
Bridge reference for that user,
which you can use to be in
establishing connections.
And once login has been
successfully established, the
cloud Bridge knows to utilize
that account for subsequent
transactions.
And so once you've successfully
logged in, you can list Medable
store connections.
And this will return the
available connections for that
user.
And these connections can be in
a variety of states: accepted,
denied, or pending.
And so from there you want to
handle connections accordingly
by either accepting pending
connections or even grabbing the
active connections for that user
which you can use to begin
syncing data.
Now it's really important to
note here that data will not
successfully sync to the cloud
unless you have an active
connection.
And this is going to ensure that
users only have access to data
to and from those that they have
authorized.
And so denied connections will
prevent any data from syncing
with the cloud and being shared
with the initiator.
And so now that we've looked at
creating connections and
establishing them via Medable
solution, let's take a look at
another new CareKit feature that
utilizes these connections and
our Bridge API.
This new API opens the door for
not only syncing CareKit data
such as activities and events,
but it can be used to sync data
of other types as well.
And so a really great example of
this is secure messaging.
Secure messaging can be seen via
our Connect tab and showcased
using the new UI modules
developed in our latest CareKit
update.
If you attended the previous
session, What's New in CareKit
and ReserachKit, you will be
familiar with the added inbox
feature via the Connect tab.
Inbox provides developers with
the ability to easily display
messages in a nice
conversation-like format.
And that messaging feature can
be tied directly into the Bridge
API and cloud backend solutions
to allow patients and care teams
to securely message directly in
their CareKit apps.
And so let's take a look at how
to accomplish this in the code.
Use the OCKConnectViewController
delegate the
OCKConnectViewController data
source methods to set up your
messaging UI.
And please note that not all the
necessary delegate functions are
showcased here, but we've chosen
to highlight some of the more
specific methods.
And so this first method is
necessary to tell the delegate
how many message items exist for
the corresponding care team
contact.
Patients and care teams could
have multiple conversations, so
knowing which messages go with
which conversation will be
crucial here.
And next you can implement the
connectMessageItemAtIndex
function and return the
appropriate message at that
index.
An array of
OCKConnectMessageItems can be
stored as you send and receive
messages.
And you can use the index
property of this method to index
into that array and return the
appropriate message.
And what this is going to do is
it's going to allow your UI to
display these messages in the
appropriate order.
And last you can implement the
didSendConnectMessage function
to securely send a message over
to your care team or over to
your patient.
And so this is where our Bridge
API and these backend cloud
solutions really come into play.
You can utilize those Bridge
methods to either create a new
conversation or to even append a
new message to the existing
conversation thread.
And so let's see how that might
look using Medable solution.
So here you can see how to
create the conversation.
And this takes the message
object which can be created from
your delegate properties and an
array of targets indicating who
those messages should be sent
to.
Now in this target ID property
you see of the target's
parameter will be the unique
identifier of the connection and
whom that message should be
sent.
And success of this function
will not only create the
conversation but it will append
the attached message.
It's really important to note
here that we recommend not
creating multiple conversations
with the same connection via
this createConversation
function.
Although it can be done, it's
really best practice to create
the conversation once.
And subsequent messages should
be appended using the
sendMessage function.
And so this sendMessage function
is very similar to the one
above.
However, it takes the message
object and now a conversation
ID.
When you create the conversation
above, it's important to keep a
reference of that returned ID
which you should be using as the
conversation ID parameter of
this function.
And this is going to ensure that
when you send a new message, it
gets appended to your
appropriate conversation thread.
And for good user experience,
it's also important to perform
any necessary UI updates upon
creating a new conversation or
even appending a new message to
an existing conversation thread
to ensure that your users are
going to get instant feedback if
their messages were successfully
sent or not.
And so this messaging feature is
another great example of how our
Bridge API and these cloud
solutions are helping to improve
the at-home patient care
experience.
And so now that we've seen the
architecture of the bridge API
and how to utilize it along with
the corresponding cloud backend,
I'd like to invite Akshay to the
stage to give you guys a quick
demo.
[ Applause ]
>> All right.
Hello everyone and welcome to
the CareKit Cloud Bridge Sync
Demo.
In this demo, we'll see how easy
it is to share data between a
patient app and a care team app
using a HIPPA compliant secure
cloud bridge.
For this demo, we'll be using
the OCKSample app which is
available Open Source on GitHub.
The OCKSample app is developed
by our [inaudible] team with all
the best practices in place.
So we believe, for this demo,
the Sample app would be a good
starting point because anyone
who's familiar with CareKit is
also very likely familiar with
the Sample app.
For more reference on the Sample
app, please refer to last year's
WWDC session Getting Started
with CareKit.
So let's see what the Sample app
looks like right now.
On my computer here, I have two
simulators.
In my iPhone simulator, we have
the Sample app.
And currently for the Sample
app, we have created and stored
a care plan store object locally
and an OCKCarePatientObject
which is associated with this
care plan store.
There are three tabs: the Care
Contents tab which shows all the
activities that belong to this
care plan store, an Insights tab
which shows [inaudible] insight
items, and a Connect tab which
shows OCKContacts that are
associated with this OCKPatient.
Explicitly for this demo, we
have also created a Care Team
app.
On my iPad simulator, we have
the Care Team app which shows
the care team member and a list
of patients that belong to this
care team member.
Clicking on a patient will take
us to their profile where we can
see their activities.
And for this demo, we're going
to show one of the patient's
activities to show the data
syncing.
Currently, both the apps have
local care plan stores, so we
won't be able to sync the data
between the two apps.
Let's go ahead and bridge this
gap using the cloud bridge.
Here's my Xcode workspace.
And here are my two projects:
the Care Team project and the
OCKSample project.
Let's go ahead and first add our
cloud bridge to our Care Team
app first.
And as Kelsey mentioned earlier,
we will be using Medable as our
cloud bridge solution for this
demo.
So the first thing that you need
to do is go to Medable's GitHub
and download or clone their API
into our project and then
integrate the framework into our
project.
I've already downloaded
Medable's API and added the
Medable's framework into my
project right here with all my
other like CareKit and
ResearchKit and all of the
frameworks.
To use Medable's API, we have to
add some of their files.
We can do this by going to their
CareKit Bridge API folder and
dragging and dropping it into
our project right here.
Let's see what this directory
has.
It has three types of files.
First, all the helper files that
we need which are Medable object
counterparts of the CareKit
objects, for example
MDCarePlanStore,
MDCarePlanPatient, etcetera.
The second is the Medable
[inaudible] Bridging Header.
Let's go ahead and add this
bridging header to our project.
I'll go to my project and in my
build settings.
I look for the bridging header.
And add the bridging header
right here.
Perfect. Now we have added all
the files that we needed from
Medable into our project.
The next thing that we have in
this directory is the care plan
store category.
This category has all the
methods that we need to create
the Medable counterpart objects
from our CareKit object.
To use Medable's API, we also
need to add a few necessary
methods into our project.
We'll be adding those into our
LocalCarePlanStore.m files.
Let's first add those methods in
and then I'll talk about what
those methods do.
In my CarePlanStore.m file, I'm
going to add those methods.
And these methods will mimic
whatever the local care plan
store methods do.
For example, in our
CarePlanStore we have an
activity method and the methods
that we just added will do
exactly the same but on the
Medable side so all of these
methods are adding activity,
removing an activity, updating
an event, etcetera.
With this, we have added
everything that we need as files
and code into our project.
To use Medable's API, you need
to create an account with them.
When you create an account, you
get three types of credentials:
a client key, a base URL, and an
organization name.
We have to add these three
credentials into our project to
hook up our project to our
account on Medable.
Let's go ahead and see how to do
that.
Go to your projects info.plist
file and create a dictionary.
And we'll call it Medable, and
set it as a dictionary.
Now in this dictionary, we'll
have to add three key value
pairs.
The first is the ClientKey.
Second one is the BaseURL.
And third is the Organization
name.
Perfect. When we add these three
credentials, we should be able
to link our project to our
account at Medable.
We have to perform all of these
steps for our Sample app as
well.
And for this demo, I've already
added all of these steps into
our Sample app already.
So now both of our apps are
having [inaudible] Medable and
configured with the cloud
bridge.
Let's go ahead and use those.
When we create an account with
Medable, with their dashboard,
we should be able to create a
care team member account.
And we can do that by providing
an e-mail, a password, and a
phone number.
So when we create the care team
member account, in return we get
a verification token.
That verification token is
needed by the care team member
to log themselves in.
And these properties can be
provided through the UI,
preferably using the ResearchKit
login step.
So let's go ahead and add those
in.
I'll go into my projects app
delegate file.
And first I will add all the
necessary properties that I
would be needing.
Here I have a cloud bridge.
I'll talk a little bit in more
detail about this in a minute.
The e-mail, the password, and a
verification token of the care
team member.
And then I'll get back to these
properties in a minute.
Let's go ahead and add Medable's
login method.
Here's the [inaudible] .login
method which takes an e-mail, a
password, and a verification
token.
If the person is successfully
logged in, we should be able to
create a patient.
Otherwise, this method returns a
fault.
Let's say the care team member
is logged in.
Now we should be able to create
a patient from here.
And that's where these
properties come in.
To create a patient, we need the
patient's first name, their last
name, and all of their details
and their e-mail ID.
Let's go ahead and create a
patient using these properties
adding the first name, the last
name, all of the properties of
the patient.
And this method does two things.
In its callback, if we were not
able to create a patient, it
returns a fault.
But if you were successfully
able to create a patient, then
the callback returns a bridge.
Now this is the place where you
can access the care plan store.
So by doing [inaudible] cloud
bridge is setting up a local
variable, the cloud bridge, to
the cloud bridge that we
received from callback, we have
access to the cloud bridge from
anywhere in our app.
And that's what we can do
cloudbridge.careplanstore.
It will give us access to the
care plan store that we need.
We will replace our care plans
store and make the
cloudbridge.careplanstore as our
default care plan store
throughout the app.
The second thing that this
method does is sends an
invitation token to the patient
in their e-mail which we
provided right here.
When the patient receives this
e-mail, they should be able to
register themselves through the
patient app.
And they would need this
verification token which is sent
-- the invitation token that is
sent to their e-mail to register
themselves.
Let's go ahead and register the
patient in the patient app.
In my patient app, I'll go to
the app delegate and add all the
variables that we need for a
patient to register.
This includes the first name,
last name, e-mail, their mobile
number, a password, and an
invitation token.
And all of these properties can
be provided through the UI.
Let's go ahead and add the
method to register the patient.
The register account method
takes in the first name, the
last name, the e-mail, the
mobile number, the password, and
the invitation token.
And, again, in the callback,
returns the cloud bridge.
This is, again, the same cloud
bridge that the care team
members are accessing.
So if you do the
cloudbridge.careplanstore, both
the care team member and the
patient should be able to access
the same care plan store.
Make sure you save this cloud
bridge in one of your variables
in your file and make the
cloudbridge.careplanstore as
your default care plan store
throughout the app.
When we do this, we have
successfully made care team app
and the patient app access a
common care plan store.
Now any activity or an update in
an activity which is done on
either of the apps should
reflect on the other app as
well.
Let's go ahead and test this
out.
For this demo, we have already
created a different version of
the app which has all the same
information but we have added
the login credentials and the
organization name also to these
apps.
In my iPhone simulator, I have
the Sample app.
And in my iPad simulator, we
have the Care Team app.
The Sample app is just the same
app with all the login
credentials needed.
And the Care Team app is also
just the same app with all the
login credentials.
Let's go ahead and complete the
pain activity for today.
In my pain activity, I'm feeling
somewhere around, let's say
seven and I hit Done.
And in no matter of time, this
activity should sync over the
data to the care plan activity
on the care team side.
[ Applause ]
Now during the day, whenever
patients feel like their
activity has changed, they can
-- whenever they update an
activity, it should also reflect
on the care team side.
And the time that this is taking
is variable, which you can set
through the API.
If you wanted to, based on your
use case, if you think the
frequency of your updates, you
can change this lapse and either
increase it or decrease it.
With this data syncing, we have
seen in this demo, we took two
applications with local care
plan stores and created a common
cloud bridge and made both the
apps access the common care
plans store and share the data
across.
We believe there was a very
urgent need for functionality
like this.
And with all of these resources
being public, we cannot wait to
collectively help thousands of
people every day.
With this, I would like to call
back Kelsey up on stage and
continue with the session.
Thank you.
[ Applause ]
>> So thank you to Akshay for
that awesome demo.
And so as you guys just saw, the
process of getting a CareKit app
up and running with the Bridge
API is fairly straightforward.
You saw firsthand how the apps
sync data to and from the cloud
and how to utilize those bridge
methods in these cloud solutions
directly in your Xcode
application.
And so throughout the session,
we introduced the addition of
the Bridge API to the CareKit
framework.
We discussed the architecture of
how it works.
And you saw how to utilize it in
the code along with viewing a
live demo.
So what can you do with this new
feature?
The Bridge API not only
integrates with each of the
existing CareKit modules but is
modular and easily extendable to
be used with new ideas and
contributions from the developer
community like all of you.
And now that we all have a
better understanding of what the
Bridge API is, it's important to
point out and recognize how
powerful this tool can be.
It opens the door and provides
developers, care teams, and
medical institutions with the
technology that allow them to
care for their patients in a
more personal and engaged way.
But what do I mean by that?
It's great to see how CareKit
and each of its existing modules
is helping to improve the
at-home patient care experience,
but it's even better if we can
involve their care teams.
To improve the patient care
process, we looked at this API
to help care teams get a better
understanding of their patient's
needs and to get one step ahead
of their care.
And this can help provide
patients with a sense of
reassurance and encourage them
to become more engaged in their
own personal care.
And these are all powerful tools
that now exist at your
fingertips.
And what comes next is up to
you.
Whether it's extending your
existing applications or
starting from scratch, we
believe that CareKit along with
the Bridge API and developers
like all of you have the power
to improve the at-home patient
care experience and decrease the
patient care gap that exists
today.
And so with this new
functionality, we look out to
all of you to take advantage of
existing third-party backend
cloud solutions or to build your
own.
And in the process, consider who
that data will be syncing with
and how that corresponding care
team app may look.
The Bridge API is only as
powerful as the care team app on
the other side.
And so we look to all of you to
help build out these care team
solutions via care team apps and
dashboards.
And CareKit is Open Source so as
you build out these solutions
and improve your existing
applications, please contribute
that work back so as a team we
can continue to evolve and grow
the CareKit framework.
And so more information about
CareKit and both the Bridge API
solutions from Medable and
CloudMine can be found at the
provided link.
And if you're interested in
learning more about CareKit or
its relating technologies,
please take a look at one of the
following sessions.
So thank you all for coming to
the session on the CareKit
Bridge API.
And we really look forward to
seeing what you all do with this
new technology.
[ Applause ]