User/Patient Relationship

[wmfeuvrel]

Hi Corey, I would like to ask you about the User/Patient entity relation. I haven’t discerned how they are related in your code. While the entity Task has a pointer to care plan, and carePlan a pointer to Patient, no such relationship appears to exist for User/Patient. In order to support queries between these two, it appears that I would need to add this relationship. Is that correct?

[cbaker6]

Hi Michael, thanks for your question. Below I will discuss how the relationships can be established, but they will differ depending on your app requirements:

While the entity Task has a pointer to care plan, and carePlan a pointer to Patient, no such relationship appears to exist for User/Patient.

This is true. The following relationships are all based on CareKit only (I don't add anything custom to these because everyone will use CareKit differently):

• OCKPatient <-> Patient
• OCKCarePlan <-> CarePlan
• OCKTask <-> Task
• OCKHealthKitTask <-> HealthKitTask
• OCKContact <-> Contact
• OCKOutcome <-> Outcome
• OCKRevisionRecord.Clock <-> Clock

So any links between them are based on whatever CareKit's documentation specifies. When a User (I will get to this in a second) is logged in and tied to a specific OCKPatient or as I like to call OCKPerson as CareKit uses OCKPatient to represent any person, animal, etc.

In order to support queries between these two, it appears that I would need to add this relationship. Is that correct?

All queries, saving, updating to the entities above should only be done using CareKit. If you modify any of the entities above and save to Parse directly, you will most likely cause a devices OCKStore to get out of sync with your server. When necessary, CareKit will ask ParseCareKit to sync any data with the linked Parse Server. If you want to force sync, you can do so through CareKit which will pull any changes linked to the current logged in User. If you setup your uuid's like I mention below, you don't have to force sync as ParseCareKit will use LiveQuery to automatically update new changes (assuming you are using parse-hipaa. I mention this in the README as well:

You should never save changes to ParseCareKit classes directly to Parse as it may cause your data to get out-of-sync. Instead, user the convertToCareKit methods from each class and use the add or update methods from the CareStore. For example, the process below is recommended when creating new items to sync between CareKit and ParseCareKit

Tables (or Classes in the Parse Dashboard) such as User, Session, Role, Installation, and Audience, are all ParseObjects. If you want to create your own relationship between a ParseObject and a OCKEntity, you should do so by following the directions here. More information about how to use ParseObjects can be found in the Parse API Documentation. Changes to ParseObject's can/should be saved directly. For example, the ParseCareKit sample app saves the user when it logs in here. In the README of this repo, https://github.com/netreconlab/ParseCareKit#synchronizing-your-data, I mention:

The uuid being passed to ParseRemoteSynchronizationManager is used for the Clock. A possibile solution that allows for high flexibity is to have 1 of these per user-type per user. This allows you to have have one ParseUser that can be a "Doctor" and a "Patient". You should generate a different uuid for this particular ParseUser's Doctor and Patient type. You can save all types to ParseUser

In fact, something similar is done in the sample app here. CareKit itself currently only supports 1 OCKPatient per OCKStore as was discussed here. If you use the uuid like I mentioned above, you should be able create multiple OCKStore's to represent each OCKPerson and open each one when you want to view sync that particular data. If you setup your ACL like the sample app then all items synced will be owned by the current logged in Parse User. To grant access to doctors, care givers, etc, you can use Roles and Relations. To learn how to use Roles and Relations in ParseCareKit, look here and the API documentation is here. You can also do this my modifying the ACLs, CLP's, etc., but this will get harder to manage as your app grows.

Of course, what I mentioned is one way, you may need to come up with other ways depending on your use case.

[wmfeuvrel]

Thank you for your detailed response. I am continuing to work through my use case and your response shed some light on the path forward.