Page Comparison

...

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

...

• 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

...

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

...

Logical model of serialised includable content could be something like:

abstract class DOCUMENTVIEW_ITEMGROUP inherit CONTENT_ITEM
	value: DV_PARSABLESECTION
    meta_data: CLUSTER[0..1]     			   // serialised form of the content 	serialisation_method: DV_CODED_TEXT[0..1]  // algorithmcuration-related
usedend
to
serialiseabstract valueclass fromVIEW_ITEM structuredinherit sourceCONTENT_ITEM
end
 
class STATIC_CONTENTCITATION inherit DOCUMENTVIEW_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 DOCUMENTVIEW_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

...