Introduction

About this page

The thinking reported on this page is for the moment just that: initial ideas on what an 'archetype design pattern' might be, and how it could be formalised / described. Anyone is welcome to throw in ideas here and propose changes or a completely different approach.

Conceptual approach #1 - using software design pattern approach

Author: Thomas Beale

What is an archetype design pattern (ADP)?

The archetype formalism and model can be used to represent all kinds of things, in many different ways - often there is more than one possibility for a given requirement. It is not always apparent what the best way, or what is accepted and in use by the modelling community. This leads to a need for accepted archetype design patterns (ADPs), which model authors and tool-builders can assume and use.

Design pattern template

The following set of headings provides a standard template for documenting an ADP.

Heading	Content description
Name	The name of the pattern.
Domain use case	The domain use cases to which it applies. Detailed descriptions wil typically be on other pages.
Pattern description	Natural language description of the pattern, how it works, possibly including diagrams.
Formal expression	Expression in form of ADL excerpt, or URL referring to definitive example archetype online.
Use (optional)	Specific domain areas of applicability.
Misuse (optional)	Specific domain problems that users might expect to use this ADP, which should be solved by other means.
Examples	Examples of this pattern in the form of references to published archetypes & use context.
Tool Support (optional)	Support for this ADP in archetype or other modelling tools.
Developers	List of authors and contributors of this design pattern.
Revision History	list of{date, status, who, reason for change} of this ADP.

Design pattern catalogue

Coded or free text response

	Coded or free text response
Domain use case	This pattern addresses the situation where a response at a single data point can be in either coded form or plain text. A typical example is a field whose value is the name of a disease, which can be chosen by the user from a terminology subset, but may also be enterable as text if the disease is not found.
Pattern description	TBD
Formal expression	This can be achieved by the following ADL pattern using an external subset:

definition
    ...
    $attr_name matches {
        DV_TEXT matches *
        DV_CODED_TEXT matches {[$ac_code]}
    }
    ...
ontology
    constraint_definitions = <
        [$lang] = <
            [$ac_code] = <
                text = <"$text">
                description = <"$description">
            >
        >
    >
    constraint_bindings = <
        [$terminology] = <
            [$ac_code] = <$url_to_refset>
        >
    >

All $vars are replaced when the pattern is instantiated, by normal ADL elements. Variable meanings:

$attr_name - name of enclosing attribute
$ac_code - ac-code of form subset
$lang - language in ontology section; repeat for each language
$text - text of ac-code definition, e.g. 'type of infection'
$description - description of ac-code definition e.g. 'this subset includes types of infection'
$terminology - id of terminology to which ac-code has binding; must be in openEHR form, terminology_name(release)
$url_to_refset - URL to the terminology subset

Use (optional)	TBD
Misuse (optional)	TBD
Examples	TBD
Tool Support (optional)	TBD
Developers
Revision History	2009-01-10, draft, T Beale, Initial Writing

Structured or Narrative

	Structured or Narrative
Domain use case	This pattern applies to the situation where a larger amount of information may be expressed either structurally (i.e. as a number of items, typically in a tree or list structure) or narratively. The need is driven by the requirement to accommodate existing systems and / or users that can only supply data in narrative form, even though structured is the preferred data capture method.
Pattern description	TBD
Formal expression	TBD
Use (optional)	TBD
Misuse (optional)	TBD
Examples	TBD
Tool Support (optional)	TBD
Developers	TBD
Revision History	2010-01-12, draft, who, Initial writing

Design proposals

TBD

Questionnaire

	Questionnaire
Domain use case	This pattern addresses the very common case of 'questions' appearing in questionnaires for new patients, admissions and other purposes in provider enterprises. Such questions are characterised by the following: the question as a linguistic expression, e.g. 'is there any history of diabetes in your family?' (note that this is obviously language dependent) the intended meaning of the question, not normally visible on the form, e.g. to discover whether any genetically related family members have been diagnosed with diabetes in the past a set of choices for the response, often: boolean e.g. yes/no multi-valued e.g. yes/no/don't know, yes/no/not sure date, partial date duration e.g. how long have you been smoking => about 5 years numeric value e.g. how many children do you have => 2 free text the question is often designed in a broad way with the intention of categorising patients rather than generating a precise clinical value. Patients who fall under a category of interest (e.g. smokers, people who have been to hospital for heart trouble etc) may then be be dealt with in a particular way, e.g. booked for consultation. Questions are not necessarily well designed, and different types of problems emerge to do with this: patients understand the question differently from the doctor ex: Q: 'Have you ever had heart trouble?' intended to mean: have you ever been diagnosed with (or perhaps treated for) a cardiac problem? This is probably the doctor's understanding. may be understood by the patient to mean have they ever personally experienced any sign or symptom to do with the heart, e.g. arrhythmia (which may simply be the normal reaction of the heart to stress, coffee etc) different physicians using the same form or questionnaire may not understand the question the same way. Questionnaires are typically not developed by the consulting physician but by their institution or by a government department. Physicians may not have been educated on the use of forms.
Pattern description	TBD
Formal expression	TBD
Use (optional)	TBD
Misuse (optional)	TBD
Examples	TBD
Tool Support (optional)	TBD
Developers	TBD
Revision History	2009-01-10, draft, Ian McNicoll, Initial Writing

Prescence / Absence

	Presence/Absence
Domain use case	This pattern addresses the need to express that a described feature, e.g. something on the colon wall in an endoscopy exam, is present or absent, in a standard computableway.
Pattern description	TBD
Formal expression	TBD
Use (optional)	TBD
Misuse (optional)	TBD
Examples	TBD
Tool Support (optional)	TBD
Developers	TBD
Revision History	2009-01-10, draft, who, xxx

Design Proposals

Gastros - Koray Aalag - Dec 2009

My proposal is either:

1. to introduce to CLUSTER or its parent an extra attribute for presence (present|absent|indeterminate) and also flavours of null.

2. to develop a custom ADL syntax to make life easier for modellers (such as shorthand for local codes) so that this can automatically be generated in downstream artefacts.

I guess the 2^nd option is more doable - and I suggest (as Ian did in the Nehta pathology models) to give values (Yes|No|Indeterminate) and then further specify flavours of null when the latter is selected. The reason why I inserted only Yes|No is a requirement of my current project; so pls. ignore that.

What process is needed?

The following headings describe questions that would need to be answered in the process of formalising the description and development process of ADPs.

What is the process for developing an ADP?

What do I do if I have an idea for an ADP?

TBD

How do I contribute to an ADP?

TBD

Who manages the editorial process for ADPs?

TBD

When is an ADP ready for use in tools?

TBD