Clinisys · Reporting · Case study

Report Composer

An application-agnostic reporting tool designed to close a real gap: laboratory systems capture enormous amounts of valuable data, but clients had a subpar experience getting that data back out. Laboratory users are domain experts, not reporting specialists, so the central challenge was giving them sophisticated reporting capability without the complexity of a traditional report-development application. Its defining capability: editing a field on a generated report writes the correction back to the source record, not just the document.

Report Designer screen with component rail, canvas showing Header and Details blocks, and a properties panel on the right

01 · Executive summary

Sophisticated reporting, without requiring laboratory users to become reporting specialists.

Clinisys needed a more sustainable approach to reporting across its product portfolio. Rather than begin with a predefined feature set, I mapped the broader reporting capability landscape and evaluated how those capabilities changed across three increasingly complex contexts: Patient, Scientific, and Management reporting.

That analysis shaped both the product scope and interaction model: capabilities laboratory users needed to control remained visible, while technical concerns the platform could reliably manage stayed behind the interface. I worked with Product, Architecture, and subject-matter experts to translate that strategy into a prototype that was demonstrated to a client before the project was shelved.

02 · Approach

Map the full landscape, solution-neutral, before deciding anything.

Contributions

Built a solution-neutral taxonomy of reporting functionality before making any product decisions
Ran a capability analysis scoring what a nontechnical lab user needed to control directly, versus what the system could safely manage, across Patient, Scientific, and Management reporting
Partnered with product, architecture, and SMEs across Clinical and Anatomic Pathology, and benchmarked comparable self-service reporting products
Designed the reusable Header, Details, and Footer component model, and the Site and Global libraries that store, version, and publish them
Designed the write-back editing capability that lets a user correct pulled data directly on a live report

Method

I built a solution-neutral taxonomy first, then evaluated each capability against how the underlying data grew in complexity: a single patient record, a scientific case or batch, or an entire population of laboratory activity. That analysis established what the platform needed to support before I defined what users should interact with directly.

03 · Context & problem

Laboratory users could describe what they needed. They shouldn't have to design the query behind it.

Reporting had remained a difficult product area for Clinisys. Laboratory systems contained valuable information extending well beyond individual test results, information that could support patient communication, scientific investigation, operational oversight, quality management, and organizational decision-making. But the people who needed those answers were laboratory professionals, not database specialists or report developers. A laboratory user could describe a patient's results, a scientific case or batch, activity across a laboratory, turnaround performance, workload by discipline, or trends over time. They should not also have to determine the joins, query structure, aggregation rules, permissions, or data architecture required to produce the report.

04 · Research: competitive analysis

How other products reduce reporting complexity for nontechnical users.

I reviewed reporting experiences designed for business and nontechnical users, including Airtable, Smartsheet, Salesforce, HubSpot, and Zoho Analytics. The objective was not to compare feature counts; I examined how each product reduced the amount of reporting-engine knowledge required from the person creating the report, focusing on data and field selection, filtering, grouping and summarizing, previewing results, terminology, progressive disclosure, and system-assisted configuration. View the competitive analysis ↗

Hide the data model

Products such as Airtable demonstrate that users can work with related information without being exposed to the full relational structure underneath it.

Make configuration incremental

Salesforce attaches actions such as filtering, grouping, and summarization to the objects they affect, allowing complexity to appear as it becomes relevant.

Turn report creation into a sequence

HubSpot structures reporting as a progression from selecting data, to choosing fields, refining the result, and saving. Users aren't required to understand the entire environment before they can begin.

05 · Research: capability analysis

Mapping the landscape before defining scope.

Before deciding what Report Composer should contain, I created a solution-neutral taxonomy of reporting functionality across seven domains: Data; Query & Selection; Organization & Logic; Report Design; Output & Delivery; Management & Governance; Platform. View the Reporting Functionality Taxonomy diagram ↗ · View the Reporting Capability Analysis ↗

Patient reporting

Single record and related clinical data. Patient → Encounter → Test → Result → Related Data. Patient reporting begins from a known record and follows established relationships around that patient; the dataset is comparatively bounded and predictable.

Scientific reporting

Case or batch. Scientific reporting may involve a single case or multiple specimens or cases processed together, expanding to include larger datasets, more relationships, grouping, aggregation, calculations, and comparison.

Management reporting

Population and organization. Management reporting extends across disciplines, laboratories, employees, workloads, quality measures, and time periods. The questions move from what happened to this patient, to what is happening across the laboratory.

Necessary capability did not mean necessary user complexity

A report may require joins, relationship validation, permission checks, or query optimization. That does not mean the person building the report needs to configure those mechanisms. The analysis distinguished between what the product must do and what the user must control.

Data should drive scope

Patient, Scientific, and Management reporting represented progressively broader reporting problems. The roadmap followed the data rather than an arbitrary list of requested features.

Reporting and analytics were related but distinct

Structured report authoring belonged in Report Composer. Dashboards, exploratory visualization, and drill-down analysis could be supported by future visualization products without turning Report Composer into an analytics platform.

06 · Design principles

Both pieces of research pointed to the same six principles.

01 · Scope by data complexity

Expand capability as reporting moves from a patient record, to scientific cases and batches, to organizational reporting.

02 · Put complexity in the appropriate layer

Expose the controls users need while allowing the platform to manage technical concerns such as data relationships, validation, permissions, and query processing.

03 · Translate outcomes into capabilities

Use the reporting outcome to determine the underlying functionality required rather than expecting users to define the technical solution.

04 · Handle relationships automatically where possible

Users need related information. They do not necessarily need to understand or configure relational joins.

05 · Reveal advanced capability progressively

Advanced filtering, calculations, formatting, and logic remain available without becoming prerequisites for basic report creation.

06 · Use laboratory language

Present concepts such as Patient, Specimen, Test, and Result instead of requiring users to work primarily in database or reporting-engine terminology.

07 · Design: one continuous journey, two tools

Designer handles setup once; Editor handles each case.

Designer: configuration, once per report design

Select Data: bind fields to their source, shape derived values with functions.

Shape Report: place Header, Details, and Footer; lay out fields, tables, and rules.

Editor: reporting on demand, once per case

Refine: toggle in the sections this case needs, then write the diagnosis and description.

Preview/Output: review the live document, correct pulled data in place if needed, sign, and save.

Workflow diagram showing Start leading into Designer's Select Data and Shape Report steps, then into Editor's Refine and Preview/Output steps — Designer produces the raw material a report gets assembled from; Editor never needed an abstract wireframe canvas, because every choice it offers, including a correction to source data, is already sitting on a real, signable document.

08 · Design: three connected areas

From creation and management through authoring, release, and addendum.

CONTENT MANAGEMENT

Create · Store · Version · Share · Publish

REPORT DESIGNER

Add Components · Configure Data · Structure Report

REPORT EDITOR

Auto-populate Data · Enter Content · Format · Add/Remove Sections · Release · Addendum

Site Library screen listing report designs and components with version numbers and publish status — Content Management

Report Editor screen showing a live patient report with read-only Specimen data and an editable, focused Diagnosis field — Report Editor

01. Content Management

Where reports and components are stored, managed, shared, versioned, and published. A Report is composed of one or more Headers, Details, and Footers, which can also be saved separately for reuse across reports, in Home, Site Files, and the Global Library shared across client organizations.

02. Report Designer

Where reports are designed and configured, by adding Headers, Details, and Footers using a toolbar of Text, Field, Function, Table, Image, Line Divider, Page Break, Groups, and Optional Sections. Fields connect the report to laboratory data; Functions provide calculations and logic.

03. Report Editor

Where a report is completed for an actual patient or case. Applicable data auto-populates from the laboratory record while designated fields remain open for entry. Release confirms the report to the record and sends it to the referring physician; Save as Addendum records later additions without replacing what was already released.

Correct the record, not just the report

Authorized fields remained linked to their source data. When a user corrected one from the live report, the change updated the underlying laboratory record rather than creating a report-only correction.

09 · Outcome

Interest from a client, then the project was shelved before development completed.

Where it ended

The prototype was demonstrated to a client, generating interest in the concept, but the project was subsequently shelved before development was completed. Report Composer was therefore not implemented and was not validated through production use. I later revisited the work to reconstruct portions of the original research, rebuild the interface in MUI, reconsider the terminology, and evaluate the original product decisions with the benefit of additional distance from the project.

Earlier workAdaptive Help & Contextual Learning →