The Question

This page addresses the question of whether there are substantively different categories of DCM, which would require different modelling 'styles' or strategies.

What's important are the abstract structures.

One thing that is useful to consider is to distinguish two kinds of 'context':

situation context - who / where / when - information about situation, i.e. places, people, time
specific context - information items that are not the key datum, but are typically required along with it, e.g.

patient state - exertion, position, etc
method/protocol - e.g. instrument, measurement protocol, device etc

In the table below, the conclusion is that the categories in the left hand column (at least, if not column 2) each correspond to a different modelling style, and are likely to be the basis for different RM classes and/or reference archetypes, that provide the basic 'shape' and semantics of the information type.

A partial classification

Abstract category	Concrete Category	Description	Proposed CIMI Modelling pattern
Lab result categories	Lab Analyte	Common features: logically atomic panel items all items have the same specific context structure	while logically atomic, due to the need of specific context items, a container like a CLUSTER or higher is required; the key datum is an ELEMENT containing a DATA_VALUE. It may be possible to model every single Lab analyte using a single ELEMENT archetype with LOINC coding.
	Lab Panel	Common features: one or more atomic panel items; situation context is same for all items in panel	ENTRY with slot for Lab Analyte CLUSTERs. One Lab panel archetype should be usable for most lab panels. Possibly a couple of other variants for special structures.
	Lab Report	Report containing one or more panel result(s); carries audit + attestation, and other specific context like order ids, lab comments etc	COMPOSITION containing one or more Lab Panels, plus top-level situation context

Questionnaires	Questionnaire item	Common features: logically atomic question / answer pair, probably with other meta-data 'values' represented structurally cannot typically be treated as having the same clinical meaning as similarly/same named data points in normal clinical Entries - they are instead usually classifiers.	CLUSTER containing ELEMENTs that model the natural language form of the question (via terms), the meaning of the question, and the possible result values.
	Questionnaire group / list	Set of Questionnaire items making up the logical questionnaire (equivalent to a 'panel' for questionnaires)	ENTRY containing one or more Questionnaire Item CLUSTERs
	Questionnaire form	The full thing, filled out, attested, committed to EHR; carries audit + attestation	COMPOSITION containing (usually?) one Questionnaire group

General clinical information structures	Clinical entry structure	Common features: 'molecular' information structure that is different for each content type, and usually has the same situation context for all items in a given recording may include linking to previously existing Entries, e.g. BMI linking to existing height and weight may include derived fields e.g. BMI, Apgar total etc	ENTRY containing free structure of CLUSTERs and ELEMENTs, making up the overall datum + specific context structure
	Clinical situation recording	committed report, document, or other artefact containing one or more Clinical entry structures, potentially with added heading structure; carries audit + attestation	COMPOSITION containing one or more ENTRYs
Orders	Order item	Common features: complex timing / condition item(s) possibly conditional branched structures (since orders are about the future) description of the intervention / drug	ENTRY
	Order set	A set of order items + other meta-data (TBC)
	Prescription	Arguably a special kind of grouping of order items
Actions		TBC
etc

We don't treat computed / summed data items that appear in e.g. Apgar or BMI as special here, because I don't think they change the structure categories.

Lab results (i.e. in general the panel result, not a single lab analyte) and Questionnaires should be treated as special kinds of collections, whose members are logical atoms of a standard mould, whereas most other clinical data is not like this - each thing is its own structure. There are probably other special kinds of collections as well.

Readers might not agree exactly (or at all) with the above but I think we have to live with an ontological reality: not everything is the same, and we need to identify the structure of information in the real world in order to find appropriate modelling patterns.