Today there are two alternatives to achieve the formalization of multilevel modeling. The first is to extend the archetypes and templates to support the new requirements, expanding its capacity for representation of clinical content. The second alternative is to define new services using archetypes and templates, expand their modeling capabilities but without modifying them. This second approach seems the more flexible and neat, especially considering that the specification of archetypes and templates for being robust and stable, and currently serving well the purpose of modeling clinical content, and just that.
For example, in a multilevel approach could have the following artifacts, where higher levels artifacts artifacts may use lower levels:
- Level 1:
- Information Model: elements with minimal semantics
- To be mapped in some way to a database
- Level 2:
- Archetype Model: self-contained general clinical concepts
- Template Model: particular clinical content / aggregation of archetypes
- To be mapped to some business logic like data validation and processing
- Level 3:
- Query Model: standardized collection of queries defined over archetypes and templates
- To be mapped to physical queries and query/retrieval services (we can use AQL as the canonical format)
- Level 4:
- Rule Model: rule definitions over differents sets of templates / archetypes (we can use GDL as the canonical format)
- Information aggregation model: definition of aggregations of clinical archetypes for calculating and evaluating statistics, indicators and series.
- To be processed in evaluation engines to generate alerts, reminders, recommendations and reports.
- Level 5:
- Messaging model: structuring information in messages
- To be mapped with HL7 v2.x, v3, CCR, CDA, CCD, EN/ISO 13606 and other interchange formats, the mappings might be defined using the openEHR XSDs as the canonical interchange format.
- Level 6:
- User interface model: guidelines/directives on how information is displayed, grouped, presented, organized, etc.
- Workflow model: rules about how the UI will be presented to the user to execute different workflows (order, preconditions, show/hide, etc)
- To be mapped with the presentation layer in software applications.
A possible case of application of multi-level approach may be to build a monthly report to the aggregation of clinical cases in an emergency department of a hospital. Then, at level 2 should have modeled the classification of a patient, for example by reason of consultation and / or diagnosis. At level 3 should have defined a query for emergency patients, filtering by diagnosis. At level 4 is defined aggregation numbers of patients by diagnosis (which uses the previously defined query). At level 6 is the definition of how the report will be presented to a user. This flexibility is achieved without modifying the application software (the elements defined in each layer are independent of technology), as it would add new elements. with new capabilities, user demand, and also the elements already defined in each layer can be reused by new elements in the upper layers.