Clinical Review

• Ask colleagues to test the form, pretending to complete it for a patient
• Check that the form flows appropriately and logically for the relevant workflow. 
• You can test the form against different ‘test patients’ - these are accessed by tapping on the patient name at the top of the form. 
• These are particularly useful when testing visibility rules that use patient age or sex

Quality Check

Carefully work through the form in builder mode tapping on each item considering the following 

DATA KEYS 

• Are these completed appropriately 
• Bottom key should be meaningful – this will come into play with the visibility rules, and in any reporting from decision support.  
• Does the editor/viewer need to see the label? E.g. if there are options of other and other is selected. 
• Does the text box really need a label or just a placeholder?  
• OR would a label only be relevant for the editor but not the viewer?  
• Is it clear what is being asked?  
• Could it be a question for the editor but a statement for the viewer? 
• Key – give it a name! don’t leave it as Boolean_1. This makes everyone’s life easier when doing visibility rules.  
• No spaces in the key name e.g. not health promotion, but health_promotion 

VIEWER/EDITOR 

• Does the viewer need to see this?  
• Do they need to see how the writer got to their answer or just the answer? 

SPELLING 

• The Configurator app has a spell check for Rich Text, but not for component labels 
• Try and write grammatically correct, for example, write the full name before using abbreviations (Alcohol Withdrawal Scale = AWS), or show the full name via a Definition. 
• Using the link to the CDHB Abbreviation policy on the Cortex Designer help site. 
• Think about how this may look for the reader if the patient has gone to an outlying area – General surgical nurses may know that abbreviation but nurses working on the plastics ward may not. 
• Abbreviations can have several interpretations i.e. FBC = fluid balance chart, full blood count. If you’re not sure – check the Abbreviations policy   

VISIBILITY RULES 

• Does the rule make sense?  
• Are questions in the right order for the rule  
• Does the trigger question have the right flow of more questions coming off it?  
• Think about if certain questions are relevant to all sexes and ages – should we be asking for the pregnancy status of a male?  
• What is it all going to look like for the editor and viewer?  
• Remember that any visibility rules for a section or a panel apply to everything within that section or panel 

PANEL  

• Individual statements or questions are ok on their own but if there is a group this should be in a panel.   
• Look at the panel colours – do they signify the importance of the panel

SCHEMA

• You access this by tapping on the patient name at the top of the form. 
• Choose between Clinical Document and Order.  This simply affects the phrases used in the footer.

OTHERS

• Test any links you have included are working correctly. 
• Are there any email addresses attached to this form? 
• Unchecked options – do you want the viewer to see what wasn’t selected?  
• Or only what was selected? 
• Pre-selected options – do you want this? It could lead to editors missing a question because it already looks answered. 
• Mandatory fields (achieved by choosing 'Optional' as 'No') – have a look at what you’ve made mandatory and why. 

Common Issues

‘Other’ boxes

• If have an ‘Other’ text box to appear if ‘Other’ is checked in an option, then may not need a label.  

Using different Editor and Viewer labels 

• The ‘Editor’ label is what the person writing on, or filling out the form will see.  
• The ‘Viewer’ label is what the person who is reading the form will see. 
• Often is makes sense for these labels to be the same, but sometimes they can be worded slightly differently to turn a question for the writer/editor, into a statement for the reader/viewer.  
• The key becomes important when we work with visibility rules.