Modelling overview - Reporting model

The reporting service is a FHIR server that provides REST endpoints for extracting ehealth data. Data is returned as a FHIR Binary resource with a content element containing the data in base64 zip compressed JSON format (application/gzip-json).

Technical reports

Technical reports is part of the Operating status report.

With access to Splunk it is possible to create report and dashboards for technical reporting.

Accounting reports

• SSL-orders: Orders including history.

• Measurement-stats: Statistics on Observations, QuestionnaireResponses and Media.

• Careplan-duration-stats: Statistics on CarePlans and status changes.

• Practitioner-stats: Statistics on Practitioners related to Organizations and CareTeams

Management reports

• Careplan-duration-stats: Statistics on CarePlans and status changes.

• Careplans-by-patient: EpisodeOfCare and Plan resources

• Careplan-and-episode-of-care-stats: Statistics on the number of Careplans and EpisodeOfCare for each Plandefinition

• Careteam-stats: Statistics on EpisodeOfCare, CarePlan and Tasks assigned to a CareTeam

• Careplan-customization-stats: Statistics on Patient specific customizations of CarePlans

Clinical reports

Patient-total: All clinical resources for Patients

Usage reports

• SSL-orders: Orders including history.

• Practitioner-gdpr: All data related to a Practitioner

• Patient-gdpr: All data related to a Patient

• Careplans-by-patient: EpisodeÓfCare and Careplans

• Patient-devices: Devices assigned to a Patient

Reporting REST endpoints

Each type of report has two endpoints:

• $fetch-<reportname>

  • run report - run report synchronously and return resource with result.

• $schedule-<reportname>

  • schedule report - schedule a report for later batch execution. The returned result is an empty placeholder that identifies the resource to be retrieved later. When the batch is run, the resource will be updated with the result. The report will be stored in the database and will be available for retrieval for a limited time period. The scheduled reports will be generated during the night, and will usually be available the next morning.

Currently the following reports are supported:

• careplan-and-episode-of-care-stats

• careplan-customization-stats

• careplan-duration-stats

• careplans-by-patient

• careteam-stats

• measurement-stats

• patient-devices

• patient-gdpr

• patient-total

• practitioner-gdpr

• practitioner-stats

• ssl-orders

Report parameters

All reports require a parameter that defines the anonymization level of the data returned. Currently only two modes are available:

• NONE 

  • the data is returned without modification

• ANONYMIZED - the data is anonymized by removing identifying information from patient resources, and encrypting all resource ids.

Each report endpoint may accept a number of other parameters for conditionally restricting the data included in the report. Eg.:

• organization

• period

• patient

• practitioner

• condition

• devicetype

• status

• seller

The availability and semantics of each parameter is defined on individual report level. See IG Operations for details.

Report security

The access to the reporting endpoints are restricted by security privileges:

• $fetch-<reportname>

  • if granted, this will allow a user to run and schedule the report.

• report-non-anonymized - if granted, this will allow a user to fetch or schedule reports with no anonymization.

For system users, reports may include data from all managing organizations. The organization parameter is optional in this case.

For practitioners, only data from the practitioners organization will be included. The organization parameter is mandatory in this case. 

Reports stored in the database can only be retrieved if the user is identical to the user that scheduled the report.

Report structure and format

Report data is returned as a FHIR Binary resource (See http://hl7.org/fhir/STU3/binary.html) with the following elements:

• contentType

  • the mime type of the content (application/gzip-json)

• securityContext

  • a reference identifying the user that requested the report. This restricts the retrieval of the report to the user.

• content

  • the report data

A report content contains a report header file and zero or more report group files, and the files are put in a zip archive in a directory structure:

• directory: <name><timestamp>

  • file: ReportHeader

  • directory: <groupname> 

    • files: <group1>

    • file: <group2>

    • ...

    • file: <groupN>

The report header file, ReportHeader, contains a JSON object with elements:

• reportName

• reportTime

• parameters

Eg. a report header returned by $fetch-careplan-customization-stats:

Each report group file is named by the id of the grouping data element. The type of grouping data element depends on the report type. It may be a FHIR resource, an SSL resource, or a report summary type.

Each group file includes the grouping resource, and one or more related resources depending on the type of report.

Eg. a report group returned by $fetch-careplan-customization-stats containing plan definition (group resource) and careplan customization summary:

See IG Example operations  for more examples

Reporting service configuration

The configuration of the reporting service determines:

• The availability of synchronous execution (fetch) for each type of report. 

• The schedule for batch execution.

• The time period that a batch report will remain in the database before being purged.