The letters IDCR are currently used in the NHS in England as an abbreviation for Integrated Digital Care Records, part of the latest push to transform health and care in England in the 21st Century towards more holistic, integrated, patient-centred care, supported by the right healthcare IT.
The abbreviation IDCR is the latest in a line of health IT abbreviations or keywords to symbolise the information technology that healthcare needs/wants/requires. Those include EPR (Electronic Patient Record), EHR (Electronic Health Record), portal, SCR (Summary Care Record), CDR (Clinical Data Repository), patient registries, etc, etc. Though such terms and abbreviations might suggest that the health IT “buyer” has a range of technical products from which to choose, it is increasingly understood that any of these tools are simply technical artefacts amidst a sea of change.
That 21st century healthcare change that is upon us is a “complex change challenge” made up of people, process, information and technology. We also know that to make such complex change happen we need a mix of clinicians, managers and technical team to work together, for the greater good, for the patient.
Involved in such change over the last years, I’ve seen many related change efforts and am aware of the significant challenge in aligning clinical, managerial and technical language and purpose effectively towards these noble goals. There is often an inherent tension between the clinical/business change desired and the technical tools on offer. Ideally a well informed clinically led team will have a deep understanding of the process they want to improve and access to/control of a technical tool that meets that clinical/business need. More often these multidisciplinary teams are convened towards a common health improvement goal, yet a little/lot unclear on how the IT will get them there. In many cases this desire for change ends up as a clinical and business push ends up tied to a likely technical product. The current push in the NHS around Integration Pioneers and Vanguards and Integrated Digital Care Records is a case in point.
Clinicians who join these explorations and discussions often struggle initially for a reference point. They may cite the health IT system that they themselves know and/or love/hate, it may be a clinical guideline (or related proforma) that they have a particular interest in having supported in this new world, or a particular clinical report that they want/need to support here and now. They use these as reference points as these are the healthcare information and knowledge artefacts that they know.
In bringing clinicians together around a healthcare improvement/IT project (e.g. EPR, IDCR, Registry etc etc) to gauge their “clinical requirements”, then analysing those requirements to generate a related system design etc, significant clinical time and real intellectual effort is required by all those involved. If the aim of these efforts is about patient centred healthcare improvement, the focus of these efforts could/should involve a look at clinical guidelines, forms, reports etc to inform the approach. Yet if one teases apart just one clinical guideline, one discovers the rich tapestry of information and knowledge embedded within. Splitting a single guideline apart in technical terms into the clinical content, workflow and clinical/business rules involved helps explain how and why traditional approaches to programme and project management struggle at scale in this field. The lengthy, detailed documentation that can result from such efforts to elicit “requirements” does little to contain the challenge here. Indeed such an approach to procurement and the related documentation can become a key part of the change challenge… and so a key gap between clinical need and technical direction can begin to emerge..
Is there an alternative approach to this “complex change challenge”? We think so.
Firstly we emphasise the word complex, to reinforce that this change challenge is about managing complexity, more akin to curating an ecosystem than crafting a machine. We offer the following tips based on our experience of these challenges at scale and with some reference to the helpful Gov.uk Government Digital Service standard.
Tip #1
Q: How to quickly scope a clinical change project with health IT? A: Put the user in charge of these (clinically led) proceedings, with the support of an agile design team. Follow the principles of User Centred Design and Agile Development with early “wireframes”/”mock-ups”/prototypes. The tools involved might be as simple as a sketch on paper, a PowerPoint slide or an online mockup tool (e.g. Lumzy.com). Either way this allows the clinical teams to express their needs and wants in terms of usability.. perhaps the most critical factor in health IT adoption. If their ambitions are big and dreamy, so be it, it’s a vision to aim towards. Of equal value, these visual designs help management and technical colleagues discuss and establish what is “do-able” within the time and budget available. Such prototypes are perhaps the simplest and most effective way for clinicians, managers and technical folk to communicate the scope of the change involved. A picture tells a thousand words.
Tip #2
Q: Where to focus the early effort in a major healthcare improvement project with health IT? A: Focus the diversity of the clinical community involved around its common interest in core/generic clinical content. One of the main challenges in bringing a multidisciplinary team together is the difference in culture, language and agendas in the room. Such discussions are full of rabbit holes for the unwary. (Try agreeing a consensus definition in such a room on terms like “Care Plan” or “Care Pathway” if you want to while away some time). Aim your focus on getting the clinicians in the room to find their common ground.. the needs they both/all share. These common needs are invariably linked to the core generic processes in health and care, although this is often poorly understood by those in the room. On a related note, focus firstly on the shared clinical content that is required, but not the workflow or rules involved. While consensus on clinical content can be gathered more easily (via openEHR archetyping for example), clinical workflow and clinical rules are generally less amenable to early consensus.
Tip #3
Q: Who should own this requirements & design process? The healthcare customer or IT supplier?
A: The healthcare customer, aka the clinical lead and core clinical team involved, supported by “in house” project management and technical architecture expertise.
In our experience there is a compelling case that the process of requirements analysis and the related design authority should be overseen/owned by the healthcare “customer”. This should ensure that these key aspects are guided by the clinical need, not by the supplier want.
We would go further to suggest that you aim to ensure the key clinical requirements captured in this process are opened up and widely shared. That could/should include both the visual mock-ups (e.g. JPGs etc) and clinical content specifications (e.g. openEHR archetyping helps again here) – so that you have captured and kept these in a vendor neutral format for supplier engagement purposes, while other clinical colleagues can learn from, reuse and recycle this same material.
The natural extension of this thinking is to suggest an Alpha “Discovery” phase to bring early health IT requirements to life in an open source reference implementation. The potential benefits here are at least three fold, its serves as (1) method of engaging the healthcare change project team with proof of what can/cannot be easily done (2) a means of bridging the significant gap between local frontline health change agents and national health IT standards setters (3) a means towards a “bi-modal” health IT strategy – keeping your future options open/avoiding vendor lock in
Experience in Leeds has highlighted these 3 key tips in a real life setting while illustrating the nature of such change. What began life as the Leeds Clinical Portal project morphed over time into the Leeds Teaching Hospitals EPR platform (named Patient Pathway Manager +). That in time became the platform that has served/is serving the Leeds Care Record, an Electronic Health Record for the people of Leeds. That journey from portal to EPR to EHR was not about swapping technical artefacts in and out, it was about change in a complex environment. Change that was clinically led, user centred in design, agile and evolutionary in development. That journey continues today in the ethos.
So if you think you are in the market for an IDCR… think again.