Sorry, this was a reply to Philippe on his message on 14:07 Op ma 2 apr. 2018 15:16 schreef A Verhees <bert.verh...@rosa.nl>:
> Mostly a patients history is regarded in a consultation. Mostly this is > history from after the start of the electronical era and being treated in > the Netherlands . At least it is common practice in the Netherlands for > most patients. > > Op ma 2 apr. 2018 14:30 schreef Thomas Beale <thomas.be...@openehr.org>: > >> >> >> On 02/04/2018 10:59, Philippe Ameline wrote: >> >> Le 01/04/2018 à 14:13, Thomas Beale a écrit : >> >> >> just by means of clarification for some readers, since I happen to know >> how both openEHR and Philippe's system works, here's the way to understand >> how openEHR would perform the same function as Ligne-de-vie (which it can): >> >> - build a lot of CLUSTER archetypes, and probably more OBSERVATION >> ones; each CLUSTER archetype would be one of the 'trees' Philippe talks >> about >> - each of those CLUSTER archetypes has slot nodes that indicate where >> subordinate CLUSTER archetypes join, and which ones are allowed, in the >> usual openEHR fashion; >> - remember, a slot can allow multiple possible substitutions >> - at run time, a form containing a top level Entry, usually an >> OBSERVATION will be deployed on the screen, and by a process of user >> choice >> / UI movements etc, the data will get filled in, and subordinate CLUSTER >> archetypes will be chosen on the way, and filled in along the way. >> >> This mode of operation is known by us in openEHR-land as 'dynamic >> slot-filling' or 'runtime templating', as opposed to the more typical >> design-time templating used in a lot of systems, where most of the choices >> are made prior to runtime. But openEHR systems do use runtime slot-filling >> as well, e.g. for writing discharge summaries and referrals, where the data >> items are only knowable in the encounter or report-writing session. >> >> >> This trend allows me to discover that openEHR already became a rich >> ecosystem. Isn't this technique close from Gerard's vision of archetypes as >> "context for concepts" in a kind of ontology? >> >> However, I probably wrongly expressed what I wanted to say, and is more >> theoretical than comparing implementations, such as openEHR and Ligne de >> vie. >> >> When we talk to one another using a natural language, we just need a >> vocabulary and a grammar. The grammar is simply a set of rules, but not a >> physical pattern. We say "John sees the green house" and not "John as the >> subject sees as the verb the green as an adjective house as a noon in a >> position of direct object complement". >> >> In the same way, it is possible to express a structured discourse just >> using an ontology and a grammatical structure (say trees) without the need >> of any structure description. >> >> >> you are I think using 'grammar' in an unusual way - normally it means the >> set of production rules that define legal utterances in some language; this >> is an intensional definition, i.e. it can be used computationally to parse >> actual utterances (including garbage) and generate structures only for the >> utterances obeying the rules of the grammar. >> >> In your usage, 'grammar' is what you call the trees, which are >> extensional maps of legal utterances, or fragments of utterances, which can >> only be connected together according to their rules, which ensure >> correctness of larger utterances, e.g. a colonoscopy report. >> >> Structurally and computationally then, the fils guides (the trees in >> Ligne de Vie) and archetypes are the same; they differ only in >> representational details. However, there are two semantic differences. >> >> Firstly, the fils guides depend completely on the ontology (which is an >> ontological terminology, to give it a more correct name, I think), and the >> two things are built as a combined representational system. Whereas >> elements in archetypes can have bindings made to ontologies and/or >> terminologies, but don't rely on them, since they can rely on their >> internal terminology to a reasonable extent (but not for value sets like >> procedure or diagnoses etc). In theory, we should do what fils guides are >> doing, and the reason we have not is only practical, not theoretical: the >> development of bio-medical ontologies is still young, and was almost >> non-existent 18 years ago when we started on this. >> >> The consequence has been that it is possible to construct archetypes that >> say questionable or even wrong things with respect to ontologies of those >> same things, say anatomical relationships. This rarely happens in reality >> simply because archetypes are built by clinical professionals and reviewed >> by many others, and mistakes tend to be avoided, or if made, caught in >> review. But clearly it's not a completely reliable strategy, and future >> versions of archetype tooling should force live checking against suitable >> ontologies to detect errors. Unfortunately, we still don't have such >> ontologies in anything like the necessary detail - despite the existence of >> OGMS, and numerous specialist OBO ontologies. SNOMED CT doesn't come close >> to what is needed here. We still lack a comprehensive ontology covering all >> of general medicine. >> >> Secondly, the 'utterances' represented by archetypes are not intended to >> be directly linguistic expressions, but rather constitute an underlying >> structural *reference* 'terminology'. The fils guides on the other hand >> express natural language utterances, i.e. they are like a structural >> *interface* terminology. With archetypes on the other hand, the names of >> elements are used as a default to name fields etc in the UI, but may always >> be overridden by some interface vocabulary, or more likely a layer of >> language-level templates tied back to templates based on archetypes. In >> openEHR we have no system for doing the latter at the moment, although it >> is often mentioned as a nice idea... >> >> >> - thomas >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
