You can access the whole set of archetypes and templates in the /knowledge folder on SVN.

Strategy and Roadmap:

The goal is to create a single Template which embodies all MST related aspects of GastrOS that is faithful to the domain knowledge contained in GST. This means it will have to be slightly different from normative English MST version 2.0h (MST2.0 English 990307) because there were changes resulting from:

 The situation with MST is complicated - there are many versions and translations out there + my revisions.

 The modelling strategy is:

By this way we will be able to drive GastrOS using exactly the same domain knowledge in GST while still having a correct model which can be utilised in future by us and others. And hopefully form the seed of the next generation MST standard.

Modelling Roadmap

  1. Model individual Archetypes based on corrected MST
  2. Specialise to match GST
  3. Create a single template holding all parts of MST
  4. Define and put presentation related information into the Template (i.e. GUI directives as template annotations)
  5. For each examination type create operational templates which contain only parts of MST for exam type
  6. Put models into CKM and expect reviews.

Here are my golden modelling principles:

  1. Keep all domain knowledge defined in MST as much as possible at the ARCHETYPE level - not delegating any domain related constraint to Templates OR ANYTHING to Application/Runtime (i.e. hardcoding)
  2. Be faithful to the cause and structure of MST during modelling.
  3. Try to follow GUI oriented organisation where possible, following the design of GST. This is not a reference terminology but a so called "Interface Terminology"
  4. Keep the number and complexity of archetypes low
  5. Not least follow openEHR modelling principles (and keep Heather happy!)

Most current model:      XMind    //     JPG

 

Issues with Modelling

1) Problem with Clinical Findings/Questionnaires:

I (reluctantly) had to insert into each and every a node in MST Findings Archetypes a new ELEMENT (Name: Presence? Type DV_CODED_TEXT with values Yes|No) corresponding to a MST Term which depicts the presence of that finding. I think there should be a more appropriate way of depicting presence of a clinical finding as I was sick of inserting repetitive stuff. I think this is far from a good modelling practice. My proposal is either:

  1. to introduce to CLUSTER or its parent an <ins>extra attribute</ins> for presence (present|absent|indeterminate) and also flavours of null.
  2. to develop a <ins>custom ADL syntax</ins>to make life easier for modellers (such as shorthand for local codes) so that this can automatically be generated in downstream artefacts.

2) Inability to represent custom units in QUANTITY

 In MST Therapeutic Procedures the diameter attribute of Prosthesis term specifies using either mm or French. This is a unit used to define diameter of catheters in clinical medicine. One workaround is specifying <ins>Quantified Real with no units</ins> which works fine with AE and AWB but fails to validate on demo CKM.

Created a jira issue: https://projects.oceaninformatics.com/jira/browse/REP-1550

So until the issue is resolved I am modelling it with mm only.

3) Anatomical sites

 The organ specific sites are hardcoded into various MST findings, characteristics and procedures archetypes. Ideally they should come from terminology but we are not going to implement that.

For Exam characteristics the Site(s) contain sites from Upper & Lower exam and also for ERCP. This means for the former one ELEMENT will hold values of sites for esophagus , stomach, duodenum and colon! We can separate colon and others in opt but selection will be quite difficult for EGD because the individual terms are too generic (like Cardia which applies to both Esophagus and Stomach). In GST these are shown by a combobox with Organ names as Separators between values (not faithful to MST); in fact these should have been splash forms because multiplicity is allowed. So we decided to append organ names to values in archetypes which involve as such.

A useful solution when implementing terminology service might be to define a parameter in GUI directive how many levels back the Widget will show the hierarchy starting from its root defined in constraint. For example if it is a subset containing 2 levels then setting the parameter to 1 (perhaps as GUI directive) will only show its immediate parent and value such as: Stomach | Cardia

EUREKA! We found a good solution: we will use term description which normally contains 'context' for the term. Just will be more specific and say:

Term: Cardia
Description: Site:Stomach

So, when a directive is put, the widget will append these during both selection and later display from persistence.
Perhaps like this: Cardia (Site:Stomach)

5) Use of 'other' and free text description in MST Archetypes

 According to MST the use of 'Other' in lists is intended for system developers to allow addition of other terms - not free text description. So MST archetypes will not contain such nodes nor free text description unless explicitly stated by MST. These should appear on 'specialisations' for local needs.

6) Hardcore semantics: how to determine values and correct presentation

Simple example:

Node X: values a,b - they can be selected together. So question is: insert a third value: both and save single instance? OR arrange a widget which looks at cardinality/occurrences and offer selection of both either by simply allowing multiple selection or create a value which says both and persist as two different instances. Perhaps depends on how to query data later on...