You can access the whole set of archetypes and templates in the /knowledge folder on SVN.
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.
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:
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.
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)
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.
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...