A model is an abstraction of the real-world distilling knowledge into core concepts and processes. A model is a careful balance between complexity and over-simplification with models that are too complex providing brittle abstractions which are poorly generalisable and models that are too simple not supporting all of the demands placed upon it in real-life clinical scenarios.

Modelling is an art but the approach can be made more systematic if modellers work iteratively within a supporting organisational environment with clinical and technical staff working together in logical teams. Importantly, the scope of their model should be limited; large enough to solve the domain problems but small enough to result in a practical implementation. As such, it is important to have an appropriate separation of concerns in which teams can work independently of other teams as much as possible and that interfaces between that team and others are formalised on a contractual basis.

High-level functional requirements

Clinical modelling is dependent on knowledge of the domain and the functional requirements to which the model will serve. It is useful to abstract these requirements to make them as generally-applicable as possible and not to generate needlessly specific requirements with limited applicability. However, the process of generated functional requirements and a subsequent data and process modelling is not a one-way process but must be an iterative two-way development in which there is feedback and discussion among all stakeholders and between all steps of requirements-gathering, modelling and implementation.

The process of developing a clinical model

I suggest dividing clinical modelling into three related steps:

1. Modelling data within a medical record
2. Modelling processes and workflow relating to a medical record
3. Implementation of a clinical model into a workable and practical solution.

These three steps should be considered separately but are dependent on one another and inherently depend on the functional requirements. In designing clinical information systems, a data model may change infrequently or a design may even be correct in perpetuity; a systolic blood pressure recorded using a cuff on the right arm of an individual will always be a systolic blood pressure recorded using a cuff on the right arm of an individual. However, a model of the processes of care will likely change more frequently as a result of changes in working practices and service design, and an implementation may change even more frequently as a result of new technologies and devices.

As each step is dependent on each other, modelling must be an iterative work with feedback loops between all steps rather than performed in sequence by different members of the team. An implementation cannot be designed without consideration of the data structures and processes that leverage the data within those structures and a model cannot be designed unless it is practical and efficient to perform an implementation. It also follows that clinical modelling must be performed by a team of individuals with a range of skills including those with important domain knowledge such as health professionals as well as those responsible for the design and implementation of the resulting software such as technical architects and software developers.

Traditional waterfall-based design methods emphasise a sequential process involving business analysis and scoping, design, implementation, verification and then subsequent maintenance. Indeed, such methods are commonly used within NHS Wales with a focus on producing a product to solve a particular problem which then becomes “complete” and enters “maintenance”. I strongly believe that this approach is wrong and instead development should by underpinned by a robust model developed iteratively considering both workflow and implementation together with an understanding that any solutions will never be complete.

Modelling the medical record

The breadth of knowledge within the medical record is potentially daunting with multiple types of data recorded in many different contexts and for many different purposes. Such data will need to be shown to users in order for them to make sense of a patient’s condition or clinical course, but also used to monitor a clinical service by providing real-time data on patient flow and progression along one of many clinical pathways.

I advocate a clinical record in which much information is stored in a highly structured format. Some free-text is necessary but where possible, clinical information should be recorded using a standardised terminology such as SNOMED CT held within larger data structures representing the clinical model.

Advances in technology such as new interventions, evolving diagnoses, new diagnostic tests and changing processes result in an ever-expanding knowledge base to which software systems must evolve and adapt. As such, no software system designed to model the medical record will ever be complete and as such, designing for incremental change in the medium and long-term is a pre-requisite. If real-world knowledge is ever-changing, then models too must constantly be refined and evolved. As such, the design and subsequent constant refinement and evolution of any model underpinning a complex clinical information system must be supported by an appropriate organisational structure which facilitates an iterative development approach. Such iterative development requires domain experts such as clinicians work closely in teams with developers to constantly refine their own understanding, focus the analysis of requirements and distil what they know to the core essentials that must underpin the design of any subsequent information system.

Electronic medical records and the importance of context and provenance.

An advantage of electronic records is that such records can be made universally available wherever they are needed such as when a patient presents to an emergency health facility or a new outpatient clinic or when the patient contacts a team via email or telephone. A disadvantage of electronic records is the need for real-time curation of patient records so that users are not overwhelmed by excessive information that is not relevant in their specific clinical context. It is therefore vital that any model supports not only the recording of information but the context and provenance in which those data were recorded and that views of aggregated information for a single patient take into account such contextual cues to ensure users see the information that is required and optionally filters information.

Such issues also arise in paper records, particularly when a single patient has multiple volumes of notes. However, as paper records serve a single organisation end-users may find important information related to their own service based on filing standards, paper colour, logos, page layout and the names of colleagues and can flick through the physical record more easily than a poorly curated and unstructured digital counterpart. However, paper records fail for patients looked after by multiple organisations, in which clinical correspondence from an outpatient clinic in one facility will usually not be available in another unless manual action by end-users is taken.

Modelling the processes involving medical records.

Medical records are more than a simply narrative of what has happened to a patient listed in sequential order. A number of important processes and workflows exist that relate to the sending and receiving of paper-based forms that must be considered in any abstraction of medical enterprise. Paper records such as printed correspondence, request forms, results of investigations are sent to a responsible individual in order for them to be read and acted upon. On some occasions, such documentation is annotated, forming a narrative of the actions undertaken by the end-user or forwarded to another, forming a chain of correspondence. Electronic systems are potentially safer offering guarantees of sending and receiving such requests, providing full audit trail functionality and non-repudiation of comments and action. However, any process relating to a medical record must be modelled with as much care as the modelling of data structures.

Most data standards relating to healthcare, such as HL7, openEHR, and FHIR, model the data relating to healthcare and not the processes and workflow that reflect the care of patients itself. While modelling data is an important pre-requisite in the conception and design of clinical information systems, modelling the processes and workflow that relate to that model is firstly an important test that data modelling is fit-for-purpose and secondly, critical itself in ensuring a resulting clinical information system will be a workable and valuable asset in providing healthcare services.

Process and workflow will change frequently as clinical services evolve and develop and any model must take such changes into account so that any subsequent implementation can flexibly handle different workflows. Abstracting workflow is the most appropriate method to future-proof any clinical system and modellers must then consider how to model the configuration of more abstract workflows into a concrete implementation at runtime.

In most clinical services, data and processes currently revolve around the completion and processing of clinical documents which are subsequently filed as part of a longitudinal prospective and immutable medical record. As such, a transactional document model is usually an appropriate reasonable and accurate abstraction of current processes of care.

Modelling and implementation

Tying a clinical model to its implementation is critical. A model cannot be designed without consideration of its implementation as it is possible to develop models of data and processes that would be impractical, cumbersome or inefficient to implement by developers. As such, close working between domain experts and software engineers is necessary to iteratively explore and improve a model to ensure it meets the demands of the domain and of practical software engineering considerations.

Avoiding mismatches between a model and real-life.

A mismatch between the model and real-life processes may cause confusion for users while models that are based on the fundamentals of a particular domain result in clinical systems that are intuitive to use with readily predictable functionality. A model should therefore abstract real-life processes and structures when possible so that end-users can easily understand what is happening within the software they are using and should not be surprised by unintended consequences. However, modelling real-life processes should not be an exact replica of an existing paper-based process but a careful abstraction designed to capture the essence of the process and to be more widely generalisable.

While organisations, directorates, specialties, teams and even individual clinicians will have their own ways of working with disease and specialty specific data requirements, there is a danger in thinking that data modelling is simply getting a single group of domain experts in a room with a white-board. Instead, such work is simply the start of a process in which these requirements are analysed and distilled and subsequently made as generic and widely applicable as possible and yet not made so generic that a subsequently developed model no longer meets the needs of the original functional requirements.