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
