/
Care Plan Developer Guide

Patients Know Best Wiki Hub | Deploy | Developer | Trust Centre | Manual | Research | Education | Release Notes

Care Plan Developer Guide

 

Care Plan Actions

Care plans actions are managed in ManagePlansAction.class - this is a not well written class, with a lot of complicated methods. Creation, edition, persistance are all managed here.

 

The plans are going through a validation process, which does two things:

  • First happens when the HTML template is uploaded and we validate if the given HTML is satisfying our guidelines. So e.g. if a plan doesn’t start with a <div> tag we render out it as a textarea. This happens in PlanWebBean.formatPHPlanAsHtml()

  • Secondly, we have a validation to filter out XSS injection, which happens in PhpPlanCustomHtmlFilter. We filter the plans with a Safelist, which consists the tags and attributes that are allowed and we use that in cleanWithJsoup. Also we use AntiSamy to filter the malicious elements in the care plans. For that we have an xml called phplan-filter-policy.xml, where all the valid attributes and styling classes are defined for each tag.

Edit and View Mode

  • Care plans look different in edit and view mode. In edit mode we render out the whole HTML so users can interact with them. However, in view mode the values of the input fields are rendered out, which cannot be changed on that page. The way care plan is rendered out in view mode also handled in PlanWebBean in method called expandHtmlWidgets()

  • We wanted to keep the flexibility of care plans, so there is no validation for checking if the user only edited the input fields and didn’t try to send some malicious element in the care plan. Those things are filtered out, but we don’t traverse through the whole latestSaved version of the plan section and compare it to the one we got from the frontend. The issue is that plan page is kind of a form in a form and it makes it very complicated to validate in the previously mentioned way. If a stricter framework is required, advance questionnaires can be used.

  • Care plans are quite flexible, but we tried to centralise the styling rules and avoid using inline styling so that the plans have a more of a standardised display. The styling can be found in _plans.scss

  • For testing we had the same aim, so all the plan related e2es constants can be found in CarePlanConstants including plan names, selectors and plan elements.

  • In e2e tests we assert the care plan’s HTML in one line, which makes it kinda impossible to spot the difference if the test is failing. Best thing to do is to is creating two HTML files anywhere in project in IJ and paste the expected in one of those and the got HTML to another and use compare. By that it is more visible what is the difference - in many cases there are spaces that removed or something that is not visible on the display. Assertion of care plan HTML should happen in a way that it is not in one line and visible for the dev what lines of the HTML are actually problematic.

  • Other important file for testing is Hl7TestReasources, where we store the paths of the HTML files that are uploaded by coords as care plan templates.

  • PhPlanCustomHtmlFilter is also important for some of the newly introduced features including non-editable sections in care plans as we add the disabled flag for the fieldset with cp_pro_edit_only_paragraph class in cleanWithJsoup method.

  • The frontend classes are the following: for view mode of care plans we use viewPlan.jsp and when editing a plan editPlan.jsp is rendered. Later is more interesting as there is a bit of JavaScript in it, which does things like triggering autosave and for that updating the HTML input fields with the new values and also it filter out HTML elements that weren’t in the latest saved version e.g. for action plan part it uses lastSavedActionPlanText.

    • There is a bit of issue with this validation, as the JS code is visible in the inspector of editPlan.jsp, if the client updates the lastSavedActionPlanText and does the same modification in the DOM as well those changes are saved. We decided that it is okay, as hackery users can mess up only their plans and vulnerable elements are filtered in the backend anyway in PhPlanCustomHtmlFilter.

  • In general standard display textual data "only" tags are fine. Their attributes and events still need to be limited, but other than that they cannot really cause much of a problem. Of course data injected always need to be properly escaped etc. The problematic parts are the ones which can run code of any kind, inject code, change code execution in any way, send / share data, allow extraction of data etc. But mostly its about running code in one way or another. If we can solve something with standard tags which don't require any JS / CSS trickery or additional library, then its better to do so, but can be done in certain cases with making it explicitly limited to that use - see example in 'Select option colouring' section.

  • Also for developing a new feature it is the best to ask product and talk with Lloyd, who puts together care plans so can give a good feedback about how in practice it would be used.

Some Features That Extend The Logic

Non-Editable Care Plan Sections

  • There was a need to introduce a section, which can be edited only by team professionals and no one else. We use fieldset tag and need to add cp_pro_edit_only_paragraph class to it, so in the edit mode of plans the fieldset tag gets a disabled flag if a non-team professional is editing the plan. The disabled flag is added dynamically and handled on the backend in PhPlanCustomHtmlFilter.cleanWithJsoup. Also a short HTML block is added for non-team pros to emphasise that is a pro only editable section and this is handled in the same method as mentioned before.

  • PR for the feature: https://github.com/patientsknowbest/phr/pull/8362

  • We also have checks in PhPlanCustomHtmlFilter, to be sure the user didn’t change anything in the pro only section, in a method called: checkNonEditableFields()

Care Plan Lock Feature

Patients Know Best Wiki Hub | Deploy | Developer | Trust Centre | Manual | Research | Education | Release Notes

© Patients Know Best, Ltd. Registered in England and Wales Number: 6517382. VAT Number: GB 944 9739 67.