Demographic package

The model is designed to be used with archetypes, hence the generic nature of all entities. Every class containing an attribute of the form details:STRUCTURE is a completely archetypable structure. As a result, archetypes can be defined for concepts such as particular kinds of PERSON, ORGANISATION; for actual ROLEs such as "health care practitioner", and for party identities and addresses.

Classes have been included for PARTY_IDENTITY and ADDRESS, even though they contain only a link to details, in the form of the generic STRUCTURE class. This is not strictly necessary - it could have been done simply using appropriately named attributes in the classes PARTY and CONTACT - but is done to provide a place to add specific semantics in future releases of the model. It is also expected to make software development easier, since it provides explicit classes to which behaviour and other implementation attributes can be added. Lastly, it allows the notions of PARTY_IDENTITY and ADDRESS to be explicitly used in archetype-authoring tools.

Instances of PARTY_IDENTITY, linked to PARTY by the attribute identities are intended to express the names of people, organisations, and other actors - that is names which are "owned" by the party, e.g. self-declared (in the case of institutions and companies) or by virtue of social relations (names given by parents, tribes etc). Identifiers of Parties given by other organisations, or the state are not represented in this way, and should be recorded in the PARTY.details structure instead (see below).

Identifiers of Parties given by organisations or the state are treated as any other attribute of a Party, i.e. recorded as part of the data in the PARTY.details structure. Identifiers of Party instances in the system are provided in the same way as identifiers of Compositions in the EHR: via the uid attribute (type OBJECT_VERSION_ID) of the containing VERSION. These identifiers are used in all cross-references between Parties, and between Parties and Party_relationships.

Relationships between parties in the real world may be expressed using PARTY_RELATIONSHIP objects, as illustrated below.

Relationships are considered directional, hence the use of the attribute names source and target, however, these names are otherwise neutral, and give no indication as to the meaning of the relationships, such as which party is responsible and which accountable (for comparison, see the demographic models of Fowler [Fowler_1997]). Accordingly, each Party involved in a relationship includes it in its relationships list, if it is at the source end, or in the reverse_relationships list, if at the target end.

The usual way to determine the directionality of a relationship between two Parties is usually by which Party’s actions caused the relationship to come into being. For example, a relationship representing the concept "patient", between a health consumer and a health care organisation would have the consumer as source and the organisation as target.

PARTY_RELATIONSHIPs are stored as part of the data of the PARTY designated as the source. This means that the relationships attribute is by value, while reverse_relationships is by references, as are PARTY_RELATIONSHIP.source and target. The actual kind of reference is via the use of OBJECT_REFs containing HIER_OBJECT_IDs to denote the Version container of a Party, rather than OBJECT_VERSION_IDs, which would denote particular versions. Logically this implements the semantic that such relationships in the real world are between continuants, i.e. the real Parties, not just one of their version instances in a demographic system.

The class PARTY and its descendants ACTOR and ROLE are all potentially versioned in a demographic system. A Version of a PARTY includes all the compositional parts, such as identities, contacts, Party relationships of which it is the source. Every Party is stored in its own Version container.