> just imagine standardizing every diagnosis
That typically leads to either bad statistics or disimproved care.
Can I ask why?
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
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)
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 
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
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
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
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.
- 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).
Philippe
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
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.
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
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
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
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)
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).
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
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 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
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
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
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