| Configuring Reports |
[This is preliminary documentation and is subject to change.]
Reports are used for these purposes:
Print.
Exporting data to external applications.
Displaying data in configured forms.
Test.
To implement basic workflow functionality.
Configured (application specific) reportsReports accessing data in the dynamic data structure cannot be built into the framework, because the framework does not "know" beforehand, what data model will be configured for the individual end-user applications, that will be built with TOPICA.
Therefore, reports accessing the dynamic data model must be configured individually for each application, just like forms.
Application specific reports will often show data from both the static and the dynamic data model. For example, reports on patient data will almost always show data from the patient (national ID, name etc.).
Report formatsThe framework contains a number of possibilites for the configurators and/or application developers for developing reports.
Reports may be constructured in the following formats:
Format | Description |
|---|---|
These reports are specified in XML files adhering to the TOPICA Reports XML format This is the easiest way to construct a report quickly. The downside is, that there are very limited posiblities for presenting data. This format can only be used to:
| |
These rapports are designed using Report Designer, which is part of SQL Server Business Intelligence Development Studio (BIDS) which again is a standard part of SQL Server. BIDS is actually Visual Studio in disguise. When developing Reporting Services reports, you also need to develop a "stub" to make your report accessible from the TOPICA application. The "stub" handles user input of report parameters and passing context information from the TOPICA application to the Reporting Services reports. The "stub" is an XML-file in the TOPICA Reports XML format - the same format used to configure TOPICA Built-in Report Format decribed above. Reporting Services reports are far more powerful than the reports in the TOPICA Built-in Report Format in almost every sense:
The wealth of functionality comes with a cost: there is a lot to learn, and managing / deploying Reporting Services reports is not straight forward (setting up Reporting servicves instances etc.). Th good news is, that this is all standard stuff - there is a lot of resources on the internet ("how to", "teach yourself videos"), and lots of courses are available both online and in the physical world. | |
This requires knowledge of ASP.NET-programming and selected portions of the TOPICAAPI , so to use this format you must be an Application Developer. This is the most complex way to build a report, so use this tool only in the (rare?) cases when the report requirements cannot be met by any of the above mentioned formats / tools. On the other hand, there are no limitations to want you can do in this kind of report (provided you know how to program it in ASP.NET / WebForms, of course). Anything that can be placed in a WebForm may be used as a "report" in a TOPICA application. Of course, whether the user will conceive a WebForm as a "report" is entirely up to the developer. |
No matter which tool is used, the following competences are important:
Knowledge of SQL (report data is always pulled from the database using SQL).
Knowledge of the physical data model - you cannot write SQL if you do not understand the database tables and fields.
As described in Data Model, the data model for a TOPICA database consists of two distinct parts:
The static part (organization, employees/user, patients, accreditation, etc.).
The dynamic part (everything that may be registered relating to a patient - a.k.a. the patient record data). The dynamic data model varies from application to application.
Understanding context.
TOPICA Basic (for passing parameters including context, and for dynamiclaaly construction the SQL used to pull data from the database).
Testing reportsConfigured reports are tested using the standard end-user tool for Running Reports.