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.

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.

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.

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.