How Partners HealthCare System Improved Its Cost Structure and Financial Visibility

1. How Partners HealthCare System Improved Its Cost Structure and Financial Visibility • September 25, 2013

2. Health Care Provider Excellence Quadrants Patient Focus • Market excellence focuses on how organizations understand the communities and populations that they serve and the context of care. Clinical excellence focuses on the acuity, safety, satisfaction and outcomes necessary to improve the effectiveness and quality of care. • Market • Clinical Wall Street Focus Main Street Focus • Operational • Financial Financial excellence focuses on the revenue and costs associated with the care provided and the funds required for the financing of care. Operational excellence focuses on an organization’s efficiency in terms of human resources, supply chain and other resources used in the delivery of care. Administrative Focus

3. 12 Key Health Care Provider Challenges • Population Management • Care Coordination • Preventative Medicine • Disease Management • Market Demographics • Sizing & Segmentation • Brand & Identity • Access & Pricing • Research and Development • Project & Trials Management • Applied Research • Translational Research • Population • Management • Alliances & Partnerships • Joint Ventures • Channels & Referrals • Strategic Affiliations • Quality & Safety • Evidence-Based Medicine • Continuous Improvement • EMR & ICD-10 • Market • Demographics • Research & • Development • Leading Edge • Advanced • Alliances & • Partnerships • Quality & • Safety • Developed • Market • Clinical • Mergers & Acquisitions • Strategic Positioning • Valuation & Pricing • Post-Merger Integration • Patient Satisfaction • Environment & Setting • People & Processes • Efficacy & Efficiency • Foundation • Mergers & • Acquisitions • Patient • Satisfaction • Financial • Operational • Accounting • & Finance • Human • Resources • Accounting & Finance • Close, Plan & Report • Cost Accounting & DSS • Revenue Cycle • Human Resources • Acquisition & Retention • Organizational Structure • Training & Development • Regulatory • Compliance • Supply • Chain • Technology • & Facilities • Regulatory Compliance • Governance & Controls • Risk Mgmt. & Mitigation • Tax Optimization • Supply Chain • Sourcing & Procurement • Logistics & Distribution • Demand Management • Technology & Facilities • Real Estate & Facilities • Systems Infrastructure • Application Architecture

4. Single Facility EPM EPM helps connect key departments. Payroll Revenue Supply Chain Department Focused Hospital Nursing Surgery Physicians Pharmacy Labs Emergency

5. Multi-Facility EPM Functional Areas are ALL Inter-Related Payroll Revenue Supply Chain Line of Business Focused Administration Hospital A Hospital B LT Care Urgent Care

6. Hyperion’s Ability to Meet PHS’ Needs and Focus Points BUSINESS NEEDS • Accommodates multiple forms of Budgeting & Forecasting • Has Robust Reporting • Easily Integrates with External Systems • Easy to Learn • Easy to Access • Easy to Navigate • Easy to Export to Common Office tools TOOL FOCUS PEOPLE FOCUS • Fast Response Times • Scales for Entities, Business Units, Etc. • Scales for User Volumes • Scales for Data Volumes • Easy to Maintain • Easy to Modify • Easy to Upgrade • Easy to Train Admins and End-Users INFO. TECH. NEEDS

7. Implementation Approach – Summary Architecture & Design Evaluation Design Considerations • Customization • While shared custom dimensions such as Source and Tier are shared there is still some variation in each Plan Type to support unique requirements. • Each entity within the system was allowed to have some “divergence” with regard to web forms and calculations but overall the goal was to have as much “convergence” as possible. • Performance • Performance is maintained by having the Aggregate Storage Option reporting cubes for any reporting above the Cost-Center level. • Maintenance • Where possible dimensions and hierarchies are sourced from the existing data warehouse to increase alignment decrease additional workload. • Security • Security can be set at the Entity/Department levels allowing access to only those portions of the application that are relevant to a particular user.

8. Summary Application Architecture

9. Timeline 2011 2012 2013 Common Ent. Approach R1 Req. Plan Design Test Build Train R2 Req. Design Build Test Train R1 Go-Live R2 Go-Live System Ready Release 2 Release 1 Budget Cycles • Release 2 - POs and Non-Acute Entities: Go-Live of Sep 30, 2013 • Requirements updated against lessons learned from Release 1 and re-validated against CEA with remaining entities • Application modified to support additional entities and/or additional applications created based on entity-specific customizations • Release 1 - All Acute Entities: Go-Live of December 31, 2012 • Full requirements gathering and development of the Common Enterprise Approach (CEA) to budgeting for ALL entities • Applications configured for all acute entities and built with flexibility, scalability and supportability in mind for Release 2 capabilities

10. Toolkit Approach for Design Dimension A Dimension B Dimension C Calculation 1 Calculation 2 Calculation 3 Form X Form Z Form Y Dimension A Dimension B Dimension C Calculation 1 Calculation 2 Calculation 3 Form X Form Z Form Z Form Y Form Y Calculation 2 Dimension B Dimension C Calculation 1 Calculation 2 Calculation 3 Form X Dimension B Form Z Dimension A Form Y Calculation 2 Calculation 3 Form X Form Z Dimension B Dimension C Calculation 1 Dimension A With the toolkit approach, common sets of flexible tools or solution objects (dimensions, calculations, forms, reports, etc.) are created. The toolkit approach uses reusable standard components that can be assembled to produce different results. Each entity uses these tools to tailor the solution to their needs. This allows each entity to be different and affords each with the flexibility to adapt to business changes over time. Acute Sector PO Sector Solution Objects Acute Sector PO Sector

11. Data Integration Blueprint • Budget (2 yrs.) & Actuals (3 yrs.) • Q2 Forecast (1 yr.) • Volume & $ by Charge Code • FTE’s & $ by Job Code • P&L by GL Account • Ad-hoc data, as loaded • * Aggregation at all levels of Vision Hierarchy and Tiers (Base + Savings + Initiatives)s ASO PRL ASO RPT 2 - Employee-level FTE & $ - Budget data only Data pushes from PRL to ASO RPT2 and ASO PRL. Hyperion Planning Every 5 Minutes Data pushes from REV and FIN to ASO RPT2. Every 5 Minutes • REV Only: Tiers aggregate on save.(Base + Savings + Initiatives) Essbase Essbase FIN PRL REV DTL Actuals and GL-level FTE Categories. On Save or On Push Every 2 Hours VISION PSFT Data Stage

12. Support Model Examples There are a spectrum of options for the support organization structure often with a trade-off between functional and technical focus and cost. Option 1 Option 2 Option 3 Option 4 Support Leadership Entities Process Owners Functional Support Application Expertise Infrastructure Expertise Silo Model Dedicated, end-to-end IT support organized around functions Centralized IT Functional alignment with pooled IT resources Centralized IT & Functional Specialty teams provide service across business functions Matrix Functional and process leads with matrix reporting Dedicated IT Support(Functional Responsiveness) Maximize Functional and Technical Coverage Functional responsiveness with centralized application and infrastructure expertise Enterprise collaboration and coordination across entities and sectors. Optimization Goal

13. Responsibilities by Group: Business Units / Functions Identifies business requirement for change to existing web form or new web form and corresponding applicable calculations Report Design & Development SmartView Queries (Ad-Hoc) Security (Who and What) Hyperion Support Group Application Configuration Application Maintenance Application Tuning Calc. Design & Development Task List Configuration Web-Form Configuration Upgrades (Business Case) Data Validation & Ad Hoc Data Import Training (End User and Applications) Security (How) Information Technology Architecture & Networking Data Integration (ETL) Hardware Maintenance Upgrades (Software & Patches) 3rd Party Software (Web Servers) Training (Technical) Server-side Tuning Traditional Hyperion Support Organization Business Process Council Business Unit or Function A Business Unit or Function B Business Unit or Function C Revenue Lead Payroll Lead Expense Lead Hyperion Lead Master Data Lead Reporting Lead Infra. Lead 1 ETL Lead 1 IT Lead Information Tech Finance BU’s / Functions

14. Responsibilities by Group: Entities Identifies business req. for change to web form & corresponding calcs and integrations Data Validation Report Design SmartView Queries (Ad-Hoc) Training (End User) Security (Who and What) Functional Support Group Functional Design Document Upgrades (Business Case) Web-Form Configuration Calc. Design Ad Hoc Data Import Report Development Training (Applications) Security (How) Application Support Group Application Configuration Application Maintenance Application Tuning Calc. Design & Development Task List Configuration Technical Support Group Architecture & Networking Data Integration (ETL) Hardware Maintenance Upgrades (Software & Patches) 3rd Party Software (Web Servers) Training (Technical) Server-side Tuning PHS Support Organization Hyperion Sponsor’s Group Acute Budget Offices PO Budget Offices Non-Acute Budget Offices Acute Sector Lead PO Sector Lead Hyperion Lead Hyperion Admin 2 Hyperion Admin 1 Infra. Lead 1 ETL Lead 1 Technical Lead Security Lead 1 Finance IS Finance Information Tech BU’s / Functions

15. Future-State Administration Activities in Hyperion 15

16. Request Path Hyperion Sponsors Group Approved? HSG reviews change requests, approves or denies requests and assigns priorities to approved changes Finish No Yes Entity Budget Offices Yes Requires HSG Approval? Entity determines need for change and communicates request to FSG Entities participate in unit testing the change in Test before Finance IS promotes to PROD Change identified No Func. Support Group FSG receives approved change request and creates functional specification for submission to Finance IS FSG receives change request and creates a summary justification with the entity for submission to the HSG if required. FSG develops application changes per the responsibility matrix Simple Finance I.S. Finance IS creates technical specification based on functional Finance IS reviews technical specification with FSG and Entities for final approval. Finance IS develops application changes per the responsibility matrix Simple or Complex? Complex