TABLE OF CONTENTS


Clinicians are the best people to design their own digitised workflows. The Cortex platform includes the Cortex Designer, which is an iOS app that allows a clinician, on behalf of their department or discipline, to build the forms that are then deployed in Cortex. 


It is built to be used by clinicians, so is user friendly and intuitive. Creating a form is as easy as dragging and dropping different components then deciding how the components will interact. Parts of the forms can be displayed conditional on answers to previous questions.  


Terminology

The key terms are: 


  • ‘forms’ - these are structured documents built in the Designer app. Forms are completed to be stored against a patient NHI, to form part of a clinical record. Users (eg clinicians, administrators) can complete forms, edit forms or read information contained in forms, as part of their roles. Forms have an editor view (how they appear to users entering data into forms) and a viewer view (how they appear to readers of completed forms).  
  • ‘components’ - these are the building blocks of a Cortex form that allow different ways of answering questions or providing information within a form.  For example the ‘number’ component allows for entry of numbers only 
  • ‘delivery method’ - these are the methods by which the forms completed in Cortex may be sent to other systems or locations.  These are set up in the Cortex administration portal. Delivery methods include email addresses, printers, and locations in other EMRs or PMSs (e.g. ‘Progress notes’ in the CDV tree of Concerto) 
  • ‘workflows’ - this is the combination of the form and the delivery method.  When a Cortex form is ‘published’, a delivery method(s) may be allocated to that form.  For example, a ‘Gen Surg Outpatient Booking form’ may have the Delivery method ‘Email Gen Surg admin’ <gensurgadmin@dhb.health.nz> attached to it. 
  • ‘living document’ - these are Cortex forms that sit at the top of the Cortex timeline, and allow for updating, including by different users at different times.  There are two types - Care Plans and Clinical Summaries. 


Cortex Workflow Types


There are four different workflow categories available in Cortex: 


  • Clinical Note - forms completed for a specific patient centred interaction.  For example, a paediatric ward round, a physiotherapy initial assessment, a procedure of insertion of an NG tube, or documenting a discussion with a colleague. 
  • Order - a form that requests a service.  For example, lab form to be printed out, a request for orthopaedic outpatient clinic or inpatient consultation which is emailed to an administrator.
  • Clinical Summary - a living document that provides a quick and easily accessible overview of a patient’s current situation. These documents can be repeatedly edited by multiple authors.
  • Care Plan - a living document that guides and documents a multistep longitudinal process, such as nursing Care Plans, Surgical pathways. These documents can be repeatedly edited by multiple authors.



Design Philosophy

When first designing a Cortex workflow, conceptually think that you are building a ‘process’ rather than digitising a paper document. Something that takes a clinician, who may be junior or senior, through a clinical interaction providing both a guide, as well as the opportunity to document what they have done. Where possible, try and design the form to reduce the documentation burden on the editor (completer of the form) and improve readability of the information for the viewer.  


Start simple, and only add complexity if there is a reason for it, a specific ‘problem to solve’.  One of the advantages of the Cortex platform is that it allows for rapid iteration of forms, so that forms can quickly evolve based on experience. 


The priority is always what is best for the clinician, but in addition to simply collecting information about a clinical encounter, there are multiple other problems that can be addressed by Cortex notes.  


The best forms support multiple people in the workflow. For example, a referral for an inpatient consult form will collect information about the current clinical state. Try to avoid requesting information that is already held elsewhere (e.g. in other cortex forms), to reduce the data entry burden for the requesting clinician. However, there is also a need to prompt referrers to include information critical to the receiver of the information to perform their role (e.g. triaging). Consider the administrators needs on receipt of the referral – do they need to know which SMO was consulted to correctly redirect the form (in which case include that) or does the process not require that (e.g. always forwarded to currently on call registrar)?


Consider the situation of the person entering the information into a form.  Are they collecting the information themselves, or observing someone else doing it (e.g. ward rounds)? Provide formatting to support clinical processes. Will the form be completed over a few minutes after the clinical encounter (e.g. documenting a procedure), or during an interaction (e.g. a family meeting)?


Consider the clinicians reading the form. There are often many more people reading notes than those completing them.  


Consider data analytics. If data collected in a form is potentially important for reporting or analytics, consider the type of component used, phrasing of the question, provision of definitions to assist the clinician in answering the question, role of SNOMED coding, etc. BIDA (Business Information Data Analytical team) provide data analytics related to Cortex, and are happy to be involved in design of Cortex forms to ensure the data extraction process is as efficient and clinically useful as possible. 


Governance

Governance for Cortex forms is based around departments for medical forms, the Allied eHealth group for Allied Health forms, and the Nursing e-Documentation group (reporting to Nursing IT group)  for nursing forms. 



Each of these groups should have a Cortex representative. The role of this representative is: 


  • Be the link between the Cortex Steering Group and the department/service to receive information about new functionality, to provide feedback to the CSG and Sense Medical, etc.
  • Be the contact point for queries from the organisation's application support team about Cortex forms.
  • Authorise publication of Cortex forms for that department/discipline.
  • Arrange review of Cortex forms periodically.
  • Have authority to make requests for analytics on behalf of the department/service. 


The Cortex Steering Group provides oversight for all aspects of Cortex, including content (tasks and workflows), and works with the developer Sense Medical on improving Cortex. 


Design Process

  • Consult the wider team and key stakeholders, including those who will complete the form and those who will read it and use the information.
  • Test the form in simulations. 
  • Start somewhere, tending to simplicity rather that complexity.  But don’t worry too much.  Learn quickly from the experiences and iterate. 
  • The goal is that a naïve user should be able to pick up Cortex, and use the form without any additional training or instruction.

 

Clinical Documents in Cortex can address a number of considerations simultaneously, and so need a different perspective to simply turning paper notes into an electronic version.  Consider the following when designing a workflow: 


Workflow guide 


  • The structure of a note should follow the logical progression of a patient encounter.  As Cortex notes can have layers of dependent questions, it is possible to have several possible workflows within the same note, but only the relevant one would be shown to the clinician depending on answers. 
  • This can also be used to provide a form of Clinical Decision Support.  For example, recommending thromboprophylaxis depending on answers regarding risk assessment and contraindications. 
  • Insert useful links at appropriate stages of the workflow.  For example, link to the Starship antibiotic recommendations at the point the clinician would be choosing which antibiotics to use for a paediatric patients.


 

Checklists for clinical quality 


  • Checklists, if properly used, have been shown to improve clinical quality. Provide prompts. Frame the checklist about improving patient care and safety not about compliance with a metric. For example hand hygiene is about helping everyone keep patients safe not about recording someone didn’t do it.


Tips and Tricks 


  • At the start of a Cortex note you can place a box saying ‘Show me tips’.  If checked, then within the document you can place simple advice which shows if the tips option is checked, such as what questions to ask when admitting an abdominal pain.  This function is very popular with junior clinical staff and we’ll be continuing to improve this with future versions of the form builder.


Structuring forms 


  • Use sections for major divisions in a form.  Use panels to groups together related questions - panels can be copied and pasted with all of their questions and so are useful for creating blocks of questions that repeat elsewhere.   
  • Use Rich Text headings to create structure within a panel.


Structured (categorical) vs unstructured (prose) data capture 


  • A very important consideration is ease of use. Forms that are quicker than paper to fill in for the same task are very popular and improve workflows.  Touch screen tablets make tapping boxes, buttons and lists very fast, in comparison to entering free text. 
  • It is a balance though. Some clinical tasks rely on thoughts gathered during consideration of problems, and the act of careful documentation by typing may support that work flow better. 
  • Experiment with a combination of structured (eg tickboxes, lists, options) and unstructured (free text) data.  
  • In addition, building questions using structured categorical data (i.e. a defined group of possible answers) also allows this data to be easily analysed for research and audit purposes.  So, where there is common information collected in a clinical note, this would be better set up as a structured question.  For example, if there is a list of common presenting conditions for a service, this could be set up as a question with a dropdown menu of those common conditions, and then they can choose ‘Other’ and enter free text for uncommon presentations. 
  • Use definitions to help clinicians know how to answer categorical questions.  For example, how to allocate a patient to smoker or ex-smoker.  This is important if SNOMED coding answers for reporting reasons. 
  • This will develop over time.  It is okay to begin with blocks of free text, then after a period of time see what information is within that text and if there are common themes whether that is better addressed by a structured question. 
  • When feedback received take time to consider it. Don’t make every change. Correct errors while letting other issues embed for 6 weeks or more before seeking feedback from multiple end users. Ask both data enters and readers of documents. Often there can be tension between the two. Get them in the same room and flesh out the differences and come to consensus. Note many people will initially be quite fixed that their way is best. Allowing them to hear other people's points of view can be very useful for standardising process.