Le 01/04/2018 à 14:13, Thomas Beale a écrit : > On 31/03/2018 10:38, Philippe Ameline wrote: >> ... >> >> When I try to explain all this to lesser tech-savvy people (means, >> who don't belong to this list ;-) ), I usually explain that: >> - usual systems (with an information schema tied to a database >> schema) are like a printed form. The day after you received the 5000 >> printed sheet you ordered, you will realize that there are several >> design flaws that you will have to endure while the stock is not empty, >> - openEHR is a flexible schema, similar to a set of stamps that lets >> you build forms dynamically from blank paper. If your design has to >> evolve, you just have to adapt one of the stamps. >> - in my system, based on an ontology and a dependency grammar, you >> can use stamps (archetypes like) and/or "write" freely. >> > > 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; > o 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. So, to make my point more accurate, I see the evolution as: - all possible discourse structures "hard coded" into a database schema: legacy systems - all possible discourse structures locally expressed as a set of archetypes that are flexibly expandable: ENV-13606, openEHR - discourse simply limited in complexity by what can be expressed using the current state of ontology and the grammar > I mostly agree here, with one major exception: entering a diagnosis. > In that case, you do want subsets that are meaningful to your work > context. If it is paediatric oncology, you may have a form with a > field that can only be some kind of cancer or related Dx that that > department deals with - then you want reference terminology terms in a > subset that cuts out everything else. You also want your subset to be > structured, i.e. with the IS-A links intact, so that you can navigate > it to choose. Agreed ; subset can be useful for user interface purposes. But it remains a design purpose ; since, for example, the oncologist diagnose becomes a health problem that all other patient's team members have to cope with afterward. The "good all" SOAP is dead ; nowadays, the encounter stream is switching to (AP)SO(A'P'): people now come with an existing set of Assessments and Procedures, not "just" with "Subjective" issues. Philippe
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
