690 likes | 896 Views
CURIO Project Workshop. Agenda. The CURIO Project – setting the scene for today. David Ingram, University College London CURIO Project Workshop, January 12 th 2011. Collaboration. NHS Data Standards and Products. Information explosion: in health care.
E N D
The CURIO Project – setting the scene for today David Ingram, University College London CURIO Project Workshop, January 12th 2011
Collaboration NHS Data Standards and Products
Information explosion: in health care number of procedures performed in relation to hospital admissions From Shortliffe and Perault, 1989 Growth of Standard Nomenclature of Medicine (SNOMED)
The wider context • Science is being transformed • ‘bioinformatics is core discipline of biology’ – Royal Society 2005 • 14 years to sequence HIV genome; SARS took 31 days • Research and practice are increasingly information intensive • ‘information is the heart of medicine’ – BMA 1994 • Multiple legacy information systems are in use • supporting and linking health care, research and industry • Government is creating pervasive new ICT infrastructure and core services • Other national and international initiatives are creating relevant infrastructures and standards
The CURIO Project - context • Open source has proved advantageous, even essential in some scientific communities • UI matters to every user. Harmonising look and feel of clinical applications is a good objective, but how? • CURIO is a partnership of the Data Standards and Products team of the NHS with CHIME at UCL, a University team active in the iterative development of health informatics standards and applications • It has used NHS CUI specifications to explore how a mutually beneficial open source framework might be developed, to support efforts towards systems integration and semantic interoperability
The Curio Project aims • Work from current specifications for NHS CUI • Drugs list, Medicines list, SNOMED term finder • Review and characterise their UI implementation requirements • Review available open source implementation frameworks • Chose the most promising and implement proof of concept code to demonstrate and evaluate feasibility of open source software (widgets) to deliver the required UI functionality • Make this work available to a wider audience, for critical review and onward development
The Curio Project – delivery • Timescale – very tight • Technology Review - 4 months • Programming of proof of concept demonstrators – 7 months • Write up and dissemination – 1 month • Project Management – very light • Gwen Smith, Denise Downs, Tim Chearman, Ravi Natarajan for CfH • David Ingram, Dipak Kalra, Seref Arikan for UCL • Alignment, for demonstration purposes, with terminology and persistence services provided by the UCL Opereffa open-source clinical application development framework
Gwen Smith Head of Technical Services Data Standards & Products Overview
CURIO Project Objectives • ‘To develop a technical environment and framework to facilitate an exploration of the challenges around the implementation of SNOMED CT in a transparent way which is shareable and may be leveraged by others to implement UKTC standards in a consistent way’ • Provide a starting point for a community and to facilitate further development and re use
Workshop Objectives • Common User Interface Reference Implementation Open source • Share outcomes • Share context: time, resource, scope, chosen use cases • Gather feedback • Explore next steps • Explore possible uses • Understand interest • Cultivate Collaboration
CURIO Outcomes: • To share today • Options appraisal document • Demo of prototype Widgets • Lessons learned • Open Source • Prototype Widgets • Technical Framework • Lessons learned • All materials from today
CURIO Before the Demo • We need your feedback • Next Steps to be determined: • Is it useful? • What are its potential uses? • What should we do next?
CUI Vision Current clinical IT systems Common User Interface (CUI) Standards can help enable safe and effective delivery of care without extensive re-training Many different application user interfaces mean that retraining is necessary.
Guidance examples Medication line • All UI guidance is platform agnostic and available free of charge • Rationale and evidence provided within each guidance document Patient banner
Guidance Catalogue • Key Information • Telephone Number Display and Input • Patient ID Display and Input • Sex / Gender Display and Input • Address Display and Input • Date Display and Input • Time Display and Input • Patient Name Display and Input • Email Display and Input • Accessibility • Accessibility Principles • Accessibility Checklists • Terminology (SNOMED CT) • Terminology Matching • Terminology Elaboration • Terminology Display • Allergy/ADR display and entry • SNOMED CT entry • Admissions clerking • Truncation of Clinical Terms • Display of Clinical Statements • Patient Administration • Patient Banner • Find a Patient • Patient List View • Medications Management • Medications Views • Drug Administration • Search and Prescribe • Medication Lines • Abbreviations • Abbreviations in Free Text • Abbreviations in Fixed Text • Consistent Navigation • Alert Symbols • Icons and Symbology • Sorting filtering and grouping • Decision Support • Decision Support Notification • Decision Support Alerts • Clinical Noting • Noting Using Templates • Noting with Graphics POC POC POC www.cui.nhs.uk
Why select • Safety impact • Complexity – user interface and implementation • Implementation reference – Standards route • Potential business case – Medication line CUI aims • Implementation learning's/compliance/feedback • Stimulate development in other platforms
To cover today • Scope • Goals • Challenges • Architecture • Controls • Non UI work • Results • Future directions
Scope • A subset of CUI specifications • Medication line • Medication list • Drug administration chart • Single concept matching • Relevant standards • Relevant architectures
Goals • Answer question #1: Is it possible to implement this specification? • Answer question #2: Is our choice of technology fit for purpose? • Performance • Development time • Maintainability • Extendibility • Reuse
Goals Provide open source implementations of specifications which tackle key issues Use an architecture that makes reuse possible Follow development practices which are valid/applicable in other technologies. Provide tooling when possible Build a community with technical and clinical capabilities.
Challenges • Technical issues • Using out of the box components • Code may become complicated (maintenance and extending code becomes harder) • You may have performance issues • 90% of use cases may be supported (great!) • Then 10% takes an awful amount of time… • Sometimes it is plain impossible to do something (though very few would admit…)
Challenges • Domain issues • There are explicit and implicit requirements • Explicit • Grid based control, icons, tooltips, dialogs • Implicit • Past medications, overdue medications • Some of the requirements introduce implicit references to clinical concepts • Most of the time, you need to resolve these references to implement UI behaviour.
Challenges • How can we resolve these references? • With an existing system, the task is to map these requirements in CUI specifications to your host system’s capabilities. • Many implementers will have to do this. • So we need to consider this process within our scope and explore it.
Challenges • How do we represent a host system? • There are hundreds, if not thousands of systems that can use CUI • Even a prototype implementation is a huge piece of work. • This is where relevant standards comes into picture.
Challenges • Relevant standards encapsulate domain information • They either represent generalizations of common implementations, or they are targets for wide spread implementation (usually both) • So standards implementation becomes a task we need to include within our scope.
Architecture • A realistic architecture is important for useful outcomes • A monolithic implementation is unlikely to be useful • Not appropriate for re-use. • Monolithic implementation means a single technology, so no chance of using frameworks from other technologies.
Controls Medication line Medication list Drug administration chart Single concept matching
Controls • Medication line • Formatting information on screen • Wrapping text • Managing delimiters • Managing line breaking logic • Managing line spacing • In short: Text metrics and formatting
Controls • Medication list • Uses medication line control • Adds its own features • Look ahead scroll bar • Text metrics, with potential performance implications • Grouping • Sorting
Controls • Drug administration chart • Most complex control in terms of UI requirements • Requires more insight into domain • Time scale • Indicating past & future • Access to more details (and to other systems) • Text metrics
Controls • Single concept matching • A small widget for us, but a great challenge for medical informatics. • Simple UI, but inherently complex functionality.
Non UI work Host system services and APIs UI (Flex) Get SnomedCT codes with “calcium” Get past drugs Get warnings for administration Get medications between dates Get start and end times of administration … A combination of technology, architecture and standards
Non UI work • DM+D • “The dm+d is a vocabulary dictionary containing unique identifiers and associated textual descriptions for medicines and medical devices ” (http://www.dmd.nhs.uk/) • It is the specification that feeds drugs to CURIO
Non UI work Web service Middleware UI • Hibernate • Tomcat • H2 • RestEasy • Flex Tooling XML Database • Still not enough… • NHS DS&P provided XML representation • How to make use of this input in a reusable manner? • Turn it into a web service
Non UI work • Snomed CT • Snomed CT is simple in structure, but … • Text matching and graph processing may complicate implementation. • It offers a lot of power, but with great power comes great responsibility… • It needs to perform well • It needs to leverage the fundamental advantages of its design • It needs to be user friendly
Non UI work • How do we implement a Snomed CT service? • Put everything into a DB! • “select * from concepts where description like ‘%calcium%’ • Done! • Not really… • Open source offers more than this!
Non UI work • “LexEVS 5.x represents the next generation of NCI Enterprise Vocabulary Services” (https://cabig.nci.nih.gov/tools/LexEVS_API) • A terminology server with support for a generic model • The model has its roots in Mayo Clinic’s work • Allows serving terminologies with a single model and a single API. • Allows enhancing concepts with custom properties, and much more • Support a distributed architecture • Support various terminology loading mechanisms
Non UI work How do we go from Snomed CT release files to a terminology server deployment? Release files are simple in structure, but they are large in terms of # of concepts, relationships and terms. Also, they are related to international release, due to relationship definitions. So, we need tooling to automate the process of deploying them to NCI LevEVS server.
Non UI work • Postgresql to rescue! • Open source advanced db • It supports pl/pgSQL, a procedural language • pl/pgSql scripts to create and manipulate database tables. • Much faster than an in memory, programming language based approach • After the db tables are created, a small Java code creates XML files.
Non UI work Snomed CT Release Tooling Concepts LexEVS PostgreSql DB server Java XML Relationships Descriptions Concepts & terms table Concepts custom properties table … Loading Snomed CT to LexEVS
Non UI work • Using LexEVS • Tuning and optimization is a deep research topic • Snomed CT’s design allows for fairly complex operations, with high computing costs. • CHIME has been using it for Opereffa project, and there is active research for higher performance, and links to EHR implementation.
Results Flex based UI controls A simple web services based back end that provides DM+D and SnomedCT based information. A set of tools to deploy DM+D and Snomed CT releases from NHS to a distributed infrastructure An open source terminology server setup Key know how regarding implementation of target CUI subset
Results • Lessons learned: • Custom component development is a key factor in producing results. • Various discoveries can be carried to other technologies, but some of them are bound to be CURIO specific. • Minor modifications in specifications make them significantly easier to implement in some technologies.
Results • Good news for you • You may have an existing system to integrate CUI work into (we did not) • You may have experience in your choice of technology (we did not) • You may have access to clinical input and feedback (we did not) • You may use some of the methods we have used, if your choice of technology supports component oriented approach
Future Directions • Dissemination of results • Involvement of interested parties • Providing feedback for a wider set of implementations • Placing existing work into a more realistic context