Modelling principles
Priorities, from highest to lowest
Clinical safety
Clarity of information for data users (for example modellers and clinicians)
Separation of information into appropriate RM classes
Ease of governance
Ease of templating
Ease of querying/implementation
Things to avoid
Abstract archetypes (problem for clarity and ease of governance)
Potential for mixing up data that isn’t comparable on retrieval (for example two different scores in one data element, separated only by a flag or by specialisation)
Potential for mixing up negation with positive presence (for example separated only by a flag)
Specialisation without a clear use case for governance or retrieval
Comments
Jan 29
When later revising these in the light of ADL2 and hopefully improved tooling I believe “Abstract archetypes” could be recommended for some use cases (provided that they are clearly marked as abstract in tools and repotistories like CKM to avoid confusion). Having abstract archetypes for truly shared fields/properties and substructures of related archetypes would mak both translations and GUI-code easier to maintain than the current recoomendation of copy-pasted structures between formally unrelated but in practice equal parts of different (in practice) related archetypes.