Clinical Modeling Core Principles - Revision history

Admin: /* Cycle through life! – Status and Versioning */

2020-07-17T19:39:36Z

‎Cycle through life! – Status and Versioning

Admin: /* Mandatory M */

2020-07-17T19:39:19Z

‎Mandatory M

Admin: /* Cardinality and Conformance */

2020-07-17T19:38:43Z

‎Cardinality and Conformance

Admin: /* Tell me why! – Evidence */

2020-07-17T19:38:25Z

‎Tell me why! – Evidence

Admin: /* Describe the kind of data! – Data types /

2020-07-17T19:37:04Z

‎*Describe the kind of data! – Data types

Admin at 19:36, 17 July 2020

2020-07-17T19:36:38Z

Admin at 19:30, 17 July 2020

2020-07-17T19:30:32Z

Admin: Created page with "=Clinical Modeling Core Principles= ==Stakeholders== Healthcare Providers Terminologists Analysts, Modelers Vendors, Interface Specialists *Research ==Ten threshold conce..."

2020-07-17T19:21:11Z

Created page with "=Clinical Modeling Core Principles= ==Stakeholders== *Healthcare Providers *Terminologists *Analysts, Modelers *Vendors, Interface Specialists *Research ==Ten threshold conce..."

New page

=Clinical Modeling Core Principles=
==Stakeholders==
*Healthcare Providers
*Terminologists
*Analysts, Modelers
*Vendors, Interface Specialists
*Research

==Ten threshold concept of Basic Clinical Modeling==
*You are not alone! – Teamwork
*Start talk talkative! – Data elements basics
*Divide and conquer! – Grouping
*Describe the kind of data! – Data types
*Guide to reality! – Examples, examples, examples
*Tell me why! – Evidence
*Foster proper answers! – Operationalization
*Profit from other art! – Re-usability and inheritance
*Document your expectation! – Cardinality and more
*Cycle through life! – Status and Versioning

Work based on a paper:��Team competencies and educational threshold concepts for clinical information modelling. / Scott, Philip; Heitmann, Kai.
Decision Support Systems and Education. ed. / John Mantas; Zdenko Sonicki; Mihaela Crişan-Vida; Kristina Fišter; Maria Hägglund; Aikaterini Kolokathi; Mira Hercigonja-Szekeres. IOS Press, 2018. p. 252-256 (Studies in Health Technology and Informatics; Vol. 255).
https://researchportal.port.ac.uk/portal/files/11936801/�Team_competencies_and_educational_threshold_concepts.pdf
http://ebooks.iospress.nl/publication/50513

==You are not alone! – Teamwork==
Active participation of clinicians necessary but requires (communication, soft, …) skills
Collaborative environment with multi-stakeholder communication
Healthcare providers must learn how to communicate well with non-clinical experts and vv
Add Process / content analysts and terminologists
Perform team-building activities

==Start talk talkative! – Data elements basics==
*The data elements shall have a short name that allows other to gather what this item means.
*This needs to be simple text in natural language, not acronyms or abbreviations.
**Examples: Date of birth, Body weight, Type of specimen, Anatomic site, Specimen Collection Time
*Data elements shall always include a description that precisely explains in additional words what the subject of the item is.
*Examples
**The date and time the specimen was collected
**The reason why the immunization was refused
**The administrative gender of a person
*Introduce an identifier (short number for example) for each data element, at least unique within the data set, eventually globally unique; this makes it much easier later to refer to the data element in further discussions.
*Agreement about naming conventions so that you are consistent

@@ Line 186: / Line 186: @@
 *The lifecycle of a definition should always be imagined as two-dimensional: a Status and a Version.
 *An item has an initial Status, such as “draft” when you start defining it. It may mature over time to a status like “final”, is used and once no longer needed or replaced by a newer and better definition it might migrate to the status of “deprecated” or “retired”.
-*This leads to a new Version of the definition:�Versioning retains the original definition (also because it is still in use), “clones” the origin and adds the changes to the new version
+*This leads to a new Version of the definition: Versioning retains the original definition (also because it is still in use), “clones” the origin and adds the changes to the new version
 ===Evolution of models and specifications===
 ===Status===

@@ Line 163: / Line 163: @@
 ===Cardinality and Conformance===
 ====Mandatory M====
-**The attribute is mandatory, i.e. a valid value shall be provided and no null value is allowed. The minimum cardinality is at least 1. This also implies that if the sender has no valid value for such an attribute, the message cannot be sent.
+*The attribute is mandatory, i.e. a valid value shall be provided and no null value is allowed. The minimum cardinality is at least 1. This also implies that if the sender has no valid value for such an attribute, the message cannot be sent.
-**A sender must support elements with “mandatory” conformance, and a receiver must understand these elements.
+*A sender must support elements with “mandatory” conformance, and a receiver must understand these elements.
-**Please use mandatory elements with caution as overly-strict requirements may result in not implementable templates or in situations that are not aligned with practice.
+*Please use mandatory elements with caution as overly-strict requirements may result in not implementable templates or in situations that are not aligned with practice.
-*Required R
+====Required R====
-**The item is required, i.e. a valid value should be provided or if missing a null value is allowed if its minimum cardinality is 1 (“empty element”), or may be omitted if its minimum cardinality is zero (“missing element”).
+*The item is required, i.e. a valid value should be provided or if missing a null value is allowed if its minimum cardinality is 1 (“empty element”), or may be omitted if its minimum cardinality is zero (“missing element”).
-**In messages, the element must be communicated if its minimum cardinality is one. In the case where the element is not mandatory, it may be communicated with a null value. Note that any element declared to be "Mandatory" must also be "Required" and have a minimum cardinality of one. If the minimum cardinality is zero, and the element is "Required", conforming applications need not send the element if data does not exist. In some governance groups this is referred to as “Required but may be empty”.
+*In messages, the element must be communicated if its minimum cardinality is one. In the case where the element is not mandatory, it may be communicated with a null value. Note that any element declared to be "Mandatory" must also be "Required" and have a minimum cardinality of one. If the minimum cardinality is zero, and the element is "Required", conforming applications need not send the element if data does not exist. In some governance groups this is referred to as “Required but may be empty”.
-**For required elements, conforming applications must demonstrate their ability to provide and communicate not null values. Receiving applications must demonstrate their ability to receive and process (e.g. store, display to users) not null values for required elements.
+*For required elements, conforming applications must demonstrate their ability to provide and communicate not null values. Receiving applications must demonstrate their ability to receive and process (e.g. store, display to users) not null values for required elements.
-**A sender must support elements with “required” conformance, and a receiver must understand these elements.
+*A sender must support elements with “required” conformance, and a receiver must understand these elements.
-*Optional O
+====Optional O====
-**The item is truly optional, i.e. a valid value may be provided or if missing may be omitted.
+*The item is truly optional, i.e. a valid value may be provided or if missing may be omitted.
-**It is indicated as “O” in the template item table, a may be considered as a shorthand for an unspecified conformance with a minimum cardinality of zero.
+*It is indicated as “O” in the template item table, a may be considered as a shorthand for an unspecified conformance with a minimum cardinality of zero.
-*Not permitted NP
+====Not permitted NP====
-**The item is not allowed, i.e. the number of allowable occurrences is 0. It is indicated as “NP” in the template item table.
+*The item is not allowed, i.e. the number of allowable occurrences is 0. It is indicated as “NP” in the template item table.
-*Conditional C (typically with a condition table)
+====Conditional C (typically with a condition table)====
-**This item has an associated condition predicate and may depend on the co-occurrence of other elements or properties of the instance or situations.
+*This item has an associated condition predicate and may depend on the co-occurrence of other elements or properties of the instance or situations.
 ==Cycle through life! – Status and Versioning==

@@ Line 162: / Line 162: @@
 You also might consider making it 1..1 under the Condition that the person is female and your scenario requires information about pregnancy, for example patient safety reasons (prescription scenario, perhaps)
 ===Cardinality and Conformance===
-*Mandatory M
+====Mandatory M====
 **The attribute is mandatory, i.e. a valid value shall be provided and no null value is allowed. The minimum cardinality is at least 1. This also implies that if the sender has no valid value for such an attribute, the message cannot be sent.
 **A sender must support elements with “mandatory” conformance, and a receiver must understand these elements.

@@ Line 138: / Line 138: @@
 ==Tell me why! – Evidence==
-*When defining a data set, a use case / rationale for the collection of the�defined set of data overall and each data element individually shall be documented
+*When defining a data set, a use case / rationale for the collection of the defined set of data overall and each data element individually shall be documented
 ==Foster proper answers! – Operationalization==

@@ Line 53: / Line 53: @@
 *Good tools intuitively support this
-==*Describe the kind of data! – Data types==
+==Describe the kind of data! – Data types==
 *Data set is a definition of elements that will be populated with real values
 *Datatypes: What is the expected nature of the data

@@ Line 129: / Line 129: @@
 *While standardized units are very important for the communication between systems e.g. 10*9/L as the “system” unit for Platelets, using a coding called UCUM), the display of the units should always fit the usual way clinicians are used to seeing them, like x 109/L Platelets
 ==Guide to reality! – Examples, examples, examples==
 ==Tell me why! – Evidence==
 ==Foster proper answers! – Operationalization==
 ==Profit from other art! – Re-usability and inheritance==
 ==Document your expectation! – Cardinality and more==
 ==Cycle through life! – Status and Versioning==

@@ Line 19: / Line 19: @@
 *Cycle through life! – Status and Versioning
-Work based on a paper:��Team competencies and educational threshold concepts for clinical information modelling. / Scott, Philip; Heitmann, Kai.
+Work based on a paper: Team competencies and educational threshold concepts for clinical information modelling. / Scott, Philip; Heitmann, Kai.
 Decision Support Systems and Education. ed. / John Mantas; Zdenko Sonicki; Mihaela Crişan-Vida; Kristina Fišter; Maria Hägglund; Aikaterini Kolokathi; Mira Hercigonja-Szekeres. IOS Press, 2018. p. 252-256 (Studies in Health Technology and Informatics; Vol. 255).
-https://researchportal.port.ac.uk/portal/files/11936801/�Team_competencies_and_educational_threshold_concepts.pdf
+https://researchportal.port.ac.uk/portal/files/11936801/ Team_competencies_and_educational_threshold_concepts.pdf
 http://ebooks.iospress.nl/publication/50513
@@ Line 42: / Line 42: @@
 *Introduce an identifier (short number for example) for each data element, at least unique within the data set, eventually globally unique; this makes it much easier later to refer to the data element in further discussions.
 *Agreement about naming conventions so that you are consistent