Surveys

[md0u80c9]

Add Nottingham EADL, the Stroke Impact Scale, Epworth Sleep Scale, Rivermead Mobility Index and IQCDE - validated surveys - to ResearchKit.

[rsanchezsaez]

Hey @md0u80c9, thanks for your contribution. I'm not familiarized with these kind of surveys but they look quite useful.

I have not properly reviewed the code, but some comments on issues I noticed:

• All new classes must have the ORK prefix.
• All new files must start with the standard RK license at the top, with your name in place of Apple in the copyright line.
• Do not use true(Swift) in place for YES (ObjC).
• Make sure there are exactly two newlines before and after the #import section in each file as explained in the Coding Style Guide.

Thanks!

[md0u80c9]

Thanks for the feedback. Hopefully all of the above should be addressed.

[umerkhan-apple]

Refactor enum to include to ORK: ORKPrebuiltSurveyType.
Also update all the enum options accordingly such as ORKSurveyTypeNottinghamEADL.

[md0u80c9]

Technically yes. However, research is often imperfect in that sense and there are certain compromises which are made. If there is a validated test in one language, quite often they are not re-validated in other languages.

So as a researcher you have to ask how much you think the changes to the survey from publication may influence it. Something like RiverMead is probably 'safe'. However when you deal with cognition and mood, there may be greater variation - but the study author should have researched the tool before they use it (they are all well-known tools within their fields, so a prospective author would not choose them randomly, and we're really just encouraging people towards the use of 'gold standard' research tools by providing them pre-built and ready to go).

Also beware that US English, UK English and Australian English matter here: if I asked you to pick up a penny versus pick up a dime that may seem a small thing, but if your cognition is already impaired, this may be significant if you don't appreciate what a 'dime' is... I have tried to 'territory-neutralised' the surveys already (hence 'a coin'). But note the Anglicism in Rivermead 'pavements' - En-US would have that as 'sidewalks'...Culture probably matters more than language!

So - in brief it probably impacts on study validity but not so much that someone would suddenly discredit a study. Any study author should have checked out the tools before they use them.

[md0u80c9]

Made the changes suggested - agree they are very sensible.
Edit: Slight mess as a dodgy commit removed the survey source files - revoked that commit and all appears well again.

[umerkhan-apple]

Refactor to Validated surveys.

[umerkhan-apple]

We probably do not want to subclass ORKOrderedTask and override this. Instead, you can have different completion steps and present them based on the score.

We would want to use a ORKNavigableOrderedTask. @rsanchezsaez, do you think we can update ORKNavigableOrderedTask to be able to implement a scoring system? The goal is to be able to display one of the three possible completion steps based on a computed score.

[rsanchezsaez]

I'll look into this in the following days.

[rsanchezsaez]

Is this still a requirement?

I've thought a little bit about it, but I cannot readily think of a simple yet general way of extending ORKNavigableOrderedTask and improving making the predicate logic to support scoring.

One solution would be adding a custom hidden numeric ORKResult held by ORKNavigableOrderedTask, and then modifying the predicate matching logic (and/or defining a new predicate type) to match against this custom hidden result (in additional to the regular predicates). But this sounds a little bit bespoke and quite hackish, maybe not general enough to be of much use. Maybe the subclass is a better solution after all.

Thoughts?

[rsanchezsaez]

Actually, this could be a good use case for a possible ORKBlockStepNavigationRule, as @md0u80c9 suggested here.

[umerkhan-apple]

Maybe we should rename this group to be ValidatedSurveys?

[md0u80c9]

I'm ambivalent towards this - I am happy to do so, but I had intended to match 'ActiveTasks' with 'SurveyTasks' so that the groups flowed (you might want to add some other sort of 'Task'.)

[md0u80c9]

Have updated the branch based upon all the feedback provided from umerkhan-apple - thanks. I have made notes on the areas that I'm a bit less certain about.

Need to look at doing the completion steps later (out of time this morning)!

[p2]

Would these be better suited in an example/sample repository? There are many validated scores and scales. We use two different ones in our ResearchKit app, but we use them in one single survey and load them from file, with other additions such as explanations and extra questions. So I'm not sure how useful it is to have these added hardcoded to core-ResearchKit.

[md0u80c9]

Apologies if this is somewhat off topic. Sorry I've not had much time to contribute anything over the last month - I've been busy with the day job (UK consultant stroke physician, with my research interest looking at the Stroke Sentinel National Audit in the UK - look at www.strokeaudit.org if interested as this could be 'core' ResearchKit territory.)

p2: I agree yes they probably could sit in a repository (this is why they've remained in their current state for now): then again I suspect many of the active Tasks also fit into a similar issue there (they have limited use cases).

I suspect this asks an existential question of ResearchKit: its aims are to bring together lots of necessary components for writing medical research applications. In fairness that probably isn't quite what it currently is or does, although it certainly lowers many of the barriers to writing a medical research application. Its current modules have wider relevance than in medical research - the surveys in particular would be highly relevant in many industrial applications. Equally it lacks health-specific functions which constrain medical research, for example HL7 integration tools which would enable it to interact with hospital systems (transferring data between care providers and users would be extremely powerful for research and patient care). Please note I'm not being critical - it is a brilliant library and I and others are finding it invaluable for developing medical applications - but it's probably not quite what it's described as.

For me the reason to contribute them was to ensure that developers had access to freely distributable, well-recognised and validated scales. I think decisions about where they should live can be taken at leisure really.

My personal view is that I would spin off the surveys, data handling and the core task structure into 'SurveyKit'. This would mean the wealth of other use cases of the survey stuff would be realised. ResearchKit would be dependent upon SurveyKit and HealthKit, would have a library of medical tasks such as the active tasks, surveys, and that probably needs some more of the integration with HealthKit, HL7 messaging support, SNOMED code handling, and integration into existing national and international health datasets, personal health libraries that exist, personal devices and possibly even other medical devices (such as BP monitors, pulse oximeters, etc).

[p2]

@md0u80c9 Regarding health system integration and HL7 standards, our team is working on C3-PRO. Not quite prime time ready yet – although used in our live ResearchKit app – but addresses some of your qualms.

[md0u80c9]

They're not really qualms - ResearchKit is awesome! Just that if we were objective about what is in it, a lot of it is invaluable for generic application authors who need to collect or handle data and in that sense ResearchKit is a misnomer. But for heavy duty research the list I produced above are things that would be needed to allow health providers and patients to integrate the data for research.

Just in my field of study (stroke), an early goal with ResearchKit is to integrate with national stroke datasets. Studying patient sourced data is vastly more useful in stroke when we can link that to all their clinical parameters which in most of Europe and Australia is routinely collected and recorded.

[scdi]

The point that md0u80c9 raises are so vital to moving the research field forward that a healthy discussion with some solutions are incredibly needed. C3-PRO, mentioned by p2, looks like it is intended to address some of those issues. The research community would and has probably benefited from both of your input and your hard work. Thank you both for your contributions. There is so much work already done and so much more to be done. Let's join rank to defeat diseases and all that is unhealthy. We have so little time.

[md0u80c9]

@umerkhan-apple : Is it worth me reworking these as instances to ORKCatalog rather than into ResearchKit itself?

[divyanag]

@md0u80c9 Hey Andrew, love these surveys, quick question for you: you mentioned that the Nottingham EADL, the Stroke Impact Scale, Epworth Sleep Scale, Rivermead Mobility Index and IQCDE are all validated surveys - do any of them have licensing restrictions/share usage restrictions that we need to be aware of?

[md0u80c9]

Hi,

Glad you like them!

I deliberately chose to put in validated surveys that don't have specific licenses so should be OK to use within projects.

[divyanag]

@md0u80c9 Perfect! In order for us to pull this in we need the author/owner of the surveys to send a single email that confirms the following: a) ownership, b) agreement to have the survey posted under the Creative Commons Attribute. Is that something that you'd be able to track down?

[md0u80c9]

Hi divanag,

Glad you like them! I will try to do that. I'm just in the middle of doing some major work on my ResearchKit app which will take up quite a bit of my time in the next few weeks. Interestingly (looking back at this thread) it involves ResearchKit and a lot of HL7 FHIR implementation - lots of proximity to things Pascal Pfiffner has been doing.

However, on reflection I really think I should reimplement these as instances rather than as subclasses.

Given the greater acceptance of Swift now than when I first wrote that - any objections if I did that and resubmitted these as Swift 3 instances, with hopefully some relevant statements as above. Bear in mind ownership on some of these won't directly exist as it depends upon their age etc (but I can get you best possible references to that).

[p2]

Great to hear Andrew! FWIW, I'll be updating our FHIR bridging frameworks to FHIR STU-3 in the next days.

[divyanag]

Hey Andrew- not a problem at all, sounds like the right way to go forward, thanks!

[umerkhan-apple]

@md0u80c9 I agree with your approach on converting these to instances rather than subclasses. You can definitely submit this in Swift! Is it okay to close this PR and expect a new one with the changes?

[syoung-smallwisdom]

@md0u80c9
Hi Andrew, just as a warning: with Swift 3.0, a class that is created in Swift can no longer be subclassed in Objective-c. Not sure that it matters for this, but it's worth keeping in mind.