Just to note, we do not disagree here. My main point is that for someone to make use of all this "machinery" we are referring to here, they first have to be aware of it.
I am keeping an eye on this discussion with great interest. All the best Athanasios Anastasiou From: Bert Verhees [mailto:[email protected]] Sent: 16 February 2018 13:04 To: Anastasiou A. Cc: [email protected] Subject: Re: Archetype pattern Dear Athanasios, A pattern must be imposed so strongly to an archetype, that even a clinician cannot escape them. That is the idea. Conforming to SNOMED may not be the best idea, but it is not a bad idea. It is a restriction which impose connections and hierarchy and still allows a user needed level of granularity Bert On 16-02-18 10:24, Anastasiou A. wrote: Hello Bert and all Thank you for your reply, please see below: > every path unpredictable if there is no pattern used, so you can find many > examples of your own Alright, sounds like a pattern by itself :) I cannot say this brings an obvious example to mind. This unpredictability though might be due to another reason (please see below). > So clinicians and technicians create different archetypes, how about the > medical informatics specialists, how about other cultures, how about people > in between? > I am sure that every person creates different archetypes, especially when you > look at the small details which are so important when querying. > ... > A similar kind of semantic pattern is also in SNOMED but then tailored to the > clinical world. I think that this goes right to "the heart of the problem" and the keyword here is "Culture", or maybe even isolated cultures. Even people from the same discipline cannot get to communicate sometimes. SNOMED and openEHR were not developed together. When you develop a model you have an objective in mind. The model is built to be able to answer a specific question (or range of questions). SNOMED is built with a different set of specifications and its granularity does not have to conform to anything other than its specifications. So, you either try to make best use of both "tools" in isolation or, you stand back and think about integrating them (but again with a specific objective in mind). In either case, I think that anyone who wants to start working in this domain needs to have a basic understanding of a few things (e.g. What is this thing called a "Data Model", what does the process look like, what is object orientation, what is abstraction, what constitutes an entity, what constitutes an attribute, what constitutes a relationship, what types of relationships are there and what do they mean in context and many other "basics".) as well as other models they are going to have to work with. Otherwise, you get those "unpredictable results". My experience has been that before you get people "excited" and engaged with this type of work, they first have to understand what it is and what is the value it brings to THEIR work. Most of the times, if you mention "Data Modelling" to someone from a health related environment (whether research or clinical), they immediately think numerical models. Finite modelling, is not even on the map. Someone is more likely to have (simply) heard of the logistic equation as a model of growth rather than generalisation as a way of specialising an entity. And we are talking "simple marketing" here. Just to have heard the term, they don't have to know exactly what it is. So, for this environment, Patterns are Science Fiction. If someone doesn't get abstraction, they will not "arrive" at patterns. This creates a mismatch between the technical and clinical communities which can probably be lowered by educating each other. I am probably equally frustrated about all the different types of Blood Pressure as a clinician is with all the different types of data structures but both are necessary, we are not trying to waste each other's time. I too need to know what the domain looks like to understand the objectives that the models are trying to satisfy. I am not saying that the clinicians are "lacking", I am "lacking" too :D All the best Athanasios Anastasiou From: Bert Verhees [mailto:[email protected]] Sent: 15 February 2018 16:29 To: Anastasiou A. Subject: Re: Archetype pattern On 15-02-18 16:52, Anastasiou A. wrote: Hello Bert I think that this is an interesting topic from a number of aspects. Can I please ask what do you mean by "clinicians create archetypes with unpredictable paths"? Can you provide one or two examples? Hi Athanasios, in fact is every path unpredictable if there is no pattern used, so you can find many examples of your own. I think the EHR-classes in the RM is too coarse grained to guarantee predictable pattern. We can also see that in the WIKI from Heather Leslie. I quote: "It has been observed on many occasions that even with identical clinical requirements, a clinical modeller and a technical modeller will build quite different archetypes. Which archetype best represents the data recording requirements? In most cases it will be the clinical modeller's attempt which is more useful, although technical input will be required to ensure it will be implementable." So clinicians and technicians create different archetypes, how about the medical informatics specialists, how about other cultures, how about people in between? I am sure that every person creates different archetypes, especially when you look at the small details which are so important when querying. Although I don't know the book of David Hay, the summary promises pattern I can agree with. A similar kind of semantic pattern is also in SNOMED but then tailored to the clinical world. That is why I came to SNOMED in my blog. The idea that the automatic creation of pattern is interesting, but as we see now, it does not work, there must be some overlaying idea. And that is hard to create for the clinical world without mimicking an already existing idea. Bert Also about the "something, that is: PATTERN", David Hay has written an excellent book "Data Model Patterns: Conventions of Thought", which although old (by now), is very well structured. A partial listing of its table of contents so that you get what I am trying to say here: The enterprise and its world Things of the enterprise Procedures and Activities Contracts Accounting The Laboratory Material Requirements and Planning Process Manufacturing Documents The "The enterprise and its world" section outlines basically every "system user" database, I dare say, ever. Are you thinking about taking a look at the healthcare environment and then coming up with openEHR patterns that can commonly address each? I think that this could be done even automatically, given the existence of enough archetypes / templates and the fact that they are machine readable with enough semantics to infer commonalities and structure. All the best Athanasios Anastasiou -----Original Message----- From: openEHR-technical [mailto:[email protected]] On Behalf Of Bert Verhees Sent: 15 February 2018 15:41 To: For openEHR technical discussions 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
