There are 2 main types of reports we will address here. Embedded reports that are developed through the SDK, and linked reports developed in SSRS. These reports have 2 parts, the report itself and the documentation in the reporting table that makes the report accessible on the Atlas Reporting tab.
Embedded Reports
These reports generally pull on oltp data right from the Atlas production environment back-end. They are programmed using the SDK, and are therefore tied to the release schedule (so new reports or changes will be available in Atlas when the next release is scheduled)
New Reports
-
- New reports are requested via Mojo, we need to ensure business requirements necessitate an SDK report vs a linked one
- A functional spec is required
Documentation
-
- Reporting table documentation is added by the programmer
- Information about the report or requested changes would be added to the ADO task.
Updates/Requested Changes
-
- Changes to embedded reports are automatically pushed out to all affiliates – this includes the updated report itself and the reporting table data.
Linked Reports
Reports are written in SSRS and can be loaded or updated anytime, in other words updates are not tied to the Atlas release schedule.
New Reports
-
- New reports are requested via Mojo
Documentation
-
- Reporting table documentation for additions and updates is done by the report developer
- Information about the report updates and changes are stored in SSRS. These include comments in the SQL itself, or in comments in SSRS that do not display to end users.
Updates/Requested Changes
-
- There is no automatic update for reports. The report developer manually adds or updates the report to the affiliate that requests it
- The report developer manually maintains the reporting table data for each affiliate that has the report.
Changes to Existing Reports
We are trying to share reports across MGB affiliates as much as possible, so even if a report is created for one affiliate it may be used by other affiliates. That said, how do we deal with requested changes to existing reports so all affiliates are getting the data they need in the format they want without any surprises?
Report Numbers
Previously reports were numbered with letters indicating the type of report, numbers (1xxx for MGB, 2xxx for BWH, 3xxx for MGH), and sometimes an affiliate suffix. The affiliate suffix was added when a report version was fixed for a particular affiliate. For example:
- FIN1055_NWH is a financial report written by MGB that is unique to NWH
- FIN1055 is a financial report written by MGB that is common to all affiliates
- DNR3022_MGH is a report written by MGH containing custom code or references to MGH only data practices
- DNR3022 would be the “generic” MGB version of the MGH report
- EVR2028 is a “generic” event report written by BWH but usable by all affiliates
The Reporting Team will follow this process going forward in Atlas.
MGB shared reports are those that are updated and maintained by MGB for all affiliates. These .rdls are maintained using ADO, see ADO and Atlas Linked Reports. We are also pushing out updates to reporting table information using the MGB reporting table as a base. These updates will not alter affiliate specific report information like adoption status, affiliate notes, and user and role permissions.
Which Affiliates Control Changes?
If a report has an affiliate suffix, it is customized for use by a specific affiliate only. That affiliate then controls all requested changes and no permissions from other affiliates are needed to make updates.
Reports without an affiliate suffix are reports that are shared across affiliates. We are developing a process to track frequency and most recent run dates by affiliate for linked reports. We do not have a process in development for tracking runs of embedded reports. The process for proposed update approval is as follows…
- EVR1056 is used by multiple affiliates. SRN would like to add additional data and an additional filter to the existing report. This data can be added and conditionally suppressed using a parameter.
- The new information can be added without forcing a change to the formatting of the existing report because the requested data can be added/removed with a “show data or suppress” parameter. The report would be updated, and we would notify other affiliates who run the report that new parameters will be added that will be defaulted so the report runs as it did previously.
- All affiliates who use the report would be asked if they wished to test the changes
- DNR1876 is used by multiple affiliates. MCL would like to add additional data and new filters to the existing report, and remove some of the existing data and filters.
- This is a substantive change that will result in changes to the existing formatting and functioning of the report. A new version would be created for MCL only that will be named DNR1876_MCL.
- Only MCL would need to test the change
- EVR2026 is an event report written by BWH but that can be run by all affiliates. IHP has a requested change to the report, but BWH does not feel the change is warranted.
- create new version, the new report id would be EVR2026_IHP
- EVR2026 is an event report written by BWH but that can be run by all affiliates. BWH wants to make an update to the report, but another affiliate does not feel the change is warranted.
- create new version for the affiliate that does not request the change.