Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 1 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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 2 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 3 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 4 of 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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 5 of 42
• 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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 6 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 7 of 42
• 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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 8 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 9 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 10 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 11 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 12 of 42
$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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 13 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 14 of 42
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?"
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 15 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 16 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 17 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 18 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 19 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 20 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 21 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 22 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 23 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 24 of 42
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-
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 25 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 26 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 27 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 28 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 29 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 30 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 31 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 32 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 33 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 34 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 35 of 42
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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 36 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 37 of 42
• 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
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 38 of 42
4. Appendices
Appendix- Exhibit 1 Synapse Training Plan for HHG
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 39 of 42
Appendix- Exhibit 2 Patient Training Resources on the Synapse Website
Appendix - Exhibit 3 Iterative Rollout in the Transition Phase
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 40 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 41 of 42
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.
Submitted by Team 3: Kadie Chen, Jerry Lee, Savita Sahgal, Anthony Shifflett, Shaun Wong Page 42 of 42
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