Overview

This page documents some initial ideas on the concept of 'reports' and other similar composite clinical information structures, including discharge summaries, and possibly 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 serialisations 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:

class VIEW_GROUP inherit SECTION
    meta_data: CLUSTER[0..1]            // curation-related
end

abstract class VIEW_ITEM inherit CONTENT_ITEM
end
 
class CITATION inherit VIEW_ITEM
	source_ref: OBJECT_REF[1] 			// pointer to Composition, Entry
	source_type: ARCHETYPE_HRID[1]		// RM type, archetype of target info
end
 
abstract class DYNAMIC_CONTENT inherit VIEW_ITEM
	snapshot_time: Date_time[0..1]		// time of generating result
	function is_dynamic: Boolean		// True if no result snapshot included
end
 
class QUERY_RESULT inherit DYNAMIC_CONTENT
	query: String[1] 			        // generating query
end
 
class API_CALL_RESULT inherit DYNAMIC_CONTENT
	api_call_name: String[1] 		    // API call name
	api_call_arguments: String[*] 		// API call arguments
end

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.

class DOCUMENT_COMPOSITION inherit COMPOSITION
	content: DOCUMENT_ITEM[*]					// structured source elements
	serialised: DV_PARSABLE[0..1]     		    // serialised form of the content
	serialisation_method: DV_CODED_TEXT[0..1]   // algorithm used to serialise value from structured source
	serialisation_time: Date_time[1]   			// time of serialisation
	doc header info?
end
 
abstract class DOCUMENT_ITEM inherit LOCATABLE
end

class DOCUMENT_SECTION inherit DOCUMENT_ITEM
	// name attribute provides name of section
end

class DOCUMENT_STATIC_ITEM inherit DOCUMENT_ITEM
	source_ref: OBJECT_REF[1] 			// pointer to Composition, Entry
	source_type: ARCHETYPE_HRID[1]		// RM type, archetype of target info
end
 
abstract class DOCUMENT_DYNAMIC_ITEM inherit DOCUMENT_ITEM
	function is_dynamic: Boolean		// True if no result snapshot included
end
 
class DOCUMENT_QUERY_RESULT inherit DOCUMENT_DYNAMIC_ITEM
	query: String[1] 			        // generating query
end
 
class DOCUMENT_API_CALL_RESULT inherit DOCUMENT_DYNAMIC_ITEM
	api_call_name: String[1] 		    // API call name
	api_call_arguments: String[*] 		// API call arguments
end

Versioning and Lifecycle

TBD