{"action":"created","issue":{"url":"https://api.github.com/repos/ResearchKit/ResearchKit/issues/745","repository_url":"https://api.github.com/repos/ResearchKit/ResearchKit","labels_url":"https://api.github.com/repos/ResearchKit/ResearchKit/issues/745/labels{/name}","comments_url":"https://api.github.com/repos/ResearchKit/ResearchKit/issues/745/comments","events_url":"https://api.github.com/repos/ResearchKit/ResearchKit/issues/745/events","html_url":"https://github.com/ResearchKit/ResearchKit/issues/745","id":162633658,"number":745,"title":"HL7 CDA support (+ printing)","user":{"login":"md0u80c9","id":3925834,"avatar_url":"https://avatars.githubusercontent.com/u/3925834?v=3","gravatar_id":"","url":"https://api.github.com/users/md0u80c9","html_url":"https://github.com/md0u80c9","followers_url":"https://api.github.com/users/md0u80c9/followers","following_url":"https://api.github.com/users/md0u80c9/following{/other_user}","gists_url":"https://api.github.com/users/md0u80c9/gists{/gist_id}","starred_url":"https://api.github.com/users/md0u80c9/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/md0u80c9/subscriptions","organizations_url":"https://api.github.com/users/md0u80c9/orgs","repos_url":"https://api.github.com/users/md0u80c9/repos","events_url":"https://api.github.com/users/md0u80c9/events{/privacy}","received_events_url":"https://api.github.com/users/md0u80c9/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-06-28T08:48:41Z","updated_at":"2016-08-27T09:22:21Z","closed_at":null,"body":"IOS 10 HealthKit adds support for HL7 CDA documents. ResearchKit would benefit from printing support. CareKit has PDF rendering but not CDA support.\n\nHL7 CDA is an XML Scheme which incorporates text and user readable objects with machine-readable ontologies such as SNoMED.\n\nParticipation in research (or self care through the 'expert patient' model espoused in CareKit) generates clinically useful data. Many research trial components are built upon standard health assessment tools. At present this data is stored in data structures from ResearchKit apps, but are isolated from the rest of the healthcare ecosystem because they cannot be easily imported or exported.\n\nLack of built in printing support requires developers to 'roll their own' - again adding a further barrier from other health professionals being able to use ResearchKit data from an individual, even with that author's permission.\n\n\nThis proposal is intended to work towards both: implement output into CDA XML for ResearchKit (and CareKit by extension), and we can then gain printing support by adding a stylesheet for the XML, which would be customisable by the developer.\n\n\nMy apologies that I can picture how this is achievable in Swift using protocols, implementation in Obj C may be trickier.\n\nCDA consists of a header containing the health provider and patient's details, and a structured body using standardised sections. The former clearly should be a combination of data already in HealthKit (I guess there may need to be prompts for missing data items as part of onboarding for CDA-supporting apps). The latter will need API developments.\n\nFor active tasks, they could be expected to return a chunk of XML with the results.\n\nThe survey components are the biggest area where there needs to be careful structuring to produce the XML. We don't want to post-process this data so the best way would be to structure the survey input around generating the output.\n\nWhat I would propose is to extend the ORKSteps and ORKForm components. Each one should optionally be able to be associated with a SNOMED code for their action. They would need certain flexibility: Booleans for example would have three variants: a) have a code or not have a code; b) have a code for True and a different code for false; or c) ascribe a value to a SNOMED code of true or false. Multiple choice is likely to be choosing between or producing a list of SNOMED codes.\n\nWe then need to think about the steps themselves. I suspect we would need a way to group steps together to produce the sections for the structuredbody - these would be ORKSteps (or a single ORKFormStep), but instead of having UI they pushed start and end sections to the final document.\n\nA 'calculated output' step would also be useful. This would also have no UI but allowed post-processing of previous ORKSteps into text output or SNOMED codes inline - rather than post-processing when ORKResult is returned. This also allows addition of text components or section information where we aren't adding information.\n\nI would assume the resultant XML would be provided within the ORKResult object and ready for inclusion into the users HealthKit resources. \n\nwe would want the option to validate the data to check it would be acceptable to HealthKit before any attempt at import (as use cases may mean not putting the document into HealthKit but sending it to medical teams so having valid XML is important).\n\nPrint support is therefore done by adding an XML Schema over the top.\n\nCareKit would have similar benefits and in fact the processing of its PDF printing would probably be doable the same way - make the XML instead, and add a Schema for printing. \n\nChallenges with this: the principle one is that I can see how the APIs for this are quite easy to do in Swift - each step or form object would comply to a set of protocols: if an object complies to the providesUI protocol then it is a UI component (all current survey components would come under that category). If it complied to the providesSNOMED protocol we know it is generating SNOMED codes; providesCDAXML tells us it is providing a chunk of XML etc without overloading the initialisers. Can't quite picture how this goes together so easily in objective C, but then again my Obj C is relatively rusty by comparison to my Swift these days.\n\nProbably lots of issues I haven't considered yet too.\n"},"comment":{"url":"https://api.github.com/repos/ResearchKit/ResearchKit/issues/comments/242906662","html_url":"https://github.com/ResearchKit/ResearchKit/issues/745#issuecomment-242906662","issue_url":"https://api.github.com/repos/ResearchKit/ResearchKit/issues/745","id":242906662,"user":{"login":"md0u80c9","id":3925834,"avatar_url":"https://avatars.githubusercontent.com/u/3925834?v=3","gravatar_id":"","url":"https://api.github.com/users/md0u80c9","html_url":"https://github.com/md0u80c9","followers_url":"https://api.github.com/users/md0u80c9/followers","following_url":"https://api.github.com/users/md0u80c9/following{/other_user}","gists_url":"https://api.github.com/users/md0u80c9/gists{/gist_id}","starred_url":"https://api.github.com/users/md0u80c9/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/md0u80c9/subscriptions","organizations_url":"https://api.github.com/users/md0u80c9/orgs","repos_url":"https://api.github.com/users/md0u80c9/repos","events_url":"https://api.github.com/users/md0u80c9/events{/privacy}","received_events_url":"https://api.github.com/users/md0u80c9/received_events","type":"User","site_admin":false},"created_at":"2016-08-27T09:22:21Z","updated_at":"2016-08-27T09:22:21Z","body":"Hi,\r\n\r\nJust thought I should update on this. I've made some great progress over the last couple of days (having finally had some time to do some writing).\r\n\r\nI've decided that the objective for the PR will be Level 1 HLA support - that is to support the user-visible text components of HL7 CCD only; but the project will contain some design decisions to support the more complex Level 2 support (ie. to support SNOMED coding).\r\n\r\nThere will be crossover with @oliverschaefer's proposal re. printing support. Producing HL7 CCD documents will effectively negate the need for printing - because the XML schema is by printable by design. It will also solve a lot of issues of data interchange, so hopefully an exciting PR.\r\n\r\nSo far we have created 'ORKHL7Fragment' subclasses of ORKResult. Tasks now return its results and can contribute fragments of an HL7 document; we use the result's identifier and add an HL7CCD prefix to the identifier to denote HL7 fragments.\r\n\r\nORKSteps will have the option of a 'default' result (which will basically report standardised results either as lines of text, or in a table, depending upon the format).\r\n\r\nI've introduced a delegate for TextFragments, so when you write an ORKStep for a task you can allocate a delegate to make the text string rather than use the default result for that step. This will be preferred when using Survey steps in professional applications as the user gets a properly constructed document, rather than unqualified results. More complete tasks are likely to be able to construct a default result which is self-complete.\r\n\r\nFragments are preferable to complete documents because we should allow ResearchKit app authors to combine multiple ORKTaskResults into an ORKCollectionResult to produce the document (ie. a complex app with multiple tasks wouldn't make one document per task, it would aim to produce one document per 'session'.\r\n\r\nMy next task is to start to work through the HL7 CCD specification to define and gather the necessary inputs for rendering the document (ie. patient details, provider details, etc). This may take some time as HL7 CCD is not exactly the easiest document in the world to read!!!\r\n\r\nI then will need to extend the different ORKSteps and ORKTasks to have HL7CCD text output. This should be a simple but lengthy task to extend and then check them, and then ensure we have valid CCD documents at the end.\r\n\r\nWe also will need some user interface for these components to send to the document store, email the documents, and other such things an app may need to do.\r\n\r\nImplications for ResearchKit/CareKit/HealthKit:\r\n\r\n@oliverschaefer: Really sorry as I appreciate there is a big crossover to the printing PR. I think this will be a better longterm solution as we not just gain printing but coding, document storage and retrieval, and import/export to/from EHRs.\r\n@umerkhan-apple and @YuanZhu-apple : this might be a really useful addition to CareKit too - thought may need to be given into closer crossover between ORK and OCK.\r\n\r\nLevel 2/3 HL7 compliance will be more challenging as we will need to work out how to represent SNOMED codes and their associations, and then update steps to support SNOMED coding results for the tasks. I think this is the time we should look at libraries of surveys etc (such as the Surveys PR I submitted some time back), as having a library of SNOMED-compliant survey tasks is really powerful.\r\n\r\nBest wishes,\r\n\r\nAndrew"}}
{"actor":{"display_login":"md0u80c9"}}