--- title: "Care Plan Developer Guide" canonical: "https://wiki.patientsknowbest.com/space/DEPLOY/4768530433/Care%20Plan%20Developer%20Guide" format: markdown --- > Macro (toc) # 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
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](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 - Care plans are two directional communication platforms, in the sense professionals can send a plan to a patient, then patient fills with his answers, which then professionals can check. For this case when the professional would like to be sure that no changes happen after the patient filled in the input fields, he can lock the plan. This is important in cases like when the plan includes sensitive data like medicine prescriptions. - There are check in the backend when patients try to edit locked plans - see related e2es in the PR. - PR for the feature: [https://github.com/patientsknowbest/phr/pull/8351](https://github.com/patientsknowbest/phr/pull/8351) - Select option colouring - For this feature `JavaScript` is needed to be used, to update the select tags class based on the option chosen by the user. This could be done in the safest way that we the onchange method - `this.className = 'form-control ' + this.options[this.selectedIndex].className;` - is whitelisted explicitly on select tag in `phplan-filter-policy.xml`, so everything else is filtered out. - PR for the feature: [https://github.com/patientsknowbest/phr/pull/8971](https://github.com/patientsknowbest/phr/pull/8971) - Some other PRs that can be helpful examples of how care plans work: - Radio button and checkbox alignment and colouring: - [https://github.com/patientsknowbest/phr/pull/8465](https://github.com/patientsknowbest/phr/pull/8465) - [https://github.com/patientsknowbest/phr/pull/8501](https://github.com/patientsknowbest/phr/pull/8501) - Display full name of the editor and creator of care plans: [https://github.com/patientsknowbest/phr/pull/8484](https://github.com/patientsknowbest/phr/pull/8484) - Remove ‘Edit’ button when pdf care plan is sent via HL7: [https://github.com/patientsknowbest/phr/pull/8615](https://github.com/patientsknowbest/phr/pull/8615) - Whitelist collapsible elements in care plans: [https://github.com/patientsknowbest/phr/pull/8745](https://github.com/patientsknowbest/phr/pull/8745) - Update care plan input fields and add custom multiple column display: [https://github.com/patientsknowbest/phr/pull/8815](https://github.com/patientsknowbest/phr/pull/8815) - Fix time input display: [https://github.com/patientsknowbest/phr/pull/9182](https://github.com/patientsknowbest/phr/pull/9182) - Whitelist telephone number linking in care plans (if a plan is opened from phone it is easiest for the user to just click on the link that is injected to the telephone number and call the number straight away). This was done with the Select colouring feature, the relevant files from the PR is listed below: [https://github.com/patientsknowbest/phr/pull/9182](https://github.com/patientsknowbest/phr/pull/9182) - apps/phr/phr-service/src/main/java/com/pkb/util/security/CustomStyledHtmlFilter.java - apps/phr/phr-service/src/main/resources/phplan-filter-policy.xml - pkb-end2end/ui-tests/src/test/resources/hl7-testdata/care-plan-with-telephone-number-in-link.html