Hi all, In my opinion there are several types of ‘patterns’:
- Specific Local Templates/patterns used in a defined community for specific purposes - Specific Clinical Models/patterns for things like: the documentation of lab-test forms/panels, collections of meta-data for documentation of specific observations/test for abdominal complaints, etc. - Generic Clinical Patterns for things like: any lab panel, address, any device meta-dataetc. - Basic Patterns for things like: any observation, any evaluation, any order, any action, and any process, and their full epistemology, etc. - Atomic Patterns for those standardised constructs making use of Data Types and that are used to construct the patterns above such as: types of Result, types of temporal meta-data, etc. Is this classification of Patterns useful? My SIAMM is about the last three patterns and NOT about specific local templates and specific clinical models. Each consists of a limited and manageable set of patterns. Gerard Freriks +31 620347088 [email protected] Kattensingel 20 2801 CA Gouda the Netherlands > On 16 Feb 2018, at 00:20, Heather Leslie > <[email protected]> wrote: > > Hi Bert, > > Unfortunately pattern by itself won't result in good archetypes. Mind you, I > think the RM classes are brilliant and they have been the cornerstone for our > modelling experience. In fact I suspect that the lack of these classes is a > large part of the reason why other modelling paradigms such as CIMI have not > been able to progress as far and as fast they had wished. > > Clinical medicine is messy, by definition. Our experience is that we often > identify patterns and then we routinely come across as many examples that > break those patterns. The slow progress that results is the result of > refining those patterns to work as universally as possible in the clinical > scenarios and how to deal with apparently outlying data points. > > Then you need to consider clinical diversity that takes into account the > range of clinicians; differing professional requirements; differing > professional levels of details; needs of specialists vs generalists; clinical > context; institution and location; cultural differences; language > differences; personal health records; requirements for public health and > research.... I could go on. We need to identify what a concept is and the > appropriate scope; ensure minimising overlap as well as minimising gaps > between concetps. Good archetype design is just not as simple as what you > yearn for, despite how logical it seems to you. Our job would be much easier > if it were so. > > The only practical way forward is to start with good representations of > clinical data and then get broad review from ALL experts - to ensure that the > clinical data is fit for use as well as to ensure that they are implementable. > > As CKM Editors we try to get developers involved in reviews but they are > often in the minority - not because they are not invited but mostly because > they don't respond. We have a large list of technicians who were part of the > companies who funded the original openEHR sprint. Some responded immediately > with 'Accept' just to try to accelerate the archetype to get a published > state. Most ignore the invitations to participate. DIPS engineers have been > the most consistent participants and many modifications in archetypes arose > from their participation in reviews - this has reflected their requirements > for clinical content as well as their suggestions regarding the technical > implications of the archetype design. > > The adverse reaction archetype is a case in point - eventually we had 221 > reviews from 92 individuals in 16 countries PLUS an unknown number of > participants from HL7 Patient care and FHIR communities. Health > informaticians and IT experts comprised at least a third of reviewers - > engineer engagement to this level is not our usual experience and if my > memory is correct, most of the technical input came from the HL7 community, > not openEHR. > > Patterns have been identified and more are being refined... but don't expect > them for all concepts, there will always be lots of unique models. > Representing data that real clinicians can use will not be solved by patterns > alone. Engaging clinicians is critical. Ontologies are useful but don't > necessarily cater for the entire reality that is clinical practice. Engineer > review and input would be much appreciated if it were available. > > Why don't you agitate to get more engineers participating in the reviews? I > would gladly invite anyone who is willing to engage. Get them to adopt an > archetype today and join in the collective effort - the resulting archetypes > can only be better for everyone. > > Regards Heather > > -----Original Message----- > From: openEHR-technical [mailto:[email protected]] > On Behalf Of Bert Verhees > Sent: Friday, 16 February 2018 2:41 AM > To: For openEHR technical discussions <[email protected]> > Subject: Archetype pattern > > An interesting wiki from Heather Leslie > > https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns > > She concludes that pattern are necessary, I agree with that, and she also > concludes that clinicians are better modelers then technicians. > > Well, that depends, of course it is very important to have domain-knowledge > when modeling data, and clinicians have the best domain-knowledge. So from > that point of view, she is right. > > But what we have seen until now is that clinicians create archetypes with > unpredictable paths. And that is bad, because it makes it very difficult to > find data and it makes it easy to miss important data, because some data were > on a path where one did not expect them. > > OpenEhr works fine to find data which are on a known or predictable path, but > what if data are on an unknown path? > > Let me explain by comparing this to a classical relational > health-application. There are similarities. > > I have seen classical relational systems which experienced a wild-grow in > number of tables, I have seen once in a prestigious university-hospital where > they had a grown of 7000 tables in 20 years, more then one per day!! No one > understood the meaning of all the tables and data, no one dared to use data > he did not understand, many data were and still are redundant. Every new > development in the ICT starts with designing new tables. > > How can in such a situation a clinician research a persons medical record, > even with the help of the current technical staff, this is often impossible. > So, important information can get lost. Adding to this are software-updates > which often cause a clean-up, and that clean-up is also done by people who do > not always know what they clean up. People live long, and a medical problem > they had 30 years ago can be important to find to solve a current problem. So > old data, and understand them, and be able to find them, can be important. > > This can also happen with archetypes. Every new development in a application > can start with a new archetype, and at a moment there can be thousands. It is > impossible for a clinician to search all possible paths for medical > information, even with the help of the current technical staff this can be > impossible. > > The old data-hell situation will not be solved by OpenEhr if there is not > something behind it. And that something, that is: PATTERN > > It is not only a clinical thing to understand how pattern in paths are best > modeled, it is in fact also a technical thing. Clinical knowledge is not > stable, the thinking about clinical facts change all the time, what now is > important is tomorrow maybe not. So the pattern need a technical, > mathematical base, that, something like Codd-normalization, but of course > then applicable to archetypes. > > The Wiki from Heather Leslie is a good starting point for the design of > pattern and stop the proliferation of paths. > > I described an approach to solve this problem in a blog, one and a half year > ago. > > http://www.bertverhees.nl/openehr/medical-data-context/ > > I had some discussion about that, but many had problems against the use of > SNOMED in this context. So, maybe read it and forget SNOMED ad find something > else to structure the medical data. > > Bert > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
