Synapse - An Integrated Healthcare Application for Patient … · 2017-02-27 · Submitted by Team...

Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong of 42

Synapse - An Integrated Healthcare

Application for Patient Engagement

Team 3 - ISMT E-200, Spring 2012

Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett and Shaun Wong


Table of Contents Executive Summary 4

Client 4

Vendor 4

Business Problem 4

Proposed Solution 4

1. Part 1 - Business Requirements 6

1.1 Business Environment 6

1.1.1 Stakeholders 6

1.1.2 Business Needs 6

1.1.3 Business environmental impact 6

1.1.4 “As Is” and Modified “To Be “Processes 7

1.2 Functions and features 10

1.2.1 Functions to facilitate interoperability with Medical Information Systems 10

1.2.2 Functions for patient management of personal health data 10

1.2.3 Functions to facilitate interaction between patient and physician 10

1.2.4 Functions to meet regulatory requirements 11

1.3 Business Benefit Justification 11

1.3.1 Costs of Implementation 11

1.3.2 Benefits of Implementation 12

1.4 Success Metrics 13

2. Part 2 - Technical Specification and Prototype 15

2.1 Architectural Approach 15

2.1.1 Synapse integration with existing System Landscape 16

2.1.2 Mapping Functionalities to Architectural Concerns 16

2.2 Software solution 17

2.2.1 Development Platform 17

2.2.2 Module View 18

2.2.3 Cross-Cutting Concerns 20

2.2.4 Component Connector View 20

2.2.5 Third-Party Toolkits 21

2.2.6 Allocation View 22

2.2.7 Deployment Model 22


2.2.8 System Metrics 23

2.3 Integration with Enterprise Systems 23

2.4 Data Design and Management 25

2.4.1 Data Entity Relationship Model 25

2.4.2 Data Synchronization 25

2.5 Solution Demonstration 26

3. Part 3 - Implementation Plan 28

3.1 System Deployment 28

3.1.1 Operational Governance 28

3.1.2 Project Timeline 29

3.1.3 Project Deliverables 30

3.1.4 Project Risks 31

3.1.5 Assumptions and Constraints 32

3.2 Operational Readiness 32

3.2.1 Supporting non-functional components 32

3.2.2 Preparation for Change Management 33

3.2.3 Training 34

3.2.4 Service Level Agreement (SLA) 35

3.3 User Enablement 35

3.3.1 Synapse Rollout Plan 35

3.3.2 Data and content management 36

3.4 Success Metrics 37

4. Appendices 38

5. References 40

5.1 Executive Summary 40

5.2 Part 1: Business Requirements 40

5.3 Part 2: Technical Specification and Prototype 41

5.4 Part 3: Implementation Plan 42


Executive Summary

Client

Horizon Healthcare Group (HHG) consists of three hospitals and six multi-specialty clinics located in the East Bay area

of Northern California. HHG provides integrated health care services including acute and critical care for inpatient and

outpatient treatments. With more than 4500 employees, 350,000 patient visits, 650 physicians, 50+ specialty areas,

and revenues of $1.2 billion in fiscal year 2011, the group includes Horizon Hospital, Horizon Clinics, Horizon Center

for Reproductive Sciences, and Horizon Children's Hospital. Currently, HHG manages healthcare data via several

disparate medical information systems, such as Electronic Medical Record System (EMR), Picture Archiving and

Communication System (PACS), and Laboratory Information System (LIS).

Vendor

iMatrix Consulting specializes in advancing the quality and safety of patient care delivery in healthcare organizations

by offering customized medical informatics (MI) solutions. The company has expertise in usability, visual design,

integration of disparate Electronic Medical Record (EMR) systems, and collaboration platforms for distributed

enterprises.

Business Problem

HHG’s 2011 revenues represent a $3.5 million decline from the previous year. This figure reflects significant loss in

revenues because of decreased outpatient retention. HHG contributes this decrease to (1) Decline in customer

satisfaction and engagement levels (2) Inadequate methods for physicians to improve outcomes through effective

management of patient progress between visits and (3) Lack of effective mechanisms to provide intuitive and timely

communication between patients and clinicians. HHG believes solving these challenges will be critical for offsetting

revenue losses, maintaining competitive market position, and sustaining profitability in the future. Further analysis

reveals the following factors contribute to these challenges:

• Absence of an integrated view of critical patient-centric data from diverse medical information systems.

• Absence of electronic tools for patients to access their medical data, such as lab reports and prescriptions.

• Absence of electronic tools to manage and view self-monitored health results of patients between visits.

• Lack of accessible and intuitive communication mechanisms for physicians to convey care plans and

treatment initiatives.

A Request for Proposal (RFP) has been solicited by HHG to address the challenges above.

Proposed Solution

iMatrix proposes the development of “Synapse,” a patient-engagement application to increase HHG’s patient-

retention rates and improve perception of quality of care. The primary goals of the Synapse system are:

• Enable physicians to view and share critical patient-specific data integrated from HHG’s diverse medical

information systems to eliminate inefficiencies resulting from multiple points of access to data.


• Enable patients to access personal medical profile information, such as lab reports, clinical summaries, and

prescriptions, to increase awareness, engagement, and involvement with disease management.

• Facilitate rich and intuitive communication channels between patient and physician to provide convenient e-

visits, improve patient engagement, and reduce unnecessary routine visits.

• Increase patient loyalty by providing tools to enter self-monitored health data so physicians can track and

analyze data to convey modifications, references, intervene, and monitor.

• Enable clinicians to access patient medical records and communications from mobile devices, such as tablets

and smart phones, by presenting quick views of messages, alerts, and notifications.

Synapse will be accessible from anywhere using a web browser and will satisfy privacy and security requirements

specified by The Health Insurance Portability and Accountability Act of Privacy and Security Rules (HIPAA). The system

will utilize a service-oriented architecture (SOA) approach to provide the following functions to meet proposed goals.

1. An integration engine which integrates patient data from existing medical informatics systems inside HHG

and provides a simplified patient-centric view of relevant records to both patients and physicians

2. A physician interaction view which provides new functions such as integrated view of records, search-based

decision support, e-prescribing capabilities, and trend analysis of patient’s self-monitored data.

3. A patient interaction view which provides access to medical records, manage self-monitored health data and

trends, provides key updates about treatment progress, procedure preparations and reminders.

4. Communication tools for e-visits and secure messaging to enrich patient-physician communication

iMatrix projects implementation of Synapse will allow HHG to achieve an estimated $7.6 million in return value ($1.1

MM cost savings and $6.5 MM in additional revenue ) within the first year itself. This return on investment would

cover costs for the implementation of the system ($2.18 MM) and also fully recover HHG’s loss of revenue ($3.5 MM)

from the previous year. Implementation of Synapse will enable HHG to improve revenues by:

• Billing patients for physician e-visits that encompass secure messaging, template-based Q/A, video

conferences, and additional treatment activities patients can avail online. Online interactions free up provider

schedules and time allowing for additional patients visits in the office.

• Increasing physician efficiency by reducing time spent in accessing information from multiple systems. Lighter

schedules will improve retention of expert physicians and enable them to focus on effective treatment.

• Enhanced patient interaction will enable HHG to streamline clinical workflows, improve outcomes and

increase customer loyalty due to better quality of service

Implementation of the Synapse platform will allow HHG to attain significant decreases in costs such as:

• Mailing and Delivery Costs to convey results, educational materials, forms, and CDs with medical images.

• Staffing Costs related to phone, fax, and e-mail support for clarifying patient questions, conveying results, and

administrative functions, such as updating medical records and relaying messages to physicians.

• Resource and Materials Costs related to printed forms, brochures, ink, fax machines, and paper.


1. Part 1 - Business Requirements

1.1 Business Environment

1.1.1 Stakeholders

The following stakeholders have been identified as participants in the business process flows of HHG:

Physician Performs study, diagnosis, treatment of disease and other physical or mental impairments.

Physician

Assistant (PA)

Autonomously conduct physical examinations, diagnose and treat illnesses, order and interpret

tests, and write prescriptions, if approved by supervising physician.

Medical

Assistant (MA)

Performs administrative and clinical tasks and procedures such as measuring patients' vital signs,

administering medications, and recording information in medical records systems.

Nurse Performs basic duties such as treating, educating, and recording patients' medical histories and

symptoms. Assists in performing diagnostic tests and analyzing results.

Patient An individual who requires medical treatment, maintenance, improvement or protection of health

for a particular disease or condition under a physician's guidance.

1.1.2 Business Needs

Synapse is designed to fulfill the following high-level business needs to meet HHG’s strategic objectives:

• Provide physicians with an integrated view of patient data from multiple medical information systems

accessible via web and mobile devices from any location.

• Allow patients to gain timely, secure, electronic access to personal health records such as lab results, medical

images, prescription information, and clinical summaries.

• Provide physicians with tools to track and analyze patients’ self-monitored health data, compliance of

prescription dosages, lifestyle recommendations, and treatment plans between clinical visits and convey

feedback regarding such data.

• Provide integrated decision-support tools for physician aid in avoiding critical errors, streamlining work flow

management, and stay updated on current research relevant to patient treatment.

• Provide improved communication tools such as e-visits and secure messaging between physicians and

patients

1.1.3 Business environmental impact

Synapse will perform the following main functions:

• Integrate and present consolidated quality data from disparate systems.

• Provide direct patient-physician communication and medical data transfer such as educational material, lab

reports, messaging, comments, and email.


• Provide self-service tools for patients such as appointment management, medical record access, prescription

refills, and illness monitoring.

Synapse will change HHG’s business environment in the following ways:

• Personal medical records, health information, appointment requests/changes/cancellations, and prescription

refills will be available to patients 24/7 through Synapse’s self-service tools

• Receptionists/support staff will be eliminated in most cases from direct communication between patient-

physician. Forms completion and medical record requests can be completed online. Receptionist/medical

staff call volume, walk-in paperwork, and record request burden will be lessened with Synapse.

• Mailing and delivery will be eliminated in the area of lab report mailing, form mailing, and healthcare

educational mailing for patients with access to Synapse.

1.1.4 “As Is” and Modified “To Be “Processes

Implementation of Synapse will enable several modifications to business process flows in the HHG clinical

environment. Our process improvements are limited to clinical work flows revolving around outpatient care. The

most significant modified processes are described below.

1.1.4.1 Tracking Patients’ self-monitored data

Currently, patients who monitor health data manually at home (e.g., blood pressure and blood sugar levels) between

visits have no way to share personal measurements electronically with their physician. Physicians have to depend on

patients to log and present such data manually during ensuing visits. This forces physicians to spend precious

consultation time wading through incomplete or disorganized data captured by the patient. Additionally, physicians

must analyze and note abnormal values or trends mentally and have no way to compare historical progress. Synapse

will provide patients with intuitive tools to enter, upload, and share personal health-monitoring data with physicians.

Once the patient enters his or her data, Synapse will log, analyze, and present an efficient, filtered format to the

physician/PA to enable timely analysis and action. Figure 1 and Figure 2 illustrate the modifications in this process.

Figure 1 - As-Is: Tracking and analyzing patients’ self-monitoring of health data


Figure 2 - To-Be: Tracking and analyzing patients’ self-monitoring of health data

1.1.4.2 Patient Requesting Medical Records/Rx

Currently, patients who want to access their medical records or renew prescriptions have to call HHG and wait for a

lengthy authorization and release process before getting access. Physicians have to access multiple systems to retrieve

records when patients ask questions about results. This makes it difficult for physicians to review and collaborate on

these records with the patient. Additionally, the released records are provided in hard copy format or lab results and

renewal information is conveyed via phone. With Synapse, patients can request records access, fill out requisite

release forms and request Rx renewal online. Physicians can view records integrated from multiple systems and

approve release or renewal. Patients can view, download or print electronic copies of records or pick up prescriptions.

HHG gets timely notification and can track inaccuracies/errors reported by patient. Figure 3 and Figure 4 illustrate the

modifications in this process.

Figure 3 - As-Is: Patient Requests Medical Records/Rx


Figure 4 - To-Be: Patient Requests Medical Records/Rx

1.1.4.3 Patient Communicating with Physician

Currently at HHG, a patient who wants to communicate with his or her physician will have to interact via a lengthy and

inefficient process. Messages are interpreted by support staff leading to confusion and absence of immediate

acknowledgement. Physicians are constrained by lack of intuitive tools to quickly review and respond to important

messages. Patients often become frustrated at the lack of timely response as health needs are dynamic. With Synapse,

patients can send instant messages, offline comments, and requests securely to physicians. Support staff can view,

filter, and respond to messages within minutes. Flagged messages are automatically forwarded to the physician for

review and response. Details of the interaction can be saved and retrieved for later viewing and any further

clarifications requested by patient can be addressed immediately. Enhanced communication will improve the

physician-patient relationship, and allow physicians to better manage monitoring of quality of service. Figure 5 and

Figure 6 illustrate the modifications in this process.

Figure 5 - As-Is: Patient Communicates with Physician


Figure 6 - To-Be: Patient Communicates with Physician

1.2 Functions and features

1.2.1 Functions to facilitate interoperability with Medical Information Systems

• Progress Notes: Retrieve notes from EMR made by the physicians, nurses, and therapists caring for patients

to reflect patients’ response to treatment, observations, and plans for continued treatment.

• Imaging Reports and Studies: Retrieve and allow users to view historical imaging reports from the hospital

RIS as well as imaging studies from hospital PACS

• Lab Reports and Immunization Records: Retrieve immunization records from EMR and lab results from LIS.

Common examples include throat culture, urinalysis, cholesterol level, and complete blood count (CBC).

• Medication Record: Retrieve a list of medicines prescribed or given to patient from the EMR system.

1.2.2 Functions for patient management of personal health data

• Demographic Information: Provide a mechanism for user to enter his or her name, date of birth, ethnicity

and other demographic information and update erroneous or missing information whenever necessary.

• Current Medications: Allow the user to maintain information regarding medication the user is taking, related

dosage, frequency, prescriber, and date prescribed.

• Pertinent Test Results: Allow the user to maintain information such as diagnostic tests completed, date test

was performed, results, trends, and who performed the test.

• Allergies: Allow the user to enter and maintain information related to allergy sources.

• Current Health Risk and Family History: Allow the user to enter and update perceived health risks for genetic

diseases and related family history.

1.2.3 Functions to facilitate interaction between patient and physician

• Secure Messaging: Enable patient to perform secure messaging with his or her physician.

• Physician Initiated Alerts and Notifications: Enable physician to signify alerts and leave notification messages

to the patient for items requiring attention.

• Audio/Video Meeting: Enable patient to request and schedule an audio or video meeting with his or her


physician to clarify treatment options or display anatomical and visual symptoms.

1.2.4 Functions to meet regulatory requirements

• Authentication: Allow a user to access information after the user’s identity has been verified.

• Authorization: Enable a patient to authorize access of his or her data to other individuals.

• Confidentiality and Integrity: Ensure the data maintained by the system cannot be intercepted during

transmission or use by unauthorized users and that data maintained by system cannot be created or

amended without appropriate authorization.

• Audit Trail: Maintain an audit trail of activities performed by users.

1.3 Business Benefit Justification

1.3.1 Costs of Implementation

The estimated costs for installing the Synapse Engagement Platform include software licensing fees, hardware,

implementation, training, ongoing costs to maintain the system, software license maintenance fees and continuing

education for support staff. The project is measured on a three-year basis. The cost of the solution will vary,

depending on the complexity of the development and implementation effort required during the project. The

estimated costs are detailed in the table below.

Cost Initial Year 1 Year 2 Year 3 Total

Software Development Licensing fees - MS Windows OS,

MS SQL Server DB, MS Visual Studio, Merge DICOM toolkit,

Merge HL7, Apixio & AllScripts web services

$120,000 $120,000

Hardware Costs for Development - Laptops for

Engineering, QA, and support staff. Servers for Engineering,

Quality Assurance, and Staging, additional storage and

backup

$80,000 $80,000

Production Hardware Costs - Web server, Data server,

Integration Engine, Storage units

$30,000 $30,000

Production Operating System and Database License Fees -

Microsoft Windows Server and MS SQL Server

$70,000 $70,000

Runtime License Fees - Merge DICOM and HL7, AllScripts

and Apixio

$10,000 $10,000 $10,000 $30,000

Professional services - 10800 development hours at $1,620,000 $1,620,000


$150/hour (12 consultants on project)

Internal implementation - Internal labor estimated at 1200

hours at $100 per hour includes integration, testing, and

analysis.

$120,000 $120,000

Initial training - Cost of training 60 staff members for 4

hours each, at $50 per hour

$12,000 $12,000

License maintenance fees - 20% of initial software licensing

fees

$24,000 $24,000 $24,000 $72,000

Continuing education for support staff - Continuing

education 60 staff for 3 hours each, at $50 per hour

$9000 $9000 $9000 $27,000

Total Costs $2,052,000 $43,000 $43,000 $43,000 $2,181,000

1.3.2 Benefits of Implementation

iMatrix conducted a comprehensive financial analysis of business processes at HHG to evaluate the effects of

implementing the Synapse system. This was done via a research approach including:

• In-depth interviews of key Synapse users who deliver patient care

• Interviews with management in operations, IT systems, and finance

• Modeling and analyzing current clinical processes and work flows to identify cost inefficiencies and missed

revenue opportunities

Our research reveals the implementation of Synapse will create a potential increase of $7.6 million in revenues

through increased revenue opportunities such as billable e-visits, cost reductions, and elimination or modification of

current inefficient and time-consuming processes. iMatrix conservatively estimated a 25% patient-adoption rate of the

Synapse platform for the first year, representing approximately 87,500 clinic visits. The associated administrative and

resource cost reductions such as the mailing of lab results and medical forms would result in approximately $1.1

million in savings. Furthermore, streamlined processes such as patients’ ability to complete forms and send

comments to physicians on visit discussion topics prior to visit, along with physician access to fast, integrated patient

data and critical follow-up item alerts will allow physicians to shorten visit duration (approx. five minutes per patient).

The ability to shorten visit time adds value to HHG by allowing physicians to schedule additional appointments. This

increase in clinical visits is conservatively estimated to contribute $3 MM in additional revenue. This estimate is based

on approximately 15% (100) of HHG’s physicians assisting an extra patient per day. Our analysis shows implementing

Synapse will increase yearly revenues by $7.6 MM. This figure offsets the $3.5 MM revenue loss from the previous

year and enables HHG to fully recover the cost of Synapse implementation ($2.18M) in the first year of service.


Projected Revenue Increases and Decreased Costs for HHG Calculation

Increase in Revenue

Increased Revenue generated by compensation for e-visits

* calculated on basis of 50% (325) of HHG’s physicians providing 6 e-visits weekly at rate of $35 per e-visit

for 50 weeks

$3,412,500

Increase in Physician Productivity

* calculation based on 100 physicians taking an additional visit of $120 in revenue per day for 260 days

$3,120,000

Total increase in Annual Revenue $6,532,500

Reduction in Administrative Costs (per patient)

Reduction in mailing costs of lab results $0.63

Reduction in cost of Lab result delivery $2.69

Savings from appointments scheduled online $7

Reduction in phone call time costs $1.75

Reduction in cost of appointment reminders $.62

Total cost reduction per patient $12.69

Total Decrease in Costs ($12.69 * 87500 patients) $1,110,375

Total Projected Increase in HHG Revenues $7,642,875

Aside from immediate monetary returns, Synapse implementation will generate a range of benefits to support HHG’s

long-term strategic goals of offering high quality care, better branding, patient retention, and maintaining competitive

positioning. Expected benefits such as increased patient engagement, improved patient satisfaction, and enhanced

patient-physician communication will support these long-term objectives. The successful implementation of Synapse

will shorten visit times and reduce unnecessary ER and office visits. These benefits can alleviate under-staffing and

work-overload problems so physicians have more time to focus on treating patients with dire medical needs.

1.4 Success Metrics

iMatrix identifies the following significant metrics to measure the value Synapse implementation will deliver to HHG.

Key performance metrics (KPIs) are organized into two categories to measure success for internal and external

stakeholders who impact the core of HHG’s business: (1) Providing quality healthcare and (2) Maintaining profitability.


KPIs to Measure Metrics and Expected Results

INTERNAL SUCCESS METRICS

Improved Productivity:

• Visit Duration per Patient - shorter visits indicates streamlined processes and better focused conversations

during visit.

• ER Visit Count – decrease indicates better disease management and reduced unnecessary visits due to

functions provided by Synapse. Reduces ER staffing cost.

• Annual Patient Count – decrease in declining count shows the effect Synapse will have on retention success.

• E-Visit Count - shows additional revenue from new service offering though Synapse

Reductions in Administrative Costs and Efficiency Improvements:

• Front Desk Call Volume - decrease in volume indicates success with patient-physician direct communication

and patient utilization of self-service tools

• Administrative Functions – reduce forms and printed material cost and mailing of lab results and delivery of

educational material cost. Eliminate/reduce mistakes and errors when entering and updating patient data.

• Portal Utilization Rate measures number of physicians and caregivers utilizing Synapse to communicate and

engage with patients.

• Physician Satisfaction Rate measures physicians’ satisfaction with usability and functionality of Synapse

EXTERNAL SUCCESS METRICS

Patient Utilization and Satisfaction: - 25% adoption in 1st year

• Visitor Conversion Rate (CR) measures the percentage of site visitors who utilize the portal and access the

intended functionalities.

• Visitor Loyalty and Visitor Recency (VL and VR) measures number of patients who visit the site repeatedly and

frequency of access. These two indicators measure patient engagement and loyalty.

• Task Completion Rate (TCR) using in-session or on-exit surveys to measure by asking questions such as "Were

you able to complete your task?"


2. Part 2 - Technical Specification and Prototype

2.1 Architectural Approach

iMatrix has chosen a service-oriented architecture (SOA) approach for the development of Synapse. Implementation

of the Synapse architecture will involve defining the use of services to support business requirements. Resources will

be made available to other participants in the network as independent services are accessed in a standardized way.

Unlike traditional object-oriented architectures, SOAs are composed of loosely joined, highly interoperable business

services. Implementing a true SOA will result in enhanced interoperability and reusability of components, which lead

to benefits, such as cost reductions, business agility and flexibility. The architectural diagram below illustrates the

Synapse system architecture from a contextual viewpoint. In this view, the system is modeled as a set of loosely

coupled logical services important to the external actors.

Figure 7: System Context Diagram

As shown in the diagram, Synapse will integrate with HHG’s existing medical information systems via industry standard

protocols HL7 and DICOM over secure communication channels. The Synapse system will also use HL7 and REST-based

APIs to integrate two external vendor systems (a) Allscripts e-prescribing and (b) Apixio Decision Support Platforms.

The data interface layer receives information from the integration engine to pre-process the data and store it in a

relational database. Patients and healthcare providers will access the Synapse user interface via a standard web-

browser on multiple types of devices. When a user wants to access specific services such as trend analysis of personal


health data or viewing lab reports, the Synapse presentation layer initiates a REST-based request to the web services

layer over a secure HTTPS channel. The web services layer in turn invokes one or more operations from the business

workflow layer. The business workflow layer retrieves relevant data using the data interface and orchestrates multiple

computational tasks to fulfill the web service’s request. Finally, the results are sent back to the presentation layer via

REST callbacks and rendered on screen for the user. Further details of the system architecture are elaborated in the

software solution section.

2.1.1 Synapse integration with existing System Landscape

Synapse will be developed and deployed as a Greenfield system. Synapse integrates with multiple existing medical

information systems by using industry standard DICOM and HL7 protocols. Synapse will be configured to pull data

from these medical information systems on a periodic basis. The data is post-processed and locally persisted in the

Synapse relational database so an integrated view of the patient medical records can be presented to both physician

and patient. Activities in Synapse, such as personal health record management and e-Visit scheduling, generate new

information, which are solely maintained in the Synapse local database and are not pushed to the existing hospital

medical information systems as those systems are not designed to process and render such information to end users.

The diagram below shows how Synapse fits into and improves HHG’s patient engagement process through clinical

management.

Figure 8: How Synapse fits into HHG’s patient-engagement process

2.1.2 Mapping Functionalities to Architectural Concerns

The table below shows a summary of the key responsibilities of each architectural layer of the Synapse system. The

software solution section provides more information regarding the architectural modules.


Layers Architectural Concerns

Presentation

Layer

• Providing optimized HTML5 and CSS-compliant views for desktop and mobile devices

• Handling view-dependent user actions, invoking corresponding operations from the

service layer and updating the views

• Displaying context-specific data pulled from EMR, LIS, PACS, and RIS

• Providing tools to manage personal health record information and organize e-Visits

Service Layer • Providing web-service for retrieving data pulled from EMR, LIS, PACS, and RIS

• Providing web-services for retrieving, storing, and performing trend analysis of patient

health record (PHR) data

• Providing web-service for notifying output of any decision analysis tasks

• Providing web-service for holding e-Visits

• Providing web-service for authorization, authentication, and auditing services

Business Layer • Analyzing trends for PHR Data

• Performing decision analysis on patient medical records

• Compressing medical images

• Synchronizing scheduling events for e-Visits

• Coordinating services for instant messaging and conferencing.

Data Layer • Receiving medical informatics data pushed by integration layer in XML and mapping them

to the Synapse relational database.

• Providing mechanism for mapping in-memory objects representing PHR, EMR, e-Visits, and

various similar components to the Synapse relational database

Integration Layer

• Pulling data from medical information systems using DICOM and HL7

• Post-processing the pulled data and transmitting it to data layer

2.2 Software solution

2.2.1 Development Platform

The presentation layer of Synapse needs to be cross-browser compatible and needs to run on multiple operating

systems. As a result, a combination of JavaScript, HTML 5 and CSS 3 was selected for implementing the presentation

layer. For the other layers, Microsoft.NET Framework 4 was selected because of its extensive class library support and

readily available pool of third-party tools in the medical informatics domain. Microsoft SQL 2012 was selected as the


database server because of ease of integration with .NET codebase via Entity Framework.

2.2.2 Module View

A module in Synapse is considered an implementation unit of software providing a coherent unit of functionality. The

following diagram of the Synapse architecture shows how different modules are organized in multiple layers.

Figure 9: Software Module Layer View

Presentation Layer: The presentation layer of Synapse contains the components that implement and display the user

interface (UI) and manage user interaction. This layer is also responsible for organizing data pulled from the service

layer in a consumable format for the UI components; for example, presentation logic applies image processing filters

to the medical images delivered by the service layer before the images are displayed on the browser. Because Synapse

presents visually rich medical informatics data in multiple views, many such views have important state information.

Separation of such state information is crucial for ease of maintenance and extensibility of the presentation layer. To

achieve this, Synapse uses the presentation model pattern, which pulls presentation behavior from a view into a

model class. This layer is developed using Javascript, HTML5, and CSS 3 to satisfy cross-browser compatibility

requirements.


Service Layer: The Synapse service layer exposes a collection of web service interfaces offering medical informatics-

related operations, which are accessed by the presentation layer. The major service interfaces include visualizing and

manipulating medical images, accessing PHR, EMR and Lab records, engaging in audio-visual communication sessions,

and performing instant messaging. Service operations in Synapse are designed to be coarse grained keeping the

performance and scalability requirements of the system in mind. Because Synapse supports different kinds of client

devices in the presentation layer, data contracts of the service layer are designed so they can be extended without

affecting current consumers of the service. The services in this layer were designed to leverage the facilities available

in the Windows Communication Foundation (WCF) framework of the .NET platform.

Business Layer: Synapse’s business layer manages processing of medical informatics data and ensures application of

business rules. Several workflow processes in Synapse involve multiple steps that must be performed in the correct

order, and interact with each other through an orchestration. For example, the decision-support component informs

the physician regarding the preventative care measures, such as flu vaccines, colon cancer screenings, and cholesterol

tests, for a specific patient based on age, medical history, medication list, and similar areas stored in HHG’s EHR. Other

business workflow components handle analyzing the patient health record to provide trend analysis, compressing

medical images offline so they can be transferred progressively later in an on-demand fashion. Depending on the

need of the specific business workflow components, Synapse architecture makes use of sequential, state machine, and

data driven workflow patterns. The business workflow components were designed on top of the Windows Workflow

Foundation available in the .NET platform.

Data Layer: The data layer manages persistence and retrieval of medical informatics data in Synapse. Data maintained

in the Synapse system falls into two categories. The first relates to information generated within the boundaries of the

system, such as personal health records uploaded by patients, e-Visit-related information, instant messaging data, and

information generated by decision-support analytics. The second category involves information pulled from the

medical information systems managed within the hospital infrastructure, such as EMR, PACS, RIS, and LIS. This layer

uses the data mapper pattern to facilitate transferring of data between in-memory objects and a relational database.

Synapse utilizes the ADO .NET Entity Framework to model business domain objects as well as mapping these domain

objects to relational data in the SQL 2012 database.

Integration Layer: The integration layer of the Synapse system interfaces with the existing medical information

systems, such as PACS, EMR, RIS, and LIS, using industry standard protocols DICOM and HL7. Synapse can push and

pull information to and from these medical information systems using this gateway layer. This layer uses the adapter

pattern to translate requests from the data layer to HL7 and DICOM-based messages.


2.2.3 Cross-Cutting Concerns

Synapse architecture contains several cross-cutting concerns, which span across the different architectural layers

mentioned earlier. The major cross-cutting concerns are: authentication, authorization, communication modes

between layers, and exception management.

• Authentication: Synapse authenticates users using a two-factor authentication scheme. This scheme

validates the end user against his or her login, password, and a SiteKey displayed on the recognized client

device. SiteKey authentication is a highly secure method used by many large banking systems.

• Authorization: Authorization is used to determine which resources or actions can be accessed by an

authenticated user. Synapse uses a claims-based identity mechanism to authorize users. Central to this

mechanism is the concept of claim, a digital record, which carries important pieces of information regarding

the user, such as the role of the user, resources the user can access, and operations the user is allowed to

perform in Synapse. Synapse implements a configurable security token service (STS), which can generate

appropriate claims for an authenticated user. The system uses Microsoft Identity Foundation framework to

analyze such security tokens for deciding whether a user should be allowed to perform a specific action.

• Communication: Another important aspect of system security in Synapse is message protection during

transmission from one architectural layer to the other. Layers inside the hospital network are already

protected within a secure IT environment; and therefore, do not require any additional encryption or

cryptographic techniques for message protection. However, Synapse also interacts with external entities in

two ways: 1) via client devices and 2) external services, such as Apixio and AllScripts. The communication

channel from Synapse to these entities needs to be secure. Synapse uses SSL-based transport layer protection

because it is an accepted industry standard and supported on a variety of client devices. Additionally, if HHG

considers a cloud deployment model in the future, a SSL-based transport layer security would be useful for

communication across layers.

2.2.4 Component Connector View

Figure 10: Component Connector View


The component-connector view in Figure 10 shows the runtime structure of the Synapse architecture. Each box shown

in the diagram represents a component running as a process in its execution environment. The line between any two

components represents a connector, which transmit streams of data from one component to another. HHG’s

information systems communicate with the integration engine via HL7 and DICOM messaging protocols. The

integration engine advertises XML messages for the data server to consume using the XML event bus. The data server

persists and retrieves data from the SQL server database using ADO.NET. The business application server

sends/retrieves messages to the data server via WCF. The user interface component exchanges messages with the

business application server using REST invocations.

2.2.5 Third-Party Toolkits

The table below shows the external toolkits used by various module layers in Synapse.

Presentation

Layer

jQuery: Synapse uses jQuery in the presentation layer for HTML document traversing, event

handling, animating, and Ajax interactions. jQuery is licensed under MIT license.

jQuery UI: This toolkit provides re-usable UI components and is licensed under MIT license.

Business

Layer

OpenFire: Synapse uses OpenFire, a real-time collaboration (RTC) server for instant messaging and

video conferencing collaboration. OpenFire uses the XMPP open protocol for instant messaging.

OpenFire server is licensed under the Open Source Apache License.

OpenJPEG: When DICOM images are pushed by integration layer, Synapse compresses the images

with the OpenJPEG codec.

Integration

Layer

MergeCom DICOM Toolkit: This commercial toolkit enables Synapse to interface with HHG’s existing

medical imaging systems using the latest DICOM standard.

MergeCom HL7 Toolkit: Synapse uses this commercial toolkit to integrate with EMR and LIS systems.


2.2.6 Allocation View

The diagram below depicts the mapping of components and third-party software to physical hardware devices.

Figure 11: Allocation View

The web server hardware will host web services using IIS and the Application Server will host the business workflows

in a .NET environment. These two server software components will be deployed in two distinct hardware units as the

application server resides within the secure intranet environment whereas the web server is deployed within DMZ.

The data server hardware hosts the data engine and database software. A dedicated server for the database and the

data engine component will be allocated for server load balancing and streamlining of DBMS operations that are

minimally disruptive to the application layer. The integration manager is allocated to a separate hardware unit inside

the DMZ because it communicates with other hospital systems and external data systems. This allocation model

allows maximum flexibility and scalability as the remaining server-side units can be allocated to the cloud easily

without disrupting the integration engine deployment. Lastly, the HTML5 and JavaScript-based browser application

will run typically on a separate hardware device owned or operated by the end user.

2.2.7 Deployment Model

Synapse’s Web server, data server and integration engine will be hosted inside HHG’s internal data center.

Because Synapse has to manage sensitive patient healthcare data, physical and electronic security is a significant

concern. HHG has already invested and built an extensive yet secure IT infrastructure to host and manage HIS, RIS,

PACS, EMR, and other healthcare informatics systems. Their IT personnel staff are experienced and trained in

efficiently managing systems containing sensitive data. Consequently, HHG prefers leveraging their existing IT

infrastructure investment to host Synapse internally. However, the Synapse architecture is designed to be flexible so

moving to a cloud-based solution in the future would require minimal changes and disruption. To protect the Synapse

servers from malicious intrusions, any communications to or from the Internet will go through HHG’s firewall, which

utilizes trusted communication channels and ports.


2.2.8 System Metrics

Factor Estimated Value

Number of Users Projected number of Synapse users in the first year is 89,000. This is derived from 87,500 patients

(25% of annual clinic visits), 650 physicians and 900 support staff accessing the system.

Daily Sessions On an average, 950 patient visits occur at HHG every day. For 70% of these visits, physicians will

access Synapse at least once resulting in 675 Synapse sessions. In 40% of these cases

PAs/Nurses/MAs will also access Synapse resulting in 270 additional sessions. Approximately 240

patient sessions are expected bringing the total to 1185 daily end-user sessions.

Transaction

Volume

Each Synapse session is expected to last about 15 minutes. Per session, 100 audit-log entries and

200 data retrievals and updates are expected to result in 355,500 database transactions.

System Response

Time

The system response time will depend on the Internet connection speed with which the client

application accesses Synapse server components. Response time is expected to be largely

instantaneous, approx. 1 to 2 seconds per message round-trip, assuming a standard broadband

Internet connection. For accessing imaging data, the response time will be double. During e-Visit

scenarios, the response time for live video and audio streams over Internet will be largely

instantaneous. Delays may occur because of varying Internet connection speeds during e-Visits.

Imaging Data

Volume

On average, each patient will have one imaging study. Each DICOM imaging study is

approximately 256MB. Given a daily access of data for 475 patients (50% of the total daily patient

visits), at least 120 Gigabytes of imaging data has to flow through Synapse daily.

Availability Synapse will be used by HHG staff and patients daily so the system’s availability uptime must be

high. We anticipate about two hours of offline maintenance activity every month. This results in

99.7% monthly system availability. Offline maintenance during off hours will ensure 100%

availability for most users.

2.3 Integration with Enterprise Systems

Synapse integrates with multiple existing medical information systems within HHG, including PACS, EMR, RIS, and the

LIS. Synapse also integrates with two external systems: the Apixio system for managing decision support and the

Allscripts system to manage e-Prescriptions. Synapse utilizes industry standard DICOM protocol to communicate with

PACS and RIS, whereas HL7 v3 is used to exchange information with EMR, LIS, Apixio, and Allscripts. As both HL7 and

DICOM are complex standards, Synapse makes use of two commercial software development kits (SDKs): Merge

DICOM toolkit and Merge HL7 toolkit, to enable fast and robust integration. These SDKs provide efficient .NET-based


application programming interfaces (API) to exchange information in DICOM and HL7 protocols without the need to

implement such standards from scratch. An overview of the integration techniques used for each system is provided

below.

Interaction with EMR and LIS: Synapse needs to retrieve clinical information, such as progress notes, medication

records, and immunization records, from the HHG EMR system. Synapse is also required to retrieve patient-specific lab

reports from the LIS system. Synapse uses the HL7 clinical document architecture (CDA) standard to retrieve such

information. CDA is a document markup standard for the structure and semantics of an exchanged clinical document.

CDA is derived from HL7's central reference information model (RIM), thereby enabling data reusability. Synapse

assumes the application role of “tracker,” an application role mandated by the HL7 message information model, when

retrieving information with EMR and LIS. Once a CDA document is retrieved, it is transferred to the Synapse data layer

for post-processing and local persistence.

Interaction with RIS: Radiology reports generated in HHG are managed inside the RIS using the DICOM structured

report (SR) service object pair (SOP) instances. SR SOPs are intended to create complex structured documents in which

text, various medical images, and other data types can be mixed and organized together. SRs support use of coded

entries and a hierarchical tree of DICOM attributes. Reference to SOP instances, such as images, waveforms, or other

SR documents, is restricted to appear at the leaf level of this tree-like structure. Synapse provides a SR service class

user (SCU) agent, which can be configured to query RIS for any newly available SR SOP instances. Once these instances

are received, the service agent parses the DICOM attributes and converts the original SOP instance into an XML

document conformant to a well-defined XSD schema. This XML document is transferred to the Data layer of the

architecture for local persistence.

Interaction with PACS: At HHG, patient-specific imaging studies acquired via different modalities, such as CT, MRI,

PET, and Ultrasound, are managed inside the PACS system using modality-specific DICOM service classes. A

radiological structured report could link to multiple DICOM studies by referring to the appropriate SOP instances

stored inside the PACS archive. Synapse provides an imaging store SCU agent, which can be configured to query the

PACS archive for any newly available imaging SOP instances. The images are transferred to the Synapse data layer

using a binary transport protocol for local processing and persistence.

Integration with Apixio: Synapse integrates with Apixio’s “Clinical Knowledge Exchange” framework for providing

patient-specific clinical-decision support. Using Apixio’s semantic search technology, a physician can mine patient’s

medical record to search for appropriate diagnostic assistance and contextual information on patient’s lab results. To

mine such information, first patient-specific data needs to be transferred to Apixio’s web-based data center. Synapse’s

integration layer pulls information from the EHR and LIS using the HL7 CDA standard as mentioned earlier. It

transforms this information to generate a CCD and uploads it to Apixio using our secure web services. For front-


integration, Synapse presentation layer communicates with Apixio’s clinical knowledge exchange using a REST-based

API. Physicians can perform search for clinical decision support within Synapse’s presentation layer.

Integration with Allscripts: Synapse integrates with Allscripts so prescriptions can be managed electronically.

Allscripts provides integration with their Sunrise Enterprise suite of solutions through the Allscripts Developer

Program. The Synapse presentation layer uses Allscripts Helios SDK to integrate with their e-Prescribing utilities.

Allscripts’ Platform can also periodically transmit medication records to Synapse’s integration layer via HL7 CCD.

2.4 Data Design and Management

2.4.1 Data Entity Relationship Model

Figure 12: Entity Relationship Model

The above schema diagram depicts the major data entities persisted in the Synapse database. It has been designed to

represent health and medication records, while representing information generated during user sessions.

2.4.2 Data Synchronization

Synapse has a local database for storing the data records from HHGs medical informatics systems, such as HIS, RIS, LIS,

and PACS. Storing the information in a local database for the Synapse application makes it instantly accessible to the

Synapse end user. However, synchronization problems exist with this approach. As time passes, data stored in the

Synapse DB becomes stale and will need to be refreshed for the end user to perform his or her tasks efficiently.

Instead of allowing the Synapse integration layer to poll the medical informatics systems periodically, the

synchronization problem can be solved more efficiently if data is pushed to the Synapse integration layer based on

triggers as and when new data gets acquired. HHG’s PACS and RIS systems can be configured to route any newly


acquired DICOM imaging studies and SRs to the storage service class provider (SCP) agent of the Synapse integration

layer. The types of imaging modalities and imaging protocols can be configured depending on HHG’s needs.

Additionally EMR and LIS can be configured to assume the HL7 application role of “Informer,” whereas the Synapse

integration agent takes the role of “Tracker” in any HL7-based event exchange. This would ensure that Synapse gets

notified any time a new record of interest gets acquired inside EMR or LIS systems.

2.5 Solution Demonstration

Usability design was carefully considered keeping the layers of complexity involved in presenting user information.

Synapse utilizes several effective web design patterns to create an intuitive, clean, attractive, and simple user

interface. Synapse utilizes module tabs in the Physician Interface (Figure 13). Module tabs is a User Interface (UI)

design pattern where content is separated into different panes, and each pane is viewable one at a time. The user

requests content to be displayed by clicking, or hovering over, the content’s corresponding tab control. Module tabs

optimize webpage screen areas without sacrificing the amount of data presented. This allows for unobtrusive and

compact content presentation.

Figure 13: Physician Interaction View


Numerous interface elements and structures to organize content, such as jQuery-based content sliders and modal

windows were used to minimize visual clutter. Modal windows offer many advantages. For example, the search

functions in Synapse Patient Interface (Figure 14) below bring up the results in a modal window so the user does not

need to load an entirely new page. Advanced search functionality takes up space, so to prevent a large search box

from taking space away from the content, utilizing a floating window reduces visual clutter. Subtle tools, such as

synchronized calendar pickers, have been utilized to make the user experience as seamless as possible. For example,

drop-down calendars are not very efficient when compared to a calendar picker, where users can click directly on a

day. Calendar pickers also help users to see the different time intervals such as day, month and year all in one view to

allow the user to make a faster and more informed decision than with a simple drop-down list.

Figure 14: Patient Interaction View


3. Part 3 - Implementation Plan

3.1 System Deployment

3.1.1 Operational Governance

Creation of the right governance structure to support the multi layered enterprise decisions involved in this project is

the top priority during Synapse implementation at HHG. We began by identifying the correct stakeholders who are

fully committed to the responsibilities of their roles. Key stakeholders identified by iMatrix are:

Role Responsibility

HHG Executive Sponsor Provides executive oversight for the Synapse application and supports project vision

HHG Project Steering

Committee

Evaluates the outcome of all phases of the Unified Process. It has the final authority

to make decisions on project changes in terms of scope, budget, or schedule

HHG Project Manager (1) Coordinates all Synapse activities which require resources from HHG and

communicates with IMatrix project manager to ensure successful implementation

HHG Physician Champions (4) Physician Project advocates who provide a united front for communication and serve

as enterprise project spokesperson/clinical decision maker as the roll-out continues.

HHG Clinical Champions (4) Nurses/Practice Managers who are trained super-users and meet regularly with staff

and physicians to prepare for upcoming changes and identify potential challenges

HHG IT Support (8) Resolves internal support issues required for maintaining Synapse application.

HHG Communications

Coordinator (1)

Creates, manages, updates and tracks communication plan impact for all stakeholder

group to reduce uncertainty among users about changes in environment

iMatrix Client Executive (1) Holds overall responsibility for project success within the iMatrix organization.

He/she interfaces with the HHG Executive Sponsor and HHG Project Steering

Committee to resolve escalated project vision related issues

iMatrix Project Manager (1) Manages iMatrix schedule and daily decisions for development and implementation.

iMatrix Software

Development (6)

iMatrix group responsible for designing, developing and testing Synapse. It includes

software architects, coders, testers, usability designers, and configuration specialists

iMatrix Technical Support (4) iMatrix Technical Support for installing, troubleshooting and resolving support issue

iMatrix Training Specialists (4) Responsible for designing training modules and providing training during rollout


As with all successful implementations, HHG’s senior management support and commitment will be one of the most

crucial factors associated with successful implementation of Synapse. Involving multiple clinical stakeholders in

governance is critical to gaining end-user acceptance and overcoming cultural resistance. Our proposed governance

structure includes physician and clinical “champions” from HHG who serve as the project team’s main contacts and

will answer all project related questions. Figure 1.1 illustrates our proposed governance structure.

Figure 3.1 Governance Structure

3.1.2 Project Timeline

Synapse will be deployed as a green-field installation. The scope of the project is large and challenging, with a complex

clinical environment, technical risks, multiple interfaces, stakeholders, and support tasks. Although benefits and ROI

are long-term, most investment and impact is upfront. This means that risks must be addressed early in the

implementation. One of the primary reasons that iMatrix chose the Unified Process Framework is because of its

emphasis on risk-mitigation. Unified Process is an iterative, risk-centered, use-case driven, architecture-centric

software development process. Unlike waterfall methodologies, each of the four phases of the Unified Process has

been designed to mitigate specific kinds of risks. Each iteration focuses on identifying potential risks and tackling them

early in the project lifecycle to increase the probability of delivering a reliable product on time and within budget.

The Synapse development lifecycle is organized as a series of incremental iterations. Use cases are used to capture the

functional requirements and to define the contents of an iteration. Each iteration, planned to realize a subset of the

use cases, has its own project management, requirements analysis, design, implementation, test, configuration

management and deployment activities. Each iteration is designed to produce a working version of the product. This

working version is tested and validated to ensure that progress is on track. Unified Process requires that architecture

sit at the heart of the project team's efforts to shape the system. One of the most important deliverables of the

process is the executable architecture baseline early in the lifecycle of the project. This executable architecture serves

to validate the essential use cases and act as a foundation for the remaining development. Following the project


charter approval, development will begin on the project which will be implemented across approximately nine months

(39 weeks) starting on July 9, 2012 and scheduled for full rollout by April 8, 2013.

3.1.3 Project Deliverables

1. INCEPTION PHASE: July 9 - Aug 20 (6 weeks) Milestone: Lifecycle Objective

2. ELABORATION PHASE: Aug 21- Oct 22 (9 weeks) Milestone: Lifecycle Architecture

• Vision document containing problem

definition, core requirements, key features

and main constraints

• Use case model survey of all Synapse use

cases and actors identified at early stage

• Initial risk assessment

• Initial requirements management plan

• Initial configuration & change management

plan

• Initial regulatory application assessment plan

• Communication Plan

• Use case model where all architecturally significant

use cases have been developed

• Critical supplementary requirements

• Software architecture description

• Preliminary User Interface Prototypes

• Executable architectural prototype

• Revised risk list and a revised business case

• Preliminary User Manual

• Preliminary System Integration Test Plan

• Preliminary System Verification Test Plan

• Configuration & Change Mgmt Tools configured


3. CONSTRUCTION PHASE: Oct 23 - Jan 14 ( 12 Weeks) Milestone: Lifecycle Operational Capability

4. TRANSITION PHASE: Jan 15 - April 8 ( 12 Weeks) Milestone: Product Release

• All uses cases and supplementary

requirements implemented

• Integrated Software Components

• Updated software architecture

• Software subsystems Integration with HHG

systems and external vendors systems

• Unit Test Results Report

• System Verification Test Report

• Preliminary User Training Material

• Updated Rollout Plan

• Hardware Deployment and Configuration

• Integration Test Report

• User Acceptance Testing Report

• Users Training Completion

• Rollout Plan Implementation

• Online Patient Training Modules deployment

• Synapse Helpdesk deployment

• Synapse Marketing Campaign

3.1.4 Project Risks

iMatrix has identified the following as the most significant risks during Synapse project implementation:

Risk Mitigation Strategy

Schedule overrun because of

scope creep

Impact: High

• Use an iterative software development process which embraces change.

• Strive to produce a shippable application at the end of each iteration. This

would enable the steering committee to decide whether to increase the

scope or ship the result of the last iteration with some additional work

Problems in communicating

with existing medical systems

built by external vendors

Impact : Low

• Use industry standard DICOM and HL7 standards to interoperate with those

systems instead of proprietary APIs whenever possible.

• During iterations for Elaboration phase, conduct integration tests with

working version of Synapse so interoperability issues are discovered early.

Performance Related Risks

Impact: Medium

• Design and conduct performance, load and stress tests that replicate actual

workload at both normal and anticipated peak times.

• When a scalability limit is reached, incrementally reduce the load and retest

in enough time for the system to apply countermeasures.

• Take a server component offline during a test and observe functional,

performance, and data-integrity behaviors of the remaining components.


User Adoption Risks

Impact: Medium

• At the beginning of each iteration in the Construction phase, build consensus

with representative end-users and project stakeholders by exploring

requirements that are targeted for that iteration.

• At the end of each iteration, conduct usability testing with a pool of users to

validate the design. The insights gathered from these usability testing

sessions will aid in planning the next iteration.

• Maintain constant communication with users throughout implementation

3.1.5 Assumptions and Constraints

The following assumptions and constraints are relevant to the Synapse project.

• HHG has secured the funding for the project. Any budgetary and financial constraints on part of HHG must be

disclosed to iMatrix before Implementation.

• HHG must appoint an Executive Level Sponsor for the Synapse Project. iMatrix Project Manager and Client

Executive must have unrestricted access to the HHG Project Sponsor and Steering Committee.

• HHG will provide appropriate documentation, test data and access to clinical workflows as requested in a

timely manner by a mutually agreed date.

• Significant changes to established project scope may necessitate revision of costs, schedules and resources.

• Synapse will utilize HHG’s backup and disaster recovery plan and procedures that are already in place for

existing medical informatics systems at HHG.

3.2 Operational Readiness

3.2.1 Supporting non-functional components

Administration Dashboard: A designated local HHG Synapse administrator is provided with a dashboard to provision

users, grant permissions, assign roles, and monitor the performance health of the system. The dashboard is also

designed to proactively monitor activity and system logs to detect problems before they affect end-user. For example,

if a link between Integration Manager Component and another interfacing system is not active, an alert will be raised

and visible on the administration dashboard.

Third-Party Services Relationship Manager: The Synapse application utilizes third-party tools and SDKs (Software

Development Kits) from vendors such as Microsoft and MergeCom. Additionally, it also relies upon web services

offered by Allscripts and Apixio. The duties of third-party services relationship manager is to keep all licenses with the

third-parties current. This individual is also responsible for following up on all maintenance provided by these vendors

and communicating the schedule to the HHG Synapse Project Manager for coordination of maintenance activities

performed by Synapse. The third-party services relationship manager must also follow up with these vendors to

ensure resolutions on urgent and blocking issues encountered by the Synapse application.


Technical Support Help Desk: There will be three levels of technical support for Synapse: 1) Automated Tools & HHG

IT Support, 2) Tier-1 Synapse Technical Support, and 3) Tier-2 Synapse Technical Support. Minor and generic issues

such as password resets, network failure, user permission and authorization, and web browser installation and

configuration will be handled by automated tools and the IT support staff at HHG. The help desk includes both online

and phone support. Online support consists of FAQs, discussion forums, live chat, and email support. Phone support

enables the user to discuss the problem via the phone hotline. iMatrix will provide a two-tiered technical support

helpdesk for Synapse. All requests will be routed to Tier-1 helpdesk first. Specialized issues or unexpected application

specific errors will be routed to Tier-2 helpdesk. The Tier-2 help desk is segmented by specific Synapse application

areas such as third-party interfacing, imaging, video collaboration and report publishing. HHG IT support and Synapse

helpdesk can also enter change requests to be analyzed and scheduled in a release by the Change Control Board (refer

to the Planning and Controlling Change section). iMatrix will utilize helpdesk support software from zendesk.com and

live2support.com services for live chatting functionality for support. The support process is illustrated below.

Figure 3.3 Synapse Tiered Helpdesk

3.2.2 Preparation for Change Management

An enterprise application must be prepared for change and have a process in place for managing it. For Synapse,

change comes in the following three varieties: 1) User initiated, 2) Vendor initiated, 3) Internally initiated by iMatrix

staff. Each one of these changes can be either planned or unplanned. Each new change request is entered into the

change management system with the appropriate priority. The change control board (CCB) consisting of stakeholders

from iMatrix and HHG will meet on a weekly basis to triage these change requests. The CCB consists of iMatrix

Synapse Project Manager, Development manager, Quality Assurance Manager, Third-Party Services Relationship


Manager, and two designated HHG decision makers. CCB weighs the risks and effort associated with each change and

schedules it in a Synapse release accordingly. This could be a regularly scheduled patch release, an emergency patch

release, or a bi-annual release depending on the criticality of the change and the work effort involved.

Change management involves requirements management, source control versioning, issue and test cases

management. iMatrix uses cloud-based change management tools offered by Atlassian Corporation. iMatrix CCB

members are able to use these tools to track the various artifacts associated with each change request and assess its

impact on components and end user scenarios prior to planning and scheduling it in a release.

3.2.3 Training

To begin the training phase, all clinical staff will attend a kick-off meeting, receive system reference information and

fill out an implementation survey. Next, selected HHG Super-user trainers will receive one-on-one Synapse

functionality and user interface training by iMatrix staff at a designated site. These super-users will consist of project

team members with both clinical experience and communication skills. Based on those sessions, HHG project team

members will partner with iMatrix in developing a training curriculum which they will use to train targeted users at

HHG (i.e. physicians and support staff). The goal will be to ensure that they have a thorough and clear understanding

of how to use the system and the concepts behind the system. Finally all clinical end users and auxiliary staff will be

trained by super-user trainers to attain competency at tasks and access relevant data in the Synapse system, both

through classroom training and online practices. Quick reference cards, cheat sheets, and diagram of workflows will

be available at clinical sites. Hard-bound copies of the reference training manual will be provided at each clinic. Special

attention will be paid to physician training due to their critical role in cultural acceptance and system success.

Physician training will be carried out on a one to one basis at assigned sites with dedicated computers. Training

sessions will be scheduled at later hours to work around physicians' schedules, rather than forcing them to work their

schedules around training. Appendix - Exhibit 1 shows a detailed view of the training plan.

iMatrix will also create an on-going training program and new user training. Online training will be available during roll

out, and for the life of the Synapse system. During every rollout week, ongoing support will be provided by four

members of the Synapse helpdesk staff, who will wear special blue shirts. The “Blue Team” will be onsite to promptly

answer questions within the clinic and respond to any hotline requests within 15 minutes. One primary training day

and one make-up training day will be designated for each week of the four iterations of rollout to ensure all staff is

trained.

Synapse will provide online training for patients in the form of comprehensive user guides, video tours, FAQs and e-

brochures as illustrated in Appendix- Exhibit 2. During deployment, interactive kiosks will be provided for patients to

register and interact through a demo account to learn the system. Reference Brochures will be stacked in reception

areas and physician’s offices. iMatrix specialists will also create recorded video training sessions and online guides


geared towards HHG staff members and patients on the Synapse website. The technical support engineers at HHG will

view these on-demand training modules and also receive specialized training sessions geared towards troubleshooting

technical issues.

3.2.4 Service Level Agreement (SLA)

Synapse must meet a high level of performance goals and provide effective service and support to HHG. The

application delivers data in several formats: textual data, medical images, and audio-video streaming. The Service

Level Agreement with HHG guides the operational and support activities for Synapse. It sets reasonable service and

support expectations and gives HHG a benchmark to manage satisfaction and expectation levels. The SLA highlights

are:

• All issues handled online or over the phone by technical support should be resolved within 4 hours. If the

issue is unresolved by Tier-1 support then it is escalated with a guaranteed resolution plan in 72 hours for

non-critical issues and within 24 hours for critical issues. Definition of issue criticality is managed by the CCB.

• iMatrix must deliver one scheduled patch release monthly and one major release every six months.

• iMatrix must deliver unlimited emergency patches for critical issues and operational roadblocks.

• iMatrix will perform one hardware/system upgrade every two years for HHG without any labor charges. Cost

of the hardware/system will be borne by HHG. Additional hardware/system upgrades within the two year

period will incur labor charges billed by the hour.

• iMatrix must ensure 99.7% monthly uptime of the Synapse system (Allscripts and Apixio are excluded).

• Additional services not mentioned in the SLA will be billed hourly.

Failure to meet the goals defined in the SLA will incur a penalty of 10% reduction of the total amount billed for

Synapse maintenance during that month.

3.3 User Enablement

3.3.1 Synapse Rollout Plan

Synapse rollout consists of services and support rollout and application rollout. The formal rollout of Synapse will be

done in the Transition phase over a period of four incremental iterations. One of the goals of this incremental and

iterative rollout is to control and mitigate the risk that comes with deploying a new system. Additionally, an

incremental and iterative rollout provides the opportunity to learn how the end-users use the system and if their

needs are being met adequately. It also allows iMatrix and HHG to study the network and computing load and plan for

scaling the solution.

Iterative Rollout Plan

• Iteration 1 - The primary goal of the first iteration is to setup the initial services and support infrastructure

and get ready to train and support the end users of Synapse. During this iteration, technical support

engineers learn about Synapse and training curriculum and materials for end-users are created. The CCB is


formulated and change control plan is put in place. Rollout communication plan and technical support

helpdesk are established..

• Iteration 2 - During this iteration, the Synapse application will be made available to 25% of the HHG staff

members who directly deal with patient care. This consists of physicians, nurses, and medical assistants

across specialty areas at HHG. Five hundred staff volunteers who are also HHG patients will be invited to sign

up for Synapse. User training and instructor-led sessions are held as needed. Some network and computing

load monitoring tasks will be undertaken during this iteration to learn about the resource utilization at

various times during the day. Training specialists and technical support engineers are trained for the next

iterations of the application rollout during the later part of this iteration.

• Iteration 3 - The third iteration of the rollout will add another 25% of the HHG staff members who directly

deal with patient care. Invitation-only patients identified as primary candidates by physicians will also be part

of this iteration. Ensuring scalability of Synapse with increased workload will be the primary goal of this

iteration. New users are trained and technical support help desk is reinforced with additional personnel to

handle increased capacity. Online training modules, one on one training for physicians and patient kiosks are

deployed.

• Iteration 4 - The last iteration of the rollout will add the remaining 50% of the HHG staff members who

directly deal with patient care. The patient signup will also be opened up for everyone. All trained technical

support engineers are transitioned to take on the workload resulting from the last and final iteration of

application deployment. Therefore, in this iteration, Synapse would be rolled out to 100% of the end users.

Fewer problems are expected during this iteration as most risks will be mitigated in the first two iterations.

Appendix- Exhibit 3 shows a detailed view of the phased rollout. During rollout go-lives, some specific strategies have

been identified by iMatrix to ensure a smooth transition for users

• Go-Live days will be during mid-week when workload is usually lighter for clinicians. Physicians will have

lighter schedules on those days, and buffer times will be designated to allow users to catch up during the day

• Extra resources will be available such as IT support, trainers and six specialists of iMatrix “Blue Team”.

• A backup plan will be in place where existing manual and electronic processes have been modeled so that if

rollout needs to be stopped, processes can be rolled back quickly to pre-rollout state.

• At the end of each go-live, a project team meeting will be held to debrief and resolve issues.

3.3.2 Data and content management

There are several pieces of data utilized and generated by the Synapse application. All data is owned by HHG and

updated by iMatrix under contractual agreement. Here are the different data flavors and their management in context

of the Synapse application:

• The user registration data is managed by HHG administrators with backup support from iMatrix as needed.

This data is managed through the user administration console for the Synapse application.


• The system logs management is automated by Synapse where stale logs older than 30 days are removed.

• Application specific data like patient records, physician notes, and audit logs are stored in the database

tables. The Synapse administration console provides the ability to view this data organized by date. HHG IT

support can download old data entries from the console for archiving. Original tables can be updated via the

administration console to remove archived entries to improve database performance and save storage space.

• Usability metrics data about frequency, feature usage, session lengths and bug reports are available to HHG

IT via the Synapse administration console. The lifecycle management of this data is the same as for

application specific data management.

• Data retrieved from third-party services by the integration engine is removed from Synapse application after

30 days if it is in an unused state. There is no need to permanently store this data as permanent storage for

them already exist outside Synapse and the data can be refreshed from these external entities on demand.

• Application binaries and configuration data are updated by iMatrix during the deployment of a release.

3.4 Success Metrics

iMatrix has utilized the following significant metrics to measure the value Synapse implementation has delivered to

HHG. Key performance Indicators (KPIs) have been organized into two categories to measure success for metrics that

are related to (1) Providing quality healthcare and (2) Maintaining profitability. Please refer back to Section 1.4:

Success Metrics for a more detailed discussion of these key performance indicators.

Metrics Source of data Success Criteria

Patient visit duration Periodic physician survey Decrease 4 to 5 minutes per patient visit

Annual patient count HHG EMR system 15% increase in annual patient visits

e-Visit count Synapse system logs Average of 278 e-visit sessions daily

Front desk call volume Annual HHG Admin survey At least 20% decrease in call volume

Administrative functions Annual HHG Admin survey 25% decrease in mailing, paper and phone costs

Portal utilization rate Data extracted from Synapse system

logs

70% physician logins

25% patient logins

User satisfaction rate Periodic service satisfaction survey Over 60% satisfaction on survey questions

Patient Visitor loyalty Synapse system logs Average session frequency is once per week


4. Appendices

Appendix- Exhibit 1 Synapse Training Plan for HHG


Appendix- Exhibit 2 Patient Training Resources on the Synapse Website

Appendix - Exhibit 3 Iterative Rollout in the Transition Phase


5. References

5.1 Executive Summary

1. Who's Who in Interactive Visualization for Analysis and Dashboarding. Gartner Research. Published: 30

September 2011 ID:G00219397

2. Good Authentication Choices for Healthcare Delivery Organizations. Gartner Research. Published: 21 April

2011 ID:G00212214

3. Cool Vendors in Healthcare Providers, 2011. Gartner Research. Published: 21 April 2011 ID:G00211301

4. HIPAA Privacy and Security Extensions in the HITECH Act: This Time, We Mean It. Gartner Research.

Published: 23 December 2011 ID:G00227975

5. Koonce T.Y, Giuse D.A, Beauregard J.M, Giuse N.B. Toward a more informed patient: bridging health care

information to the patient through an interactive communication portal. J Med Libr Assoc. 2007 Jan;95(1):77–

81.

6. Giuse D.A. Supporting communication in integrated patient record system. AMIA Annu Symp Proc. 2003. p.

1065.

5.2 Part 1: Business Requirements

1. Roemer Paul, Standardization Lies Beyond the Clinical Realm. HealthsystemCIO.

http://healthsystemcio.com/2011/07/14/standardization-lies-beyond-the-clinical-realm/ Published July 14,

2011. Accessed February 18, 2012

2. Gregg, Jessica and Saha, Somnath. (2007). Communicative Competence: A Framework for Understanding

Language Barriers in Health Care. Journal of General Internal Medicine, 22(2), 368-370.

3. Schumacher S. Patient relationship management: streamlined approaches for defragmenting healthcare.

Health Management Technology. June 2001; 22(6).

4. Healthcare relationship management depends on tailored database. www.healthcareitnews.com.

http://www.healthcareitnews.com/news Published May 13, 2004. Accessed February 19, 2012.

5. Who's Who in Interactive Visualization for Analysis and Dashboarding. Gartner Research. Published: 30

September 2011 ID:G00219397

6. Good Authentication Choices for Healthcare Delivery Organizations. Gartner Research. Published: 21 April

2011 ID:G00212214

7. HIPAA Privacy and Security Extensions in the HITECH Act: This Time, We Mean It. Gartner Research.

Published: 23 December 2011 ID:G00227975

8. Koonce T.Y, Giuse D.A, Beauregard J.M, Giuse N.B. Toward a more informed patient: bridging health care

information to the patient through an interactive communication portal. J Med Libr Assoc. 2007 Jan;95(1):77–

81.

9. Giuse D.A. Supporting communication in integrated patient record system. AMIA Annu Symp Proc. 2003. p.

1065.


5.3 Part 2: Technical Specification and Prototype

1. SOA Consortium Overview. SOA Consortium http://www.soa-consortium.org/ Accessed March 25, 2012.

2. .NET Framework Highlights .NET Developer Resources and Case Studies http://msdn.microsoft.com/en-

us/netframework Accessed March 20, 2012.

3. Fowler, Martin. Presentation Model http://martinfowler.com/eaaDev/PresentationModel.html (Accessed

March 22, 2012. Windows Communication Foundation http://msdn.microsoft.com/en-

us/netframework/aa663324 Accessed March 17, 2012.

4. Overview of ADO.NET http://msdn.microsoft.com/en-us/library/h43ks021(v=vs.71).aspx Accessed March 18,

2012.

5. The DICOM Standard. Digital Imaging and Communications in Medicine (DICOM) National Electrical

Manufacturers Association, 2011 http://medical.nema.org/Dicom/2011/11_01pu.pdf Accessed March 18,

2012.

6. Ignite Realtime OpenFire. Ignite Realtime. http://www.igniterealtime.org/projects/openfire/ Accessed March

16, 2012.

7. OpenJPEG library : an open source JPEG 2000 codec. OpenJPEG.org.http://www.openjpeg.org/ Accessed

March 16, 2012.

8. Fielding, Roy Thomas. Representational State Transfer (REST) - Architectural Styles and the Design of

Network-based Software Architectures. University of California, Irvine, 2000.

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

9. Craig McMurtry, Marc Mercuri, and Nigel Watling: Microsoft Windows Communication Foundation: Hands-

On, SAMS Publishing, May 26, 2006, ISBN 0-672-32877-1

Accessed March 16, 2012.

10. Steve Resnick, Richard Crane, Chris Bowen: Essential Windows Communication Foundation (WCF): For .NET

Framework 3.5, Addison-Wesley, February 11, 2008, ISBN 0-321-44006-4

11. Craig McMurtry, Marc Mercuri, Nigel Watling, Matt Winkler: Windows Communication Foundation

Unleashed (WCF), Sams Publishing, March 6, 2007, ISBN 0-672-32948-4

12. "ECMA 335 - Standard ECMA-335 Common Language Infrastructure (CLI)". ECMA. 1 June 2006. Archived from

the original on 14 June 2008. Retrieved March 18, 2012.

13. Guthrie, Scott (3 October 2007). "Releasing the Source Code for the NET Framework". Archived from the

original on 07 September 2010. Retrieved March12, 2012.

14. Shaver, Dave. "The HL7 Evolution - Comparing HL7 Versions 2 and 3". Corepoint Health. Retrieved March 16,

2012.

15. "6.1 DIMSE Services". Digital Imaging and Communications in Medicine (DICOM) Part 1: Introduction and

Overview. National Electrical Manufacturers Association. 2006. pp. 11.

http://martinfowler.com/eaaDev/PresentationModel.html�

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm�




































5.4 Part 3: Implementation Plan

1. McLaughlin J. , Motwani J., Madan M.S. , and Gunasekaran A, Using information technology to improve

downstream supply chain operations: a case study, Business Process Management Journal, Vol. 9 No. 1, 2003

pp. 69-80

2. Keane, W. M. , Metz B.A., and Ogunkeye J. B., Electronic Medical Records: Implementation and Beyond,

Jefferson University Physicians, http://www.jefferson.edu/emr/documents/EMRPres0107.pdf, Accessed April

11, 2012

3. Massachusetts Hospital CPOE Initiative , CPOE Readiness Roadmap Guide, October 2005 ,

http://www.masstech.org/ehealth/cpoe/Roadmap.pdf, Accessed April 12, 2012

4. 9 Things That Will Take the MEANINGFUL Out of Meaningful Use, Medseek, April 05, 2012.

http://medseekblog.typepad.com/medseek_weblog/patient_portal/, Accessed April 12, 2012.

5. Blackstone Valley Community HealthCare, Electronic Health Records in Action : Stories of Meaningful Use,

The Office of the National Coordinator for Health Information Technology, Spring 2011

6. Manning, Trish, Lessons learned from Physician office Implementations preparing to meet Meaningful Use

Requirements of the EHR Incentive Program ,

http://www.mahealthdata.org/Resources/Documents/Hmart11/hm11-c1-manning.pdf, Accessed April 13,

2012.

7. Project Implementation Process (PIP) Guidelines, Vanderbilt University Medical Center, May 01, 2003, h

ttp://www.mc.vanderbilt.edu/infocntr/implement/IT%20Projects%20Implementation%20Process1.pdf,

Accessed April 14, 2012.

8. System Implementation, U.S. Department of Health and Human Services Health Resources and Services

Administration, http://www.hrsa.gov/healthit/toolbox/HealthITAdoptiontoolbox/SystemImplementation,

Accessed April 15, 2012

9. West, David, Planning a Project with the Rational Unified Process, Rational Software White Paper, August

2002.

10. Ambler Scott W. A Manager’s Introduction to The Rational Unified Process (RUP)

http://www.ambysoft.com/downloads/managersIntroToRUP.pdf, December 4, 2005, Accessed April 10, 2012

11. TEN Step Plan to a SUCCESSFUL Implementation., Component Control,

http://www.componentcontrol.com/pro_services/implement.html, Accessed April 13, 2012

12. Selling the RUP Concept: Increase People’s Comfort Level and Plan Your RUP Rollout, West Pole, 2005,

http://www.westpole.com/pdf/selling-rup.pdf, Accessed April 16, 2012

13. A Systems Implementation Project Planning Guide: Solutions & Project Management Services for Systems &

Operations Projects, Cliff Consulting Inc., July 2007,http://www.cliffconsulting.net, Accessed April 14, 2012

Synapse - An Integrated Healthcare Application for Patient … · 2017-02-27 · Submitted by Team...

Documents

Transcript of Synapse - An Integrated Healthcare Application for Patient … · 2017-02-27 · Submitted by Team...