Menu Close

Technical Feasibility Focus Group

By Dr Tom Foley, Dr Fergus Fairmichael.

Participants

Dr Wai Keong Wong, Consultant Haematologist UCL
Prof Brendan Delaney, Professor of Primary Care Research Kings College London, Project Coordinator and Scientific Director TRANSFoRm project
Mr Seref Arikan, Software developer at Ocean Informatics
Prof Tony Cornford, Associate Professor in Information Systems, London School of Economics
Mr John Fellow, Analyst, Centre for Workforce Intelligence
Dr Fergus Fairmichael

Synopsis

Interoperability

The underlying challenge is one of interoperability.  Health record systems are not designed to facilitate interoperation with other health records, other structures or to capture more than a minor amount of clinical connection.  Their primary aim is to provide instant access to health records for those involved in an individual’s care.

There are two key challenges that relate to interoperability:
• Heterogeneity of data.  Data structures vary, terminologies differ, there are often mapping problems and concepts may not match up
• Loss of depth of meaning.  Often what is recorded in the EHR does not reflect what took place in the clinical encounter.  There are different codes used, important negatives are often not recorded and context is often lost.

Design

Technical feasibility is also related to specialisation of design into particular use cases.  Often the functionality reflected in a particular implementation of an EHR locks its data into that particular use case and does not lend itself to other purposes.  The EHR repository (how you keep, serve and process data) is extremely specialised and inflexible. Systems often evolve for their purpose, such as a small GP system, which would fall over if you hit it with a query against the whole population.  It has not been designed to operate at that scale.  The assumption is often made that we can leverage big data and process huge amounts of data held within EHRs, but it is simply not always possible.

Technical approaches to improving data quality

There are three approaches to improving data quality.  They are not mutually exclusive and could be used, in combination, to aid improvement:
1. Natural language processing (NLP) can be used to impute meaning and this can be incredibly useful for rich text sources but ultimately, it does not change what it is that is being recorded by the clinician.
2. The use of intelligent dynamic templating systems, where the system tries to facilitate what the clinician is recording and can enrich the structure and clarify.
3. In some cases input data directly from devices into the system, e.g. BP machines

30 years ago some believed that eventually, the patient would be able to enter their symptoms and the computer would make the diagnosis.  We have moved away from that and now recognise that decision support systems will augment the clinician.

EHRs are very expensive and difficult to build and maintain as they are often built to serve particular needs at a particular time within an individual provider.  There is a significant technical challenge in delivering reusable software platforms and there is a need to think about generic flexible systems with an infrastructure that can accommodate different uses.  One of the challenges for computer science and informatics is developing a methodology that that allows a problem to be solved today that has the potential to scale to solving multiple problems in the future using the same components. 

Standards

There is a need to push for adoption of standards. Constantly building a bespoke link between systems is a very expensive method that may not be sustainable.  There are tools to create standards and there are standards bodies.

There is a role for government in leading the development and promoting the use of standards, however there should not be a reliance on government and there should be a role for everyone to play.  Standards should be produced through standards bodies and these can be open standards with ecosystems in place to facilitate this development.  These standards should apply internationally where possible.

Experience

There was discussion around examples of projects which may provide valuable insight for the development of the LHS.  The TRANSfORm project (http://www.transformproject.eu/) highlights the need for a variable mix of slightly different technologies to be applied despite the similar principles across platforms.  Another project called tranSMART (http://www.transformproject.eu/) provides a research platform for linking clinical data with genetics data using the i2b2 data model (https://www.i2b2.org).  This is used by around 250 units worldwide and has highlighted the need for the right skills mix to make it work.  Some people have approached the use of tranSMART as an off the shelf solution but later struggled with implementation due to not having the required skills mix.  This gap in knowledge is a huge problem.   Another useful resource is the EuroRec Project (http://www.eurorec.org/). EuroRec is a European organisation aimed at promoting the use of high quality EHRs and supporting EHR quality labelling and defining functional and other criteria.  

Scale

There are many challenges around scale and data size.  What can easily be achieved on a small scale, looking at 10,000 observations may not work with a population of 50 million with the same observation sets.  If it is necessary to build a new system for each use case then the cost becomes prohibitive.   Providers have already invested significantly in EHR technologies and we do not want to force them to abandon this.  It would be costly and would have significant pushback.  Gradual implementation of additional functionality and investment into systems is the way forward.

Conclusion

There are potential technical solutions.  The real issues around the level of awareness of the need for particular expertise within providers and challenges around scalability.  The principle of developing instances of the LHS seems very simple, but when you try to implement it you face many small technical challenges that have to be overcome one by one.  It gets a lot more complicated.
There is a need to have people with an understanding of how to implement EHRs, databases, ontologies and archetypes together with the clinicians.  At present knowledge about what does and does not work is not shared effectively from one provider/project to another, which can hinder further projects. 

Website: