EHR Designer: Engineering Volumepiim.newschool.edu/clients/TATRC/CSIFY10/reports/FY10... · 2015-04-30 · Node.js. AngularJS, Google’s Javascript MVC framework, is an up-and-coming

EHR Designer: Engineering Volume Noah Pedrini, Marine Koshkakaryan, PIIM, The New School Last Updated: February 6, 2015

[Page 2]

EHR Designer: Engineering Volume Last Update: February 6, 2015

©2014 PIIM , THE NEW SCHOOL

Notes Revision History Date Notes Author 3/12/2014 Document creation and formatting Jihoon Kang 3/12/2014 Add initial content to “Underlying

Technology” section Marine Koshkakaryan

3/12/2014 Add initial content and diagram to “Methodology” section

Marine Koshkakaryan

7/29/2014 Add “User Flow”, “Implementation” , “Requirements”, and “EHR Components” sections

Marine Koshkakaryan

7/30/2014 Add content to “Introduction”, “Underlying Technology”, and “Software Design” sections

Noah Pedrini

7/30/2014 Proofread “Implementation” section Noah Pedrini 7/30/2014 Edits on all sections and formatting Marine Koshkakaryan 10/14/2014 Add “Implementation, Phase

Two” section Marine Koshkakaryan

12/18/2014 Add content to “Implementation, Phase Two” section regarding the development of the design themes

Marine Koshkakaryan

02/06/2015 Add section for “Demonstration and Feedback”

Marine Koshkakaryan

[Page 3]



INTRODUCTION This Document This is the Engineering Volume for the EHR Designer. The purpose of this document is to provide a Concept-of-Operations for this system. It is expected that this document will change and evolve over each quarterly deliverable of this project. The EHR Designer The EHR Designer is a drag-and-drop, WYSIWYG EHR designer geared to programmers, medical professionals, and everyone in between. It’s a tool for communicating design and workflow ideas. By taking advantage of design best-practices and utilizing the common workflows identified through years of research in the medical domain, the EHR Designer provides a way to mockup a stylized graphical user interface and explore layout ideas. More broadly, it is envisioned that the presentation layers of legacy EHR systems will be re-designed in the coming years to target the web as a primary delivery platform. With this in mind, the EHR Designer positions itself as an useful tool for assisting with the creation of these graphical user interfaces by providing an evolving library of pre-designed components and design guidance. The tool also addresses the oft-overlooked considerations of design and user experience as relates to EHR systems. By staging the EHR Designer on a public website and integrating social features such as sharing and commenting, it is our aim that an active community will arise around the look and feel of EHR systems. A demo of this application can be viewed at http://ar210.piim.newschool.edu:3010. The source code, including a detailed technical README, can be viewed on the project’s GitHub page at http://github.com/piim/ehr-designer. UNDERLYING TECHNOLOGY The EHR Designer incorporates the MEAN stack, an up-and-coming alternative to the more traditional LAMP stack. The MEAN stack is comprised of MongoDB, ExpressJS, AngularJS and Node.js. AngularJS, Google’s Javascript MVC framework, is an up-and-coming library that has been used in previous projects and offers a number of attractive features. For this project, the most compelling feature Angular provides is the facilitation of rapid development by simplifying the process of setting up the application’s core structure and UI interactions. Leveraging established libraries like Angular also has the added benefit of positioning the project to be more easily contributed to and modified by others. Additionally, the client makes use of Twitter’s Bootstrap UI Framework for a streamlined look and feel. On the back-end, MongoDB has been adopted as a data storage technology. MongoDB is the leading technology in the trend towards “NoSQL” databases and integrates well with Node.js. Since the EHR Designer’s core data structure is hierarchical, nested JSON documents representing user’s designs, Mongo was also a natural fit.

[Page 4]



The Node.js server uses a variety of additional supporting technologies including Express, Passport, Mongoose and PhantomJS. Express is a web application framework for Node.js that simplifies the creation of the core responsibilities required by a web server. Passport is a “middleware” (plug-in) for Express that handles user authentication. Mongoose provides a way to standardize the structure of the data objects that are written to the Mongo database, and enforces the conformance to those schemas. PhantomJS is a “headless browser” that, wrapped in Node plug-in called node-webshot, allows the application to create snapshots of public project pages that are used to provide visual previews on the front-end. Finally, Mandrill is used to send email over SMTP when the email-verification option is enabled. Some supporting technologies have also been employed to facilitate dependency management and testing. These include the NPM and Bower package managers, used to manage project dependencies on the back-end and front-end respectively; Grunt, used to automate tasks such as building dependencies and auto-generating template-based files; and Karma/Jasmine, used for running unit tests that verify core assertions about the application’s stability and ensure its reliability moving forward as new changes are made. METHODOLOGY The following methodology was put in place for the EHR Designer project and guided its development:

1. Requirements Gathering i. Team collaborates on defining use cases and creating an exhaustive list of

requirements. ii. Team reviews use cases periodically (often after a sprint in development is

completed) and makes any necessary adjustments to requirements and tasks. iii. Team identifies high level tasks for given phase. iv. As requirements are defined and high level tasks are created, the Engineering team

engages in exploratory prototyping to identify the technology stack and other needs.

2. UI Design i. User Experience Design ii. Wire-framing iii. Styling

3. Development i. Engineering breaks down technical task and logs them to the backlog. ii. Engineering team creates sprints from backlog. iii. Engineering team assigns tasks to developers and moves them into pending status. iv. Engineering team resolves a task when it is completed.

4. Review i. Team tests and reviews tasks in resolved status. ii. Team closes tasks that meet a requirement as expected. iii. Team re-opens a task that does not meet requirement as expected. iv. Team re-slates tasks not meeting requirements to the current or future sprint and

restarts steps 3-4

[Page 5]



USER GROUPS The following user groups have been identified as targets for the system:

1. Clinical Providers 2. Patients 3. Application Designers 4. Application Developers

USER FLOW The user flow describes a typical use of the EHR Designer application by a typical user from the user group. Note that not all steps in subsequent flow have been completed; a brief status for each of the following user actions has been indicated in this sections. Please consult the following section called “Implementation” for specifics regarding implementation up to date. Core User Flow:

• Create a new project - complete • Add pages to a project - - complete

o a single view/layout represented on the canvas • Add elements and components to page/canvas - complete

o User will select from a predefined list of elements and components (Elements refers to commonly-occurring core elements in a webpage such as text, buttons, input fields, etc.; Components refers to pre-built combinations of elements representing commonly-occurring modules in EHR systems)

o Each component will default to the “ideal” state to convey design thinking, though they will be ultimately customizable by the user and un-enforced.

• Edit element properties - complete o Use the Property Inspector to edit the properties of elements on the canvas o Each component/element will have supported attributes that the user can customize.

Elements will have a “data” attribute, which will allow the system to know more about the context in which a component is used.

• Preview and Save - complete • Select theme - pending

o Themes will ideally cover a range if possible, i.e. as relates to contrasts (white/black background), use of negative space.

• Export - in progress o The export capability currently allows for the export of component represented in

JSON. o Options: image, PDF, developer files. Select target platform (HTML5, etc., if

developer files chosen) • Post to community - in progress

o Sharing is accomplished through setting of the status of a project to public; other social features will be developed in future phases.

o Share with others, rate and comment on other ideas, browse, etc.

[Page 6]



IMPLEMENTATION During this initial phase of the EHR Designer project, the core functionality as identified during the pre-planning stage was successfully implemented. Following is a detailed description, with screenshots from the demo deployment where applicable. The Login and Account Creation capability is complete. If email verification is enabled, users are required to confirm their account by clicking a link in a confirmation email the system generates and sends to the users registration address. The email verification process takes place before the user is permitted to login. This feature is disabled by default. See images 1 and 2. Image 1. Signup

Image 2. Login

Users with or without an account who have not yet logged-in, may select the Browse link whereby they can view public projects. Sorting and searching of projects on this page is also complete. See image 3.

[Page 7]



Image 3. Browse page, showing public projects

Once logged in, the user is directed to their “My Projects” page, where they can find all their existing projects and create new ones. As per the design, each project, when hovered over, displays three icons that give the user the option to EDIT, DELETE and PREVIEW the project, which have all been implemented. The number of pages within a project and its created and last-modified dates are also displayed at the bottom of each tile representing a project. If a project has been made public, the tile displays a snapshot of the first page. See image 4. Image 4. My Projects, showing the user’s projects

Projects can contain any number of pages. Clicking on a project tile takes the user to a page listing the pages within a project, and also allows them to create a new page within that project. Much like

[Page 8]



the project tiles, the page tiles also contain a snapshot of the content of the page, options to EDIT, DELETE, and PREVIEW, and metadata similar to that displayed for a project listed at the bottom. Searching and sorting have been implemented for both projects and pages. See image 5. Image 5. My Projects, showing pages within a sample project

Clicking on a page tile will take the user into the main working canvas area where the already designed content is displayed. The main menu options are still available on the top of the page. The project banner displays bread crumbs that orient the user to the project and page they are currently working on. There is a button to add a new page, save the current project, and preview the current page. See image 6.

[Page 9]



Image 6. Canvas page

Creating a new page takes the user to a blank canvas after clicking-through a prompt asking them to give the page a name. When creating a new page, the canvas comes pre-configured with default grid dimensions as shown in the Settings tab screenshot below. In the settings tab, the user can also apply a template to their canvas and make a private project public (or vice versa) in the “Privacy” section. See image 7. Image 7. Settings tab

The heart of the EHR Designer is the canvas, and the user interface elements that can be dragged onto the canvas are found in the Library tab. The Library contains two main sections, the “EHR Components” section and the “UI Elements” section. The “EHR Components” section is further

[Page 10]



divided into subsections of common EHR UI areas. This library contains pre-designed components ready to be dragged onto the canvas for use. The UI elements are the basic building blocks and are used to construct components. See image 8. Each element on the canvas, when clicked, will trigger a context-sensitive Property Inspector. This is where the user is shown the configurable properties for each individual element and is provided with the ability to change them. The properties for the different types of elements vary. The properties for a button, for example, contain a property for specifying an optional icon, while a checkbox has a property for specifying the list of options that will drive the number of displayed checkboxes and their labels. In some cases, elements may be mapped to a sample FHIR patient resource or a pre-defined FHIR value set, in which case the custom text or data provider are overridden. The user is also provided buttons in the Property Inspector for restoring the defaults of the element they are working on or deleting it altogether. See image 8. Image 8. Library, showing the EHR Components and UI Elements tabs

The History tab allows the user to track their actions and undo them. By clicking on any previously listed action, the canvas is restored to the state. The Debug tab shows a JSON representation of the data structure underlying the canvas and elements it contains, and will automatically be hidden when deploying the EHR Designer to production. See images 9 and 10.

[Page 11]



Image 9. History tab Image 10. Debug tab

There are additional features implemented in the latest version of the EHR Designer, those not covered in detail above have been listed here:

1. Media Browser for uploading custom images and using them for Image elements or any other UI Element containing an image, such as Icon Buttons

2. The ability to “bind” text values of UI Elements to fields within a dummy patient (stored in FHIR format), and, similarly, bind list-based UI Elements (such as ordered unordered lists, checkbox/radio button groups, etc.) to FHIR Value-sets

3. A tutorial that walks the user through the process of creating a new project IMPLEMENTATION, PHASE TWO During the second phase the top three advanced features were chosen to be implemented next; following is a detailed description. The first feature is the ability to export projects. Each project displayed on the “My Projects” page now has an EXPORT button in addition to the EDIT, DELETE and PREVIE. These options become available when the project is hovered over with the mouse. Selecting the EXPORT option opens the “Export Project” dialog where AngularJS is available as the export type. See image 11.

[Page 12]



Image 11. Export Project, selecting AngularJS

The Export converts the mockups created in the EHR Designer project into an AngularJS project Scaffolding, which is downloaded onto the users system in a zip file as depicted in image 12. Image 12. Export Project, exported files.

[Page 13]



The second of the top three features being implemented in phase two is the capability which gives the user design rule warnings in real time. As they interact with the canvas the ‘best practices’ which have been adapted into rules are being checked against. If a user action results in the violation of a design rule the system adds the description of the violation in the “Warnings” tab located in the left pane of the canvas. In our example below two elements are added to the same or similar vertical plane but are not aligned with one another, this generates a warning. The user is given the option to dismiss the warning in which case no changes are made to the elements causing the violation and the warning is removed. See image 13. Image 13. Warnings, showing alignment warning.

[Page 14]



The “Resolve” button when hovered over informs the user of the resolution if they choose to apply the changes. In our example below the resolution is to left align the two elements in question. See image 14. Image 14. Warnings, showing resolution.

Once the Resolve button is selected the offending elements are adjusted based on the resolution proposed and the warning is removed. Image 15. Warnings, after resolve.

[Page 15]



The third feature allows users to apply pre-stylized design themes to their canvas. PIIM and other contributors in the open source community can define CSS design themes. Users can then select themes from within their EHR Designer projects. In the “Settings” tab there is a section titled “Style Theme”, the dropdown displays the style theme options available for the user to choose from. Image 16. Themes, showing Style Theme section in the Settings tab.

Currently samples for “Classic” and “Modern” themes, inspired by previous EHR re-design work, are available. Once a theme has been selected, the corresponding CSS style is applied to the UI elements dragged onto the canvas from the Library. The following images demonstrate the two different themes applied to the same form. Image 17. Themes, showing Classic theme.

[Page 16]



Image 18. Themes, showing Modern theme.

REQUIREMENTS The following is the initial list of requirements identified in the beginning stages of the project and some collected throughout. The core functionality that was within scope for the first phase of the implementation represents a subset of this more exhaustive list of requirements. Other functionality may have been identified and implemented while design and development were underway that may have not been captured in this list. Initial Requirements Definition 1. Login Prerequisite: the user has registered. Postrequisite: the system authenticates the user. 1.1 The user enters his user ID in the “User ID” text field. 1.2 The user enters his password in the “Password” text field. 1.3 If the system authenticates the user, he will go to My Project. 1.4. If the authentication fails, the system displays an error.

[Page 17]



2. Create / manage projects Prerequisite: the user has successfully logged on. 2.1 The user creates a new project: project title and creator (self) are assigned. 2.2 The user may add collaborator(s) and assign privileges to each collaborator. 2.3 Each collaborator must have signed up successfully. 2.4 The user privileges are: “Co-creator” and “Viewer.” 2.5 If a new project is created successfully, the new project appears on “My Projects” along with other existing (if any) projects. The user can open one of these projects. 2.6 If the user wants to access project(s) which he is assigned as a collaborator, he may find it under “Shared Projects.” If his privilege is “Co-creator,” he may open and update contents of the project. If his privilege is “Viewer,” then he may open but only view the project. All collaborators may add comments to projects. 2.7 The user may delete project(s) created by him. Confirmation will appear. The user may not delete project(s) which he joined as a collaborator, i.e., not Creator. 2.8 The user may change the title of project(s) created by him. Confirmation will appear and notice will be sent to collaborators (if any). 3. Model User Interface 3.1 Layout Prerequisite: the user is logged on. The user has created and opened a project, OR the user opened a project as a collaborator with the “Co-creator” privilege. Postrequisite: the user initiates and/or edits the layout of the interface by assigning the dimensions, number of columns, and grid. 3.1.1 The user may determine the dimensions of the interface. 3.1.2 If the user does not determine the dimensions, the system will use the default values 3.1.3 The user may choose the number of columns. 3.1.4 The user may turn on/off grid. 3.1.5 The user may determine the grid scale. Note: Global settings for size of canvas for every page created within this project. 3.1.6 Page number to id where in the collection it sits (if the selected item is a page) 3.1.7 Page type (if the selected item is a page) 4. Components and Elements 4.1 Components/subcomponents Prerequisite: the user is logged on. The user has created and opened a project, OR the user opened a project as a collaborator with the “Co-creator” privilege. The user has established the layout of the interface and the dimensions, number of columns, and grid for the interface have been determined. Postrequisite: the user finds specific component(s) and brings them to the modeling interface (canvas). 4.1.1 The user can access the UI (EMR-specific) components at Component Library. 4.1.2 The components are classified as multiple subjects (e.g., notes, radiology, emergency medicines). 4.1.3 The user can choose a component and drag it to the modeling interface (canvas). 4.2 Elements

[Page 18]



Prerequisite: the user is logged on. The user has created and opened a project, OR the user opened a project as a collaborator with the “Co-creator” privilege. The user has established the layout of the interface and the dimensions, number of columns, and grid for the interface have been determined. Postrequisite: the user finds specific element(s) and brings them to the modeling interface (canvas). These elements can be stand-alone or can be integrated with other components and/or subcomponents on the canvas. 4.2.1 The can access the UI elements at Element Library. 4.2.2 The user can choose an element and drag it to the modeling interface (canvas). 4.2.3 The user can choose an element and drag it to a component placed on the canvas. 4.3 On-Canvas Objects (position, scale) Prerequisite: the user has placed at least one object (component or element) on the canvas. Postrequisite: the user modifies position and/or scale of the selected object as needed. The user deletes the selected object as needed. 4.3.1 The user can select an object (component or element) and the system highlights the selected object. 4.3.2 The user can delete the selected object by pressing the “delete” key on the keyboard. 4.3.3 The user can change the position of the selected object by dragging it with the mouse or pressing the position keys on the keyboard. 4.3.4 The user can change the scale of the selected object by dragging the bottom right corner of the object. 4.4 Property Editor Prerequisite: the user has placed at least one object (component or element) on the canvas. Postrequisite: the user modifies appropriate condition(s) associated with each object using Property Editor. 4.4.1 The Property Editor panel displays editable conditions of the selected object (component or element). 4.4.2 Each object has its own appropriate conditions that the user can edit. E.g., the panel displays font, font size, weight, italic, text color, alignment, tracking, leading, and position when the user selects a text object. 4.4.3 The editable conditions per individual component/element. 5. Preview Prerequisite: the user has created and saved a project. Postrequisite: the user previews the project. The status of the project switches from “In-progress” to “Published.” The user may send a notice to chosen recipients (e.g., collaborators) 3.1 The user may preview the project via the Preview function. This simulates the actual layout and functionalities using the preview mode. 3.2 The user may exit the preview mode to continue his project. 3.3 The user may publish the project if desired. Additional steps will follow (see Publish for details). 6. Publish Prerequisite: the user has created and saved a project. Postrequisite: the user publishes the project. The status of the project switches from “In-progress” to “Published.” The user may send a notice to chosen recipients (e.g., collaborators)

[Page 19]



4.1 The user may publish the project via Publish. 4.2 The user may send a notice to other users including collaborators. 4.3 The system lists the project under Published Projects. Priority Requirements for Future Phases

• Add ability to apply design themes • Further FHIR incorporation • Support for light event handling and navigation • Export project, explore options other than pdf and html • Technology specific component libraries • Cloud hosting • Build out the social and sharing capabilities to include creating user groups for collaboration • Add user designed component libraries • Rules & Formulas • Testing and Deployment • Continue adding to the pre-designed components and template libraries based on outcomes

from the design and user experience team effort. • Make final adjustments based on final GUI design guidance for multi-inclusion, universal

client. Final Deployment EHR COMPONENTS

The top five tasks for which physicians use EHRs include: accessing patient information, documenting care, e-prescribing, viewing labs and diagnostic tests results, and entering orders.

(source: http://www.healthcareitnews.com/news/docs-blame-ehrs-lost-productivity?topic=,08,19)

This project began with the research and cataloging of existing EHR user interfaces. Following are the modules and sections identified during the process. The “EHR Components” section in the library tab of the EHR Designer web application contains samples of the pre-designed representations of some of the items in this list. More detailed documentation of the research and cataloging is available by contacting PIIM personal. Patient Search

• Search Patients • Search Results

Patient Registration • Register New Patient

o Identifying information (basic patient information) o Contact information o Address o Demographics o Advanced Directive o Insurance/Billing Info

• Register Existing o Search

[Page 20]



o Results Demographics

• Basic patient information o Contact Information

Patient’s contact info Emergency contact info Employment info

• Clinical Information Advance Directives Appointments

• Request for Appointment • New Appointment • View Appointments

o Appointment Overview o Upcoming Appointments (detail)

• Confirm Appointments (check-in) Tracking Boards

• ED • ICU

Other •

Clinical • Chief Complaint • PMH • PSH (past surgical history) • Active diagnosis • Allergies

o Severity: mild, moderate, severe o Reaction o Onset: unknown, adulthood, childhood o comments

• Family History • Social history • Nutrition History

Immunization • Add Immunization • View Immunization

o Vaccine Date administered Administered by Lot Number Expiration Date Dose Comments Optional

[Page 21]



• Body site • Route

Medications • Current Medications

o Search box and simply select meds o Related Dx (options of Dx provided for MD to choose) o Start Date o Stop Date o Comments

• Past Medications Medication Reconciliation Vitals

• Blood Pressure o Location o Patient position

• Heart Rate • Respiration • Temperature

o Temperature source • Oxygen Saturation (SpO2) • Height and Weight and BMI

Notes (The most common type of notes templates) • Type

o H&P o Progress o Consults o Procedures o D/C Narrative o ED Notes o Periop

• Service (general, OBGYN, thoracic, neurosurgery etc.) • Date & Time

CPOE Manage Orders

• Active Orders o Scheduled o Continuous

such as IV fluid o Code Status

full code no code limited code

o Diet o Lab o Imaging

[Page 22]



o Other procedures • Home Meds • Order History

New Order • Medication • Radiology • Lab • EKG Lead

o Sign Provider Nurse

• Medication Warnings (when ordering duplicate) o Current warning o Report (snapshot)

SOFTWARE DESIGN The EHR Designer’s front-end codebase has been organized modularly so that file structure is as indicative of relative responsibility as possible. An outline of relevant elements of the folder structure is as follows:

• /bash – shell scripts for importing elements/components to database • /dist – template files • /lib – server files • /node_modules – back-end dependencies (created via npm install) • /test – test scripts • /www – client-side web files

o /app – Angular.js files o /assets – css and fonts o /bower_components – front-end dev dependencies (created via bower install) o /images – static and dynamically-created images

/default – static default images for a project and page /icons – static icon images /projects – container for dynamically-created images representing pages

o /json – static data not residing in database o /partials – html portions used in views

• server.js – main Node.js server script Specific files of note on the backend are:

• /lib o /config

config.js – Make changes to the default port (3000), MongoDB connection string and email verification options

[Page 23]



route.js – Defines valid application-wide urls and routing behavior, and maps them to methods in /lib/controllers/* for processing

o /controllers/* – Controllers (largely mapped to /lib/models) containing route-processing logic

o /models/* – Defines the valid MongoDB objects and their schema Key aspects of the front-end code are described below. Authorization As regards blocking access to protected pages, the frontend works under the assumption that the backend will return a 401 HTTP Status Code when the logged-in-user attempts to access a resource that they do not have permission to access, or the resource they’re trying to access requires authorization and there is no logged in user. That said, the http-auth-interceptor module intercepts all server responses and dispatches an event:auth-loginRequired event on the root scope. Code in the /www/app/app.js file listens for this event and redirects the user to the login page when dispatched. Session Management When a user logs-in successfully, the server’s authentication code (handled by PassportJS) writes a browser cookie containing session information. When the application starts (i.e. on browser refresh), the www/app/auth/auth.factory.js file tries to initialize a user from a cookie by querying a key-value store provided by ng-cookies. Additionally, whenever the view state or status of a logged-in user changes, a code block in /www/app/app.js attempts to get a user from the server if the page requires one. DEMONSTRATION AND FEEDBACK Demo On January 30th 2015 PIIM presented the EHR Designer to Betty Levine and Robert Connors from TATRC, and List Bartolo-Barnett and Chris Franklin from BUMED. BUMED had previously shown interest in the potential of the application and therefore has been included in several presentations. Suggestions and Feedback During the question and answer portion of the latest demonstration of the EHR Designer participants were encouraged to provide feedback on what they would like to see in the EHR Designer. One notable suggestion was to incorporate health and medical standards other than FHIR. Another was to add the capability to lock elements and components into place on the grid.

Documents

EHR Designer: Engineering Volumepiim.newschool.edu/clients/TATRC/CSIFY10/reports/FY10... · 2015-04-30 · Node.js. AngularJS, Google’s Javascript MVC framework, is an up-and-coming