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
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
But ICD is a statistical not a clinical tool.
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) 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
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) 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
Hi Pablo,
I totally agree with you.
Regards
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
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
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
+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.
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
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.
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
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”
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
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
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
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-----
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
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