Clinical Modelling Basics

To exchange clinical information in a computable way clinical computing systems need to express, store and exchange clinical data in the same format.  In the clinical domain requirements and definitions of clinical concepts can change very quickly and need to be adaptable to new purposes, so a traditional waterfall style of development is often not the most effective way of delivering or managing this requirement.

In Health Informatics the concept of a ‘Clinical Archetype’ is firmly established.  This is a definition (a model) of a clinical ‘concept’ such as a ‘weight’, a ‘height’ or a ‘blood pressure’ that can be used by a computer system.  The archetype contains places to store all the items (elements) of data that are needed to fully define the concept.  This may include, for example, a ‘clinical term’ to describe the concept such as ‘Blood Pressure’, and places for values or comments.  Terms would normally be taken from a standard clinical terminology (Read Codes or SNOMEDCT), whereas values and comments may be numbers or text added by end users.

For example, a computer model of a ‘Weight’ record would need values for a Date of Measurement, a Description, a Value and Units of Measurement for the value.  A record in a computer system could look like:

• Date: 14-Oct-2013
• Description: ‘O/E Weight’
• Value: 70.5
• Units of Measure: kg

From these archetypes clinical software suppliers can provide ‘templates’.  Templates use only the elements of archetypes that are needed for the current task, leaving out things that may not be of relevance at that time.  For example, a ‘blood pressure template’ may not use the ‘blood pressure archetype’ elements of ‘cuff size’ or ‘position’, if not required for that particular application.  The template author may only want to use ‘Systolic’ and ‘Diastolic’ elements to provide a simple form for recording blood pressures.  Templates can use elements from different archetypes at the same time, allowing for the provision of complex forms and reports for systems users.

Designing clinical archetypes requires the contribution of clinicians.  As the primary end users of archetypes, clinicians need to be confident that they are complete and safe; that they enable accurate and meaningful recording of clinical data in computer systems; and that they support clinical care.  In other words: clinical review is essential to make the archetype ‘fit for purpose’.

The challenge lies in gathering the clinical requirements in a format that allows rapid and agile development and deployment, and in bringing together clinical users and system developers.  The solution we are working with to solve this makes use of a clinical archetype and template editing tool called ‘Clinical Knowledge Manager’ (CKM).

Clinical Knowledge Manager is an internet based, collaborative tool that provides functionality to design, edit, review and publish clinical archetypes and templates.  It can export to XML formats, allowing for rapid deployment.  Version tracking and reviewing functions allow for flexibility in adapting to new or changed requirements.  Face to face meetings of the reviewers are not normally required.  Use of the archetypes in real systems is only ever possible when the communities of reviewers agree that they meet their requirements, and when value in implementation is clear and apparent.  By distributing the work of designing clinical models systems suppliers benefit by not having to duplicate work done elsewhere and by achieving agreement on data structures, reducing the need for mapping and re-engineering of their software.

To support safer medicines in Scotland there is a requirement to establish computable models of ‘Allergy’ and ‘Medication’ records.  In this document the term ‘model’ means a representation of clinical concepts that a computer system can then use to store and exchange the data reliably.  In this case the models we use are ‘archetypes’ and ‘templates’, as described above.

NHS Scotland has developed a number of different models for representing medications and we have several proprietary clinical systems (such as INPS Vision and EMIS PCS) with their own models for medications.  Because all these models are different, systems are not able to reliably exchange data with each other using electronic messages.  To solve this we are using CKM to collaboratively design archetypes that will encompass the requirements of all the stakeholders in NHS Scotland.  In effect this means designing a single model for medication.

Outputs of this work will:

• Reduce costs for development
• Reduce times for implementation
• Support the clinical requirements
• Support system suppliers requirements
• Reliably exchange structured data across health care systems (inter-operability) thus being a key enabler for the ‘Closing the Loop’ initiative.
• Support the development of a single medication record for Scotland
• Support patient facing applications
• Support innovation and development of new applications on new platforms
• Reduce medication and prescribing errors when patients transfer between care providers.

The same issues also apply to ‘drug allergy’ records – again stored in many different ways in different systems.  Work on bringing together a common ‘drug allergy’ record for exchange of data was already well advanced by the GP2GP project in use in England.  Providing a model for this was also identified as a priority for NHS Scotland because it can provide significant safety benefits.

Using this method of exchanging data means that the records can be processed by the receiving system.  That is: they are computable, rather than just displays of the information.  They can therefore be used to automatically populate electronic prescribing systems, enable computerised decision support and reduce or eliminate re-keying, transcribing errors and associate clinical risks.

The dose versus product problem

Fundamental differences in the methods used by prescribers to order medications for patients in community versus hospital settings adds complexity to the ability for medication data to be safely exchanged when it crosses these care boundaries.

In hospital ‘in-patient’ settings, prescribers order medication by describing a dose to be administered, without direct reference to the actual product used to supply this dose.  This is then translated by pharmacists and those administering the medications to an equivalent using actual products.  For example, the medication order ‘Furosemide 60mg orally at 8 am’ would be supplied and administered as ‘Furosemide 20mg tablets, take 3 tablets at 8 am.’

In community prescribing prescribers order medication with direct reference to the product.

The consequence of these differences is that to reliably exchange prescribing data across the care boundaries requires the provision of computable ‘medication directions’, sometimes referred to as ‘Dose syntax’.  This will reliably allow the translation from a product based order to a dose based one, and visa-versa.

Significant progress on the modelling of this has already been undertaken by dm+d and NHS England.  EHealth in NHS Scotland has agreed to support further development of this work to progress it to a practicably implementable state.  This is required to deliver key outcomes of ‘Closing the Loop’.  Review and agreement of the models for Dose Syntax will be supported using CKM and the reviewing processes outlined in this document.