Building Rules - Before you start

Due to the flexible nature of the Pathway Developer, there is no "set" way to build Pathway rules, unlike a wizard which assists users in constructing the end product. The caveat to a wizard is that a it applies some level of restriction as you must complete one step before proceeding onto the next. The Pathway Developer allows you to freely construct any parts of your pathway in no particular order.

The information below is considered best practice and is for guidance purposes. It is based on experience, however is by no means a complete listing.

As developers build rules and become proficient, they have their own styles. As with computer coding the same statement could be written in many ways. The same applies to Rules being built using Pathway Developer.

The steps that a developer will go through when  creating a pathway are usually the following:

• Create a Codeset File.
• Create Rule Nodes and enter Rule Lines within them.
• Create outputs which can be in the form of:
• Notification alerts.
• Lists.
• A template.
• Mail Merge fields for Recall letters\ patient information letters.
• CSV extracts generated at the practice.
• Central report extracts automatically generated on a dashboard.

Best practice.

• Specifications.

In order to start building a pathway a detailed specification is crucial for development. If requirements for a pathway are based on guidelines that have flowcharts, then your pathway will emulate those flowcharts. Workflow and Guideline tiles can be used as part of the specification and development process.

Reporting and extract requirements should all try to be part of the specification in order to evaluate if they can all form the same pathway file.

• Read\CTV3\Snomed codes.

These are required in advance to build Codeset Files.

• Codeset Files.

You must have at least one Codeset File in place before you start building Rules. Rule Nodes cannot be constructed without being linked to a Codeset File.

Codeset Files can be built and amended simultaneously. However best practice suggests you try and construct as much of the Codeset as possible. Amendments to the codeset files are envisaged as the Rule is being developed.

• Layout.

Empty Ruleset Nodes with a description can be used to help with layout where possible.

Practice Lists\ Extracts\ Mail merge\template Rule Nodes could be kept together in sections of a Rule rather than being combined in a single Rule Node.

Layout advantages.

1. By separating the functions of a Rule Node, changes to a component will not impact on the other components. E.g. a change of criteria for a practice report Rule Node for Asthma patients will not impact the extract for Asthma patients Rule Node.
2. Easier to locate if kept together rather than spread out throughout a rule.
3. Saves replication of the same rule.
4. Easier to maintain between developers.
5. Easier to support and view through indicator logic.

Examples:

Fig 1 shows an example where the user has separated the Rules into individual sections and components in the pathway, using empty Rule Nodes as placeholders.

Fig 1.

Fig 2 shows an example where the user has combined a template, data extract and report into one node..

Fig 2.