Thanks, Ian, for your reply. I regret to say that I don't understand all that you write, but on the other hand, I am busy with this kind of questions a few years, so I do not expect them to be solved this weekend, and they also do not keep me from sleeping. It is not very important to me.
But I have one remark about your point 4, about SNOMED. Just some thinking. I think I understand the original purpose why it is designed. Encoding every clinical term and arranging them in graphs, and also offer translations. But they did not stop there, they defined a query language and a data storage language, both capable of not only handling terms, but also handling graph-based hierarchies and handling quantities. The purpose still can be to offer an international usable storage, but why then the query language? I think they want to offer a base for an EHR, but they don't say that loud, so they do not scare away vendors. But again, it does not keep me from my sleep, it is better for me to concentrate on what is feasible now and have fun with that. Best regards Bert Op 16 feb. 2018 14:55 schreef "Ian McNicoll" <[email protected]>: Hi Bert, A couple of quick observations... 1. You are correct that the flexibility of openEHR can lead to chaos. Or more accurately it simply reflects the existing chaos. The idea of having the CKM archetypes is to allow us to hold up a set of well-designed patterns for folks to use, accepting that this is a huge and varied problem space in which reduction of chaos will take a long time. Reducing the chaos is a cultural and organisational problem, not just about technology and semantics. 2. openEHR is not just about having interoperable, shared models. It is just as much about being able to quickly develop and adapt datasets, even if these use significant local content. 3. Deciding when to use 'standard' archetypes or when to roll your own is not easy. It requires decent knowledge of openEHR but much more importantly, detailed health informatics knowledge and expertise. This is still like climbing Mt. Evert - you are better off hiring some local Sherpa Guides, at least for the first few ascents. Ordinary clinicians do not have this knowledge - their knowledge of their domain is critical but often siloed. 4. The reason that SNOMED CT did not provide your solution is that it was never designed to do so. It provides an excellent means of sematically labelling the values of clinical questions "What was the name of a diagnosis, procedure or medication?" but cannot handle the complexity of how and where that question was asked - this is the role of the structural information model repesenting documentaion of clinical care, not biological entities. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 <+44%207752%20097859> office +44 (0)1536 414994 <+44%201536%20414994> skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 16 February 2018 at 13:22, Thomas Beale <[email protected]> wrote: > > > On 16/02/2018 09:48, Bert Verhees wrote: > > On 16-02-18 12:41, Thomas Beale wrote: > > > > - Specific Local Templates/patterns used in a defined community for > specific purposes > > > specialisations of any archetype for local usage. > > I don think you should ever create an archetype in the idea that it is a > local archetype. I think you can never guarantee that. Archetypes are a > model of thinking, a semantic model, instead of a technical model, like > Codd-normalization. > So in an other situation there will also be the need to express the same > way of thinking in an archetype, but they will probably structure it > different. > That is something were we should find a way to avoid that. > > > the key word is 'specialisation'. In ADL, a specialised archetype is a > computable technical artefact, and creates data reliably queryable just > using the parent archetype. (Note that only ADL2 specifies this properly). > > The question of 'good' structuring is a separate one. > > > > - 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. > > > COMPOSITION archetypes, probably some SECTION archetypes > > Sections are, I think, a problem, they are part of the path, so they > change query-paths and can make data invisible, because maybe no one > thought of a section when searching in a database. > I don't know if AQL has a wild-card to pass sections without paying > attention to them. I think that is necessary. > > > AQL does have a 'wildcard' - it is the CONTAINS operator - it's the > equivalent of the '//' operator in Xquery and Xpath. That's why you can > query for an Observation path (say, to systolic BP) regardless of how many > layers of SECTIONs it might be under. > > - thomas > > -- > Thomas Beale > Principal, Ars Semantica <http://www.arssemantica.com> > Consultant, ABD Team, Intermountain Healthcare > <https://intermountainhealthcare.org/> > Management Board, Specifications Program Lead, openEHR Foundation > <http://www.openehr.org> > Chartered IT Professional Fellow, BCS, British Computer Society > <http://www.bcs.org/category/6044> > Health IT blog <http://wolandscat.net/> | Culture blog > <http://wolandsothercat.net/> > > _______________________________________________ > 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
