1. Open Health Tools UI Platform
Approved for Public Release: XXXXX. Distribution Unlimited.

2. Agenda The Team The Problem The Solution The Approach The Projects
The Architecture
Research Findings
Lesson’s Learned

3. Agenda The Team The Problem The Solution The Approach The Projects
The Architecture
Research Findings
Lesson’s Learned

4. The OHT UI Team Gail Hamilton
Software Consultant , MITRE
Marine Koshkakaryan Web Application Developer, PIIM
Mary Greer Software Engineer, MITRE
Noah Pedrini Software Engineer, PIIM
Ken Rubin Health Enterprise Architect, Hewlett Packard
Damian Bendersky Interactive Web Developer, PIIM
Yalini Senathirajah
Assistant Professor,
Department of Medical Informatics SUNY Downstate Medical Center
Erik Sax
Software Engineer, MITRE

5. Agenda The Team The Problem The Solution The Approach The Projects
The Architecture
Research Findings
Lesson’s Learned

6. 2. Open Health Tools Documentation
UI Problem We are Trying to Solve: Allowing Clinician Access to Full Patient Health Record
Phone
Siloed Health Data
Multiple data sources
‘One size fits all’ User Interface (UI)
EHR UIs
lack of usability in non- standard EHR user interface design1
Lack of Interoperability between
EHRs
Components of Health IT stacks
Cost to organizations Health IT Budget
Significant % of annual IT budgets2
Fax
Handhelds
EHR(s)
EHR
EHR
Scanned Records
Patient
They have, on average only 15 minutes to spend with each patient.
And have even less face time with a patient.
In this time they must
access the situation ,
to diagnose problem and
verify that old and new data confirms/ refutes this hypothesis
recommend treatment
To do this the doctor has to sift through a large amount of information, from various sources some of it not readily available.
These sources of information include:
VISTA – The system that they will currently be using to store patient records, or using as a messaging system
– generally Outlook
Fax – for any information that has been faxed from other clinicians or from outside sources
Phone – After a phone call, the physician has to write down the salient points of the call
And any scanned in records that are generically labeled “outside records”, and ,may include records from
AHLTA – The DoD medical system.
As a physician put it: “Everyday you need to search all these sources of information for data.”
Which leads to this…
All this information must be searched through and correlated in the physician’s head.
1. John Halamaka : for-boundless-energy-and-optimism.html?m=1
2. Open Health Tools Documentation

7. Agenda The Team The Problem The Solution The Approach The Projects
The Architecture
Research Findings
Lesson’s Learned

8. Open Health Tools UI Platform
Enable an adaptable Health IT Infrastructure, through providing an adaptable user interface that is flexible enough to meet the needs of a range of Health IT users as part of a suite of Open Health Tools
Provide an Open Source pilot of end to end capability that demonstrates how to lower the barriers to innovation

10. Open Health Tools UI Platform Solution
An adaptable framework that enables a user to build a personal view of a patient record, using a palette of widgets, each of which is separable and platform independent allowing for flexibility and system evolution through substitutability.

11. Palette Based User Interface

12. Agenda The Team The Problem The Solution The Approach The Projects
The Architecture
Research Findings
Lesson’s Learned

13. Planned Approach for OHT UI Platform
Identify through OHT Meetings likely participants
Expectations that this would be volunteer activity
Set up standing weekly meeting
Have frequent MITRE-led code-a-thon sessions where majority of work would take place
Develop solution to a OHT UI developed use case
Use hingX as a collaboration tool

14. Key Challenges Geographically dispersed participants
Volunteer activity
Competing schedules and priorities
MITRE: Funding change -> reduced resources

15. What Happened? Had Weekly meetings False starts Help of Ken Rubin
Tried to accommodate too many ideas
Help of Ken Rubin
Defined key principles of platform
Gave everyone a common understanding of UI Platform goals
Started building out some use cases
Held a 2 day code-a-thon at MITRE
Some interests were not aligned
Lost some participants

16. OHT UI Approach
Bring together interested parties through OHT to tackle aspects of the UI problem that aligned with their self interests
MITRE team: Transition work, and ideas and platform outside of MITRE
Parson’s Institute : Move HealthBoard from Flex and have back end infrastructure, transition design ideas
Yalini Senathirajah: Bring evidence based research to this approach, and bring this approach to a wider audience.
All: Finding collaborations to overcome resistance to new UI concepts and design ideas

17. OHT UI Platform Principles
Design to the 80%
DO no(or minimal) harm in customization
Integrated, adaptable and consistent across modality/ platform
Portability of access. Has to across multiple data repositories/ EHRs / products
Palette of reusable, easily extensible and complementary components

18. Agenda The Team The Problem The Solution The Approach The Projects
The Architecture
Research Findings
Lesson’s Learned

19. Two Complimentary Projects
Shared goal of innovating presentation of medical information
medCafe - “One size fits all EHRs do not ‘fit all’; I believe in composable interfaces that empower clinicians to lay out information in way that suits them best!”
HealthBoard - “Medical data can be presented better; integrating strong information design principles, visualization makes it easier to understand”
Similarities: collapsible widgets, tabs, themes; both open- source, available on OSEHRA and GitHub

20. HealthBoard
Let me take a moment to introduce our two characters...

21. HealthBoard
Developed by Parson’s Institute of Information Mapping (PIIM), funded by TATRC, with design input from Walter Reed
Presentation layer for “patient centered medical home”
Goal: bridge geographical barriers to medical care via web- based system, increasing interactions and decreasing costs
Project consists of patient and provider portal prototypes (Flash/Flex), as well as design assets
Adds non-traditional components like messaging system, chat, nutrition manager, custom “trackers” (i.e. smoking cessation)
Geared towards military personnel, but could easily be applied to broader healthcare community

22. medCafe

23. medCafe Developed by MITRE, framework for composable EHR system
Provider-focused, allows users to build, modify, customize patient record to their liking
Features
Customizable client (widgets) and server (repositories)
Composable interface, customizations persist across session
Support for multiple data repositories (Vista, local db)
Demonstrative of how customizability has potential to optimize system reach and adoption
Built using Java, jQuery, jQuery UI, OVID (Java OpenVista access)

24. Though they felt complete, they knew there was more...
Main Focus
UX and design
(front-end heavy)
System architecture
(back-end heavy)
Data/Persistence
All data static
Changes don’t persist across sessions
All data dynamic
Changes to data and UI configuration persist
Next steps
Hook-up to real data
Make mobile version
Separate into client and server
Explore potential as service

25. Two Complimentary Projects, Two Days, 6 People
medCafe Team
Began developing query layer for reading/writing FHIR data stored in MongoDB (built w/ Node.js and Backbone.js)
FHIR - Emerging standard for representing healthcare concepts in consistent format and allowing access through RESTful interface
HealthBoard Team
Familiarized ourselves with medCafe architecture
Continued building out initial vitals module
Updated prototype to load and parse test observation data (vitals) from sample FHIR server

26. Two Complimentary Projects. Two Days, 6 People
medCafe
Build out FHIR server, separate into distinct project
Add HTTP response codes, sweep for FHIR compliance, validation
HealthBoard Mobile
Integrate with medCafe’s FHIR server
Integrate medCafe, Open Health Tools UI Group principles
Widgetize views, make composable/customizable
Make responsive, work on variety of devices
Parson’s team plans on contributing back to medCafe

27. Epilogue: Since our Meeting
medCafe: Completed FHIR server support for reading/writing observations (vitals), patients and providers
HBMobile
Reading/writing all in-app vitals (weight, bp, temp, respiratory rate, heart rate) to/from FHIR server
User login, signup and profile editing up and running
AngularJS javascript framework integrated
Working on medications (including FHIR server support)
Wrote Python script to convert drugs in RxNorm db to FHIR- formatted flat file

28. Agenda The Team The Problem The Solution The Approach The Projects
The Architecture
Research Findings
Lesson’s Learned

29. Enable Innovation UI Presentation RESTful Services hData/ GreenCDA
VistA
UI Presentation
RESTful Services
hData/ GreenCDA
HL7
Now here is a rather complex slide. So I’ll step through it.
First you see that we have two major components, a RESTful web server which is a subset of web server.
So the first thing we want to do is connect to an EHR – VistA and bring the data into the system. In this example you see a snippet of medications in the hData document.
The system ingests this XML format and through RESTful web services serves up all the pieces in the VISTA as modular web services.
The system accesses these web services simply by using the following something like this sample URL, used to access medications.
Users never have to see this URL, as this happens behind the scenes.
I list a sample of these here including Patient Details, Medications, Alerts, Vital Signs, etc,…That mirror the structure of the medical record itself.
The output is in JSON format. JSON doesn’t look very pretty, but for developers this is the holy grail. Because this is the format that javascript understands. So it is easy for web developers to work with.
With simple translation tools they can quickly produce HTML, that looks similar to this. But adding javascript enables a whole world of options. The simplest in medCafe being a simple text formatting of the data encased in a widget. Or on the other extreme, displayed within a javascript timeline, showing the whole patient history.

30. Provide Consistent Access to Data Pieces
VistA
RESTful Services
hData/ GreenCDA
HL7
JSON
Observations
Medications
Careplan
Conditions
Patient
Procedures
Now here is a rather complex slide. So I’ll step through it.
First you see that we have two major components, a RESTful web server which is a subset of web server.
So the first thing we want to do is connect to an EHR – VistA and bring the data into the system. In this example you see a snippet of medications in the hData document.
The system ingests this XML format and through RESTful web services serves up all the pieces in the VISTA as modular web services.
The system accesses these web services simply by using the following something like this sample URL, used to access medications.
Users never have to see this URL, as this happens behind the scenes.
I list a sample of these here including Patient Details, Medications, Alerts, Vital Signs, etc,…That mirror the structure of the medical record itself.
The output is in JSON format. JSON doesn’t look very pretty, but for developers this is the holy grail. Because this is the format that javascript understands. So it is easy for web developers to work with.
With simple translation tools they can quickly produce HTML, that looks similar to this. But adding javascript enables a whole world of options. The simplest in medCafe being a simple text formatting of the data encased in a widget. Or on the other extreme, displayed within a javascript timeline, showing the whole patient history.

31. UI Platform: Enable Innovation
Web Server
RESTful Services
hData/ GreenCDA
HL7
HTML
AJAX
Now here is a rather complex slide. So I’ll step through it.
First you see that we have two major components, a RESTful web server which is a subset of web server.
So the first thing we want to do is connect to an EHR – VistA and bring the data into the system. In this example you see a snippet of medications in the hData document.
The system ingests this XML format and through RESTful web services serves up all the pieces in the VISTA as modular web services.
The system accesses these web services simply by using the following something like this sample URL, used to access medications.
Users never have to see this URL, as this happens behind the scenes.
I list a sample of these here including Patient Details, Medications, Alerts, Vital Signs, etc,…That mirror the structure of the medical record itself.
The output is in JSON format. JSON doesn’t look very pretty, but for developers this is the holy grail. Because this is the format that javascript understands. So it is easy for web developers to work with.
With simple translation tools they can quickly produce HTML, that looks similar to this. But adding javascript enables a whole world of options. The simplest in medCafe being a simple text formatting of the data encased in a widget. Or on the other extreme, displayed within a javascript timeline, showing the whole patient history.

32. Agenda The Team The Problem The Solution The Approach The Projects
The Architecture
Research Findings
Lesson’s Learned

33. User-composable EHRs – Research and Findings
Yalini Senathirajah, PhD
SUNY Downstate Medical Center

34. History
Developed user-composable EHR (‘MedWISE’) in ~2007, as part of PhD work at Columbia University
Real functional system built into New York Presbyterian Hospital existing system
Tested with real patient cases and clinicians
residents, attendings, physician assistants
Selected results:
All users able to learn in a short training period and use system for real case review
Most (>80%) of users enthusiastic, rated favourably on ease of use, usefulness

35. Findings
Reduced repetitious navigation (70% decrease) suggests time savings
Support for reduced cognitive load; reduced need to integrate information in mind
Some users take advantage of new opportunities to improve system, adapt it to specific needs, fix existing problems
Concerns about accuracy, possible errors;
small studies show no difference in diagnostic accuracy from conventional system
Philosophical issues regarding errors;
See: Essential Questions: Accuracy, errors and user perceptions in a drag/drop user-composable Electronic Health Record. Senathirajah Y, Kaufman D, Bakken S. Stud Health Technol Inform. 2013;194:

36. Agenda The Team The Problem The Solution The Approach The Projects
The Architecture
Research Findings
Lesson’s Learned
Next Steps

37. Lesson Learned Adaptable to changing circumstances
Move over new standard quicker
Accept that will lose people / groups along the way
There will be attrition of groups
More face to face meetings and have initial face to face meeting much earlier
Collaboration
hingX was not well used: primarily as artifact repository
Need to work on how to use collaboration tools better
Workshop
Have sooner or at least 2
Better preparation: transition of ideas/ technology before the workshop
Better evaluation of two architectures prior to workshop

38. Next Steps FHIR Integration
Reconcile John Nolen work on FHIRMeteor with NodeOnFHIR
Reconcile with efforts underway at MITRE and OSEHRA
S/W Integration effort to move medCafe to FHIR
Fully transition to Parsons Institute
Licensing on FHIR
Apache 2
Need more collaborators willing to work with us
At an exciting point, with FHIR integration – we don’t want to see the work end now!

39. Open Health Tools UI Platform: How Did We Do?
Enable an adaptable Health IT Infrastructure, through providing an adaptable user interface that is flexible enough to meet the needs of a range of Health IT users as part of a suite of Open Health Tools
Provide an Open Source pilot of end to end capability that demonstrates how to lower the barriers to innovation

40. Thank You! Gail Hamilton
Software Consultant , MITRE
Marine Koshkakaryan Web Application Developer, PIIM
Mary Greer Software Engineer, MITRE
Noah Pedrini Software Engineer, PIIM
Ken Rubin Health Enterprise Architect, Hewlett Packard
Damian Bendersky Interactive Web Developer, PIIM
Yalini Senathirajah
Assistant Professor,
Department of Medical Informatics SUNY Downstate Medical Center
Erik Sax
Software Engineer, MITRE

41. Questions? For more information .
medCafe
Contact : Gail Hamilton :
Live demo
Login: guest1, Password: guest1
HealthBoard
Source code (GIT)
OHT UI Platform Collaboration Site

42. Questions

43. Background

44. Palette of reusable, easily extensible and complementary components
Many small, independent pieces that each run ‘standalone’
Easy to deploy and add new capability through adding new widgets
User decides which components to use depending upon patient
Allows use of ‘Best of Breed’ components
Replacing/ upgrading components is easy

45. Integrated, adaptable and consistent across modality/ platform
Javascript framework on top of HL7 Standard
Enables widgets to run independent of Platform
Consistent display
Laptop / Desktop Browser
Mobile Device
Tablet Device
Lowering Barriers to Innovation
UI developers only need to have knowledge of Javascript
Add new widgets through simple Javascript API

46. Portability of access Has to across multiple data repositories/ EHRs / products
Normalize data to HL7 Standard
hData
Currently moving to FHIR
UI developers only worry about one data format
Less time and resources on taking care of underlying data interoperability issues
More time can be spent on creating better ways to display the information to enable better and safer patient care
Building rapidly deployable FHIR node.js server

47. User Defined Interface
Speed Patient Data Re-Acquisition
Use Pre configured Interfaces
Components/ Template
Template: predefined set of components arranged optimally
Default templates are provided to align with common use cases
Create/ add new templates as desired
User/Clinician Defined Views
Customize view for patients
Align with patient use cases
Per Patient Views
Some patients do not ‘fit the mold’
Modify a view for a specific patient and save record view
Displays saved view on re-engagement with Patient
Speeds re-engagement with a patient