A recent discussion between colleagues from the anaesthetic community in the UK centred on what can best be described as the granularity of an anaesthetic record. Put simply, is there a need to include every possible detail of every drug, procedure, device and event in the record, or is it sufficient to use some time-honoured abbreviations and shorthand, as alluded to by the title of this blog?
Can information be omitted because its inclusion is inferred, in some instances? For example, when performing a neuraxial block, a clinician may record the following in relation to infiltration of the skin with a local anaesthetic agent:
Nothing – the skin infiltration procedure is inferred
LA to skin
Lidocaine to skin
1% lidocaine to skin
2ml of 1% lidocaine to skin
2ml of 1% lidocaine to skin, 23g needle
We can see a step-wise increase in the amount of detail recorded for this brief and very simple procedure.
[For the non-clinicians, the procedure is used to provide analgesia (pain relief) at the skin entry point, prior to the insertion of a larger gauge needle.]
How much detail is sufficient and under what circumstances would more detail be warranted? Should the batch numbers of both the drug and the needle be recorded? Arguments in favour of the ‘maximum detail’ approach may point toward patient safety, drug and equipment inventories, cost control and the medico-legal aspects of care, should there be an adverse event.
Most of us could probably agree that maximal detail is desirable, but it has to be balanced with what is practical in the care setting. Time spent jotting down the minutiae is time that could (or should) be spent observing the patient.
A possible compromise is to use technology to assist with the record keeping. Two options present themselves:
Assistive features for data input in a digital care record system or AIMS
A speech interface for data input to same
Looking at option 1 in more detail, ideally the UI would present a touch-screen interface where the user can select a pre-defined procedure (such as a neuraxial block). The application should have the ability to create, store and switch rapidly between user profiles, so that the UI recognises and adapts to the clinician interacting with it. If a clinician has previously set up a template for a neuraxial block, then in theory, a record containing the maximum detail could be created in just one or two button touches on the screen.
The option to edit the template is essential, for those days when the 23g needle supply has run dry, and a 25g is used instead.
Next to the screen there may be a QR code (or barcode) scanner that can scan and identify the local anaesthetic agent and the needle. One touch to confirm each, and both drug and device are recorded.
Option 2 is just as flexible, and with modern speech and command-based interfaces, a UI could (also in theory) accept voice commands. For example:
[Command Word] Record the administration of 2ml 1% lidocaine to the skin using a 25 gauge needle
This option is being explored in a discussion paper, with a view to building a prototype for proof-of-concept. A subtle adaptation would be for the command-word to identify the clinician, so that they don’t have to announce themselves each time to attest a new record entry.
Scaling Up The Detail
I chose a very short, minor procedure to illustrate the point about potential benefits of novel interfaces to digital records. Taken at scale, the time and effort required to record larger, more complex procedures could be reduced drastically, with many secondary benefits to safety and quality improvement.
If you’re interested in helping to build a PoC prototype, or to join the group over at SCATA looking at speech interfaces to AIMS, please get in touch.
In recent times, there has been renewed interest in the UK from Health Care Entities (HCEs) in the purchase and deployment of Anaesthesia Information Management Systems (AIMS). The drivers of this change are a topic for debate, but after the demise of the Connecting for Health programme in NHS England over a decade ago, HCEs have had greater freedom to make purchasing decisions on applications and IT infrastructure that suit their local needs, rather than top-down impositions from a national programme. This has resulted in a more mixed economy of systems than would otherwise have been the case, had the national IT programme been a success.
Other drivers may include the capability of point-of-care devices (PoCDs) to communicate data in a structured format such as HL7-FHIR, an international standard that has a comprehensive implementation guide, and is popular with developers. In the past, medical device communication was often based on rudimentary standards such as RS-232, a generic communications protocol that was adapted for medical devices.
A further boost has come in the form of mature, reliable wireless communication standards suitable for use in clinical environments. Even the revolution in flat screen LED and touchscreen technology has played a role in encouraging the spread of information management systems. The traditional anaesthesia monitoring system, designed to record and display physiological data from the patient in real-time is often accompanied by a separate screen for viewing and recording additional data relevant to the perioperative care episode.
In spite of these developments, there is anecdotal evidence that the increased prevalence of AIMS in the immediate theatre environment isn’t having the desired positive impact on care that would be expected. This document discusses the challenges for implementers of AIMS and makes suggestions for how they can be overcome.
What’s in an AIM?
A good place to begin the discussion of the challenges is to outline the scope of AIMS. In general terms, the broader the scope of an application, the more complex its UI/UX becomes. Another way of saying this is that the more ‘bits’ you add on to an application, the harder it becomes to use it and the more likely your UI will be cluttered and unwieldy. Compare this to (say) a simple application that performs one task well, such as a dose calculator or one-page assessment form.
Considering the scope of an AIMS, the following list describes the main items and data points that are likely to be included:
Patient Demographics (name, identifier, date of birth, gender/pronouns)
airway – type, size, procedural details e.g. intubation grade
breathing system
assisted ventilation
TIVA/TCI – devices, regimens
Physiological Monitoring
Fluid balance
Post-anaesthesia care
Fluid prescription
Oxygen
Analgesia
Other medications e.g. anti-emetic, thromboprophylaxis
Care destination and level
figure 1 UK National Anaesthesia Record Project Summary Schematic
The benefits of AIMS
Safety
time spent on direct care rather than documentation
decision support
Economic
track costs and activity more effectively
Better data quality and more accurate coding
Promotes audit and quality improvement
Legal aspects of improved fidelity, legibility and accuracy of data
The benefits of AIMS can also be explored through typical use cases for the records they produce. It can be helpful to think of the application as being separate from the data it creates. In other words, think of the application as being the ‘front’ of the AIMS, displaying data and interacting with the user through the User Interface (UI), whilst in the background, collecting and storing data from PoCDs. Depending on how the AIMS is configured, there may be a wealth of data points in the record, not all of which are surfaced through the UI.
Use Case 1
A typical care record for an anaesthetic episode where the purpose is to display data from devices in real time, allow the clinician to record events and if necessary, review trends and other data points relevant to this episode. At the end of the case, the clinician checks and attests that the data is accurate before closing the record. The granularity of this ‘live’ record is greater than would be expected in a summary, but still doesn’t include every recorded data point that exists. Some information is hidden for ease of display.
Use Case 2
If, at a later date, another clinician involved in the patient’s care requires the record of a previous episode, this should be possible. Rather than retrieve the entire record, there should be an option for a ‘summary view’ that highlights the key elements, in particular whether there were any adverse events.
Use Case 3
In the situation where an incident or adverse event has occurred, there is likely to be a requirement for the full detailed record to be surfaced via the application. This would include every data point, including its provenance. For example, which device was recording heart rate, what was the result of the pre-use check of the anaesthesia workstation, etc.
Barriers and Dis-benefits
The likeliest barrier to the purchase and implementation of AIMS is cost. Not only is the initial outlay significant, the procurement will likely include implementation and training costs, support agreements, product lifecycle licensing agreements, hardware and networking costs.
HCEs that have AIMS tend to be the larger centres with greater budget flexibility.
Demonstrating value or RoI is challenging, as many aspects of AIMS are replacements for (or extensions to) existing paper processes. Changing to a digital model can bring ‘soft’ benefits that are hard to quantify. For instance, how many adverse incidents are prevented by the automated logging of data by the software, rather than by a clinician, by hand? It can be argued that automation frees the clinician to observe the patient more closely. Equally, it can be argued that making manual recordings focuses the clinician on the patient, at times when their attention may be elsewhere.
AIMS enable many more data points to be collected per case, and the data points may be more structured than a paper record. A greater level of detail is valuable for the analysis of adverse events, especially when a concurrent automated record of the physiological variables is available. Unfortunately the additional data points come at a cost – more time spent logging events and procedures into an application and less time focussing on the patient and the progress of surgery.
There’s a possibility that clinicians may get overloaded by software that presents too many data points, and makes too many requests for data input at key moments in the care episode. Good UI/UX design can overcome some of these challenges but the principles outlined in the much-shared article “Why Doctors Hate Their Computers” are pertinent to this environment too.
Over at SCATA, a small team are working on an implementation guide in HL7-FHIR for a structured anaesthetic care record, focussing initially on the intraoperative phase. If successful, the guide will allow developers to implement AIMS with a standard information model (in FHIR) that will solve many of the issues with current AIMS, especially semantic interoperability i.e. the ability of systems to exchange records seamlessly.
Alongside this work, there is an embryonic demonstrator project that is designed to assist developers in either building a new FHIR-standards-based record, or extending their existing AIMS to support creation and export of a FHIR-based record. Ultimately, the aim (pun intended) is for AIMS to be supported globally by an internationally-agreed standard FHIR-based information model which is open and non-proprietary.
In a recent post, we talked about the challenges of describing medical devices such as needles, tubes and catheters in a structured format. The existing device HL7-FHIR resources and OpenEHR archetypes are weighted in favour of electro-mechanical devices, rather than those of the non-communicating “dumb” variety.
The efforts of the SCATA Open Standards Working Group to tease out the unique properties of the non-electro-mechanical devices may ultimately bring a new set of resources that manufacturers can leverage to describe their products in greater detail, in a standard way.
2D Barcodes
As of 2022, according to wikipedia, there are 43 different 2D barcode systems. This number is likely to change as different systems are adopted as standards, or fall away through disuse.
Product manufacturers use barcodes extensively for a variety of purposes. For better or worse, the 2020 pandemic has given the QR code a real shot in the arm – pun intended. Although not unique to the QR code, it has the ability to encode a URL which can be scanned using the camera on a smartphone. The smartphone can then give the user the option to open the URL in a browser. We’ve become familiar with this routine in the form of the check-in at the entrance to restaurants, pubs and clubs, with the URL essentially taking the user to a form where they input some personal information.
Linking the QR code URL to an Open API
An extension of this idea imagines a staff member with a smartphone in healthcare scanning a QR code on the packaging of a device such as an ET tube or a CVC kit. The URL is an API call (most likely a GET) with the ID of the product as a parameter.
An example might be https://someopenapi.com?deviceid=1234567
Clearly, there is a debate to be had about who manages the API, how many APIs are needed (just one, or one for each supplier/manufacturer?), how products are validated and what happens if validation fails, the product is missing, or the data returned is incomplete or inaccurate. Also, the actual ID of the product will have to be universally unique – not a major challenge to generate, but with significant overhead on the part of the supplier (or intermediate data controller) to manage and maintain.
Leaving those concerns aside for a moment, vendors are familiar with printing barcodes (2D or otherwise) on their products. If, as a result of scanning a 2D barcode on a product, a smartphone browser-based app could return data from an API, then in theory it could pass that data to an application, which can then store it.
Our intent is to build an open API prototype as a proof-of-concept, to demonstrate that using the camera on a smartphone, a healthcare worker can populate a section of a clinical record, namely the properties of a device (or devices in the case of a kit) used in an episode of care.
A recent project in the UK to create structured documents for shared decision making (SDM) in healthcare got me thinking about what happens in perioperative care. After gathering my thoughts in the obligatory mind map, I began to think about the differences and challenges.
perioperative SDM mind map v1
The key challenge in perioperative care may be the time available for the care decision process. In the remainder of this post, I’ll focus on ways in which SDM can adapt to time constraints in a perioperative journey.
Service Users
Considering perioperative journeys, we can think of service users as falling broadly into one of three categories.
never had surgery
occasional surgery for unrelated conditions
frequent flyers
For adults that had surgical procedures in early childhood, you might put them in the first category, as the procedures are unlikely to be relevant when making choices about surgery as an adult.
For adults in the second category, experience of past surgery may have an impact on present choices, but if the current procedure is unrelated to past procedures, a whole new set of choices are likely to be made.
Lastly, there is a cohort of adults that attend regularly for similar or identical procedures such as cystoscopy or other screening-type procedures. For this group, choices are generally less important, although there may be important differences in the choices of the healthcare professional (HCP) in terms of the conduct of the procedure. For example, an HCP might have a preference for general over neuraxial anaesthesia for cystoscopy. There is potential for a clash between the patient’s preferred option and that of the HCP. A key goal of the SDM process is to document and attempt to resolve these differences, recognising that there are situations where the knowledge and experience of the HCP can be the primary determinant of the choice made.
Healthcare Professionals
In addition to the biases that come with procedural experience and familiarity, HCPs also tend to focus on benefits while ignoring or understating risks and known complications. SDM tooling could (in theory) help to overcome some or all of these biases.
The seniority of the HCP is a factor. A given procedure will have a different complication rate in the hands of a more experienced operator, so this has to be factored into the SDM somehow.
Information about risks and complications should be presented in a way that is understandable and contextualised, preferably using pictures, as there is evidence that verbal descriptions of risk are widely misunderstood1.
Perhaps most important for the HCP is the time allowed for the SDM process. The subject matter for discussion may be extensive, and increases with the complexity of the procedure. For a new complex procedure with a limited amount of peer-reviewed evidence in its favour, the HCP may have a difficult task ahead of them in reaching a decision to undertake it, especially in an anxious, risk-averse service user.
To explore all the choices fully takes time, a commodity that few HCPs have in plentiful supply in their daily routine.
Brief Encounters
A well-trodden pathway for surgical pre-assessment is for a patient to have an initial telephone or video call with an HCP from a designated service, often a nurse. The practitioner usually follows a structured assessment protocol, with conditional logic to determine whether further enquiry or investigation is required. In many cases, this is the only assessment recorded before the service user attends for their procedure. There are instances when, due to administrative error, even this initial step is missed.
A shorter and more challenging pathway exists for urgent and emergency care, when the assessment may have to be done in parallel with initial treatment or resuscitation. In extreme cases such as emergency management of the unconscious patient, no verbal assessment is possible. Instead, the practitioner relies on any digital records that may exist and the results of physical examination.
Between these two extremes, variation is possible, but for the majority of elective (planned) surgical cases, the initial telephone or video consultation becomes a baseline assessment for the HCP responsible for care on the day of surgery. For anaesthesia in the UK, this is likely to be a consultant, SAS doctor or experienced trainee, but the immediate pre-operative visit in either the ward or reception area is often carried out by a trainee or an anaesthesia associate. Given the pressures on the surgical service, another variation is that the immediate pre-op assessment can be done by a colleague who happens to be free at the point where the patient arrives, or when an operating list crosses fixed time-period boundaries. An example is when an operating list finishes earlier than expected, a colleague can use the time for assessment of cases on other lists, even though he or she will not be involved directly in a particular list or case.
Unilateral Decision Making
Consideration must also be given to situations where a decision has to be made quickly, with or without involvement of the patient. For example, when new information or investigation results become available and the patient is under general anaesthetic or sedation. Clearly, without waking them up, by necessity any decisions made must be unilateral. A patient that lacks capacity may have an unexpected complication and there are no next of kin to contact for guidance. In these situations, a common approach is to include standard clauses for “any treatment necessary in an emergency” in the paper and (increasingly) digital consent forms that patients are asked to attest to before a procedure.
Putting all this together, it becomes evident that there are real challenges in SDM for perioperative care, with different HCPs involved at different times, and many procedures being done by staff that either haven’t met the patient before, or been involved in their care.
Meeting the Challenge
To address these issues, the anaesthesia profession in the UK have made efforts to build a common information repository for service users. The goal is to reduce both variation and wheel-reinvention by health care providers, and to give a peer-reviewed, controlled and consistent message. In addition to these digital services, traditional information leaflets are available.
As popular as they are, these digital resources have potential for improvement. Their proliferation can make the task of finding the right information for a given procedure or condition more difficult. Using internal hyperlinks within the documents can help a service user to choose between the options, but ideally, there should be a single UI that can be queried for a given procedure.
Currently, other than during assessments (remote or otherwise), there is no simple mechanism for users to ask questions of the service provider, set preferences or goals for treatment, or enter into a discussion about treatment options more generally. One can argue that this functionality sits in the domain of the personal health record, or a shared record summary, but given its importance in maximising safety and efficiency in the care pathway, efforts to design a standard for SDM become all the more exigent.
Summary
In the UK, surgical and anaesthetic services face critical pressure and their ability to deliver good outcomes is contingent on meeting the wishes and expectations of the service users through shared decision making. Digital tools such as pre-assessment pathway management, remote consultation and peer-reviewed information repositories go some way toward meeting the goal. Further progress requires a simple, intuitive interface to the user’s SDM record, so that they can confirm, edit, annotate and comment upon decisions about surgical care and anaesthetic techniques and procedures. A standard format for an SDM record would go some way towards achieving this goal, and it’s incumbent upon the profession to engage with ISOs to ensure that any proposed standard is fit for purpose.
The SCATA Open Standards Working Group met early in 2022 to discuss Martin Hurrell’s proposal to enlist the help of the HL7 Devices group to author a FHIR Implementation Guide for the intraoperative phase of anaesthesia, based on his domain analysis model. This will be a challenging piece of work for a number of reasons. Although the scope is limited to just the intraoperative phase, we agreed that beyond the common FHIR resources such as Patient and Practitioner, there will be a requirement to either extend or create new resources to express fully all the concepts in the domain.
Things With Plugs
Anaesthetists are familiar with point-of-care devices (PoCDs) to monitor the patient and to deliver drugs in the form of IV infusions. PoCDs have enjoyed a lot of attention from the standards community. The ISO/IEEE 11073 (2020) standard for device interoperability has its own FHIR implementation guide. Looking at this in more detail, it’s evident that PoCDs are mainly electro-mechanical. Put another way, they are things with plugs.
In the context of anaesthetic and surgical care, many specialised devices are not electro-mechanical. Needles, tubes and catheters are all devices in the sense that they are manufactured, have a specific purpose and require training and expertise to wield safely. How should we record and represent the many and varied properties of invasive devices such as needles and tubes in a care record?
Defining invasive
Needles, tubes and catheters have many properties. Before looking at them in detail, it may be worth clarifying what we mean by invasive in this context.
Our working definition of an invasive device is one that is inserted into a body structure via the skin or into an existing body cavity.
Immediately, we can see a problem with this definition. Leaving aside congenital sinuses and cavities, in addition to the mouth, nose, anus, urethra, vagina and external auditory meatus (ear canal) we must add the various -ostomies, the commonest in our domain being tracheostomy, and we mustn’t forget the eye, which is protected by conjunctiva rather than skin.
Perhaps more problematic is agreement on how far a device has to penetrate a body cavity or structure before it can be called invasive. We have a spectrum of invasiveness from ‘very invasive’ such as vascular and radiological procedures, to ‘minimally invasive’ and ‘hardly invasive at all’. It’s the latter that is most problematic. Nasal cannulae/prongs only enter the nostrils by a few millimetres, if at all and are classified as non-invasive. What about nasal cannulae for HFNOT? They enter the nasopharynx – does this mean they are non-invasive or minimally invasive? In our classification below, we’ve opted for non-invasive, but it’s far from black and white.
Physical or Functional
It’s helpful to think about invasiveness in terms of whether a device crosses physical or functional boundaries. A device that punctures the skin crosses at least one physical boundary, and possibly more on its journey toward the target. A device inserted into a space such as the oropharynx is crossing a functional boundary – the mouth. The mouth doesn’t normally play host to physical devices so anything placed there, even on a temporary basis, is crossing a functional boundary. When we reach the oropharynx, another functional barrier is crossed. Objects placed in the oropharynx normally elicit a gag reflex – a protective mechanism. Continuing on the invasive spectrum, tubes placed in the trachea cross the larynx which can be considered both a physical (vocal cords) barrier and a functional (avoidance of aspiration) barrier. In this scheme, nasal cannulae enter the nostrils but don’t cross any physical or functional barriers, whereas HFNOT cannulae pass through the nasopharynx and are therefore, by definition, more invasive than nasal cannulae.
Specialised Airway Device v1
Common Properties of Needles, Tubes and Catheters
Now that we have a working definition of invasive, let’s consider the types of invasive devices that could be used in a typical intraoperative care episode. At this stage, we’re constraining the list to needles, tubes and catheters. Typical examples might include:
vascular cannulae (composite needle/cannula) and catheters
regional and neuraxial block needles and catheters
invasive airway devices
urinary catheters
Before looking at their properties, we should clarify some terms.
A cannula, according to wikipedia, is a tube that can be inserted into the body, often for the delivery or removal of fluid or for the gathering of samples.
In other words, it’s a type of tube. We don’t need to worry too much about needles or trocars inside cannulae at this stage, but we need to consider the distinguishing features of the three devices – needle, tube, catheter.
Rigid or Flexible
In our devices mind map (see below), we have a property type that is enumerated as [needle, tube, catheter]. If we had to elaborate further, we might say something about rigidity, or its converse, flexibility. There is a spectrum from rigid to flexible that begins with large-bore needles, progressing to fine-bore needles, PVC and rubber tubes and ending with soft, flexible catheters. Rigidity is determined by material, gauge and in the case of rubber and PVC, to an extent, temperature. Rigidity can be modified, either by heating or cooling, if it has an impact on the ease with which the device serves its purpose. An example would be the refrigeration of nasogastric tubes to increase rigidity and facilitate passage into the oesophagus.
It can be argued that needles and catheters are just a type of tube made of different materials. Taking this analogy further, some devices are formed from two or more tubes bonded together.
The Lumen
In attempting to classify needles, tubes and catheters, we can think about them as one or more lumens, each with its own properties, sometimes bonded together. A double-lumen endobronchial tube is essentially two single-lumen tubes bonded in a specific configuration. A triple- or quad-lumen central venous catheter can be thought of as three or four lumens bonded together, identified by gauge, colour and the configuration of their exit points – tip, side, proximal or distal.
Putting all this together, we attempted a mind map that tries to tease out common or related properties. The current draft in XMind is here.
healthcare device v1
As will be apparent from the thumbnail, there are a lot of device properties. In the remainder of this post, I’ll try to highlight the more controversial decisions about what properties are common to the device, and those that sit more comfortably as properties of the lumen.
Common Properties
Material
Looking at existing care records, it’s evident that occasionally, we like to record special device features such as reinforced tube and insulated needle. Other properties that might be considered worthy of recording are included as shown. The substance that a device is made of would normally be part of the manufacturer’s specification – something that we’ll come back to.
It would be unusual for a device to have multiple lumens composed of different substances, but if you can think of a use case, please get in touch.
Depth Markings
Typical examples might include Tuohy needles (centimetres) and many types of catheter.
Other Properties
The remaining common properties are shown above. Some properties such as eponymous label could be extended and are best implemented as a value set linked to a terminology such as SNOMED-CT.
Lumen Properties
Finally we come to the properties of the lumen(s). These are illustrated best, with accompanying notes, in the mind map, but a summary follows.
number (1..n)
connector type
push-fit
luer lock
connector size
15mm
22mm
colour
tip configuration
bevel
angle
blunt
rounded
pencil point
non-return valve
exit port
end/tip
side/wall
distance from tip
metrics
gauge
length
diameter
hub
cuff
position
volume/pressure
type
number (1..n)
purpose
filter
antimicrobial
particulate
air
pore size
sensor integration
thermistor
co-oximeter
specialised function (e.g. suction)
Size Matters
The multi-lumen central venous catheter (CVC) presents a problem for the model, as it has both a size property for the catheter itself, generally 7F (French Gauge) for an adult, and a size property for each of the lumens. The latter are normally given in SWG, just to confuse matters further. As a consequence, we require two size properties – one for the device as a whole, and another for the lumen(s), recognising that for single-lumen devices, the metric will be the same. The model can cope with this, as we can constrain out any redundant size properties for single lumen devices.
Conclusion
Having set out these properties in as much detail as we can, the next task is to build a model in one of the open frameworks. So far we’ve mentioned HL7-FHIR but in the interests of inclusivity, we should also mention OpenEHR. The two frameworks have important differences in the way that they approach the design and implementation of clinical models.
Larry may have been the first clinician to understand the challenges and to propose solutions. Almost half a century later, we are still grappling with them. Should a clinic letter from Breast Surgery be filed under “Surgery” or “Breast Surgery”? In other words, how should surgical specialties be sub-categorised?
When an anaesthetist encounters difficulty performing an epidural for a mother in labour, how should the details be recorded – what is the difference between an “attempt” and a “pass”? How should the concept of “guidance” be recorded: is loss-of-resistance part of the guidance element?
Questions of this nature are hard to answer – there will be a variety of views expressed by clinicians. When software engineers design, build, test and deploy software for the medical marketplace, they may solicit input from clinicians to help tease out some of the thornier problems. Developers may not understand fully the relationships between different concepts in medicine. This process is ‘clinical curation’, and unfortunately it’s often a case of rinse…repeat.
You might argue that what’s needed is a Clinical Terminology service such as SNOMED-CT. The trouble is, terminology will only get you so far. Sure, you now have access to about a hundred different concepts that relate to “blood pressure” but when you’re building your application, how do you pick the right concept for the context in which the blood pressure is being measured?
This is where clinical models are essential. They capture not only the concept, whether it be coded in SNOMED-CT or some other terminology, but in addition, they show how the concept fits within the clinical context. The leading clinical modelling framework is OpenEHR. In future posts, I hope to demonstrate how OpenEHR models provide a clear path to application development, without the headaches and overhead of thrashing out relationships and semantic meaning in medicine.
The other framework that you may have heard of is HL7-FHIR. There is lively debate in the clinical modelling community of the relative merits of OpenEHR vs HL7-FHIR. I’ve posted a few links below that will give you a flavour of the dialogue between the two communities.
