Reports

Overview

This page documents some initial ideas on the concept of 'reports' and other similar composite clinical information structures, including discharge summaries, and possible care plans.

The key thing that distinguishes a 'report' as we understand it here is the notion of being able to 'quote', 'include' or 'copy' in existing content, and mix it with new content.

Status

The information on this page was developed by, among others, Tomas Nordheim Alme, Bjørn Næss, Boštjan Lah, Borut 'Fabio' Fabjan, Ian McNicoll and Thomas Beale.

Requirements

Typical use cases

Discharge Summary, Summary report, possibly Managed Lists (i.e. curated lists)

Functional requirements

  • Content types:
    • inline new content
    • links pointing to external content (i.e. not resolved in the report, only potentially on screen by click through)
    • 'quoted' content, i.e. 
      • content copied in, 
      • with meta-data (what?) 
      • and link to original
      • annotations
      • status indications e.g. 'confirmed', ...
    • query result snapshot
    • multimedia thumbnails + link to originals
    • Sections, as in current RM
    • may include whole Compositions? (why?)
  • signable - need to determine what serialised form is signed
    • multiple signatories
    • same as 'attestations' in current RM?
    • signing occurs in a finalisation step
    • signable sub-items? (TB: try to avoid)
  • progressive building / content inclusion;
    • versioned in the normal way
  • report templates
    • archetypes of a new RM Report type should act as Report 'templates' (in the usual IT sense)
    • do we want to model a 'library' of report templates, e.g. as  service?
  • lifecycle
    • whole report only, or sub-items? (TB: prefer whole report)
  • participants
    • authors
    • contributors
    • composers (= data entry)
  • other meta-data, possibly same as AUTHORED_RESOURCE e.g.
    • keywords
    • references

It is assumed that referenced or copied content may be from openEHR or other systems, including non-versioned, possibly unreliable systems.

Design Concept

Structure

TBD

Content Inclusion

One of the key challenges has been how to include existing content in a report. Inclusion by copying could be achieved by two methods:

  • include copies of structures, e.g. Entries
  • include seriaisations of structures as text (e.g. HTML, XML, Markdown ...).

The second option is interesting since it seems closer in spirit to the idea of quoting content in a report. The result would be that a Report would consist of some originally-authored structural parts, and some content that was in the form of DV_TEXT or DV_PARSABLE or similar, containing the quoted elements in a serial form.

This approach would enable query results to be included in a Report as well.

Options for serialisation seem to include:

  •  XML: presumably standard openEHR XML
  • JSON: requires a JSON equivalent of standard openEHR XML
  • ODIN: as for JSON
  • HTML: possibly not future-proof?

Consequences of implementing quoted content as serialised text:

  • it should preserve more closely what was seen on the screen when content inclusion was done; 
  • querying won't see the same content twice. 
  • But do we want the report to be fully structured and computable in its own right?

Logical model of serialised includable content could be something like:



The above would allow mixing of document content and structured content. This arguably complicates things. A better model may be to make 'documents' a different kind of content consisting only of sections and serialised content.


Versioning and Lifecycle

TBD