CURIO Project Workshop

AgendaStart time

Session Presenter

11:00 Welcome Gwen Smith

11:05 Introduction David Ingram

11:20 Overview Gwen Smith

11:35 Demonstration Seref Arikan

12:15 Lunch13:00 Technology choice Seref Arikan

13:25 Discussion and direction

Gwen/David

14:25 Feedback Gwen/David

14:45 Close Gwen Smith

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

number of procedures performed in relation to hospital admissionsFrom Shortliffe and Perault, 1989

Growth of Standard Nomenclature of Medicine (SNOMED)

Information explosion: in health care

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

OVERVIEW

Gwen Smith Head of Technical ServicesData Standards & Products

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

AgendaStart time

Session Presenter

11:00 Welcome Gwen Smith

11:05 Introduction David Ingram

11:20 Overview Gwen Smith

11:35 Demonstration Tim Chearman / Seref Arikan

12:15 Lunch13:00 Technology choice Seref Arikan

13:25 Discussion and direction

Gwen/David

14:25 Feedback Gwen/David

14:45 Close Gwen Smith

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 CONTEXT

CUI Vision Current clinical IT systems

Common UserInterface (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

diltiazem – RETALZEM – modified-release tablet – DOSE 60 mg – oral – three times a day

Diltiazem – retalzem – modified-release tablet – DOSE 60 mg – oral – three times a day

paracetamol – 120 mg in 5 mL – suspension – DOSE 80 mg – oral – every 4 hours

cefotaxime – powder for solution for injection – intravenous – DOSE 400 mg – every 8 hours

• All UI guidance is platform agnostic and available free of charge

• Rationale and evidence provided within each guidance document

Patient banner

Medication line

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

www.cui.nhs.uk

POC

POC

POC

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

CURIO DEMONSTRATION

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

A combination of technology, architecture and standards

Get past drugs

Host system services and APIs

Get SnomedCT codes with “calcium”

Get medications between dates Get start and

end times of administration …

UI (Flex)

Get warnings for administration

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

• NHS DS&P provided XML representation• How to make use of this input in a reusable

manner?– Turn it into a web service

XML

Middleware

Database

UI

Tooling

Web service

• Hibernate• Tomcat• H2• RestEasy• Flex

• Still not enough…

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 workLoading Snomed CT to LexEVS

XML

Concepts

Relationships

Descriptions

Snomed CT Release Tooling

PostgreSqlDB server

…

Concepts custom properties table

Concepts & terms table

LexEVSJava

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

Future DirectionsClicking on a drug should display a

context menu with action items

Handle mouse click event

Display a control at the point of mouse click

Allow displayed control to include a

list

Show list of drugs which are not

visible in the grid

Get width height and position of rows in the

table

Flex

JavaFX

GWTDOJO

Source code repositories

…

XYZ

An evolving approach, covering a larger technology and use case base

TECHNOLOGY CHOICE

Technology Choice

• Scope• Goals• Method• Challenges• Technologies• Results

Technology Choice

Obligatory note:• Choice is the emphasis here• CURIO has its own constraints as a project• The choices in technology are specific to

CURIO, therefore none of these choices should be perceived as recommendations!

• It is extremely hard to avoid comparing apples and oranges when it comes to technology choice.

• All of the following is provided in the context of CURIO

Scope

• A selected set of web based software development technologies

• Their advantages and disadvantages in the context of CURIO project.

• What criteria were employed for selecting the members of the set? (Especially, why web?)– We have limited time & resources– We need to share the outcomes with minimum

deployment and maintenance effort– We have to focus on open source– We have to avoid viral open source licences

Scope

• With these constraints, the following technologies were chosen– DOJO Toolkit– Adobe Flex– Google Web Toolkit– JavaFX

Goals

• Evaluate handling of key aspects in these technologies, where key aspects are determined by technical requirements of the selected CUI specifications– Communication with server– Browser DOM manipulation capabilities– Browser normalisation– Event handling– User interface related capabilities

• Tools, out of the box components, custom components..

Goals

– Community– Development tools and practices

• Critical for reuse of outcomes with other technologies• Mature tools and practices matter

– Documentation• We wanted to go through chosen technologies

with these criteria

Method

– Analyse CUI specifications– Break them down to purely technical atomic tasks

(or as close to atomic as it can be)• “Display drug name on a single line if it fits” turns into

“Requirement to measure text width and height within a control”

– Then, create a list of all these technical tasks, so that CUI requirements is turned into pure technical requirements

Challenges

– For almost any task, it is quite hard to say that is not possible with option X

• Software allows a particular task to be performed in many ways.

• Capabilities of chosen technologies can significantly change during the project.

• An expert (team) can produce solutions which may not be obvious to a less experienced user of the same technology

– For tasks which are possible, it is still not easy to see if performing a task is easier with option A or B

Technologies

– Javascript based technologies vs Flex• Both approaches run code in the browser

– What is the difference?• DOM & Javascript vs Flash plugin

– Advantages of DOM & Javascript– Advantages of Flash

– Disadvantages of DOM & Javascript– Disadvantages of Flash

Technologies

– Distance to common paradigms• Object oriented, component based development

– Technical capabilities reside in library layer, but object orientation is at the language level

• Different technologies support object orientation at different levels.

– Why does it matter?• It is a bridge for carrying implementation approaches

from one technology to another• A common language for implementers

Technologies

– However, you do not have to be OO– It helps in our case, in CURIO

• All chosen frameworks support OO approach, along with a component based approach.

– Other key criteria• HTML 5• Community size• Vendor support & roadmaps

Results

– We decided to use Adobe Flex• Professional development environment with open

source alternatives• Object oriented and component based framework

– Matches with our previous experience

• Large deployment base• Large community of developers• Vendor support

– Very mature UI capabilities, especially for text metrics and pixel level operations

• Kick off date, and maturity of HTML 5 was critical

Results

– Lessons learned• You really need to understand custom component

mechanics and component lifecycle in Flex.• Its text metrics support makes it unique, but changes in

CUI may remove that advantage• It serves you quite well, if you are used to mainstream

development languages and environments like Java or C# (and related tools)

• Its usage with other web based applications is a common use case, but it may get complicated

DISCUSSION AND DIRECTION

Format

• Split into Break out groups to discuss:

• Topics• How useful is this type of project?• Potential uses for the widgets?• Possible next steps?

Feedback

• Feedback from the attendees

Close