MUSE International Tuesday Workshop – Session 805 June 2, 2010, 1:00P – 3:30P

1. DR Reporting Made Easy with SQL Server BI Tools MUSE International Tuesday Workshop – Session 805 June 2, 2010, 1:00P – 3:30P Glen D’Abate & Jamie McDonald

2. Introductions Instructors Acmeware Course Participants

3. Course Overview

4. Objective The objective of this workshop is to provide an overview and demonstration of SQL Server 2005’s Business Intelligence capabilities, specifically with Report Models and the Report Builder tools. We will construct SSRS Report Models and that allow non-technical staff to dynamically develop ad-hoc MEDITECH reports using the SSRS Report Builder application.

5. Workshop Overview • Overview of DR reporting strategies in context of Report Builder • Identification of DR data and strategies for extracting to a Report Model datamart • SSRS Report Model Projects • Creating Data Source Views • Creating Report Models • Using Report Builder to access Report Model, reporting basics and saved reports • Filtering and grouping • Formatting and developing a tabular report • Advanced filters, creating formulas, and Help • Matrix and graph reports (time permitting)

6. Glossary of Terms • MEDITECH Application database – Proprietary database structures (NPR or Advanced Technology - AT) in which MEDITECH applications directly file data • Data Repository (DR) – Replications of data from Application Database into an open (ODBC or OLE DB) accessible SQL Server RDMS • SQL Server Databases (livedb, testdb, livefocdb, testfocdb) – DR databases in which application data (test or live, NPR or AT) is stored • SQL Server Reporting Services (SSRS) – Feature of SQL Server RDMS that allows reports to be designed, developed and deployed for consumption • Datamart – Extraction, transformation, filtering, and indexing of data into structures specifically formatted for construction of Report Models • SSRS Report Manager – Web based application for hosting and managing reports. Also the application from which the Report Builder tool is launched. • SSRS Report Models – Data structure on which the Report Builder tool runs • SSRS Report Builder – Tool for non-technical staff to develop ad hoc reports

7. Course Format • Modular sections • Lecture on topic with slide presentation • Provide example demonstration building Report Models and reports as we go • Each section builds on previous section • We encourage interactive discussion throughout!

8. Review of Alternative DR Report Development Options • Microsoft Access 2007 • Crystal Reports 2008 • SQL T-SQL Downloads to .CSV Files • SQL Server Analysis Services (OLAP Cubes) • SQL Service Reporting Services (SSRS) Report Models and Report Builder • SSRS – Report Server Projects (i.e., full use of Visual Studio Tools for SSRS Report Development

9. Flexibility / Complexity Trade-off Too Hot! SSAS is easiest to use. Drag & Drop, Slice & Dice. Only provides numeric analysis. Difficult to develop & modify data. Report Builder allows non-technical users to build and format custom ad-hoc reports. Report developers need not understand data relationships. Requires IT to build Report Models which limit available data columns. Complex data analysis / manipulation is not possible. Just Right! Too Cold! Report Projects require programmer-level technical skill set to develop reports. Uses Visual Studio programmer environment for report development. Most flexibility in report design and can link to complex T-SQL statements for reports requiring data manipulation and analysis.

10. Report Model / Designer Approach PROs • Allows reports to be dynamically generated by “end-users.” No need to come to IT for “one more column” on a report • Web-based reports can be nicely designed and formatted • Report Models can be indexed for excellent performance • Report Manager provides secure access to report execution • No software to load / support on developer’s systems CONs • Requires technical staff to develop and maintain underlying SSRS Report Models • Another copy of data (in application db, in DR, now in Report Model datamart) • Cannot address more complex reports (e.g., reports that require multiple passes at HCIS data to produce result set of interest)

11. Where Are Reports Developed? Launches Report Builder application. Can open existing reports or build new reports from scratch. Web Server Hosting SSRS Report Manager

12. Quick Demo of Report Builder UI Uses “Registration” Report Model Entities generated from Report Model Entities are constructed from one or more table in the data mart via a data source view (.dsv) Column data available in each entity

13. Identification of DR Data & Strategies for Extracting to a Datamart

14. Step by Step Recipe to Report Builder • Identify data-of-interest for end users (typically within one or a few MEDITECH applications). • Develop data access strategy. We typically recommend scheduled extraction to a datamart but it is possible to build Report Model Views directly against the DR using SQL Tables or SQL Views. • Construct helpful data transformations in datamart extract logic (e.g., convert text Lab Results values to numeric fields, convert CDS Response to Datetime datatype, etc.). • Build SSRS Report Views using Datamart tables. This re-establishes “relationships” implicit in the NPR or AT data structures. • Build SSRS Report Models using Report Views. Internal fields can be hidden, other fields identified for filter selection. • Deploy Report Models and Train end user on Report Builder application.

15. DR has 6000+ Tables as well as two Live Databases in 6.0 + Identifying the appropriate source of specific application data from within the DR is one of the most challenging aspects of any report development using the DR Data is highly de-normalized in the DR. “Name” in the AdmVisits table is very different than “Name” in DLabTest table, and very different than “Name” in MriPatients table. Many factors determine what data to include in datamart including focus of Report Model, inclusion of Inpatients and/or Outpatients, length of history required and more.

16. Issues Addressed in SQL Datamart Extract • Multiple related DR tables have data combined into a single table (e.g., visit level admission and abstracting data combined) • Default values can be entered where NULL data (e.g., replaced with “N/A”) • Text values, common in MEDITECH fields are converted to move useful data types (e.g., Numeric Response to SQL Numeric datatype) • Data can be filtered to a smaller set than in the DR (do you really need the ND test results from 1998?) • Data can be filtered to meet reporting criteria (e.g., remove confidential patients)

17. Example of Registration Data Extract Internal ID fields are not for Report Builder but used in Report Views Typical data fields available in Report Model DR Fields modified to better format New Age field computed for Report Model Inpatient or Outpatient Locations recombined to one field Visit Provider Type data flattened for ease-of-use in Model

18. Data Extract DR Table Consolidation Optional data (using LEFT JOINs) is included in Registration Data Model when available. Data from many tables in the DR are combined to a single table “entity” to be used in the Report View and Report Model. Example of identifying only the most current entry associated with a patient visit

19. Data Extract using Incremental Data Cancelled Admissions or other filtering (e.g., remove confidential patients) can be include in datamart extract The DR table column RowUpdateDateTime can be used to identify “changes” to data for incremental updates

20. Primary Key Fields and Their Function Example Datamart Tables There may be multiple AllergyID entries for any given VisitID SourceID omitted for sites with single SourceID throughout DR

21. Building Datamart a Indexes Restricting the volume of data and highly indexing data, especially at the Report View highest aggregate level (i.e., typically visit for MEDITECH application data) is highly effective at making report output very responsive

22. Datamart for Training Course Customer Defined Screen queries and responses (includes multiples) and time dated repeat results ADM registration data as well as some ABS data Charge, receipt, adjustment, refunds and other transaction level details Visit level financial (B/AR) data ITS Report summary information (though no text reports yet) ITS Order details Laboratory Specimen Tests & Results Patient Allergy information including free text descriptions

23. Creating SSRS Report Model Projects

24. What is a Report Model Project • In order to build a Report Model, you need to create a Report Model Project using Visual Studio 2005 (or 2008) • A Report Model Project contains the components or objects that are used to build and deploy Report Models to the Report Manager web site • A Report Model Project is comprised of one or more Data Source (.ds) files, one or more Data Source View (.dsv) files, and one or more Report Model file (.smdl) files

25. Creating a New BI Report Model Project OLAP Cubes What we are working with today Report Server Projects use the capabilities of the full Visual Studio IDE for Report Development Give a meaningful Report Model name Add to existing Solution or Create a new Solution container

26. Visual Studio IDE Solutions Explorer Report Model Tree View Report Model Detail View Output Messages Properties

27. Solution Explorer Solution is simply a container in which Projects are loaded Project contains the objects (i.e., code) that comprise the Report Models Data Sources Data Source Views Data Models Establishing a Data Source for the Report Model lets it know where to go to find data on upon which Reports will be built

28. Data Source Designer DR Server Select Datamart database or DR livedb Establishing a Data Source for the Report Model lets it know where to go to find data on upon which reports (using Report Builder) will be built

29. Project Properties Web server Project Properties determine where the Report Models will be deployed (must be a web server where the Report Manager application is installed)

30. Creating Data Source Views

31. Data Source View Features • A Data Source View is a description of components of the database to which the Data Source is pointing • This Data Source View describes the selected DR tables, their contents, and the relationships between them • Table in a Data Source View MUST have primary keys defined explicitly to determine uniqueness of records in the table • Table relationships established in the Data Source View are critical to the correct output being generated in Report Builder developed reports • Typically, defined relationships reconstruct the data relationships that exist in the MEDITECH applications

32. Adding or Importing a .dsv File Acmeware typically has a Development project and a Production project Add a New or Existing Data Source View New Data Source View launches wizard Allows an existing .dsv file to be copied into project (e.g., copying a development .dsv to production)

33. DSV Wizard – Identify a .ds file First, the Data Source View must identify one or more Data Sources (.ds) files to be used to identify data to be accumulated in the .dsv file We choose a single .ds file that points to our datamart

34. Default .dsv Relationship Our datamart replicates the structures in the DR which lack FK constraints Selecting this option usually selects the correct columns but inevitably the defined relationship will need to be modified after completing the wizard While adding foreign key constrains to our datamarts would be ideal, in practice, this is very difficult since MEDITECH does not ensure the sequence in which data hits the DR (and therefore the potential order in which it hits our datamarts). For example, it is technically possible for a new Lab Test Print # to appear in a patient result before the corresponding Lab Test Dictionary receives an entry for the Print #.

35. Select Datamart Tables in a .dsv The Census data is used in multiple different .dsv files One patient visit may have multiple allergy entries. One allergy entry may have many lines of allergy text.

36. Name the .dsv Meaningful name to identify .dsv file when building Report Models

37. View Default Relationships Are Wrong Default relationship created by wizard is often incorrect in the context of MEDITECH DR (and corresponding datamart) schema design All three keys are required to identify a unique record in this table. This is not typical to a relational database schema. Arrows must point from summary table to detail table

38. Relationships Must Be Modified Summary level data is the “Source”, Detail level data is the “Destination” The labels do not seem to make sense but his configuration has been tested and appears to be what is required

39. MEDITECH Schema Often Requires Multiple Column Relationships Where two columns are required to uniquely identify the summary (parent) table records, then both must be included when defining a relationship to the detail (child) table

40. Design View of Registration .dsv Parent Child Child Parent Child

41. Enter Friendly Name Property Properties for selected object (Registration Data table/entity) Modifying the FriendlyName Property will default to the Entity Name in the Report Builder

42. Creating Report Models

43. Report Model Features • A Report Model (.smdl file) provides metadata (data about data) for the data being referenced by the Data Source View. • When the Report Model file is generated, entities, roles, and fields are automatically created • Typically, these entities and fields relate back to the datamart columns and their data within the database • Field properties are automatically generated based on the system’s analysis of the data in a .dsv field • A Report Model Design wizard steps through each option and setting required to build a .smdl file from a .dsv file • After running the Report Model Design wizard, the model can be published to the report catalog, assigned the appropriate role permissions, and then used in Report Builder • To make it even easier for users to create reports using this model, it can be further refined after the wizard is completed

44. Adding a New Report Model Like .dsv files, Report Models (.smdl) files can be created as new its using a wizard or can be imported as existing Items We recommend having a Production Project to which .dsv and .smdl files are only copied (i.e., never modify in PROD). If Data Source Name is the same in DEV and PROD, no changes are necessary when importing to PROD.

45. Report Models are Generated for a Single Data Source View (.dsv) File A single .dsv file is used by a single Report Model (.smdl file)

46. Report Model Generation Options We have primarily taken the default generation rules

47. Report Model Statistics Recompile statistics if the .dsv changed in any way. I typically always choose the “Update model statistics” option.

48. Naming a Report Model Use a meaningful name as this will be seen in the Report Builder tool Do not publish a new model with the same name because you will invalidate existing reports that are generated against this model. If you do create a new model with the same name and try to publish the model, you will see an error message. Always work on the same model to ensure that the IDs remain the same.

49. Modifying Report Model Properties Roles can be given a friendly name Internal fields should be hidden This property determines how a column will be treated when a filter is applied in Report Builder

50. Building & Deploying Report Models A Solution, one or more Projects, or one or more Report Models may be built or deployed Build and deployment Status