CIMI: Thoughts about Modeling and use of Archetypes as Clinical Models
Gerard Freriks
1- Context of documented Health Data
Archetypes are used to document healthcare as provided by an HcActor in the role of author.
Archetypes define what can be documented in, and exchanged between, Health IT-systems and components.
Data defined by meta-data in the archetype is used to document the provision of care to an Subject of Care.
Data is instantiated in an EHR-system using archetypes.
It is the author that adds data to the EHR and is accountable for this.
This implies that what is in the EHR is largely a subjective view of the author.
Many times the author uses information provided by the SoC, its surroundings and third parties.
This implies that data documented in an EHR is subjective in two ways (Author and data provider dependent)
This implies that data documented in an EHR never is exactly the reality as it unfolds in the Patient System.
Only Inferences can be made about the Patient System. And these Inferences can be documented.
Only what is stated in the EHR is ‘known’.
Therefor the EHR system follows the Closed World Assumption, meaning: what is not documented does not exist in the EHR.
2- Patient System is the concept that encompasses:
- the full body, as one full, complete, as one entity, as person
- body parts, components/systems, physiology, chemistry, genetics, etc.
- and its surroundings; family, work, sports, etc.
3- Documenting Processes
[SIAMM: Process Modeling style]
Inside the Patient System (PS) many processes take place.
As axiom one never can observe these processes directly; we can make inferences about these processes, only.
What can be observed are phenomena that result from these processes inside the PS.
These phenomena need to be observed by an HcActor first, before they can be documented. There are unobserved and observed phenomena.
Next to processes inside the PS other processes need to be taken into consideration.
These processes are enumerated by ContSys:
- Process of Documentation of the (ideal) clinical treatment process
The next set of items are defined by System of Concepts and as used by SIAMM.
They are named Operations: - Observation/ResultCollecting Operation,
- Inference/Assessment making Operation,
- Planning Operation,
- Ordering Operation,
- Execution Operation.
- Process of documenting Clinical Activity: Diagnostic activities and Therapeutic activities
- Process of documenting Quality management
- Process of documenting Administrative topics
- Process of documenting Communication
- Process of documenting Activity Management
- Process of documenting Evaluations of processes (Assessments/Inferences)
- Process of documenting Knowledge management
This implies that only data (Statements) that are labelled as: Documenting Clinical Activity are about facts about the Patient System.
All other Documentation Processes are about re-used data about Clinical, and other non-clinical Activities.
4-Archetypes, Statements as assertions
What is documented are Statements of the kind: ‘X’ has as characteristic ‘Y’. Or ‘X’ is about ‘Y’.
‘X’ = ‘Y'
E.g. ‘Diagnosis’ is about ‘Diabetes’
5-Statement Context and Semantic Interpretability
[SIAMM: Documenting epistemology]
In addition to the overall context of data inside any EHR-system this bullet point is about the context of the assertion/statement:
- WHAT is considered to be the Statement/Assertion with the component ‘NamedObject’ and ‘ResultValues’.
- WHERE is about absolute and relative localization of that what is stated in space, time and Patient System.
WHO is about who participate in the Statement. Who is the target/focus of the statement. This is not always the Subject of Care and the Author - WHY is about the reasons why the statement was made.
- HOW is about the Method and Confounding factors that were used to make the statement.
This creates the standardised Statement:
‘the Statement ‘X’=‘Y’ must be interpreted in the context of what is documented as Statement Context (WHERE, WHO, WHY, HOW)’.
And it must be interpreted in its Documentation Context.
Such a complex/compound Statement is capable to deal with data and their epistemology and allow a full and safe interpretation of data.
It allows Semantic Interpretability.
6-SIAMM Kind of Statements: the generic ENTRY pattern
[SIAMM: Attribute Modeling style]
ENTRIES model one of the Operations as process: ResultCollection/Observation, Inferencing/Assessing, Planning, Ordering, Executing.
Each ENTRY is about one of the defined Process of Documentation.
The ENTRY about ResultCollection has as outcome of that Operation observed facts, as observed by the HcActor involved and authored by the author.
This Collection of Results is a Panel consisting of one or more Panel components as other statements.
This means that the ENTRY is always about an Operation in the context of one of the Documentation processes.
CLUSTER models define the complete What, Where, Who, Why and How of: the Operation, the Panel Statement and the detailed Statement. Three layers of CLUSTER models in the ENTRY.
In this way the ENTRY is always a largely fixed pattern. Method and Confounding factors will change depending on the topic that is modelled.
Because the ENTRY is a fixed pattern specialisation is NOT via changing the names of the nodes but changing the content of the Data Field attribute of the ELEMENT class.
Exactly is known via the names of the nodes, and/or bindings to codes from a Reference Terminology, what the focus is of the statement and what the context components are.
In SIAMM the Statement and its full context are defined using theSIAMM ENTRY model implicating that there is no place for pre- and post co-ordinated SNOMED codes that deal with Findings.
7-Modifiers / (Qualifiers)
Documented Statements and parts of statements and the interpretation of the statements are influenced by the two Contexts as described above.
(Documentation Context and Statement Context)
The two Contexts function as a description of all Qualifiers for the statement.
The Interpretation of Documented Statements are influenced by Modifiers, also.
Considered Modifiers are: Status, Certainty and Presence/Absence.
These Modifiers can operate on each node in the ENTRY pattern. From modelled Operation to data filed in an ELEMENT.
[SIAMM Rules]
Rules are needed to deal with propagation of the Modifier and use of Coded fro Coding Systems.