# Terminology bindings ... again **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2017-07-17 14:19 UTC **Views:** 8 **Replies:** 171 **URL:** https://discourse.openehr.org/t/terminology-bindings-again/15500 --- ## Post #1 by @system Recently we discussed terminology bindings. We probably still have not got them right, but we don't have a model of what we think they should be. I posted a quick idea of a possible more structured version: ``` term_bindings = < ["snomed_ct"] = < ["/data[id3]/events[id4]/data[id2]/items[id26]"] = (SIMPLE_BINDING) < target = <[http://snomedct.info/id/169895004](http://snomedct.info/id/169895004)> -- Apgar score at 1 minute notes = <"some notes"> min_version = <"2017-02-01"> etc = <"etc"> > ["id26"] = (CONSTRAINT_BINDING) < target = <"71388002 |Procedure| : 405815000 |Procedure device| = 122456005 |Laser device| , 260686004 |Method| = 129304002 |Excision - action| ,405813007 |Procedure site - direct| = 1549700l6 |Ovarian structure|"> min_version = <"2017-04-01"> notes = <"some notes"> etc = <"etc"> > > > ``` I noted that the right hand side of a binding can be a few different things, each of which would be accompanied by various meta-data, including: - a single concept code - a single code or other id referring to an external value set in an external terminology (in SNOMED it is a SNOMED code; for e.g. ICD10, there is no standard that I know of) - a composition expression that refers to a more refined concept - possible a constraint expression that locally determines a value set intensionally, to be resolved by application to the Terminology service. I'd rather avoid the last, because of the brittleness of intensional ref-set query syntax expressions. In any case, we need a better idea of what meta-data are needed. E.g.: - something to do with (min) version of terminology required for the reference to be valid - something to do with purpose? - other notes - a tagged list of basic types? I would like to get a better idea of the requirements. - thomas --- ## Post #2 by @system When you add the descriptions in SNOMED, language of the SNOMED\-database would be important, version is already there, I would say "version" instead of min\_version, it makes it more generic usable\. Bert --- ## Post #3 by @Koray_Atalag Hi Tom, I think min_version can be problematic as certain terms can be deprecated in future versions and then this naming could be misleading. That said for SNOMED it’ll still be present in future releases just marked as inactive. For other terminologies this cannot be guaranteed. BTW SNOMED uses term Effective Time --- ## Post #4 by @system Now that I have more experience with SNOMED expressions, I like the idea of doing the binding with an expression, also I think an expression includes the single code binding, if that is correct there is no need of defining a different notation for single code binding, just use a simple expression formed by one specific concept code. Also the expression being something processable and very versatile, we can express complex concepts with a few codes, which will help on adding knowledge to the archetype and serve to a better and simpler CDS. About the metadata, there should be expressed against which SNOMED release this expression was created. We can't be sure only with min version. I should be responsibility of the user to check if the expression works on a different version/release of SNOMED. Another metadata is if the version is a local extension, some countries have their own extensions. I don't know if we need to support other terminologies (technically) and if doing that is useful (strategically). Terminology services can do SNOMED to ICD, and ICD is not clinical relevant. LOINC is useful, but there is a SNOMED-LOINC collaboration, so we might expect an official mapping in the future ([https://loinc.org/collaboration/snomed-international/](https://loinc.org/collaboration/snomed-international/)). IMO we should focus on SNOMED. --- ## Post #5 by @mikael Hi, Yes, it is correct that expressions include single code binding. Those kinds of bindings are just the simplest variants of expressions. :-) I think that in a few years’ time nearly all implementations of SNOMED CT not only implement the international version, but also one are a few international, national or local extensions, so this use case is probably the normal use case and not the exceptional use case. Regards Mikael (Among other things SNOMED CT Implementation Advisor) --- ## Post #6 by @system Thanks Mikael, that's what I suspected. I'm seeing a convergence in terms of clinical terminology towards SNOMED CT. --- ## Post #7 by @mikael Hi, I do that too. It seems like more and more people are moving away from the position that SNOMED CT is complex and expensive to a position that SNOMED CT is manageable and an affordable way of getting rid of local terminologies and add value. Regards Mikael --- ## Post #8 by @system CIMI made the decision to use LOINC for the ‘question' part of the statement. And SNOMED for the ‘answer’ part. Leading to: Question = Answer, or something coded in LOINC is something coded in SNOMED. Nodes in an archetype coded in LOINC and data coded in SNOMED. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #9 by @system The scope of LOINC is NOT the same as the scope of SNOMED\. Gerard Freriks \+31 620347088   gfrer@luna\.nl Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #10 by @system Hi Gerard, are you able to provide more information on the reasoning that led to this decision? Maybe links to documents or any other insights? This would be quite interesting for our acitivities in Germany\. Best, --- ## Post #11 by @mikael Hi, It depends on what you mean by scope … There is an agreement between SNOMED International and Regenstrief Institute to not batch include concepts that directly match LOINC codes in SNOMED CT. However, in general SNOMED CT can have concepts that represent the same or similar ideas as LOINC codes. Regards Mikael --- ## Post #12 by @yampeku Without knowing the internal decision process, I would say that has something to do with the fact that HL7 guys in CIMI already used Loinc for describing document and section codes in CDA (not being uncommon that they just define new Loinc codes to new kinds of documents and sections). Same can be achieved with Snomed BTW, Spanish Snomed Extension includes codes for the Compositions, Sections and Entries defined in the national archetypes --- ## Post #13 by @yampeku Probably we should have a look at [https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard](https://confluence.ihtsdotools.org/display/SLPG/SNOMED+CT+URI+Standard) FHIR also uses the same base uri, but builds the URI using a custom syntax such as [http://snomed.info/sct?fhir_vs=isa/138875005](http://snomed.info/sct?fhir_vs=isa/138875005) But looking at the Snomed URI standard I assume they will just go with that in the future --- ## Post #14 by @michael.lawley FHIR also supports the expression language in the URL with, for example, http://[snomed.info/sct?fhir_vs=ecl](http://snomed.info/sct?fhir_vs=ecl)/<<123464:474748=<<84848484 But note that these URIs (the above and your isa/ one below) are defined by HL7 FHIR, not SNOMED International. Technically they identify FHIR ValueSets that expand to the set of codes you want. You could do a lot worse than adopting the FHIR ValueSet mechanism for binding. There are some excellent terminology servers out there (full disclosure, one of them, Ontoserver, is mine). Michael --- ## Post #15 by @yampeku Interesting to know, although I don't see that as an option in latest FHIR spec [https://www.hl7.org/fhir/snomedct.html#implicit](https://www.hl7.org/fhir/snomedct.html#implicit) --- ## Post #16 by @michael.lawley Yes, it wasn’t part of STU3 (aka 3.0.1) but is now in the R4 spec - see [http://build.fhir.org/snomedct.html#implicit](http://build.fhir.org/snomedct.html#implicit) Michael --- ## Post #17 by @Philippe_AMELINE Hi, There is currently some kind of interesting momentum against Snomed\. It can come from governments that refuse to pay for it \(current mood in France\), of from practitioners who, after having been asked by their gov to "sort out their Snomed subset" came to the conclusion that it doesn't exist\. <Troll>Some also predict that the most certain result of keeping up trying to build systems using such shitty fully endemic components is to have medical doctors disappear from missing the "information society" turn\.</Troll> Have some of you been aware of the Meriterm \(European\) project? Best, Philippe --- ## Post #18 by @mikael Hi, Maybe SNOMED International’s document ”Guidance on use of SNOMED CT and LOINC together”, [http://snomed.org/snomedloinc](http://snomed.org/snomedloinc) , could be of interest to some of you? Regrads Mikael --- ## Post #19 by @mikael Hi, Have anybody ever heard about a health\-it\-project that hadn't a smaller or larger group of sceptic people that try to build momentum against the project? :\-\) For SNOMED CT the trend at least seems to be that fewer and fewer people belongs to the sceptic group, and about half of the European Union member countries seems to be member in SNOMED International \(https://www.snomed.org/members). Will France as usual be the last country that adopt something that originate from Great Britain? :\-\)   Regards   Mikael \-\-\-\-\-Ursprungligt meddelande\-\-\-\-\- --- ## Post #20 by @system LOINC defines a way to asks clinical questions which coded answers may be represented by SNOMED\-CT\. LOINC has the worldwide integration and SNOMED\-CT has the detailed semantics, and is the leading global clinical terminology\. So the both are well matched partners, and as a consequence the owners of both coding systems, IHTSDO and the Regenstrief Institute agreed to a plan to integrate both coding systems to one coding system\. This plan defines a cooperative work, which started in 2014, and according to this plan, all LOINC\-concepts will have SNOMED\-CT concepts somewhere in 2018\. Bert --- ## Post #21 by @system That looks useful, but is it finished? The heading 5.1 has the text "Use of SNOMED CT and/or LOINC in" .... --- ## Post #22 by @mikael Hi, It has the status ”Release Documents” in the SNOMED International’s official document repository [https://www.snomed.org/doc](https://www.snomed.org/doc) , so I think that it is finished. However, I think that they had some problems with converting some of the documents from Word into Confluence, so the problem with the heading might relate to that? Regards Mikael --- ## Post #23 by @system Mikael, It might be worthwhile if Snomed International checks that, in case something more important is missing. I say that symathetically, I've had to address numerous such errors we had in our format changeover a couple of years ago, and there have been a couple that were important. I['m still finding the occasional one ... - thomas --- ## Post #24 by @mikael I have now submitted an error report. /Mikael --- ## Post #25 by @system Please never underestimate the Germans\.\.\. --- ## Post #26 by @system In Latin America is all the contrary, more countries are becoming SNOMED members and adopting SNOMED at the govt level. --- ## Post #27 by @Philippe_AMELINE Pablo, I wish you sincerely all the best. IMHO, the question is not really to enroll but to deliver... and considering the tremendous amount of money that was invested in HL7 and Snomed (both to elaborate and try to implement) and the actual societal return, there is such a discrepancy that the hypothesis that, due to missing the "information society" turn, health systems are entering terrible crisis times is to be considered seriously. In current "information society", you have two options when considering "health information systems": 1) You dedicate yourself to "medical information systems" instead, and can freely build for (inter-connected) silos, 2) You consider "health" in its genuine meaning and you have to realize that it is a complex domain fully opened to all other societal issues... hence should ban components that are endemic to medicine. Maybe (and I really mean it for Latin America), it should be high time to leapfrog, not to join the "dollars wasting club" ;-) Philippe --- ## Post #28 by @Philippe_AMELINE Interesting times indeed :\-\) --- ## Post #29 by @grahamegrieve hi Philippe No one who's actually tried to use Snomed CT could think that in it's current form it's the answer to everything. But anyone who's tried to work on real terminologies must also be aware of just how much work is involved in these things. So there's very much a glass half full/empty thing here. I understand not being thrilled with Snomed CT as a choice, but as the french government, for instance, actually confronted how much more it will cost to do something else? There's more than one kind of club to have that wastes money.... I've had a quick look at Meriterm... like all good rdf, it's not easily penetrable. But it looks like the authors are not informed about Cimino's desiderata... which brings us back to the wasting money thing... Grahame --- ## Post #30 by @Philippe_AMELINE Grahame, What you state is plainly valid, and the "it exists" argument is not to be considered lightly. However, as an engineer and a developer, I always try to measure the payload of a component when I consider using it. Where does it fit in the "pair of wings" to "dead horse" range? IMHO, HL7 and Snomed are not on the right side and adopting such components is like drilling in concrete: it never becomes easier. When it is about considering costs, I can argue that something that is "not well born" will cost considerably more than necessary during its entire life span. Any such technique is hard to build, hard to integrate and hard to maintain. As a guy that built and operate a self made 54000 atomic terms ontology, I can tell you that addressing this issue in the proper way can save considerable amount of money and (this is the most important part of it) free considerable energy that can be invested in reinventing health instead of plaguing practitioners with new burdens. My aim with this "troll" was just to tell that this kind of questioning exists and also that some "fools" are currently joining to create what they think could be "well born components". I have the feeling that it is high time we "leapfrog" in being able to "organize the journey" from the patient's "bio-psycho-social bubble" instead of getting dedicated to "siloed care center boxes"... and that HL7 and Snomed will keep their users in the wrong reference frame. Time will tell... but interesting times ahead! Philippe --- ## Post #31 by @system Hi Phillipe and Graham, This may help your discussion: [https://www.snomedinaction.org](https://www.snomedinaction.org) Unfortunately, it only gives a high level view of where SNOMED CT is used, for example, if you look at the map, it mentions, “Leeds Teaching Hospitals decided to embrace SNOMED CT in their Emergency Department”. However, I wonder, why the many other departments in that hospital are not using SNOMED CT too? I would really like to know where the true successful implementations of SNOMED CT are? Where I mean an implementation, I don’t mean for example a just a mapping from one terminology to another, like mapping READ codes to SNOMED CT, but also using the post coordination functionality of SNOMED, and making full use of the hierarchical structure of SNOMED CT. I am get the impression that SNOMED CT is hard to implement, and therefore wondered if we are at some kind of tipping point, like where HL7v3 was a few years ago, and some bright spark came along, and now we have FHIR that is gaining great traction in the health community due to the ease at which it can be implemented. [details="(attachments)"] ![image001.png|262x105](upload://p8MXrm58Y361SokWC6oKEqvthpW.png) [/details] --- ## Post #32 by @system I think you have just created the new technological utility scale! --- ## Post #33 by @grahamegrieve > > I am get the impression that SNOMED CT is hard to implement, and therefore > wondered if we are at some kind of tipping point, like where HL7v3 was a > few years ago, and some bright spark came along, and now we have FHIR that > is gaining great traction in the health community due to the ease at which > it can be implemented\. > this is very true, and I wish that someone would stick their neck out and do this at scale with a community behind them\. Many of the parameters for how it could be done are obvious around free and crowd\-support etc\. But the big problem is that there is no capacity for it to happen as a palace revolution; it must be a full civil war first\. Grahame --- ## Post #34 by @Philippe_AMELINE Hi John, The tipping point will only get reached when a sufficient amount of Snomed users will state that it is uselessly hard to implement\.\.\. and when someone will invent a smart way to simplify it\.\.\. not there yet ;\-\) But I really insist on the two orthogonal issues at stake: 1\) a component should ease your job and not kill your project \(detect "dead horses" early\), 2\) a component should not keep you stuck in the wrong \(ancient\) reference frame\. No need to say that FHIR is easier to put at work than the plain RIM, but it still keeps its community in a system where "boxes that saw the patient passing by can exchange information" when we should \(due to both the chronic turn and the information society era\) be dedicated to organize multidisciplinary teamwork around patients\. Best, Philippe --- ## Post #35 by @system Hi, IMO having s national terminology server like we have in Uruguay, is a first step of delivering. jus imagine standardizing every diagnosis, every procedure and every drug around the country? I can only see benefits for clinical environments and public health, they will have data to actually see what's happening in a complex system. also this is part of a state strategy for health accessibility. BTW, we don't have tons of money, so even if some tactical areas fail, is the investment of learning. But we are learning from institutions that already did this and using their experience, this not an isolated journey reinventing the wheel. There are 3 questions to make when your are starting: 1. Is there any use of SNOMED in my ehealth strategy? 2. Is there an alternative? 3. What's the cost of SNOMED vs. the alternative? I'm an engineer and just recently I was understood the real value of SNOMED sheet using it for data querying. Without getting your hand dirty a little bit is difficult to know for sure what are the pros and cons. Obviously this is not a panacea and needs a lot of work to implement and maintain. ROI is long term as in everything in ehealth (like implementing openEHR!) best, Pablo --- ## Post #36 by @system The killer move would be to do something I advocated for years unsuccessfully: **separate SNOMED technology from content** and allow them to be independently licensable and used. Here, technology means representation (RF2 for example), open source programming libraries for working with ref-sets, specs and implems for e..g the constraint language, URIs and so on. It should be possible for a country (the one I am most familiar with w.r.t. to terminology today is Brazil) to create an empty 'SNOMED container' of its own, and put its existing terminologies in there - typically procedure lists, drug codes, lab codes, devices & prosthesis codes, packages (chargeable coarse-grained packages like childbirth that you get on a health plan) and so on. There are usually < 20k or even 10k such codes for most countries (UK and US would an exception), not counting lab analyte codes (but even there, 2000 or so codes would take care of most results). But the common situation is that nearly every country has its own version of these things, and they are far smaller than SNOMED. Now, SNOMED's version of things is usually better for *some* of that content, but in some cases, *it is missing concepts*. The ability to easily create an empty SNOMED repo, fill it with national vocabularies, have it automatically generate non-clashing (i.e. with other countries, or the core) concept codes and mappings, and then serve it from a standard CTS2 (or other decent standard) terminology service would have revolutionised things in my view. This pathway has not been obviously available however, and has been a real blockage. The error was not understanding that the starting point for most countries isn't the international core, it's their own vocabularies. The second killer feature would have been to **make creating and managing ref-sets for data/form fields much easier**, based on a subsetting language that can be applied to the core, and tools that implement that. Ways are needed to make the local / legacy vocabularies that have been imported, to look like a regular ref-set. The third killer feature would have been to **make translation tools work** on the basis of legacy vocabulary and new ref-sets, not on the basis of the huge (but mostly unused) international core. I think IHTSDO's / SNOMED International's emphasis has historically been on curating the core content, and making/buying tools to do that (the IHTSDO workbench, a tool that comes with its own PhD course), rather than promulgating SNOMED technology and tooling to enable the mess of real world content in each country to be rehoused in a standard way, and incrementally joined up by mapping or other means to the core. I think the latter would have been more helpful. There is additionally an elephant in the room: **IHTSDO (now SNOMED International) has been tied to a single terminology - SNOMED CT**, but it would have been better to have had a terminology standards org that was independent of any particular terminology, and worked to create a truly terminology-independent technology ecosystem, along with technical means of connecting terminologies to each other, without particularly favouring any one of them. It's just a fact that the world has LOINC, ICDx, ICPC, ICF and hundreds of other terminologies that are not going anywhere. What would be useful would be to: - classify them according to meta-model type - e.g. multi-hierarchy (Snomed); single hierarchy (ICDx, ICPC, ... ); multi-axial (LOINC); units (UCUM, ...), etc - build / integrate technology for each major category - I would guess < 10 - help the owning orgs slowly migrate their terminologies to the appropriate representation and tools - embark on an exercise to graft in appropriate upper level ontology/ies, i.e. BFO2, RO, and related ontologies (this is where the <10 comes from by the way) - specify standards for URIs, querying, ref-sets that *work across all terminologies*, not just SNOMED CT A further program would look at integrating units (but not by the current method of importing to SNOMED, which is a complete error because of the different meta-models), drugs and substances (same story), lab result normal and other range data, and so on. None of this can be done without properly studying and developing the underlying ontologies, which are generally small, but subtle. I'll stop there for now. I suspect I have kicked the hornet's nest, but since Grahame kicked it first, and I can run faster than him, I feel oddly safe. Probably an illusion. - thomas --- ## Post #37 by @Philippe_AMELINE Thomas, Since, in that domain (terminologies, classification, ontologies...), it is not that easy to understand someone else's explanation without a sketching tool available, do you think I betray your thoughts if I sum it up as "Snomed should not be licensed as a "one size fits all" package but should be mainly usable as a set of tools and services in support of localized adaptations by national organizations"? It is certainly a good thing to be discussed in order to have Meriterm fill the gap. Besides, as you probably remember, the main reason I don't like Snomed is because it is structured like a coding system and not a "narration ontology". As an example, I would say that a narration ontology should contain atomic concepts, like "fracture", "location", "right ankle", but should let "fracture of the right ankle" be built as a description structure (say a small tree that express that the fracture is located at the right ankle). Snomed inherited the incorporation of meta-concepts from its history as a coding system (the kind of component that is to be used in systems where information are stored in simple value-pair slots that don't allow for elaborated description structures), as would be the vocabulary of a massively agglutinating language... Since our languages are not massively agglutinating ones (we built sentences), each group has to invest a very long time selecting the subset that fits their "local language" (for example the subset for GPs). I have always seen Snomed as a system that could be fit to "fill slots in forms" but not as a proper vocabulary to tell a patient's health story... in my own terms, it means that it is not the proper component for modern applications. Philippe --- ## Post #38 by @system Wasn't it Voltaire who said that the best is the enemy of the good? --- ## Post #39 by @Karsten_Hilbert > just imagine standardizing every diagnosis That typically leads to either bad statistics or disimproved care\. Karsten --- ## Post #40 by @system " but in some cases, *it is missing concepts*" Shouldn't we contribute? Is the same as openEHR, there are missing archetypes and we need the community, users, clinical modelers and engineers to contribute. LOINC also misses concepts, and when I asked them how can I contribute, they sent me the process and some templates for requesting a new concept to be added, pretty simple, formal and open! IMO we can't expect perfection, is a bad strategy and a move towards isolation. I think pragmatism is better and go with "this is the best we can expect for". We are the ones that should push towards the ideal, but as a guide not as a goal (getting a little philosophical here...). The same idea applies to tooling, anyone can create tools to manage the terminology better. In our own backyard we have tools that need improvement, but we accept them because there is no better alternative. --- ## Post #41 by @system > > just imagine standardizing every diagnosis > > That typically leads to either bad statistics or disimproved care\. > Can I ask why? --- ## Post #42 by @system > Thomas, > > Since, in that domain (terminologies, classification, ontologies...), it is not that easy to understand someone else's explanation without a sketching tool available, do you think I betray your thoughts if I sum it up as "Snomed should not be licensed as a "one size fits all" package but should be mainly usable as a set of tools and services in support of localized adaptations by national organizations"? well, it would be very helpful if anyone had the right to use 'SNOMED technology', to create their own terminology content (mainly by importing legacy vocabularies). Now, that's not ideal of course, but in reality, that is the starting point for nearly all countries - outside of the UK and some locations in the US, I don't know of a country that makes any extensive use of the international core (I am talking operational, not research use of course). That can change in time, but it's not how it is today. So the core SNOMED CT terminology needs to be licenced separately, as one thing that can co-exist in a SNOMED-technology container (now it starts being obvious why even the naming is problematic - it would be better to have an 'IHTSDO technology stack', which could accept SNOMED CT, ICDx, LOINC, UCUM, and anything else. With smart tricks to do with mapping and concept code generation to create partitions (which SNOMED codes already have - it's a good system), you can create order from the chaos. But the starting point is the chaos, not the order, as some people seem to think. > It is certainly a good thing to be discussed in order to have Meriterm fill the gap. > > Besides, as you probably remember, the main reason I don't like Snomed is because it is structured like a coding system and not a "narration ontology". > > As an example, I would say that a narration ontology should contain atomic concepts, like "fracture", "location", "right ankle", but should let "fracture of the right ankle" be built as a description structure (say a small tree that express that the fracture is located at the right ankle). Snomed inherited the incorporation of meta-concepts from its history as a coding system (the kind of component that is to be used in systems where information are stored in simple value-pair slots that don't allow for elaborated description structures), as would be the vocabulary of a massively agglutinating language... Since our languages are not massively agglutinating ones (we built sentences), each group has to invest a very long time selecting the subset that fits their "local language" (for example the subset for GPs). you can do the equivalent of agglutination these days - post-coordination - for which there is a grammar, but this brings its own challenges, and I have yet to see anything but the simplest post-coordinations (e.g. laterality) in real use (but to be fair, 5 or so simple post-coordinations would solve many, many real use case situations). Formally, the post-coordination idea is quite nice, but the real-world tension and main reason it may never work outside the basic cases (laterality etc) - actually there are two, as follows: - **data in a real data set is not all coded** - only some items are - these are mixed in with plain text, quantities, numbers, ordinals, dates, times, durations and various URI / multimedia like things - **data is conveniently collected and displayed in pieces** (i.e. 'shredded' form), not as a grammar string; these pieces may be mixed up with other non-coded data types. So the question is: if we have formal models of the structured form such as archetypes (maybe even FHIR profiles), why bother with the grammar strings? Inspection of any archetype, e.g. pregnancy summary will show this to be true, but in fact, you can just look at almost any screen form in almost any EMR product to see the same thing. The world just isn't all coded, often not even mainly coded. LOINC comes with a 6-axis meta-model, so it is an automatically aggluinating terminology as well. > I have always seen Snomed as a system that could be fit to "fill slots in forms" but not as a proper vocabulary to tell a patient's health story... in my own terms, it means that it is not the proper component for modern applications. well filling slots in forms is useful, especially for fields like 'diagnosis'... but it can only fill some slots - the coded/codable ones. Its real promise would be to support a) high-quality structured ref-sets (not flat vocabularies) and b) reasoning-based inferencing. I think these things will eventually come to pass, but they really should be done in a meta-model that makes them work for ICDx, LOINC, RxNorm, ICF, ICPC, and anything else, not just SNOMED CT. - thomas --- ## Post #43 by @yampeku I assume the reason is that asking clinicians to do coding without any help provides great variability and leads to coding errors. What Thomas said about presenting clinicians with addecuated subsets is key to avoid that. There are also mechanisms to check coding quality/errors, but usually need high domain & terminology knowledge (but creating systems that 'learn' from documentalists' knowledge is feasible) --- ## Post #44 by @system It is a very very very bad practice to ask clinicians to code! Standardizing diagnosis is a very different thing than asking clinicians to code, the first is the strategy, the second is one possible, and bad, implementation. There are 3 ways of "coding" that I know of: 1. primary coding (ask clinicians and other clinical users to code directly), 2. secondary coding (users record information, a team of specialists do the coding later), 3. assisted coding (software helps users to code, and there are many ways of doing this, from NLP to GUI wizards). But I'm not sure if Karsten was talking about this, let's wait :) --- ## Post #45 by @system I would put it the other way around: it can only be done with structured, controlled subsets, that retain hierarchy from the original terminology, remove unneeded codes, and do a few other tricks (adding non-coding 'group' concepts to help guide the user). This has to be done using smart tree controls, or anything that logically works as a tree-based choosing tool. No flat lists ;) - thomas --- ## Post #46 by @Philippe_AMELINE Bert, I get your point and I can perfectly understand that if Snomed can get used to do what you need done, you are plainly entitled to use it, even if "not perfect"\. But the issue could be stated differently: we are living a very specific moment since, at the same time, we become part of a genuine information society AND are engaged in a turn from acute to chronic care\. It means that we should all be trashing the "good old systems" and dedicate ourselves to building risk management systems that allow multidisciplinary teams to manage patients' health journeys over time\. Do you think that HL7 and Snomed are the proper components for this kind of innovation or that they are stuck in the ancient world? Do you think that using endemic technologies \(components that only exist in the medical domain\) can be of any use when it comes to health\.\.\. that's to say operating in person's "bio\-psycho\-social bubble", a place where education, employment, social issues are as important as medical information, and are all plain contributors to risk management? It is not about "good" versus "perfect", but about having a whole domain \(and its practitioners\) get stuck in a dead arm of the information society\. Best, Philippe --- ## Post #47 by @Karsten_Hilbert >>> just imagine standardizing every diagnosis >> >> That typically leads to either bad statistics or disimproved care\. > > Can I ask why? It of course depends on the suitability of the standardization process \(as in the applicability of a coding system to the domain \- medically and in purpose\)\. It is a problem of up\-/downcoding\. Standardizing typically needs classifying, the classes of which are either to fine\-grained \(doctors will pick a diagnoses which seems somewhat similar to what they think it might be, thereby falsifying the apparent accuracy of statistics based on the coding system\), or too coarse \(the picked diagnosis will be overly broad, thusly not reflecting reality "enough"\)\. I guess what I am saying is that one cannot expect to "just standardize" diagnoses and hope to meaningfully draw conclusions from that post hoc\. The standardization process needs to be tied to the question that is going to be asked of the standardized data\. Karsten --- ## Post #48 by @system There are many implementation solutions for primary, assisted and secondary coding. In assisted coding what you mention is one way. The best solution IMO that I saw implemented is free text search, matching to an interface terminology that internally maps to SNOMED. The interface terminology is controlled, and based on real terms gathered from users, so this methodology adapts to the location and usage. And what the wizard provides are alternative and suggested terms from the interface terminology. Everything is a tree here but no tree is shown to the end user, they just see free text suggestions for his/her input. A team of experts maintains the interface terminology and mappings to SNOMED. Mappings to other terminologies can be done, for instance with LOINC, or even ICD for statistics. This is the approach of a health provider in Argentina and is the way the national EHR strategy is being implemented in Uruguay. I think Chile will also follow those steps. --- ## Post #49 by @Philippe_AMELINE > - So the question is: if we have formal models of the structured form such as archetypes (maybe even FHIR profiles), why bother with the grammar strings? This is a pivotal question, but you may remember that I am used to putting it the other way around: if you can tell something using a vocabulary and a grammar, why bother having a formal model of structured forms? ;-) Such concept is described in a (already) 10 years old document ([http://philippe.ameline.free.fr/download/texts/LigneDeVieForPrevention.pdf](http://philippe.ameline.free.fr/download/texts/LigneDeVieForPrevention.pdf)). Philippe --- ## Post #50 by @Karsten_Hilbert There are 3 ways of "coding" that I know of: 1\. primary coding \(ask clinicians and other clinical users to code directly\), 2\. secondary coding \(users record information, a team of specialists do the coding later\), 3\. assisted coding \(software helps users to code, and there are many ways of doing this, from NLP to GUI wizards\)\. But I'm not sure if Karsten was talking about this, let's wait :\) I was mainly talking about the first, which is standard in German ambulatory care\. Karsten --- ## Post #51 by @system I got it, when I said standardizing diagnosis you might thought of your specific implementation / experience. But I was talking about the strategy, not the implementation. The strategy can be good and implementations fail miserably, is not a problem of the strategy :) As I said, primary coding is the worst way of implementing this, should not be recommended by any literature, and software vendors / organizations / govt imposing that should be held responsible for bad implementations. --- ## Post #52 by @system because the structures take care of all data points, not just coded ones. But your are rather special - they do the same thing, unlike an ordinary grammar, so it's not really an argument. In fact I would say that today we could derive a computable transformation from the trees <=> ADL2 archetypes. yes this is an excellent document - it even has the distinction between archetypes and (what we call) templates - the heading 'Federating heterogeneous information'. - thomas --- ## Post #53 by @system Philippe, I don't understand why you ask about HL7 and SNOMED in the same question, they have nothing in common and have a complete other purpose, nor are they depending on each other. I have no opinion about HL7, which version, which of the many substandards? It is a too large subject for a simple question. I do have opinions about SNOMED and I agree it does not offer a complete grammar like a natural language does, so to tell a story will be hard in SNOMED-terms. Do we need that? As far as I can see it can describe every medical condition, and if it cannot, there is room for several ways of extending it. I am sure we have not yet explored all that is possible with SNOMED. It is the technology for the coming decades. Allthough it is hard to get traditional software-vendors to implement SNOMED, it cost money, especially in traditional software architecture this is expensive, allthough there are reasonable roadmaps described. But that is okay, let them sleep. In OpenEhr it is an easier start to adapt it in archetypes. Further steps, I think, are a SNOMED query-service against a SNOMED terminology service, combining queries in archetype-repositories, and in data and this way find data in a intelligent way. There are usability paradigm shifts coming, clinical software being used by non-medical educated people, software for small purposes like apps, software being used by machines, flexibility is needed, and storing and querying and understanding clinical data for the very long term. As far as I can see we have the most technologies/tools to support these new purposes. Now we need the developers to use it. I see a rich future for software development. Best regards Bert --- ## Post #54 by @Philippe_AMELINE Bert, The main reason I mentioned the [Troll] hashtag was because I am really conscious that what I say is far from being mainstream. Hence I consider myself honored that some of the things I say can "rock the boat" a little bit and raise several questions. To tell it roughly, I consider that practitioners are missing two crucial turns: they are disconnected from the information society (for several reasons, medical confidentiality of course, but also because MD keep seeing information systems as "back office" components, also because they are often individualists very at ease in silos (practice and specialty)) and they are still fully organized for acute care (to put it simply, the medical system is fully upside down and the GP should become an orchestra conductor (what she often dreams she already is) but is stuck in the one-man band role). It could make sense to consider that the first lock (the dead branch of the information society flow) controls the second lock (missing the chronic care turn). This for many reasons: - chronic care means managing risk over a long span of time, - chronic care means genuine team work around a given person (not the fixed team "inside the same box" but the dynamic team of the contributors around a given individual). Translated in technological concepts, my own take is that is means switching: - from a record oriented vision to a project management vision (a record is the place where you optimize your own decision support ability through keeping the signal/noise ratio as high as possible ; a project manager is the place where people build/feed/contribute to a set of shared processes). - from a "care places centered" system (the patient moves from silo to silo, from record to record) to a system "federated by the person" environment. To put it simply, it is a genuine Copernican revolution where individual, instead of having siloed information stored about themselves in every "box" they cross, would own a system in support of their life long holistic vision and ask their services providers to contribute to it (means to join a team). The most important point to consider here is that, when considering the person's bubble, it is really mandatory to be plainly holistic, that's to say to consider health as a project among many other projects (education, employment, social issues, ordinary life projects, etc). It is a place where the term "patient" is prohibited. Finally, to answer your question about "HL7 and Snomed", I see these two components as symptoms of the "medical information plague": they are fully endemic, they are over-complex and prevent innovation (once you have invested 5 years understanding it, your startup is already dead). To make it short, as some claim that maize killed the Maya civilization because it demanded too much energy to grow, I claim that these systems are killing health systems because they keep them stuck in an ancient vision of health. Feel very free to consider this assertion as coming from the edge. Besides, even if I know HL7 and Snomed rather well, I perfectly may miss some points... however, I really hope that, contrary to what you wrote, they are not "the technology for the coming decades" ;-) Best, Philippe --- ## Post #55 by @Karsten_Hilbert > because MD > keep seeing information systems as "back office" components, also > because they are often individualists very at ease in silos \(practice > and specialty\)\) Practitioners need to be able to control their space for, at a minimum, liability concerns, which are brought about by the amount of implicit trust that is put forword towards them \(and then happily withdrawn at the slightest chance of litigation\)\. It is only natural that most MDs will resist "change for no good reason" and be \*very\* conservative\. > and they are still fully organized for acute care \(to > put it simply, the medical system is fully upside down and the GP should > become an orchestra conductor \(what she often dreams she already is\) but > is stuck in the one\-man band role\)\. \~70% of \_all\_ reasons for encounter are fully solvable inside the GP "domain"\. But that goes counter to what most patients want and believe they need\. Which is the biggest obstacle for primary care based healthcare\. At least in Germany\. "Chronic care" is nothing new, it has been the mainstay of General Practice for, what, centuries ? \(not that any noticeable number of IT solutions had fostered that approach so far\) > the dynamic team of the > contributors around a given individual\)\. That, of course, is a vision in need of better application\. > The most important point to consider here is that, when considering the > person's bubble, it is really mandatory to be plainly holistic, that's > to say to consider health as a project among many other projects > \(education, employment, social issues, ordinary life projects, etc\)\. It > is a place where the term "patient" is prohibited\. If we remove the term "patient" we will remove the very last trace of what it means to fall ill \- to endure, with the necessary patience\. Only "clients" remain, believing that healthcare can work like a business process, getting themselves repaired as needed\. While I fully support the process of informed shared decision making, and embrace it to the extent possible, 15 years of daily face\-to\-face encounters with literally many thousands of patients painfully teaches that the majority is not currently able to take matters into their own hands AND live with the consequences\. So, yes, let's build systems to be open and to enable caretakers and caregivers, but let's not expect those systems to be used that way by the great majority\. Karsten \(speaking from a German healthcare perspective only\) --- ## Post #56 by @Philippe_AMELINE > because the structures take care of all data points, not just coded ones. But your *fils guides* are rather special - they do the same thing, unlike an ordinary grammar, so it's not really an argument. In fact I would say that today we could derive a computable transformation from the trees <=> ADL2 archetypes. Yes... it just means adding the ADL concepts inside the ontology. > > Such concept is described in a (already) 10 years old document ([http://philippe.ameline.free.fr/download/texts/LigneDeVieForPrevention.pdf](http://philippe.ameline.free.fr/download/texts/LigneDeVieForPrevention.pdf)). > > yes this is an excellent document - it even has the distinction between archetypes and (what we call) templates - the heading 'Federating heterogeneous information'. I was fed at the proper source ;-) Philippe --- ## Post #57 by @system > Bert, > > The main reason I mentioned the [Troll] hashtag was because I am really conscious that what I say is far from being mainstream. Hence I consider myself honored that some of the things I say can "rock the boat" a little bit and raise several questions. > > To tell it roughly, I consider that practitioners are missing two crucial turns: they are disconnected from the information society (for several reasons, medical confidentiality of course, but also because MD keep seeing information systems as "back office" components, also because they are often individualists very at ease in silos (practice and specialty)) and they are still fully organized for acute care (to put it simply, the medical system is fully upside down and the GP should become an orchestra conductor (what she often dreams she already is) but is stuck in the one-man band role). that is exactly right, and I think there is still a revolution that must come to get the GP out of the solo 'cabinet mental' and indeed be some sort of a) team player at the practice level and b) orchestrator of care - in terms of managing referrals and the outcomes, post-care etc. But that is not our business, the healthcare profession needs to work this one out. > It could make sense to consider that the first lock (the dead branch of the information society flow) controls the second lock (missing the chronic care turn). This for many reasons: > - chronic care means managing risk over a long span of time, > - chronic care means genuine team work around a given person (not the fixed team "inside the same box" but the dynamic team of the contributors around a given individual). > > Translated in technological concepts, my own take is that is means switching: > - from a record oriented vision to a project management vision (a record is the place where you optimize your own decision support ability through keeping the signal/noise ratio as high as possible ; a project manager is the place where people build/feed/contribute to a set of shared processes). I don't quite agree here: because the 'record' (properly conceived) is the only thing that exists to chart the long-term situation of the patient, as doctors retire, nurses go on holidays, patients themselves move to new cities or countries. What can you trust to tell the story from your childhood asthma to your 2 pregnancies and births, to your hypertension and type 2 diabetes? Or even just your 10 year battle with one of the lesser cancers (very common) or lifelong management of a single disease. There is only the longitudinal health record. I agree though with the project management notion of course. Our [recent work on Task Planning ](https://www.openehr.org/releases/PROC/latest/docs/task_planning/task_planning.html)is trying to get up to this next level and join 'model' care pathways with real patient care plans and team-based care processes. It's going to take some years to get it really sorted out, but I think we are on the right path. I have seen the latest increment of the Activity-Based Design work at Intermountain Healthcare last week - we are converging. So when I say the 'EHR' I also include informational artefacts from long-running Planning and work processes, not just what we have today, which is observations, decisions, orders, and a record of actions done. > - from a "care places centered" system (the patient moves from silo to silo, from record to record) to a system "federated by the person" environment. To put it simply, it is a genuine Copernican revolution where individual, instead of having siloed information stored about themselves in every "box" they cross, would own a system in support of their life long holistic vision and ask their services providers to contribute to it (means to join a team). I think this revolution is starting. Now it is becoming clearer to the industry what has been obvious to us - that no single provider creates all the data that relate to the patient, so the long term solution is healthcare data and major services (workflow / process) must eventually be part of a back-end system that isn't owned by any product vendor or care delivery location, but instead managed on behalf of the patient by a trusted third party. A colleague many of you will know, Amnon Shvo, from Haifa, has been going on about the 'EHR Bank' for at least a decade now. I remember saying to him 10 or 12 years ago, this is the right idea, but the industry won't accept it. But now I think it's becoming clear that the industry is going to have to accept it, and those vendors who don't want to will be relegated to the outer reaches. > The most important point to consider here is that, when considering the person's bubble, it is really mandatory to be plainly holistic, that's to say to consider health as a project among many other projects (education, employment, social issues, ordinary life projects, etc). It is a place where the term "patient" is prohibited. I would say: the term 'patient' just gets demoted to meaning a client/supplier relationship that sporadically occurs between a person in a health system, and the health system's healthcare provider organisations. - thomas --- ## Post #58 by @system we have some concepts inside the archetypes themselves, and bindings to terminology. This is not as clean as your system, which has a very nice vocabulary included, whereas we chose (rightly or wrongly) to try to connect to Snomed, LOINC and all the other published terminologies out there. - thomas --- ## Post #59 by @Philippe_AMELINE Tom, this question is pivotal and deserves a dedicated conference ;-) When you ask "What can you trust to tell the story from your childhood asthma to your 2 pregnancies and births, to your hypertension and type 2 diabetes?" what can of "record" are you thinking about? Namely, in the practitioner reference frame, a record is the place where you mention the smallest quantity of information that are "food for thoughts". What I summed up as "optimizing the signal/noise ratio". Hence a GP record doesn't look like a cardiologist record and is much different from a nurse record. In many countries (France included), governments made the assumption that a "record of records" can be a "continuity of care record". I have always claimed that it is a terrible idea since a record of records is a place where the signal/noise ratio plummets. In France, the DMP (initially Personal Health Record, now Shared Health Record since the "P" switched from Personnel to Partagé) already failed several times since its announcement in 2004. A new attempt will start in October. From 10 years of interaction with practitioner about this "record of records", I noticed that what they expect from it (for those who expect something!) is always in the form "other will provide their information sorted as I expect it"... no need to say that it is not what the word "sharing" means ;-) Pretty everywhere, the answer relies on magical thinking, à la "automatic specialized views"... but the core issue is not addressed (and even not really understood). So far, we ends up with - many siloed specialized records that only consist in instant "viewpoint oriented" pictures (in the words of Koray "As a result the patient information is all over the place in various formats"), - the conclusion that pilling them up in the same "meta-record" will deliver a mess of heterogeneous pictures and not the movie that could tells your story. The real issue is twofold: - how to select information that "historically matter"? (you may remember the words of Ed Hammond in Berlin (Eurorec 2002) saying that "hospitals produce lots of information, a small part of it being of historical matter, while family doctors produce little information that are nearly 100% of historical matter"), - how to have them "tell your (health) story"? As an engineer, the proper attitude when a problem cannot be (smartly) solved in a given reference frame is to try to find a different reference frame where "things become simple(r)". My take is that what is very hardly achievable in the organizations' reference frame (typically Cartesian, with access rights as matrix, for example - what I call "the boxes") becomes much more "natural" when addressed in the person's reference frame (typically Polar with the team "around" and access rights as Roses - what I call "the bubble"). Since I have been exploring this "reference frame shift" for nearly twenty years (and will only launch the Ligne de vie this year), I can say that what is at stake in the bubble is actually not a record, but plainly a project manager (means the dual concept project + team) and that "your history" is by far more accurately told this way than it would be in any record. As a conclusion, I have to confess that such concepts are pretty new (and that the concept of shifting from a Cartesian to a Polar reference frame often leads to quickly loose the audience). When it comes to "project management vs record", even people that attended to numerous demonstrations of the Ligne de vie often use a "time line" in order to built a "time oriented view" of their record and claim they have a Ligne de vie. A project management system is way more than a diachronic view plugged on a document manager (or an information manager) but, as nailed by Ed Catmull at Pixar "Unfortunately people like to copy the wrong things"... and you probably know it firsthand since so many people keep thinking that Archetypes are GUI forms instead of flexible information schemas ;-) Philippe --- ## Post #60 by @Philippe_AMELINE > so the long term solution is healthcare data and major services > \(workflow / process\) must eventually be part of a back\-end system that > isn't owned by any product vendor or care delivery location, but > instead managed on behalf of the patient by a trusted third party\. Why do you believe that a third party is necessary/useful? In my opinion, your \(health\) information is yours and you can manage it yourself in a personal cloud or with a Ligne de vie\. > I would say: the term 'patient' just gets demoted to meaning a > client/supplier relationship that sporadically occurs between a person > in a health system, and the health system's healthcare provider > organisations\. OK\. And the pivotal term here is "sporadically"\. When switching from the \(health\) organization reference frame \(still cameras fixed on the walls\) to the person's reference frame \(head mounted real time camera\), you switch from a set of specialized sporadic encounters to a life long holistic management \(that includes sporadic health related encounters\)\. This is the reason why the term "patient" is not consistent here\. I always wonder what people have in mind when they write "patient centered system"\. Maybe a head mounted camera that just capture still images and operates inside care places only ;\-\) Maybe just words, but when properly analyzed, they tell a lot about cognitive dissonances\. Philippe --- ## Post #61 by @system well, IT-savvy people can do that. But realistically, everyone will pay a company to do that, and then you have to start thinking about what your contract with the company looks like. Do they respect GDPR? Do the implement privacy and security? Do they guarantee permanence? Performance? Availability? Record transfer to other countries, cloud storage etc? And so on. At the very least, the cloud-side data manger has to provide a running instance of openEHR, or Ligne-de-Vie or whatever. Will they keep it up to date? Whose implementation? Etc. Some of these requirements can be provided by generic cloud storage companies, but many will require a dedicated e-health data manager kind of organisation. Now, if this is commercial and profit-oriented, with no proper governance or regulation, there are serious dangers (data being onsold to pharma and insurance companies, data loss and so on). Then we have to consider the need for convenience. IN large socialised health systems - UK NHS, most EU countries, and any large US HMO (Kaiser Permanente etc) does it really make sense for each person to have to go shopping for a place to put your lifelong health record? So when you put all this together, a relatively small number of organisations that provide this service, in an ultra-reliable way will be needed. Doing it with cheap personal cloud will seem ok, until it is discovered that people are losing their passwords, forgot to pay the cloud provider bill, changed cloud provider but forgot to transfer their data and so on. Medical errors will result from that, so I don't see it as a viable path. theoretically that's true, but I don't think it's an important point because I think everyone knows that 'patient' stands for 'person, when obtaining healthcare'. I don't think the word 'patient' is going to disappear from the healthcare lexicon anytime soon... - thomas --- ## Post #62 by @mikael Hi, Of cause it is possible to create something that is easier to use. ICD-10 is a good example of something that have similarities with SNOMED CT and is both (for some use cases) easier to implement and more widespread. But I if you want something that is based on logic, because you want to use logic functions when you use the system, it comes with the complexity of logic. And it is not that complex to implement SNOMED CT. The problem is probably that we have fewer trained people in health informatics (including in for example SNOMED CT and openEHR) that in other informatics areas. Regards Mikael --- ## Post #63 by @system But ICD is a statistical not a clinical tool. --- ## Post #64 by @mikael Hi Tom, I don’t see that your “first killer move” by separating SNOMED CT technology from content would make that much sense. The specification and technology you are describing in quite many sentences in your e-mail seems to be quite much like the EN 14463 Classification Markup Language (ClaML) specification and the ecosystem around that specification. However, that specification and the associated tools are not that well known or well used, so why would it be a “first killer move” to separate SNOMED CT technology from content? If it was a killer move someone had already created EN 14463 Association and competed out SNOMED CT and SNOMED International … Instead it seems to be the collaboration and pooling of resources to create, extend and improve the common content in SNOMED CT that is possible to share among different countries that is the driving force for countries to join SNOMED International. The members would like to move away of the situation where each country spend large resources to create similar terminology products covering the same kind of clinical findings, anatomy, substances and much more. Instead they would like to focus on the things that are truly specific for each country. However, spending large resources to create similar things in each country doesn’t seem to be a problem in your argumentation, Tom? Your “second killer feature” seems to be the existing SNOMED CT Expression Constraint Language - Specification and Guide ([http://snomed.org/ecl](http://snomed.org/ecl)) and the supporting tooling, or do you mean something else? In your “third killer feature” I don’t really understand what you mean by that the translation tools should work on “the basis of legacy vocabulary”. But your second claim seems to be that it should be possible to use the tools to only translate parts of SNOMED CT and that is a function in all SNOMED CT translation tools I have heard of. I don’t think that anyone would say that IHTSDO Workbench was a success, but more as a result of a few quite wrecked IT-projects made under various external less than optimal circumstances. To judge an organization’s will from the functions of the final IHTSDO Workbench, which you seem to do, is therefore quite unfair. (The IHTSDO Workbench was replaced with better adapted software quite quickly, so I think nowadays quite few people in the SNOMED International community remember the IHTSDO Workbench .) Regards Mikael --- ## Post #65 by @mikael Hi Philippe, If you only would like to use some of the basic concepts as building blocks in post-coordinated expressions using for example the SNOMED CT Compositional Grammar Specification and Guide ([http://snomed.org/scg](http://snomed.org/scg)) and skip the more complex/combined concepts you are more than welcome to do so. It is very easy to automatically translate between the post-coordinated expressions and the more complex concepts if we need to transfer information between information systems that uses the two different approaches. One of the main reasons why the complex concepts are there is that is gives the possibility to easily associate the complex concepts with two or more terms that describe the concepts, which many implementers and users appreciate very much. Regards Mikael --- ## Post #66 by @mikael Hi Pablo, I totally agree with you. Regards Mikael --- ## Post #67 by @mikael Hi Philippe It seems like you are making a big deal of that SNOMED CT is an ancient product, but I would like to see your explicit arguments about that instead of only negative generalizations\. From my point of view it is quite modern with an OWL based ontology with additional features for terminology and versioning, which basically is what SNOMED CT are\.   Regards   Mikael --- ## Post #68 by @mikael Hi Pablo, Yes, of cause it is! My main point was that a statistical classification is a simpler product than a clinical ontology and it is therefore also easier to implement a statistical classification than a clinical ontology. But if your use case require a clinical ontology instead of a statistical classification, you need to accept that it is more difficult to implement a clinical ontology than a statistical classification. Regards Mikael --- ## Post #69 by @system Of course we should contribute missing concepts - that's a given (and the mechanisms for doing so are always improving), but read my post again, that is not really the main problem with where we are now - I'm talking about strategic directions. - thomas --- ## Post #70 by @system +1 but for the focus of this conversation I think we are trying to solve (find a relatively good enough solution) the clinical side and use detailed terminologies for that. --- ## Post #71 by @Philippe_AMELINE Hi Mikael, The question will always remain "what component do you need at a given technological moment?" If what you want to do is what has been done since 1980, that's to say fill forms inside a care place and exchange it with other care places, I guess that Snomed CT is the proper component\. Since it was born a coding system, you can create complicated meta\-concepts in a single code \(of course, it means you will have to find your own subset inside an always expanding universe, but ease comes with a price\) and it is very convenient to fill the good old set of attribute–value pairs\. On the contrary, if you estimate that a modern approach would be to tell and organize a patient's journey, you have to exhibit more modern structures because in order to "tell something", you need not only a terminology \(say a vocabulary\) but also a grammar\. A proper grammar \(at least the one I use\) can be a "dependency grammar" in the form of a graph or trees\. Now that you can tell elaborated things using a vocabulary \(the ontology\) and a grammar \(the graph of trees\), the "agglutinating" structure of Snomed rapidly sucks\. Because now that "fracture of the left ankle" can be expressed as the branch "fracture" "located at" "left ankle", there is no longer a need for the hundred of thousand \(and counting\) "codes" that where convenient for ancient systems but are now a genuine problem\. Do you imagine a natural language that would be so massively agglutinating that it would contain words like "FractureOfTheLeftAnkleThatWasTreatedButStillHurts"? I guess that, due to a terrible learning curve, the children would speak at six ;\-\) To sum it up, Snomed is probably convenient for application with a structure schema that can only handle a coding system \(hey, it also comes with a semantic network\) but is not fit as a formal language vocabulary\. Best, Philippe --- ## Post #72 by @system Hi everyone, After following this thread for a few days, I decided to jump in with my two cents because either things got too rethorical while looking for a state of art solution matching particular experiences or I'm missing the point more than I should. Historically, statistical classifications such as ICD10 and ICPC2 have been used in health [informatics] (even on handwritten forms, for ranking purposes). They are as easy to understand/use as their taxonomy allows them to be, but the added value is limited to such scope. They are also pretty close to the way generic binding is currently handled (matching and validating code/term pairs). SNOMED CT is not perfect and is not simple, but we cannot demand to oversimplify such a complex matter. It encompasses a lot of work to achieve a formal ontology that allows both people and machines to understand | fracture | : | finding site | = | ankle | in multiple idioms. I think it's quite effective as a "language" (yet not trivial, but again, to get the mass to accelerate, some force must be applied). In spite of the meaning on it's own, that expression can also be easily computed to a preecoordinated concept (if one exists and is required, e.g. | fracture of ankle |) or to a set of concepts that match the described meaning (even if you don't know all of them beforehand, but just some basic/critical defining attributes/relationships) so the professional can get filtered suggestions (supported by a capable health application/system, just like they already do with statistical classifciations/coding systems). It also allows you to query/retrieve the same data point despite being coded as (| fracture | : | finding site | = | ankle |) or | fracture of ankle |. Actually, it allows even more due to customization and localization. I too want to look at the the future and picture a state of art component and hopefully a [health] technological utopia, but a lot of work led us to what is currently available. Are we taking that to try/improve things and get somewhere? Are we holding back until something more mature, more usable, more future-alike comes up? Which path is more likely to bring us closer to the goal? Best regards, Ricardo Gonçalves. --- ## Post #73 by @Philippe_AMELINE Hi Ricardo, The question of settling in a local optimum or to go find a better place has probably been the most ancient question that sapiens has been facing ;-) Should we keep working hard in this place where harvesting is so hard, or should we try to climb this mountain and see if it is not easier on the other side? My opinion is that there is a good reason not to get stuck (trying hard forever) with Snomed. As you said, thinks started with classifications, then some people came up with coding systems and later on with ontology. The ability to tell things improved step by step and led to an evolution of information structures. Meanwhile, the whole society was transformed by ambient information systems to the point that we entered the post-industrial era, and, as you know it well, the chronic turn demands for a deep reinvention of the medical domain. My opinion is that you cannot cope with such challenges using a "language" that, due to its roots as a coding system, includes "words" like "Pathological fracture of ankle due to secondary osteoporosis" (concept 704293000). Time will tell if the settlers were more wise than the explorers... and we all have to keep in mind, as you nailed it, that we may have different goals. Best, Philippe --- ## Post #74 by @yampeku As Ricardo already said, "Pathological fracture of ankle due to secondary osteoporosis" is less a "word" and more a "phrase" that computers can easily understand, because it is equivalent to: 64572001 |Disease (disorder)| : 42752001 |Due to| = 703264005 |Secondary osteoporosis (disorder)| { 363698007 |Finding site| = 33696004 |Bone structure of ankle (body structure)|, 116676008 |Associated morphology| = 22640007 |Pathologic fracture (morphologic abnormality)| } I don't know what is 'ancient' about being able to ask things like "give me all the patients with a diagnosis of a disease due to osteoporosis" or "all patients with fractures in the lower body" --- ## Post #75 by @Karsten_Hilbert And it is also dangerous to your health if used for clinical care \(never mind that that's mandatory in Germany\): If I rule out AIDS in a patient I can \- in Germany \- attach to the EHR the relevant ICD\-10 appended with an "A" for "Ausschluß" \(as in "ruled out"\)\. When said patient travels to the United States many people will understandably ignore the "A" \(as it has no meaning to them and it does not belong to the core definition of ICD\-10\), et voila, we've got a manufactured HIV infection\. Even more dangerous situations could be construed\. Karsten --- ## Post #76 by @system Ad hoc negation, in German ;) But that's not really the fault of ICD10; it's a misuse of it. One might argue that it occurs because ICD10 doesn't provide a proper way of representing exclusions, only positive identifications. And that's an old, long debate... - thomas --- ## Post #77 by @Philippe_AMELINE Not certain to get your point here\. "Geometrically", a classification is a pavement of a domain \(for ICD10, the diseases\), each sector being delimited by inclusion and exclusion rules \(in the same way frontiers are defined for countries\)\. "Rag bags" \(of the kind "other X"\) are used to fill existing interstices\. Hence, every code is by construction exclusive from any other code\.\.\. and using a classification to "describe" can only come from confusing a point of the domain \(say "type 2 diabetes"\) with the delimited sector that comes with the same name \(say, depending on inclusion and exclusion criteria, all hyperglycemia that cannot be qualified as type 1 diabetes\)\. Of course, is it possible to forget all this and use a classification as a lexicon\.\.\. but that would be plainly evil ;\-\) Philippe --- ## Post #78 by @mikael Hi Philippe, I think that you have missed that SNOMED CT is created for multiple use cases\. Your use case that you describe as "a modern approach" is a good use case that I like\. In that use case SNOMED CT can be used in the way you describe using SNOMED CT's concepts a little higher up in the hierarchies together with SNOMED CT Compositional Grammar and SNOMED CT's concept model\. Another use case, that many implementers consider is important but you don't seem to care about, is the ability to handle legacy data to be able to keep a life\-long health record\. Most people alive today where born when simple health records that only used simple coding where in massive use\. \(When that era started and \(potentially\) ended is up to the reader to decide\.\.\.\) To cater for information that are more of legacy information, SNOMED CT also has concepts that can represent that kind of information\. But SNOMED CT also has a machinery to transform between the different representations\. Your example "fracture of the left ankle" is not possible to express using a single concept from SNOMED CT, but if it had been possible it had been possible to automatically transform that concept to the expression below, which seems like to be what you argue for in your "modern approach" use case\. 64572001 | Disease \(disorder\) | :    \{ 363698007 |Finding site| =          \{33696004 |Bone structure of ankle \(body structure\)| : 272741003 |Laterality| = 7771000 |Left \(qualifier value\)|\},       116676008 |Associated morphology| = 72704001 |Fracture \(morphologic abnormality\)|    \} I therefore find your arguments against SNOMED CT equally relevant as arguments of the type "SNOMED CT is useless, because it contains the concepts 285336007 | Background radiation \(physical force\) |, 60638008 | Planetary surface craft, device \(physical object\) | and 242250006 | Crash landing of spacecraft \(event\) | and I don't need that kind of concepts at my clinic\." because the simple solution is to not use what you don't need\.   Regards   Mikael \-\-\-\-\-Ursprungligt meddelande\-\-\-\-\- --- ## Post #79 by @system Nevertheless, I think it would have been good to move / remove the pre-coordinated codes out of SNOMED, and leave a pure post-coordinatable core, which would actually look a lot more like Philippe's (much smaller) terminology. This relates to the old debate on reference v interface terminology, and just throwing out precoord concepts is probably not right - they need to be in a completely different hierarchy. The post-coordination grammar in SCT is good, its theoretical challenge is the concept meta-model, i.e. what things like 'morphology', 'laterality' you can mention, and in what relationship. But this is hard for all of us, and requires some serious ontology work (Mikael and other experts know all about this of course). What I would say is this: in a similar way that I think SNOMED should have separated out 'SNOMED technology' (representation, APIs etc) from content, I think the concept meta-model should have been / could be made a separate artefact, maybe even an OBO ontology - at the moment it is too hidden inside the giant content artefact. If that were done, we could work more effectively on aligning with information / content models, whose attribute names should, generally speaking relate to (or be the same as) the meta-model ontology entities. If we pursued this line, the ontology would instantly be expanded by examination of archetypes, and conversely, many archetypes could be fixed where they contain errors or questionable attribute names. THis isn't to criticise experts or work done in SNOMED per se, but we should be perfectly happy to *critique* SNOMED, as long as that critique is collegial, and above all intelligent. (BTW maybe Philippe was not entirely diplomatic, but he did implement a very nice post-coordinating terminology and clinical noting system, so he knows a thing or two). So in that sense, I stand by my earlier comments that it would have helped (and still would help) if SNOMED International would consider some of my suggestions on separation of technology from content, separate the meta-model, and also a more serious effort to help connect terminology to information models / content models. We are slowly solving this on our side, but strategic cooperation would be better. One thing is clear: terminology is not a standalone proposition. - thomas --- ## Post #80 by @mikael Hi Tom, I believe that you proposal to ”move / remove the pre-coordinated codes out of SNOMED” is very appealing in theory. However it is very difficult in reality to agree on where the line between a suitable pre-coordinated concept and a concept that is better to post-coordinate or handle in another way are. The line between the two alternatives also seem to be use case dependent, which makes it even more difficult, and of cause also related to the boundary problem. However, until there is a strong agreement on where the line should be I continue to believe that it is better so include the concepts in the same pile and let each use case decide how to select the concepts they need and transform between the different representations. I like discussions about SNOMED CT and I don’t have any problems at all with critical comments as long as they are fair. Those kinds of criticism quite often makes me writing change requests. I am also happy to answer questions about SNOMED CT. However, I and several other people that are involved in the SNOMED CT community are quite tired of people that argue that SNOMED CT is bad based on incorrect facts and/or SNOMED CT is bad because it isn’t optimized for their narrow use case. Regards Mikael --- ## Post #81 by @system Hi Mikael, What efforts are being made to resolve the boundary problem? I applied to get involved with the SNOMED information modelling group but wasn’t successful, to try to engage on exactly that point. I’m not aware of any work going on. I’d be very pleased to get involved if I could. It’s a fiendish problem and we need cooperation and collaboration from both sides of the fence. Regards Heather --- ## Post #82 by @michael.lawley Hi Heather, In general, anyone is welcome to participate in the work; you don't need to be one of the small number of Advisory Group members. That helps with travel costs, but most of the real work is done on teleconferences, not so much at the face to face meetings. I would be very interested to hear people's articulations of where they think the boundary should be for this boundary line. I'd also be interested to understand better what people think the problem is with having "extra" / unnecessary pre-coordinated concepts; what advantage is to be gained from removing them, and what is the perceived scale of the problem. michael --- ## Post #83 by @system HI Michael, I have no idea what teleconferences are happening. I don’t know how to engage. It’s not easy from the outside! Heather --- ## Post #84 by @mikael Hi Heather, SNOMED International collaboration site is nowadays located at the address [https://confluence.ihtsdotools.org/](https://confluence.ihtsdotools.org/) . (It seems unfortunately that the link is more clicks away from the start page than before. :-( ) At that address, you can click “Spaces” in the upper left corner of the page and then “Space directory”. You will then find a long list with the collaboration space for different groups and other resources. To my knowledge there aren’t any group called exactly “information modelling group”, but there are several groups that work will modelling, so maybe the group has another name? If you only would like to read the material, I think that you don’t need any account on the site, but if you would like to participate a little closer, you can apply for an account on the Confluence site. Regards Mikael --- ## Post #85 by @system One simple rule solves the boundary problem\. In my words\. In principle models we use in the Semantic Stack are autonomous and orthogonal to each other\. Meaning that at precisely defines points the intersect, SNOMED is an ontology defining terms for concepts\. Concept can be primitive or compound\. Primitive concept examples are: Left and Right and Eye, White, Red and Blue\. All terms one expects in a dictionary\. Compound concepts are pre\-co\-ordinated concepts: Left Eye, Right Eye\. Eye White coloured Red, ‘Blue eye’\. All terms one expects in a pattern/standard phrase using words from a dictionary in a syntax\. The rule is: Pre\-coordination is done via Archetype/Patterns using Primitive concepts\. Pre\-coordination is not done via an ontology/terminology\. Off course clinicians on their screens or doing statistics need Compound concepts and therefor need pre\-coorodinated terms\. These pre\-coordinated terms must never be used to store, retrieve, interpret raw health data inside Health IT\-systems\. Gerard Freriks \+31 620347088   gfrer@luna\.nl Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #86 by @system I have made some attempts to study the problem in the past, not recently, so I don't know how much the content has changed in the last 5 years. Two points come to mind: 1. the problem of a profusion of pre-coordinated and post-coordinatable concepts during a **lexically-based choosing process** (which is often just on a subset). this can be simulated by the lexical search in any of the Snomed search engines, as shown in the screen shots below. Now, the returned list is just a bag of lexical matches, not a hierarchy. But - it is clear from just the size of the list that it would take time to even find the right one - usually there are several matches, e.g. 'blood pressure (obs entity)', 'systemic blood pressure', 'systolic blood pressure', 'sitting blood pressure', 'stable blood pressure' and many more. I would contend (and have for years) that things like 'sitting blood pressure', 'stable blood pressure', and 'blood pressure unrecordable' are just wrong as atomic concepts, each with a separate argument as to why. I won't go into any of them now. Let's assume instead that the lexical search was done on a subset, and that only observables and findings (why are there two?) show up, and that the user clicks through 'blood pressure (observable entity)', ignoring the 30 or more other concepts. Then the result is a part of the hierarchy, see the final screenshot. I would have a hard time building any ontology-based argument for even just this one sub-tree, which breaks basic terminology rules such as mutual exclusivity, collective exhaustiveness and so on. How would the user choose from this? If they are recording systolic systemic arterial BP, lying, do they choose 'systemic blood pressure', 'arterial blood pressure', 'systolic blood pressure', 'lying blood pressure', or something else. Most of these terms are pre-coordinated, and the problem would be solved by treating the various factors such as patient position, timing, mathematical function (instant, mean, etc), measurement datum type (systolic, pulse, MAP etc), subsystem (systemic, central venous etc) and so on as post-coordinatable elements that can be attached in specific ways according to the ontological description of measuring blood pressure on a body. This is what the blood pressure archetype does, and we might argue that since that is the model of capturing BP measurements (not an ontological description of course), it is the starting point, and in fact the user won't ever have to do the lexical choosing above. Now, to achieve the coding that some people say they want, the archetype authors would have the job of choosing the appropriate codes to bind to the elements of the archetype. In theory it would be possible to construct paths and/or expressions in the archetype and bind one of the concepts from the list below to each one. To do so we would need to add 40-50 bindings to that archetype. But why? To what end? I am unclear just who would ever use any of these terms. The terms that matter are: systemic, systolic/diastolic, terms for body location, terms for body position, terms for exertion, terms for mathematical function, and so on. These should all be available separately, and be usable in combination, preferably via information models like archetypes that put them together in the appropriate way to express BP measurement. Actually creating post-coordinated terms is not generally useful, beyond something like 'systemic arterial systolic BP', or just 'systolic BP' for short, because you are always going to treat things like exertion and position separately (which is why these are consider 'patient state' in openEHR), and you are usually going to ignore things like cuff size and measurement location (things considered as non-meaning modifying 'protocol' in openEHR). 2. similar **problems in the authoring phase**, i.e. addition of concepts to the terminology in the first place. If more or less any manner of pre-coordinated terms is allowed, with the precoordinations cross-cutting numerous ontological aspects (i.e. concept model attribute types), what rules can even be established as to whether the next proposed concept goes in or not? It is very easy to examine the BP hierarchy, and suggest dozens of new pre-coordinated terms that would fit perfectly alongside the arbitrary and incomprehensible set already there... (another 3x) I've picked just the most obvious possible example. We can go and look at 'substances' or 'reason for discharge' or hundreds of other things, and find similar problems. I don't mind that all these pre-coordinated concepts exist somewhere, but they should not be in the primary hierarchies, which really, in my view should look much more like an ontology, i.e. a description of reality which provides a model of what it is possible to say. If that were the case, the core would be much smaller, and the concept model much larger than it is today. - thomas --- ## Post #87 by @mikael Hi tom, I can agree with you that if SNOMED CT was created when all patients in the world already had all information in their health record recorded using cleverly built and structured information models (like archetypes, templates and similar), but that is not the case. Instead SNOMED CT also tries to help healthcare organizations to do something better also with their already recorded health record information, because that information to a large extent still belongs to living patients. It would be interesting to have your opinion about why it is a real problem with the “extra” pre-coordinated concepts in SNOMED CT in general and not only for the use case of creating archetypes or what would be nicest in theory. Regards Mikael [details="(attachments)"] ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) [/details] --- ## Post #88 by @system Hi Mikael, but that would appear to be an argument that since data in systems is dirty, badly designed, so SNOMED will reflect this by being badly designed! I don't agree with this at all. I think that the majority of SCT concepts which are arbitrary pre-coordinations (presumably due to the fact that someone saw them in real data, or knows they are in use in their hospital) constitute part of a (pretty messy, but practically useful) interface terminology. I remember myself and others arguing for this in the I&I standing committee in about 2011. That should be moved to a whole separate 'piece' of SNOMED - leaving a clean core that follows proper rules like mutual exclusion, collective exhaustiveness, coherence in distinction criteria down the IS-A tree and so on. That core would be small, manageable, and the concept model could then be worked on properly to build it out, providing a far richer basis for pre-coordination. This model would be something that certain archetype structures could be harmonised with. (Note though that many archetype structures don't have a biochemical or biophysical basis, but something like 'cultural models of recording'). The interface part could then start to be cleaned up and have some discipline of its own; it could be more effectively connected to tools that are actually used in real interfaces, like choosing widgets, or underlying logic for searching. These terms would all be mapped back to the core via post-coordinated expressions - the ultimate test of the approach. The main problem with the current state of affairs is simply that the vast majority of concepts creates incoherent cognitive noise when people are trying to: --- ## Post #89 by @siljelb I read Thomas’ reply with great interest, and I generally agree that with a well thought out information model, the very detailed precoordinated expressions are redundant. At the same time I understand Mikael’s point of view too. BUT, what I’m often met with is that because these precoordinated expressions exist (like for example “lying blood pressure” and “sitting blood pressure”), we should use them INSTEAD OF using our clever information models (that we do have) for recording new data. In my opinion this is wrong because it doesn’t take into account that healthcare is unpredictable, and this makes recording more difficult for the clinician. How many different variations would you have to select from? Take the made up example “sitting systolic blood pressure with a medium cuff on the left upper arm”; this will be a lot of possible permutations, especially if you take into account all the different permutations where one or more variable isn’t relevant. So while I don’t think the existence of these precoordinated terms in itself is a problem, it’s a potential problem that people get a bit overzealous with them. [details="(attachments)"] ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) [/details] --- ## Post #90 by @system Thomas, I agree with your opinions. **In summary:** **Model 1**- Ontological models define primitive concepts in Terminologies. Concepts that one can expect to see in a dictionary. **Model 2**- Archetypes define compound concepts using primitive concepts from terminologies. Archetypes are models that model a concept and its epistemology/context. Archetypes are agreed re-usable patterns and are like sentences constructed using syntax and words from a dictionary. This is the level where post-coordination takes place. **Model 3**- Templates are specific models composed of Archetypes defining the content of an interface (database, screen, clinical reasoner, etc) Templates are temporal, locally defined, chapters and paragraphs defining/documenting patient data obtained in the healthcare process. **Model 4**- For specific reasons users might want to see pre-coordinated terms on screens, or statistical reporting demand it. This means that raw data obtained using Model 3 can be converted to pre-coordinated terms from a Terminology. It is a User Interface issue. All models are orthogonal to each other and intersect at well defined places. Models can not be mixed and overlap. When they do, the problem is intractable. Next to these 4 models we need additional models: - Healthcare Process (ContSys) - Documentation process (Observation Process, Evaluation Process, Planning Process, Ordering process, Execution Process, Administrative processes) - … Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #91 by @system Maybe a match-table which matches pre coordinated expressions to all possible post coordinated expressions which have the same meaning will be necessary. How can you else find data-entries of a specific meaning by filtering on SNOMED? Bert [details="(attachments)"] ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) [/details] --- ## Post #92 by @yampeku IMO having both representations (pre and postcordinated) is not bad per se (in fact, knowing that they are equivalent is pretty good). The main problem is that technical people (including myself) shouldn't just dump the entire snomed ct into a data field and call it a day. To design better and useful systems you need a first "curation" phase where you define your relevant subsets that fit your system. The boundary problem is less of a problem if even if different terms were used when the record was created we can assess that they are in fact the same thing. I think people are a little unaware of this step and causes problems as the ones you and Thomas mentioned [details="(attachments)"] ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) [/details] --- ## Post #93 by @system Dear Silje, I think we agree. In my view it is not wise to use pre-coorinated codes that include contextual information. The reason is that the complete why, when, who and how result in too many permutations in order to be tractable. One must make the distinction between how data is expressed in a generic system interface connected to other services such as: database, clinical reasoner, import/export, etc. and between a specific interface that users connect with for data inspection, data entry, statistical data analysis. The former must NOT use pre-coordinated terms; the latter depending on user requirements will use pre-coordinated terms that can be constructed using the raw data in the generic system interface. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #94 by @system Diego, this is a wise thought\!\!\! It seems logical, but that is often in good ideas, they seem like: why did no one ever think about this\. No clinician handles the complete medical science/SNOMED repository in his profession\. Some even use a very small sub\-part, think about a dentist, a physiotherapist, a midwife For some is it also the case that not only the subjects are different, but also how deep the details must go\. For some professions it is not interesting to know if blood\-pressure was measured lying or sitting\. It looks like a good idea if the SNOMED repository will be split up for professions, maybe that needs to be done on national level, because the clinical profession\-structure can differ in countries\. The rest of the database should be there for second searches, for interpreting codes which come from other professions\. I hope someone will pick up this idea, because it is hardly to be done for individuals\. It needs to be done by national SNOMED maintenance teams\. Bert [details="(attachments)"] ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) [/details] --- ## Post #95 by @system Totally agreed, Silje. I think preordination for anatomical location is invaluable, but it’s the only use case that I have identified as one we absolutely can’t do without. But I would love the opportunity to really investigate this properly, and with others who understand SNOMED better than I. That will help with the boundary issue/semantically grey area. I’d prefer that we could use and reuse simpler, really high quality value sets from in multiple archetypes for different contexts eg a list of diagnoses in the Problem/diagnosis archetype as well as the Family History archetype. The archetype context is invaluable here. And the terminology community focussing on high value terms that would provide great impact. Regards Heather [details="(attachments)"] ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) [/details] --- ## Post #96 by @system Yes. The simple rules that solve the Boundary Problem need some exceptions. - anatomical structure - possibly some aspects of devices To investigate it properly is a possibility. The problem I see is the How question. For me there is only one solution and that is by analysing the problem and thinking about it. Ingredients that we could take in consideration are notions like: - Models in the Interoperability Stack must be autonomous and orthogonal - The Models we need in the Stack - Closed world assumption of Archetypes versus Open world assumption of the ontology behind SNOMED - Requirements for data exposed to users via statistics, screens, forms, and documents - Requirements for data stored, retrieved from databases - Requirements for data to be interpreted by clinical reasoners - Modelling methods Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #97 by @Jussara_Macedo_Rotz1 Heather, As you know Brazil has chosen to adopt SNOMED CT on a business case basis, trying to create clinical models that make the better use of structures and meaning. Therefore my research group has dedicated to study detailed clinical models and to deepen our knowledge of Snomed CT. We agree with GF that we have four ways to do it and that depends on the use cases. As Mikael said there’s no fix boundary between when you use pre or post coordinatinated expressions, although context to me naturally is easier to be represented in the structure ( templates). TO leverage our knowledge os Snomed CT everyone in our team has taken the Snomed CT Foundation Course. I think that many assumptions made here are explained there. BRAZIL has just joined Snomed CT International. We intend to propose a creation of a Worlgroup focussed on DCMs, for the openEHR community, as Thomas tried to do years ago. I will be In London for the next Business meeting, and gladly would have a meeting with others with the same objective. Jussara Rötzsch [details="(attachments)"] ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) [/details] --- ## Post #98 by @system Hi Jussara, Our approach to building archetypes at present are intended to represent the data as domain experts require it and making no assumptions about the terminology used, including use of pre/post coordination principles etc. The models have to allow end users to choose how they engage with terminology and ensure that it can be represented. As such the international archetypes are maybe overly comprehensive but we have to cater for those using heavily post coordinated SCT terms through to others using only local value sets. We have deliberately avoided having separate models that assume pre/post coordination as per CIMI equivalents because we view that as being ungovernable, and maintenance of semantic equivalence adds layers of complexity that will likely be impossible to maintain. However I do see a time when we need to publish associated documentation for models that propose ‘best practice’ use of SNOMED and maybe other terminologies, which will then support interoperability with the same value sets being used in the same way. It is that ‘best practice’ that I’d love to see start to evolve, which includes requirements gathering that results in parallel archetype AND value set definition/development for use cases and defined contexts. As clinical program co-lead, to the best of my knowledge, at the moment the formal part of openEHR has no direct influence on the SNOMED CT work/priority and that is frustrating. Collaborative work is where the magic will start to happen! Cheers Heather [details="(attachments)"] ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) [/details] --- ## Post #99 by @mikael Hi Bert, Most countries (or big organizations) that start to use SNOMED CT creates those kinds of subsets of SNOMED CT to make it more manageable. See for example NHS in England [https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40](https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40) . Regards Mikael [details="(attachments)"] ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) [/details] --- ## Post #100 by @system Thanks Mikael, very interesting. I will check if they do that in the Netherlands too. Bert [details="(attachments)"] ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) [/details] --- ## Post #101 by @mikael Hi, It is good that more countries that use openEHR also join SNOMED International. SNOMED International prioritize what their member countries calls them to prioritize, so that can increase the collaboration with openEHR. I will also be in London. Regards Mikael [details="(attachments)"] ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) [/details] --- ## Post #102 by @yampeku We recently added subset support to our Snomed Expression Language execution engine. We also added the Spanish MoH subsets as an example. They can be found in SNQuery under "See Subsets" option (only available with latest Spanish Edition version (20170430)). If NHS license allow this, probably could be interesting also to add their subsets [details="(attachments)"] ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) [/details] --- ## Post #103 by @Philippe_AMELINE Gerard, I like your rule (build a grammar that coordinates a vocabulary of "atomic concepts" instead of agglutinating meta-concepts in the vocabulary), but not your "left eye" example ;-) In my own "universe", the "left eye" is a true physical object (when "eye" is a concept). I would say the same thing about the "left common carotid artery" which is something you can actually "touch". Representing this concept as an artery which belongs to the carotid network on the left part of the body is not pre-coordination but rather what could be expressed by a semantic network. I agree with your "blue eye" example since it is simply "an eye which color is blue". To answer Mikael Nyström in the same message, I would be OK with his conclusion about "the simple solution is to not use what you don't need" if : - this task had not been unsuccessfully tested by Belgian GPs, who literally spent years trying to select a subset with no avail, - this "language" was not advertised as a communication system... which actually keeps you exposed to the full set unless everyone agrees to a common subset (using Tom's proposals and Gerard's rule, for example). Mikael is right when he says that it would be unfair to say that Snomed "is bad because it isn’t optimized for [one's] narrow use case"... unless there are lots of narrows use cases needed and unless one of these narrow use cases is key to the next mainstream use case. If innovators (typically the ones with weird use cases) consider Snomed as a millstone around their necks, it is actually an issue worth considering. As pointed before in this thread, this conversation is closely related to HL7 V3 and its RIM before it was "fhired". Best, Philippe --- ## Post #104 by @system Dear Philippe, On purpose I provided these examples. I agree that anatomic structures can be pre-coordinated. They are the exception to the rule. And perhaps in the domain of medical devices we could have exceptions. I see the analogies: - Ontology = Encyclopedia - Terminology = Dictionary - Archetype = Phrase Under specific circumstances we need aggregated concepts for use in the User screen, or during data entry, or data export (for statistics) SNOMED has the capability to create those complex codes for these very specific purposes. When we need to store and retrieve in a database or when a Clinical Reasoner processes data the Rules apply. Archetypes help define the datum but also its full context/epistomology so the data can be interpreted safely. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #105 by @Philippe_AMELINE Hi Gerard, I would rather see Archetypes as "discourse models" that form a mold for sentences or groups of sentences. The Phrase, in you enumeration, would rather be the instantiated information (stored in database). If you are curious about the way a tree of concept can be homogeneous to a sentence, Google "dependency grammar". This has been my main topic for 30 years in the report generation domain, and I can say that "simply ordering information on a form" and "trying to tell something using a structured vocabulary" are much different tasks. Typically, the first approach concentrates on the leaves while the other makes certain that branches give the proper meaning to the leaves. Best, Philippe --- ## Post #106 by @Seref Hi Philippe, See inline please > > > I see the analogies: > > - Ontology = Encyclopedia > > - Terminology = Dictionary > > - Archetype = Phrase > > Hi Gerard, > > I would rather see Archetypes as "discourse models" that form a mold for sentences or groups of sentences. The Phrase, in you enumeration, would rather be the instantiated information (stored in database). > > If you are curious about the way a tree of concept can be homogeneous to a sentence, Google "dependency grammar". > > This has been my main topic for 30 years in the report generation domain, and I can say that "simply ordering information on a form" and "trying to tell something using a structured vocabulary" are much different tasks. Typically, the first approach concentrates on the leaves while the other makes certain that branches give the proper meaning to the leaves. You nailed it here. My approach to openEhr based data warehouse design has been taking the leaf nodes of compositions as facts and paths to them as dimensions. The design of RM fits this view really well. It is a bit of an irony that strongest focus on openEhr adoption is on the data creation step, i.e. clinical care and its potential for secondary use rarely gets attention > Best, > > Philippe Y --- ## Post #107 by @system Philippe, I understand Archetypes are discourse models and form a sentences A collection of sentences (Entry Archetypes) form one story/session/Composition and define the content of a system-interface connected to a database, or screen, or other service like a messaging system. In my terms: A Template consists of Entry Archetypes and is the content of a system-interface. The Composition, Template, the system-interface are equivalent, but need the story, system-interface, Template must contain the data and its full context/ epistemology. The Archetypes in my thinking are standardised patterns with which to construct an Entry archetype. My hierargy becomes: Ontology - Encyclopedia Terminology - Dictionary Cluster Archetype - Standardised phrases/patterns Entry Archetype - Clinical sentence including epistemology/context (collection of patterns) Composition - Clinical story a Template with a collection of sentences/Entry archetypes Queries can be for leave nodes to find in a Patient Record the datum. In order to interpret the datum fully and safely one must inspect the whole associated Entry and/or Composition, (depending on specifics) Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #108 by @Philippe_AMELINE Gerard, I think that I get your point, though not being proficient enough in openEHR details. In my own universe, the basic information unit (as stored on disk) is a tree. Each node of this tree being an element from the ontology, the tree is fully autonomous and doesn't need external interpretation material. For example: Echocardiography Indication .... Findings Mitral valve Doppler Mitral leak .... Hence, the "basic query unit" is not for leave nodes, but rather for a path ; for example a query for "Echocardiography/Findings/Mitral valve" would return a sub-tree. But maybe you were saying this already. Best, Philippe --- ## Post #109 by @system Paths is also how openEHR querying works, and in pretty much the same way, except for the technical fact of using archetype codes rather than literal strings. - thomas --- ## Post #110 by @system Philippe, Fist of all: My ideas about modelling and using archetype, etc is not shared by OpenEhr I agree that the tree is important. My tree starts at Composition contaiining one of more Sections, and/or Entries. The Entry models a process of one of these: data observation, data evaluation, data planning, data ordering and data about events/actions. Each of these models deal with the full epistemology of that topic using standardised patterns/Clusters/Archetypes That what is observed is a Cluster archetype that models the datum plus its context/epistemology. What is important is the Modelling Style. In OpenEhr the nodes of the Archetype are changed. In my style, since I make use of predefined patterns I will not change the nodes but change the data in the Elements. In my style of modelling querying the leaves is that what is done. The unique path defines its meaning. In my way of modelling the collection of paths is a kind of ontology for data in healthcare records. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #111 by @Philippe_AMELINE I wrote literal strings for clarity ; actually it is a path of codes from the ontology\. To be accurate, if the ontology contains: GECHN1 Echocardiography \(means label 1 for concept GECHN ; it could exist a "true synonym" GECHN2 = Cardiac echography\) 0FIND1 Findings AMITV1 Mitral valve Then the query for "Echocardiography/Findings/Mitral valve" would be expressed as the path of concepts GECHN/0FIND/AMITV In openEHR, each Archetype is a "local semantic reference frame" while I work with a global one\. Philippe --- ## Post #112 by @system Gerard, I don't know that your modelling approach is that far from openEHR - you are from memory using CLUSTER in a way we are not, but I don't recall the details. In any case, is there a recent reference page on the web where a technical summary of your modelling style can be seen? thanks - thomas --- ## Post #113 by @system Dear Thomas, There are two possible Modelling styles: **- Archetype Leafnode style (Element-Data style)** Specialisation by changing the Element Data field Each archetype is a fixed, standardised, pattern, a mini-ontology The fixed path to the leaf-node defines the full meaning of that leaf-node **- Archetype Node style (Class-Attribute style)** Specialisation by changing node names in the archetype Each archetype makes use of non-standard patterns. The meaning is changed by changing node names. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #114 by @system Maybe we should relate this thinking to CEN13606 because that Reference Model allows more generic thinking\. \(Thinking this because GF was the convenor of this CEN standard\) But even then some more explanation would be welcome\. Bert --- ## Post #115 by @Philippe_AMELINE Diego, IMHO your contribution is orthogonal to what Thomas very accurately explained. Building subset is a symptom of the issue, not a solution. As I tried to explain in my initial post, we are currently facing two generation of technologies in medicine: - systems that record information as trees of atomic concepts, in the same way we are all exchanging in "globish" by inserting English concepts in a grammatical structure, - systems that still rely on a fixed database schema and usually have a "discourse system" limited to field/value pairs. 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. I have always understood openEHR as a link, a step, between the "good old way" (discourse range hard coded into a database schema) and a modern approach where you can really "tell a patient story" using a genuine (structured, processable) language. 15 years ago, Thomas and I spent hours discussing the opportunity for openEHR to include a reference ontology in its kernel ; this decision was not made for very good reasons, but I guess that it still remains a necessary evolution. Thomas very accurately explained why SNOMED is a deceptive candidate for such a reference ontology. And, unfortunately, it is deep rooted in its origins as a coding system. I can hear all the arguments about "legacy system" and even "legacy medicine" (the one still fully organized for siloed acute care at a time our society already entered the information age and suffers from chronic diseases). The question remains to guess if SNOMED is a component that lets you stuck in the past or helps you disrupt the legacy craps. Now, let's imagine a modern system that would allow you to "tell a patient medical story" from the various viewpoints of a multidisciplinary patient centered team. What would be the point about having "local vocabulary subsets"? Do you think that a GP shouldn't use the word "mitral leak" or any other "specialized" word in the medical vocabulary? My feeling is that selected subset is a solution when using SNOMED as a coding system. The subset being the global list of values that are legal for the fields in the existing schema, in the same way you will select subsets in a billing system. But when it comes to "telling a story" using a language, in my opinion subsets are a non-sense. We don't use "vocabulary subsets" when we talk, and each contributor in a patient's team would mechanically get exposed to a super-set; subset is actually only fit for silos... and at a time when medicine is already becoming a narrow silo in health, I really don't see it as a sound strategy. Best, Philippe [details="(attachments)"] ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) [/details] --- ## Post #116 by @system Both styles are possible with any RM. It is a choice. Most archetype modellers use the Class-Attribute / Archetype Node style. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #117 by @system Do you mean, inside OpenEhr by using the GenericEntry? Or are there other entry-types possible also? --- ## Post #118 by @system The specialisation in the OpenEHR RM itself is an anomaly, that can be circumvented. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #119 by @system In my opinion there is something essential missing, so far. What is missing is a collection of standard Cluster archetypes/Patterns that can be used to create any story, describing the observation/evaluation/planning/ordering and action processes including all the possible contexts. All the Archetype Patterns create one Documentation ontology. That Documentation ontology as grammar combined with a terminology like SNOMED and LOINC looks like Phillipe's system. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #120 by @system Okay. Do you have a technical description of what you are talking about? Thanks Bert --- ## Post #121 by @system Sorry, I am reading on my phone and it seems I missed an email. I read further day after tomorrow when I have a descent email client. Best regards Bert --- ## Post #122 by @system What do you expect from a technical description when it comes to styles? Under the hood one sees no striking differences. Archetype nodes are archetype nodes, leafnodes are leafnodes. What is different is the way one uses ADL to constrain the RM. Or do you mean to see the documentation Ontology? Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #123 by @system Style can be explained, please do. Documentation ontology can be useful. Please send that too. Thanks Bert --- ## Post #124 by @yampeku What I was referencing was one way in which current systems (or more exactly, their developers) could use codes already available in Snomed to create subsets of their forms, regardless their input forms have precoordinated options or use some kind of postcoordination mechanism. By defining these subsets, you are making this form comparable with other similar forms (that use other approaches to store similar information). It isn't about making doctors in the same organization being able to have *new* ways of encoding things, is about taking the forms they currently use and encode them in order to be comparable with data in other organizations (and in principle, they don't even need to be aware of this codification). With this, we can make data have a meaning outside their original systems. This is why I say that precoordination in snomed is a good thing. They are terms that have been put in a form somewhere, and having them as is, and at the same time having their undelying equivalent postcoordinated expression helps in softening the boundary problem IMHO. I'm always up to go into the future inventing new cool things, but at least in healthcare we are not allowed to lose data already available in current systems. [details="(attachments)"] ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) [/details] --- ## Post #125 by @Philippe_AMELINE Some people (count me in) strictly ban what you call precoordination (that I call "aglutinating language") because they believe that there is a nearly infinite set of them and such a system is born to "explode" as the frog that wanted to mimic the ox. To put it differently: you cannot express all possible discourses as predetermined concepts. Do I interpret your answer correctly if I say that you have an optimist vision in the form "there is a limited number of clinically sound precoordinations so that SNOMED expansion will reach an asymptote that keep being manageable"? [details="(attachments)"] ![image001.png|279x540](upload://1TjKm0XjTtvuwf4HjxMFlLQwFsI.png) ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) ![image003.png|334x478](upload://gJOtiV070PhGkQUr08ClHSrr1Lh.png) [/details] --- ## Post #126 by @yampeku What I say is that legacy applications or current systems usually offer limited options with the knowledge available when they were created. These options were decided back in the day and usually fit with precoordinated terms. And defining this subsets helps on going forward [details="(attachments)"] ![image002.png|270x448](upload://xkP77bOmEPl3ZK3R8GBb0zDAYnB.png) [/details] --- ## Post #127 by @system 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): see above - in the last 5+ years, much greater use has been made of smaller CLUSTER archetypes, which perform the function of the fils guides trees, but not as well, because the modellers don't use the LdV modelling discipline at that fine-grained level. We should do that in openEHR; it would require somewhat better features in some of the modelling tools. I actually think we should consider how to map the fils guides into OBSERVATION and CLUSTER archetypes in openEHR, and also export out archetypes into fils guides format. 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. But for a vast amount of other textual / ?coded? data, interface vocabularies, or just plain old text are what is needed. WHere interface terms are used, they should of course have a reference to a post-coordinated expression in an appropriate underlying terminology. -thomas --- ## Post #128 by @system Pre-coordinated SNOMED codes are like classifications, in that they are used at the user level, the User Interface, The Ontology behind SNOMED allows the pre-ordinated codes to be decomposed in its constituents. These decomposed primitive codes can be used in structures like archetypes at the proper places. In this way the pre-coorodinated SNOMED codes are iso-semantic. But we keep the semantic differences codes expressed using the SNOMED ontology and the Archetype and its codes. Ontologies have the Open World Assumption. A pre-corodinated code like: No-Cancer means never there was, is or will be cancer. Ontologies describe reality. In archetypes that use the Closed World Assumption Diagnosis=cancer, PresenceModifier=No means No Cancer found but perhaps they are. It just was not found. Presence of absence in a database are described. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #129 by @system In system interfaces we must not use pre-coordinted SNOMED terms. In User Interfaces we can to use them. In extremo one pre-co-ordinated code can describe the whole oeuvre of Shakespeare which makes sense in very specific circumstances for very specific purposes Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #130 by @system One thing I have noticed in recent systems in Brazil I looked at is that the codes are locally defined (e.g. SIGTAP, a Brazilian vocabulary for procedures) and almost all pre-coordinations of the most unscientific kind (with terms of the form 'cholecystectomy performed at private or military clinic'). Initially, it looks like a lost cause, but in fact SIGTAP only has (from memory) < 5000 terms, and there are ways of dealing with it. The Read codes in the UK were more scientific, but still contained many weird pre-coordinations (the famous example being 'hit by falling space junk while riding a bicycle'), but was also only O(10k) in size. So the 'size of the problem' is often inversely proportional to its awfulness, when talking about legacy terminology use, and this is what makes it possible to do something about it. The fact is, many old systems just couldn't express that many things. - thomas --- ## Post #131 by @system I'm unclear why you call this a use of the closed world assumption: the entire openEHR framework is for building HISs that enable reporting of reality as it is known to those working in it. So if they put 'No cancer' that just means that the current clinical thinking for some patient, *with respect to some investigation*, is that the original presenting problem is not cancer. That never means that the patient doesn't have cancer in their body somewhere, it just means that the currently investigated signs and symptoms don't relate to cancer, according to the the investigation carried out. Even that can be overturned later. But everyone assumes this - the EHR is always understood as an 'open world' system, where absence of X doesn't mean negation of X, it just means that no-one has investigated X. - thomas --- ## Post #132 by @system Thomas, OpenEHR and 13606 deal with Closed World Assumption systems. And therefor both mean in the case of 'No Cancer' that Cancer was not found in the database or that No Cancer was the documented result of an evaluation. Both statements are documented things in a Template that according to the author cancer is not found. But any time in the future it might. 'No Cancer' as pre-coordinated term in the case of SNOMED means that no cancer was, is, or will be present. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #133 by @system In a so-called closed-world system, everything that is stated constitutes the totality of the truths about the world it relates to. In particular, *absence* of an assertion (such as 'patient X has cancer') means negation, i.e. that patient X doesn't have cancer. But openEHR and 13606 don't work like that; absence of some particular statement about X just means nothing has been said about the relevant issue so far. - thomas --- ## Post #134 by @system I'm sorry but "...no cancer was, is, or will be present." doesn't even make sense. No system can record what can or can't happen in the future, and that concept is not part of any terminology AFAIK. --- ## Post #135 by @system I think, we happen to be in full agreement. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #136 by @system Pablo, It is as Thomas and I wrote. **Open world Assumption:** Ontologies declare absolute truths irrespective of geographical location and point in time. **Closed World Assumption**: Archetypes help express what an author wants to document. These are very subjective truths at a point in time. This subtle but important distinction is only one of the reasons to refrain from the use of pre-coorodinated SNOMED terms. Things like these matter when we start to reason about the documented patient data. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #137 by @Philippe_AMELINE Thomas, If I had to sum up the debate, I would write something like: - pre-coordination is necessary for legacy systems that stick to coding systems and didn't make the move to more elaborated representation of information, - pre-coordination's drawback is that expressing sentences as concepts will mechanically lead to an explosion of the list of concept unless the scope/audience remains small enough so that it ends up reaching an asymptote that can be dealt with, - considering SNOMED's ambitions (worldwide, large scope), we can reasonably doubt that such asymptote exists. Philippe --- ## Post #138 by @Philippe_AMELINE > 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): 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 --- ## Post #139 by @system > 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. > Wasn't that always the case? --- ## Post #140 by @Philippe_AMELINE We are currently switching from "mainly acute" to "mainly chronic" care. Reason why I claim that the "encounter information stream" must switch from SOAP to (AP)SA(A'P') In my understanding, the concept of episodes of care came long after Weed coined the SOAP approach; but I may be wrong. However, the main concept here is to consider an encounter as part of a global process and no longer as an isolated event. This is, unfortunately, still a disruptive concept ;-) Philippe --- ## Post #141 by @system 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 'terminology'. The fils guides on the other hand express natural language utterances, i.e. they are like a structural 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 --- ## Post #142 by @system 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. --- ## Post #143 by @system Sorry, this was a reply to Philippe on his message on 14:07 --- ## Post #144 by @Philippe_AMELINE Actually, I don't think that I use grammar in an unusual way. If I do it technically, lets assume for the sake of the discussion that I am really talking about a grammar, ie a set of rules that allows you to interpret an arrangement of concepts as a discourse. Typically, a dependency grammar is not just a tree representation, but a tree representation where you take as a rule that the sons of an element qualify this element. Since every natural language sentence can be represented as a dependency grammar tree and vice versa, it is possible to assert that a dependency grammar is a sufficient grammar. My point is that you have an ontology (say a terminology with terms grouped as concepts and concepts interrelated in a semantic network) and a true grammar, then there is no need for a "structural terminology"... one of the reason being that (part of) this terminology can find its place in the ontology. The first advantage is that practitioners can freely "tell whatever they want" in a structured way. For example using a tree interface with, for example, only the first elements already in place (say "encounter" as tree root and SOAP entries as sons). But it doesn't seem as the best interface for fully deterministic cases and archetypes (in their most basic meaning, ie flexible information schemas) are fit. Fil guides are used "in-between", as a way to help users fill trees with proposals of the kind "from the path you are currently located, you may benefit from this set of sons to carry your description one step further". I may elaborate on this. To sum it up, if you have a vocabulary and a grammar, you don't need anything more to tell things. In order to build systems that users can use, it is possible to use several techniques, such as "freely filling trees" (maybe guided by Fils guide) or using archetypes depending on the determinism level of what is to be told. Philippe --- ## Post #145 by @system 1- What stands AP)SA(A'P’) for? Here below some missing topics we need to have agreement about 2- Thinking about the health and care provission documentation process there are: - Observation process - Evaluation process (including, and restricted to, diagnosis, diff diagnosis, problem kist, episode list, etc - Planning process - Ordering process - Execution process of acts 3- We need to recognise that some data is de novo, other data is repeated after a querry 4- Systems need to be aware that some data is directly health care care related, other is administrativem process oriented 5- When that what is documented is used in shared working processes we need a common vocabulary: i.e. System of Concepts for Continuity of Care Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #146 by @system Yes, but the main topic here is the use of SNOMED inside openEHR, so there is no terminology world separated from the content modeling and data recording world. We will use SNOMED inside the openEHR context, so the SNOMED meaning will be constrained by the openEHR meaning when recording clinical information. We should be constraint to that context. --- ## Post #147 by @system you may want to have a look at the for this. - thomas --- ## Post #148 by @Philippe_AMELINE > 1- What stands AP)SA(A'P’) for? I guess that you know the SOAP as the 4 main "chapters" of a clinical encounter ([https://en.wikipedia.org/wiki/SOAP_note](https://en.wikipedia.org/wiki/SOAP_note)). From Lawrence Weed's concepts, a patient encounter should be recorded as a "grid" with problems as columns and SOAP elements as line. This concept is theoretically sound for acute care since it starts with patient's verbatim of the reasons for encounter (S standing for Subjective - which is truly dated!). In the current "state of the medical art", always more chronic care oriented, a patient often comes with an ongoing list of problems and treatments, hence (AP)SO... and leaves with the same or a different list of A and P, hence (AP)SO(A'P'). 14 years ago, I worked with a knowledge management research team on establishing both the theoretical aspect and the user interface of such concept, by the name "virtual staff". To make it short, imagine the Ligne de vie, with the vertical "now" separator... then spread this separator as a curtain in order to open the patient encounter as a cognitive map located between the past (AP) and the future (A'P'). > Here below some missing topics we need to have agreement about > > 2- Thinking about the health and care provission documentation process there are: > - Observation process > - Evaluation process (including, and restricted to, diagnosis, diff diagnosis, problem kist, episode list, etc > - Planning process > - Ordering process > - Execution process of acts I am currently writing a paper (in French) telling a story of "boxes" and "bubbles". Boxes are care places (say organizations at large) with roles within a domain. Bubbles are the patients (say persons at large) with a "polar reference frame vision" about "who is around and among them, who is close or not so close". In the usual system, only boxes operate an information system... and they are pretty bad when it comes to "continuity of X" (replace X with care, education, employment, etc). Now, let's suppose that the reference information system is in the bubble. And that service providers are just considered as contributors that can join the current team that surround the person. In the ongoing paper, I am trying to describe what happens when "a bubble steps through a box"... and it is an amazing model to make many things clear! > 3- We need to recognise that some data is de novo, other data is repeated after a querry > > 4- Systems need to be aware that some data is directly health care care related, other is administrativem process oriented > > 5- When that what is documented is used in shared working processes we need a common vocabulary: i.e. System of Concepts for Continuity of Care Thanks to François Mennerat, a glorious CISP Club founder, we have been aware of Consys for many years... but "so many years" is also the problem! Philippe --- ## Post #149 by @system Philippe. 1- documentation in health and care, as you wrote, can have two points of focus: - focus: the healthcare provider: as author documenting in his EHR about the patient what this HcP has done - focus the patient: as subject of care allowing other HcProviders as authors to document what has been done The problem is to have these two focus points not only to co-exist, but be integrated. My French is good enough to read 2 medical textbooks in French when I was training to become a GP. If possible share that article with me, I’m curious. 2-In my view ContSYS is one of the ingredients needed to integrate these two focus points. We need more than ContSys: - a model for the epistemology - archetypes designed using re-occuring standardised phrases - terminology providing primitive terms - a generic standardised solution for modifiers: (non-)presence, states, certainty - standardised services/interfaces for database, user screen/keyboard, messages, clinical reasoner - supporting terminology services (i.e converter into/from user friendly terms, …) - all based on orthogonal shared standardised models. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #150 by @system Is that so? There will be systems that allow pre-coordinated codes. There will be systems that use as many pre-coordinated codes. And several in between solutions. This means that reasoners will be used to create transformations. It is likely that ontological servoces will be used, And then we will have a potential problem. But perhaps solvable with the correct precautions. One being that ontological servoces are NOT used and that ad hoc rules do the transform. What possible solution is the canonical one? which is the ‘golden truth’. When we add to all this that only part of the epistemology can be pre-coordinated it means that part of the temporal aspects for instance can NOT be dealt with in SNOMED, then we have the situation that part of the epistemology is in SNOMED and part defined in the Archetype/Template. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #151 by @system I will get back to you after having read it. Do you deal with the cascade of Tasks and Subtasks as if it is a fractal? Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #152 by @system GF: "When we add to all this that only part of the epistemology can be pre-coordinated it means that part of the temporal aspects for instance can NOT be dealt with in SNOMED, then we have the situation that part of the epistemology is in SNOMED and part defined in the Archetype/Template." --- ## Post #153 by @system In addition to this, OpenEhr tends to the use of simple precoordinated concepts, that is because the archetypes explain the details. It is, for example, rare in OpenEhr to use the concept for "bloodpressure sitting". Normally one would create two leafnodes, one with the concept for "bloodpressure", the other for "sitting". This level of expressing detail in archetypes is historically grown in the years from before SNOMED, and it seems like a blessing now, because it makes the discussion about concepts with complex meaning a bit superfluous. Avoid complex meanings in leaf nodes and express complexity in archetype structure, and the number of different concepts to be used will be reduced and the chance of availability of needed concepts rises. The message is simple: don't allow items with complex meanings in leafnodes, but use archetypes to represent complexity. --- ## Post #154 by @system Please see below, --- ## Post #155 by @system Can we specific define in about ten words which problem is talked about in this discussion? Maybe we can then use that definition as a guideline to keep the discussion focussed. Best regards Bert Verhees --- ## Post #156 by @system see below Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands > > GF: "When we add to all this that only part of the epistemology can be pre-coordinated it means that part of the temporal aspects for instance can NOT be dealt with in SNOMED, then we have the situation that part of the epistemology is in SNOMED and part defined in the Archetype/Template." > --- > > Using SNOMED does not block using other terminologies or even local terminologies. 13606 and OpenEHR do not block anything. There are too many degrees of freedom. All creating problems interpreting the data fully and safely. > In OpenEhr is always a part of the epistemology in the context of the archetype, that is its power. Terminologies serve to undoubtable define the presented data-item or act as a data-item. This is also the case in CEN13606 In most systems the full epistemology is not recorded. It is there because of implicit or explicit agreements between users. There are NO agreed standardised archetypes/patterns we all use to define the meta-data in order to document the full eppistemology so data can be interpreted fully and safely. --- ## Post #157 by @system I agree > The message is simple: don't allow items with complex meanings in leafnodes, but use archetypes to represent complexity. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #158 by @system GF :"There are NO agreed standardised archetypes/patterns we all use to define the meta-data in order to document the full eppistemology > so data can be interpreted fully and safely. " So what do you suggest as a solution? --- ## Post #159 by @system Archetype modelling and the use of SNOMED pre- and/or post-coordination Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #160 by @system > Archetype modelling and the use of SNOMED pre- and/or post-coordination You too have a nice day --- ## Post #161 by @system It is Obvious: - We need to take the next step in Semantic Interoperability: Semantic interpretability. - And think about what is missing, so far - How to use codes from Terminologies and Classifications - How to deal with the full Context/Epistemology - How to deal with modifiers for presence/absence, certainty and other state info - What other models we need to deal with clinical, administration, and collaboration, processes In order to have systems that allow the full, safe, interpretation by humans, services, reasoners now and in the future. Systems with the minimal amount of implicit information needed to interpret safely and fully. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #162 by @system That is the problem. There is no focus. This discussion will not solve anything. --- ## Post #163 by @system Check the initial messages on the thread. Basically how to use SNOMED in openEHR, and in a specific area: data querying. AQL support for SNOMED codes and expressions was an initial part of the topic. We are trying to solve a basic problem: how to get data out the systems in a smart way. This is because archetypes are good but don't have context that terminologies have, and AQL is good but only queries what is defined by models. So we need something to query over terminologies in combination with querying over models. Reasoning, interpretation and modeling approaches are other orthogonal problems. This is a very specific problem for the openEHR specs and ITS, is not a general problem to solve. --- ## Post #164 by @system It is a generic problem that impacts OpenEHR also. Present systems need a lot of implicit human knowledge in order to interpret the data safely and fully. SNOMED pre-corodination is one way to make this implicit knowledge explicit. It possibly is a solution. My point is that it is not the best solution. Not only do we need to make more of the implicit knowledge explicit but use archetype structures/patterns to define the full context/epistemology in a Standardised, shared way. Existing systems use a myriad number of ways to store health and administrative data. This demands specific requirements to be met. Systems of the future have other additional requirements that impact archetype patterns and the standard way of using coding systems. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #165 by @system Some theory [along these lines](https://wolandscat.net/health-informatics/analytic-framework-for-health-information/) is needed... --- ## Post #166 by @system Thomas, I will have to digest it. I’ll be back. GF Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) Kattensingel 20 2801 CA Gouda the Netherlands --- ## Post #167 by @system Right - but the normal sense of 'grammar' is something that controls / validates sentences made up of words so at least they have acceptable structural forms, even if they say semantically nonsensical things. The fils guides 'grammar' is supplying both levels - correct form (by implication, due to of tree elements as you pass through them) and valid semantics (due to the of the tree elements, thus preventing 'colon of stenosis' but allowing the reverse). OpenEHR does this job using templated archetypes, and in more or less the same way,. But I wouldn't call this a grammar - it is the underlying Reference Model that provides the 'hard' rules of the statement form. In both cases the 'trees' could be considered models of 'possible things to say' - they thus represent models of epistemic knowledge, which is to say knowledge about individual instances, obtained or created in the clinical process. In both cases, ontology (or terminology) provides the meaning of any mentioned element. well maybe 'structural terminology' is a bad term; what I am really talking about is (possible utterances). yes, there is no doubt that the way you engineered achieves this very well, and we have things to learn in terms of bridging the gap between linguistic expression and structural expression - for now, openEHR has no 'system' to do the former, it is just done by those who want it. - thomas --- ## Post #168 by @Philippe_AMELINE > Right - but the normal sense of 'grammar' is something that controls / validates sentences made up of words so at least they have acceptable structural forms, even if they say semantically nonsensical things. The fils guides 'grammar' is supplying both levels - correct form (by implication, due to of tree elements as you pass through them) and valid semantics (due to the of the tree elements, thus preventing 'colon of stenosis' but allowing the reverse). Let's imagine that there is no fils guide. A "patient record" is a graph of trees (means trees which nodes can be interconnected by typed traits, either to connect the description tree that implements a given document description tree, or to follow a given issue over time, etc). If you assume that this trees are organized as a dependency grammar and their nodes are filled using an ontology, you don't need anything else to read it, feed smart agents, etc. It is a story told using a structured language (ie a grammar and an ontology). Of course, as you mentioned, it is possible that it contains "wrong entries" like "colon located at stenosis". In the wild, it can be achieved by providing practitioners with just an interface where they can freely express themselves by building trees (this is the usual interface for encounter notes since it is fully non deterministic). Now, for many good reasons, we could want to guide the way (some/most) trees are elaborated (to ease and speed up the process, to make certain that the information we want to process will be "well put", etc). In deterministic areas, we can use archetypes. In semi-deterministic areas, we can use fils guides (a flexible way to guess and propose the next "sons" depending on current path). In my mind, fils guides and archetype are of different kind: an archetype is a flexible information schema and nodes that were "build using this mold" keep a link to it ; on the contrary, a fil guide is nothing more than a UI helper that makes a one step deep proposal (since, when validating a proposed son, you now are on a different path (previous one + validated node) and the system will try to find a fil guide for this path). Since the process is fully dynamic and local to the user (depending on the set of fil guides he uses) the nodes don't have to remember what fil guide they originate from. To sum it up, you can have a journey walking in well known areas (archetypes) and finding your way in the wild (tree filling interface). When in the wild, you can sometimes be presented with a "step wide carpet" (Fil guide) that helps you walk more comfortably (this process being iterative, you can "follow the carpet as it unfolds", but can also head on in another direction). > well maybe 'structural terminology' is a bad term; what I am really talking about is *models of possible content* (possible utterances). I was mainly talking about the extra structural elements such as "Entry", etc. Besides, if "models of possible content" are very important inside the deterministic area, it would be pretty limited to have the only alternative "model of free text". If only because, if you provide users with a structured language, you will also be able to detect that they enter an area where you can present them with a model. When I wrote that a fil guide only makes a "one step ahead" proposal, I forgot to mention that it can also trigger an archetype (hey, since you are mentioning blood pressure, why not simply fill this form?). > yes, there is no doubt that the way you engineered *fils guides* achieves this very well, and we have things to learn in terms of bridging the gap between linguistic expression and structural expression - for now, openEHR has no 'system' to do the former, it is just done *ad hoc* by those who want it. Fils guides are fit in a semi-deterministic environment and only when there is a reference ontology available (because it compares user's current path with semantically similar expert designed paths). I really hope we can cooperate in this direction. Philippe --- ## Post #169 by @system Philippe, Can I understand that you file-guide are patterns that fit archetypes so Healthcare Providers can compose whatever they want. The file-guides insertions are context driven. The system of file-guides acts like an Ontology for clinical/administrative content. Archetypes define how things are presented in a system-interface. Gerard Freriks +31 620347088 [gfrer@luna.nl](mailto:gfrer@luna.nl) --- ## Post #170 by @system we really should build a combined descriptive architecture to show how all this fits together to solve: --- ## Post #171 by @Philippe_AMELINE I use a level\-zero ontology \(say a set of 55000 terms as implementation of atomic concepts linked inside a semantic network à la "colitis" \-is a\-> "inflammatory disease" and "colitis" \-located at\-> "colon"\)\. All information stored about a patient are expressed as trees\. As a dependency grammar, each tree "tells a story" \(for example a colonoscopy report, an encounter note, the list of health problems, etc\)\. Once that said, there is no need for anything else when it comes to process this information\. Now, we could want to guide/ease the way it is created by practitioners\. Mimicking openEHR, I built my own flavor of Archetypes as flexible information schemas \(but much simpler since they just have to host a "model tree", a set of constraints \(mandatory or mutually exclusive elements, etc\), and the corresponding user interface\)\. Fils guides are made for situations when there is no reference model and this is just a very simple \(yet powerful\) "trick"\. The basic statement was that when an expert builds a reference tree, you usually have to "cross her habits" \(the first branches\) before "reaching her knowledge" \(what surrounds the leaves\)\. The other problem being that, for example, when writing an encounter note where you deal with neurology and proctology issues among other topics, you can hardly navigate a neurology reference tree, then a proctology reference tree\. Now, imagine that you ask the gastroenterologist to build this reference tree, then you break it apart as a big set of branches, and finally ask your expert to define, for each branch, the most general path that makes it a valid proposal\. For example, the branch with the 3 choices "benign|suspect|malignant" would be attached to the path "\*/mass/aspect" \(\* being a joker for "any sub\-path"\)\. As you can guess, it is now possible to put all reference trees into the same bag and, each time a user validates an element, to get her current path \(say "encounter/objective/findings/polyp/aspect"\) and to go find in this bag the closest fil guide path that fits \(if any\)\. In order to do that, the system will first try to find if there is a fil guide which path is exactly "encounter/objective/findings/polyp/aspect", If not, it will try to find a fil guide which path is "encounter/objective/findings/polyp/X" where "X \-is a\-> aspect" in the ontology, Then look for "encounter/objective/findings/Y/X" where "X \-is a\-> aspect" and "Y \-is a\-> mass" in the ontology, etc\. It may finally elect "\*/mass/aspect" as the closest valid path and put "benign|suspect|malignant" as proposals in user interface\. If the user selects "suspect", then the path she is standing is now "encounter/objective/findings/polyp/aspect/suspect" and the system goes back looking in the fils guides bag\.\.\. etc As you can understand, the system of fils guides is neither an ontology nor an information reference schema\. It is fit for systems that can "tell structured stories in the wild" because they are based on an ontology and a grammar\. Finally, the nice thing with fils guides is that they are really complementary with Archetypes\. No need to say that, instead of "benign|suspect|malignant" it would have been possible to attach an archetype to the path "\*/mass/aspect"\. Instead of simply being proposed the three possibilities to move one step forward in the tree \(the 4th possibility being, of course, to go get something else in the ontology or to write a free text\), the user would see a form popup, click whatever needed and see the whole sub\-tree being added to her "encounter note" tree\. In my system, the native "free text control" is a tree filling interface\. So the aforementioned mechanism can also operate inside the free text area of an archetype\. The other possibility is to use fils guides when reaching the leaves of an archetype\. Some leaves may be "hard\-connected" to open another archetype, but leaves that are not may have the chance of being flexibly connected thanks to the fils guides\. To sum it up: If you have a vocabulary and a grammar \(say an ontology and trees as a dependency grammar\), you don't need anything else to tell and process discourses\. In the deterministic area, you can use archetypes to standardize the discourse \(it will eases user's task, eases processing by smart agents, etc\) In the non\-deterministic area, users can express themselves by building trees by hand and you can guide them in an opportunistic way thanks to fils guides\. IMHO, that's pretty straightforward\. Philippe --- ## Post #172 by @Philippe_AMELINE > we really should build a combined descriptive architecture to show how all this fits together to solve: > > - the continuum of deterministic - non-deterministic utterances possible in healthcare > - the linguistic interface v structured info behind question It would be great. I can provide the wine for those who are interested ;-) > the second is not the same as the first - there are many docs who prefer a language /document / writing / speaking interface than a structured form, even if the information really is or could be structured in a standard way. Yes, you are plainly right and IMHO they are entitled to do whatever they want as long as they "feed the ongoing processes with needed information". The pity being that there is no such notion in medicine so far... reason why my current effort is oriented toward providing citizen with a "personal health project manager" in order to have them demand that their practitioners behave as contributors in a multidisciplinary team. > Well, I knew that more than 10y ago when we first talked about this ... So much to do :) Probably 15 years ago ;) But at that time, your task was to go get the legacy systems where they were and offer openEHR as an evolutionary process. Maybe times are changing... this kind of articles becomes mainstream and I my bet is that the solution is not inside the box and that a Copernican revolution from care places to patients as reference frames is needed. [https://hbr.org/2018/03/to-combat-physician-burnout-and-improve-care-fix-the-electronic-health-record](https://hbr.org/2018/03/to-combat-physician-burnout-and-improve-care-fix-the-electronic-health-record) Philippe --- **Canonical:** https://discourse.openehr.org/t/terminology-bindings-again/15500 **Original content:** https://discourse.openehr.org/t/terminology-bindings-again/15500