Today, we will go over the new features in ResearchKit, we'll talk a little bit about the contributions from the open source community and how you can contribute. But first, I'd like to start with a recap of ResearchKit. We introduced ResearchKit over a year ago and the aim was to take the basic components of clinical research and to move them over to the mobile world. And those basic components are informed consent, survey tasks and active tasks.

It's pretty staggering to think about the number of iPhones that are in the world and how users like you and I can contribute to research. But there's some significant differences between clinical research and the mobile world, specifically in clinical research. The participant is right there where the researcher can see them and show them what to do and be with them. So when you move to the mobile space there are some things to consider. I'd like to go over each of these components and show you how ResearchKit does them.

Informed consent is requirement for all studies that use human subjects. Researchers are required to tell participants what the study's about, what data they're going to collect, how they're going to use the data, how they're going to ensure privacy, how the person can withdraw from the study, and many more things.

So typically what happens is that a person like in the Autism & Beyond study will be given a form like this to read. It's rather long because if you were to put it end to end it would be taller than I am. So it's a lot of text the person needs to go through.

So translating this to ResearchKit we developed an informed consent module and what we do is we split this large form into a series of screens. On each screen it describes that particular section, gives an overview, provides a learn more link where the participant can drill down and get more information if they want to, as they're doing here with withdrawing.

And then at the end everything is put back together again for one final review and then the person can decide to participate in the study or not. If they decide to participate in the study, then they'll be asked to give their name and sign an electronic consent form just as our most famous user, Johnny Appleseed, is doing here.

Now what I want to point out is if you're a developer and you're doing your first ResearchKit app you can't just cut and paste this text here that Duke has or any other study has. Informed consent text is approved by an institutional review board or ethics committee and you need to use the text that they give them.

And you also have to like resist the urge to be a creative writer and to like, you know, I look at these things and think wow, I can simply this, I can make this really exciting to read. But you don't want to do that, you just want to take what the researcher gives you and make sure that it has been approved. So that's informed consent.

In clinical research researchers typically have a participant do at least one survey if only to ask for demographic data. But it's also quite common for researchers to use standard surveys like this, the patient health questionnaire or PHQ-9. Now it's pretty easy to translate a paper survey into a mobile survey and ResearchKit tries to make this a little bit more pleasant by in most cases putting one question per page.

And of course, we can support anything that paper has in terms of fill in the blank, multiple-choice. But because it is mobile ResearchKit can do even more. You can do your multiple-choice, it can have a truly sliding-scale where you have to slide your finger, you can give location as an answer or date and time or images. There are many, many rich answer formats in ResearchKit that can be there. Good, the date looks right for me now.

So that was our survey tasks. Now active tasks, in a clinical setting a participant might be asked to do something like walk, so the researcher can observe their gait or maybe to solve a puzzle or tell a story for psychological research. Or they might even be asked to do things like that require fine motor coordination. And again, in the clinic you have somebody there to show you how to do it and to make sure you're doing it correctly. So I'm going to show you two tasks so that you can get an idea of how ResearchKit handles active tasks.

The first is a voice task and here the participant is asked to say "ah" into the microphone and then the app collects the audio and analyzes it in any way that is fit for that particular research. So this task has all the components that can be in an active task, so let's go through them. There is a page that describes what the task is, that gives instructions to the user on how to perform the task, and a lot of active tasks have a countdown timer.

And then some feedback to the user and in this case it's saying that she's too loud, so you can make sure that you do the task correctly. All the screens you see, the animation, the screen to screen navigation are all provided by ResearchKit. To get this task you only need to use one call in ResearchKit, it's that easy. Here's another task. This is a tapping speed task where a user needs to tap back and forth as fast as she can during a given time. But there are many, many other tasks in ResearchKit, including a walking task, spatial memory task, and there are others.

So those are active tasks. From the first day that ResearchKit was released it was integrated with HealthKit. It's very easy in Xcode to add the HealthKit entitlement to your app and it doesn't take too many more lines of code to get a screen like this where you can ask the user to have access to the data in HealthKit. When you do that you need to specify the data that you want to read from and write to the health app.

The user has the option to give you permission for everything that you ask for or she can just give you permission for specific pieces. So I suggest that when you are going to ask for access to data that you ask only for the data that you're absolutely going to use in your research. So don't ask for everything and you'll have a better chance of success of getting that permission from the user.

One of the big questions that we got asked over the past year is what does ResearchKit do with the data, where does it store it. And that's really easy for me to answer because ResearchKit doesn't do anything with data. If you were here for last year's presentation on ResearchKit where John Earl explained the architecture of ResearchKit he also talked a lot about result objects.

And the short story is that ResearchKit has a results property on the Task View controller and it will hand you the results in that property. But it's up to your app to persist the data locally and also for a research study you want to send that data to secure server where you can aggregate and analyze it.

If you haven't watched John Earl's presentation from last year I suggest that you do so because in it he also shows how to code informed consent, survey tasks and active tasks. But rather than have me go over that coding today because you can watch that video I would like to bring up my colleague, Yuan Zhu, who can go over the new features of ResearchKit and explain to you how to code with them. Yuan.

Thank you Bunny. The open source community discovers that mobile research needs more features than research can provide it. And we have been collaborating with the community to add more features to ResearchKit. So today, I'm really excited to show you three of them. First, branching task. It can be confusing on the paper, but on mobile devices this is really themed to the user. Second, app access. It protects user's privacy and data, which is critical to most of the research apps. Last, charts. Present the data in a visual way to your user, then your user can understand the data better. First, I will talk about the first one, branching task.

Whether your app is giving instructions, presenting a survey or running an active task everything in ResearchKit is a collection of steps, which together form a task and the task can be presented to the user. With this model it's quite straightforward to create a linear task, but branching task is not that obvious how to create. Let me show you an example.

What you see here is a survey with three questions. And apparently it only makes sense to ask the second question to the user who has responded yes to the first question, do you own a car. And the last question, do you own a bicycle should always be asked at the end regardless the answer to the first two questions. Then you may wonder how could I create this survey in ResearchKit.

To help you do that I introduce you a new class, ORKNavigableOrderTask. Since it's a task, so it has a collection of steps as well. But besides that it also holds a collection of navigation rules. The navigation rules defines the branching logic in the task. Next, I'm going to show you how to use this new class to present a survey and just show to you and it's really easy to use.

In the code first I need to create those question steps. Once I have the questions steps I can create the navigable order tasks with those steps. As you can see, it's as easy as create a linear task. But after that I need to create the navigation rule for it.

The navigation rule I'm trying to create here is to display own a bicycle question right after the own car question to the people who don't have a car. And I want to let you know the navigation rule has three elements. First, a trigger step, which it triggers the navigation rule to be evaluated. Second, expected answer, so expected answer here is no to the first question, do we own a car. Last, it requires a designation step. Now you have learned the three elements in the navigation rule. Let me show you the code now.

In the code first I use the resultSelector to locate where is the result. And then I create the predicate with the expected answer. After I have the predicate I can create the navigation rule with the destination step. Last, I'll add the first question, do you own a car, to be the trigger step. As you can see, it's quite easy just one, two, three I create this navigation rule. And also the task is ready to be presented to the user. Now you have learned how to use branching task. Next, let me show you the app access.

User account is a very important aspect of managing the user in your app. App access provide this necessary functionality. Two basic operations to support account in your app, account registration and account login. Account registration allows your user to log in to register with your app is password and username. And a registered user can use account login to continue participating in your app even on a new device. So that's account.

And you may know, user's privacy and data security are very important for most of the research apps. To help you do that we recommend your app to allow the user to set up a passcode [inaudible] and use it later to unlock your app. Same here there are two basic operations in passcode.

First, passcode creation. It lets user to select a desired passcode. Once the passcode is created, then the app can assist the user to enter the correct passcode to enter the app to use passcode authentication. Now you have learned app access has two parts, account and passcode. Let me show you the account part first.

You see here it's a screenshot of account registration. It lets a user register with your app by providing an email address and enter the possible twice to avoid typos. Next, I will show you this in code. All I need is to create one step ORKRegistrationStep with identifier, title and text. And the last parameter options can be used to provide additional input fields like gender or date of birth. Once I have this step I can put it into a task and present it.

After the step is completed I need to retrieve the username and password from the result object. It's easy to do. I just need to use the predefined identifier to get them. Once I have the username and password I can securely send them to a remote server to create the account for the user. So that's account registration. Next, account login. For the user who already registered want to continue participating in your app.

You see here it's a screenshot of the account login. It allows a user to log in with username and password. Additionally, if a user forgot his password there's a button available for them at the bottom. We only need a few lines code to create this in your app.

Same here, we need a step ORKLoginStep. I create this step with identifier, title, and text. And you may notice the last parameter I need to provide a ViewControllerClass. Why? Because I need to subclass the view controller from the ResearchKit to provide my own custom handler to the action forgot password in case something forgot password and click that button. After I have done this, then this login step is ready to be presented. Now I'm showing you account registration and account login. Next, let me show you how to let your user create an account, create a passcode and use it to unlock your app later.

In the process of passcode creation the user will be asked to enter the passcode first, then confirm it and optionally, if the device has Touch ID enabled the user can opt in to use Touch ID to unlock your app later. You can see here a few steps, but in the code it's really easy to do.

Same I need one step, ORKPasscodeStep and after I create it I recommend you to provide a decryption text to your user to explain the purpose of setting up a passcode. That's all I need to do. Some of you may want to ask where the passcode is being stored, that's a good question.

Let me show you that. From this diagram you can see the passcode is being stored in the iOS Keychain, so it's secure and also telling you the passcode writing and passcode reading are both managed by the ResearchKit, so you don't need to worry about it all. Isn't that cool?

The passcode authentication view controller's delegate provides opportunities to the developers to handle the different result of the possible authentication. For example, if the passcode authentication succeed I can present that function to the users. But if the passcode authentication failed I need to show alert or the passcode authentication is canceled I can show the default welcome screen to the user instead. So that's this delegate and also this new controller is ready to be displayed to the user.

Now I have showed you all the parts in the app access, I hope you find it useful. I can show you the charts. With charts you can present your data to your user. There are three types of charts in ResearchKit, as you can see from those screenshots. There are pie charts, line graph, and discrete graph. Let's zoom into the first one, pie chart.

A pie chart is [inaudible] ring and which is divided into segments. Each of them represent a proportion of the whole and each segment has its own value, color and title. Once you have learned the basics of this pie chart I can show you the code behind this. To code it I need to create this pieChartView first, then I'll assign a data source object to it because the data source object provide all the information to be displayed in the chart.

Now I need to implement this data source, but before I'm jumping onto those functions I need to take some time to set up the data object first. In order to do that I first define a base structure to carry the basic information for each segment in the chart.

You can see from here I defined the base structure with title, value, and color. All the basic information that is needed. Once I have done that I can create the data objects with those structures. Next, I will return them in the functions. Since I already have these objects ready I can create those functions easily.

First, I return the total number of segments, then I return the value of each segment and the value that will be used to calculate the proportion in the ring. After that is a color and the title. After I have done that, then this pie chart is ready to be displayed.

Now you have learned how to use pie chart with ResearchKit. And line graph and discrete graph are quite similar to use. You can simply go to GitHub site, download our simple project to learn from it and you can see the URL on the screen. Branching task, app access, and charts are the three new features I introduced to you today. With them I'm sure you will find doing a research app will be more easier. Now I'm giving it back to my colleague, Bunny, to talk about contributing to ResearchKit.

The reason why ResearchKit has so many great new features is because of our open source community. Many of our contributors are here today and I'd like to thank them. But any of you out there can work with us to make ResearchKit even better, so let me tell you how.

Contributing to ResearchKit is like contributing to any other open source project. Go to our GitHub repo, pick or open an issue and please drop us a line and let us know what you're working on. Then submit a pull request. At that time Apple engineers and active members of the ResearchKit community will take a look at your code and no doubt they're going to have some advice for you on how to improve it. So we want you to work with the review team until everyone's happy. Then your changes will get merged into the master branch.

Sometimes later we'll branch for convergence. At that time you code will have been localized into all the languages that iOS supports, updated for accessibility, and tested on a wide variety of devices and scenarios. We'll also look at your code with an eye towards privacy and security. Now this open source process might seem a little Apple centric to you, but we want to make sure that your code can be used all over the world and by users who have a variety of different abilities and on a variety of different devices. So now that you know how to contribute some of you might have ideas of what to contribute and others of you maybe you don't, so I'd like to give you a little inspiration.

But before I do that we do tag a new stable version at some point and our last stable version is Win.3 that we tagged in January. Okay, so what can you contribute? Of course, you can contribute active tasks, I've already showed you a few. This year we've had a 9-hole peg test contributed and I'd like to thank Julian Therrier [assumed spelling] for contributing that. This task is supposed to be a digital version of a test that's done in the clinic for rehabilitation medicine to test upper extremity functioning.

Now right now this task is undergoing validation in a research study because we don't really know whether or not this digital version is equivalent to the one in the clinic. So validation is really important. When you develop a new task researchers want to know that what you say it's measuring that the task is really measuring that. So you might have to get involved in a little bit of validation study to do that.

The Tower of Hanoi is a puzzle that's commonly used in psychological research and I'd like to thank James Cox for this contribution. I'm sure there are many other tasks out there. In fact, researchers often write to me and say that they would like things like maybe the Stroop, which is the color test or psychomotor vigilance task. So there are many things out there that if you ask researchers I'm sure that you can develop these tasks. There are many other answer formats than what's in ResearchKit I'm sure and I'd like to thank Quintiles for giving us the location answer format.

As you probably gathered from Yuan, the basic thing in ResearchKit is a step and there are always many more steps that could be contributed. I'd like to thank Quintiles once again for contributing a wait step. This step turns out to be really important when you're doing a very lengthy calculation and you want to get the results to the user before they proceed on with other steps in the task.

Modules are encapsulated pieces of functionality that help researchers. Yuan just told you about the charts module, this is a great contribution and I'd like to thank Ricardo Sanchez [inaudible] and James Cox for contributing this. Just about every new ResearchKit app is using this module and it turns out that users love to see charts about their data, their progress in the study, and things about the study.

The genetic basis of condition is of interest to many researchers and right now there are two ResearchKit apps out there looking at genetics. PPD Act is looking at the genetic basis of postpartum depression in women. And MyHeart Counts recently added a genetic component so that they could look at genetics in cardiovascular health. It turns out if you want to collect genetic material from someone, there is an informed consent process that's above and beyond what's required in your app.

So I'd like to thank 23andMe for coming up with the ResearchKit module that shows how to do the -- that has informed consent in it. And right now they're hosting this on their own website, so if you want to use 23andMe to collect genetic data you could go to their website and get this ResearchKit module. And the great thing is that they have complete documentation of how to add this to your app and the modifications that you need to make in your app to make sure that this works really well. I'm sure there are other modules that you could contribute.

Now as I mentioned before, ResearchKit doesn't do anything with your data, so you need to connect it to a data service. If you're someone who provides data services I suggest that you download our sample, ORKSample and you modify it to use your data service, then host that modified app on a GitHub repo, so people can come there and see how to connect their ResearchKit app to your data service. It would be a great help to researchers who are struggling with trying to get that data over to a server.

So after you've made all these code contributions maybe you want to do more. I can see some of you. If you've gone to ResearchKit.org recently you'll see that we feature a number of tutorials written by the open source community. Specifically, I'd like to thank the [inaudible] Blog in France and Raywenderlich.com.

We love to see developers teaching other developers how to code. And if you're one of those rare people who know how to code and write, please find a topic in ResearchKit that you think needs explaining and write a tutorial. Then let us know about it and we'll help you to get out the word. Now while the ResearchKit community has been busy writing, so has Apple.

We've updated the ResearchKit programming guide and reference documentation earlier this year and we also added a chapter to the iOS Human Interface Guidelines to give you guidance on how to write a great ResearchKit app. If you haven't read that, please go out and do so at your earliest convenience.

I have some homework for you. This is your call to action. If you haven't already downloaded ResearchKit framework, please do so today. You'll get access all the great new features that Yuan talked about. Inside the framework you'll see a sample folder and in that is the ORKSample app, we added that this year.

I suggest that you build and run it, it's a great app. It's in Swift, it uses best practices not only for Swift and ResearchKit, but for iOS in general. It has a great architecture for a ResearchKit app. You can even start with that app and you'll have a great start on your own research.

Also build and run the ORKCatalog app. As its name suggests, it's a catalog of ResearchKit functionality. When you run it you'll see what each active task does, you'll get a look at all the answer formats, you can even see what an eligibility survey is like and more. And finally, please make a contribution. ResearchKit is open source and it will become only what you make it.

Everything you need to get started with ResearchKit is on this page, developer.apple.com/WWDC16/234. There's links to the GitHub repo, to the tutorials I talked about, to own documentation, so please look at it. This afternoon I'd like you to join us at the Getting Started with CareKit session. CareKit is a new open source framework that we introduced in March and that will help you to build great apps for people to manage their own care. So with that, thank you and have a great rest of WWDC.