curio project workshop. agenda start timesession presenter 11:00welcome gwen smith 11:05introduction...
Post on 19-Dec-2015
214 views
TRANSCRIPT
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
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
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 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
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– 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
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
Format
• Split into Break out groups to discuss:
• Topics• How useful is this type of project?• Potential uses for the widgets?• Possible next steps?