Dear Keith
Reading through your excellent response, it seems to me that I have quite failed to explain where Iâm coming from. Allow me to expandâand explain. This will take a few pages.
My perspective is not primarily as a âclinical modellerâ. What really jabs my buttons is quality improvement in medicineâtopics like Demingâs philosophy, statistical process control and optimal clinical decision makingâand how these relate to the design and subsequent utilisation of data structures.
Although I might lay claim to a smidgen of domain expertise related to say allergies, having on occasion in the past run the Anaesthetic Allergy Clinic at my hospital, and having published a fairly well-regarded paper on this topic (https://pubmed.ncbi.nlm.nih.gov/25405395/) my example was meant to be illustrative of bigger issues. Donât rush off and fix the representational issues (symptoms) there and consider the problem (disease) solved! My real interest is in deeper, more looming issues.
Three examples
Let me labour the point with not one but three sketches:
- Letâs say youâre re-designing a city, perhaps after a large earthquake. Would you let each quarter / borough / suburb âmerely get on with itâ without some overall plan related to reticulation, roading, mass transport, âhow the city will look and feelâ and so on? (If I were cruel I might contrast Christchurch and Napier here).
- If you were engaging in a military exercise as a leader, no matter how devolved your command structure, would you provide the divisions under your command with a set of highly structured communication protocolsâand no other guidance or overall strategy?
- If you were in charge of a fairly large programming task, say in the order of 100,000 lines of C++ or Java, would you just let various teams âget on with itâ after handing out (say) a set of structured protocols for communication between modules, or would you create a carefully considered overall design strategy (etc)?
Yet, Iâd suggest, the anticipation in our âfederation of softwareâ that is meant to advance New Zealandâs health information technology well into the 21st century is predicated on lack of an overall design strategy. I cannot of course allege this, without (i) explaining why we need a strategy, at least more precisely than the analogies Iâve provided; and (ii) hinting what this strategy might be. Letâs try this.
Good Medicine
In my original post, I sketched out a working model of medical science. This is how good doctors do medicineâcreate models (hypotheses) that explain problems; test these adequately; and then provisionally accept successful hypotheses. There is never absolute certainty in medicine. For example, if we think there is a small-to-moderate possibility of a pulmonary embolus to explain breathlessness, we might do a D-dimer, and if this is negative, exclude that possible diagnosis and pursue another explanation. Perhaps the symmetrical foot swelling and soft third heart sound suggest a better explanation? But the BNP is 20. What now?
This example hints at two concepts that good doctors already use intuitivelyâbut that are coming more into the mainstream as we computerise medicine. The concepts are first the use of Bayesian inference (we take our prior odds of the condition and modify these using the likelihood ratio associated with the outcome of a test to obtain posterior odds), and second, our staple of causal inference.
This in turn cuts to the heart of the problem where we have âtacticsâ but no strategy. If we havenât laid out the broad plan for our enterpriseâbe it a battle or city planning or a large programming taskâit seems a bit unreasonable to expect everything to come together. Once you apply such concepts to the example of specifying âcommunication templatesâ like FHIRâwithout any guidance or constraints on whatâs needed for the underlying data representationâit should be clear that you have several problems.
But let me flesh this out, using what we have. Iâll take the Bayesian example first. As far as Iâm aware, there is nothing built into FHIR that allows someone to make a statement like âI think thereâs a 95% chance that this patientâs neurological findings represent multiple sclerosisâ, or âI think the prior probability that the exertional chest discomfort is related to unstable coronary arterial plaque is about 60%â. There are also no constrains on or even guidelines for those making an underlying data structure (possibly a relational database) that hints at what needs to be represented there.
Some will of course assert that this is âluxury medicineâ, âpie in the skyâ, or ânice to have but impracticalâ. Nothing could be further from the truth. This is the bare bones, without which any attempts to computerise merely crystallize our current dysfunction in silicon.
But letâs say a designer is smart and up to date, has done her homework, and realises the ever-increasing influence of Bayesian inference on medical decision making. She structures the decision-related components of her database around this. Then she comes to communicate the vital prior to another system written by a like-minded database designer. She tries this using FHIR.
Oops! Impedance mismatch!
The FHIR âsolutionâ here is perhaps to make an extension. But that extension needs to apply to every decision! Double oops. Thereâs a whole level of representation that is not supported.
Letâs look at another such example. Someone comes in in heart failure, which I diagnose. I justify this diagnosis by associating the clinical symptoms (say ankle swelling, impaired effort tolerance and orthopnoea), clinical findings (pedal oedema, basal crackles and a third heart sound) with findings on investigation (say interstitial oedema, or perhaps a raised BNP). I then ask âWhy?â and realise that the patient has long-standing, poorly controlled high blood pressure. I also notice that there are casts and red cells in the urine, and determine that the likely cause of the high blood pressure is glomerulonephritis. I then seek a cause for the chronic glomerulonephritis.
Again, I might have built the capability to represent this causal chain (and even the likelihoods and evidence) within my database. But how do I transmit this using FHIR? Um. (Thereâs yet another problem here of how you say âI did this because âŚâ but I wonât explore it here).
Itâs quite important to point out that there are two main issues here. The lesser issue is the inadequacy of FHIR to represent the above patterns of clinical inference. This is compounded with the realisation that this is a systemic issue that demands huge revisionâalmost a philosophical shift from a paradigm of passive observations to an instantiation of the do calculus of Judaea Pearl.
The bigger issue is that everybody is doing their own thing at a database levelâbecause there is no larger, strategic picture. At least, none that Iâm aware of. Each brigadier is orchestrating his own attack; each suburb or precinct is deciding independently on things like water reticulation, electricity supply and housing density; each group is programming independently and hoping that their module will interface (using the provided communication structure) with the other modules, based on some rather vague hints.
As I see things, this is made worse because there is pretty much nothing in FHIR that is mandatory. ( I can expand on this point if needed).
More concerns
I must be honest here. I felt that Peterâs response had a distinct flavour of âdonât worry your tiny little head over thisâ. I think that your comment is much more balanced:
FHIR â being an open standard, and having good international cooperation, and strong thought-leaders has a chance of doing this, but also many risks, due to the power and range of the Structure Definitionâs extension and constraint mechanisms.
Iâm nevertheless still worried that the problem is far bigger than youâve suggestedâand runs a lot deeper. I get the overall impression that the feeling both in FHIR globally and in the NZ approach to healthcare IT strategy is âSheâll be rightâ.
Perhaps Iâm completely deluded? But if you donât mind, Iâd like to flesh out these concerns in a little more detail. I think that if anything that you understate the problem when you say:
Each layer of complexity above and beyond Entities, Attributes and Relationships â such as inheritance/polymorphism in OO, or the multiple extension and restriction mechanisms in FHIR, requires a greater level of care in modelling so as not to render instances incompatible with localised variations, or version-based change. Right now there are some incompatible styles of FHIR extensions being used in some jurisdictions/vendor implementations, and a style guide, set of best practices, etc is sorely needed to avoid some of the problems you identified in your original critique. And FHIR Implementation Guide Authors are thinking about this, and making efforts to create international harmony between shared international base specifications.
A convenient punchbag
First, I absolutely agree that mapping between a hierarchical âontologicalâ structure and a relational one is fraught. In the following few paragraphs, Iâm going to use SNOMED CT as my punchbag (it presents such a large target) but please note that this usage is just an illustration of broader conceptual issuesâmapping and different ways of representing things. As with the allergies, Iâm not asking for it to be fixed. And itâs not even the biggest problem.
An obvious problem arises where an ontology is âjust plain wrongââfor example, when I last checked, SNOMED CT classified eagles as a type of stork! Concepts like âentire psycheâ or âergot of legâ make no sense as anatomical terms, and there is no anatomic or physiological basis for encoding ear lobe acupuncture points as âanatomical structuresâ, either. There may also be missing elements in the ontologyâreturning to our eagles, SNOMED CT has a rather arbitrary choice of which eagles it represents (Donât ask why. Why does it even have eagles?) But other issues are more subtle:
- The rules may change over time. This may be relatively trivial (for example renaming Pneumocystis carinii to P. jiroveci), slightly more impactful (Deciding that P. jiroveci is not a parasite, but a fungusâit thus needs to be renamed P. jirovecii and moved to a completely different section of the tree), or completely upsetting the applecart (Deciding that all of the Archaea constitute an entirely new Domain of organisms, and thus splitting the base of the tree of life into three. Or four. Or six. Or superkingdoms. Whatever.)
- The entire structure may have to change even more dramatically at many points (more of this later).
- A wild proliferation of terms is common.
Letâs pick up on this last point. You donât have to be a fan of Steve Yeggeâs Execution in the Kingdom of the Nouns (http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html) to realise that tree-like structures that are made up principally of nouns tend to be bulky. There are good reasons for this.
If we go back to the original SNOMED (not CT) it had multiple dimensions. This allows for a convenient if naĂŻve plotting of items in an eleven-dimensional space: anatomy, morphology, living organisms, drugs, signs/symptoms, occupation, diagnoses, procedures, physical agents (etc), social context and general qualifiers. This is also fairly easily represented in a relational manner, with a small number of tables, each with a moderate number of entries. Itâs obvious that if this is to be faithfully translated into all the possible combinations, the number of terms rapidly becomes silly, so those making the translation are forced to make trade-offs.
I have a convenient (if older) version of SNOMED CT with a terms table that contains ~1.3 million terms. The average length of a term description is just under 37 characters, itself quite intimidating. If I say:
select conceptId, term from terms where term like âInpatient stay%â;
⌠then I obtain individual codes that reference lengths of stay from 1â14 days, but if I want to code say 15 days, I can do this with a code for â> 12 hoursâ, âLength of stay NOSâ, or possibly âLength of stayâ with no qualifierâand some sort of custom code or post-coordination. But even these issues, despite the bulk and invitations to mis-coding, are relatively trivial.
Slightly more worrying is the case where I want to precisely code the anatomical location of, say, tuberculosis. Thereâs a code for tuberculosis of the thoracic spineâbut if I want to code that it involves T11 and T12 (TB spine is often a two-body disease) I again need some sort of post-coordination, or hack. But much more concerning is where a new disease comes along. Letâs take COVID-19, which can affect pretty much every organ system. Do we introduce codes for âSARS-CoV-2 infectionâ involving pretty much everything, or do we make it up as we go along, or do we pick and choose, or do we initially post-coordinate and later fix up? Or what?
In summary, ontological constructs invite huge complexity, compromise fidelity of representation, and invite in synonyms and arbitrary compensation for their holes. They are inflexible in the face of change.
Change in Medicine
The same problems tend to afflict all ontologiesâincluding the ontological construct that is FHIR. Youâve touched on this slightly by mentioning âlocalised variations, or version-based changeâ but those not steeped in medicine over many years often donât realise how much it mutates over time. This is not just adding of new terms or even new groups of terms. It can involve adding whole new branches of medicine, or profound structural change in entire disciplines. Neurologists may find themselves having to accommodate their entire system to an avalanche of clot retrievals, to name but one example. Other areas can be downsized and retired rather suddenlyâwhen I was a house officer, gastrectomies were still by far the commonest upper GI surgery, as peptic ulcer disease was thought to be caused by acid and not Helicobacter pylori. Now we treat stomach ulcers with antibiotics.
In other words, in trying to map between tree-structures (even those without multiple inheritance, which we might discuss separately) and relational structures, there are not just issues with adequacy of representation, but also with a continually changing targetâand one that potentially will result in entire branches of the tree being restructured continually.
If complex ontologies arenât restructured, then the representational adequacy of the entire structure will erode over time. And the more complex they are, the more likely this revision will be required. Because FHIR tries to cover (at least, in the 80/20 context) vast areas of clinical medicine, itâs even more prone to require extensive revision than something like my example of SNOMED CT. (Letâs not even mention that âfat tailâ ).
How do we fix this?
To me, the rational solution here is threefold: (1) Use a fundamentally relational design at a system-wide level (specifying a simple model that is provided to all playersâeven if itâs âjustâ a model of how to do things) to accommodate the high dimensionalityâand if you get this right, you will almost never have to alter your structures, as the âlanguageâ embodied in the structure is relationally capable of dealing with not just new nouns and their relationships, but also new processes and their relationshipsâand so on; (2) Exclude complex hierarchies from this design as even if they seem ârightâ, they will be forced to change and become more bulky; and (3) design your messaging around the first two points, rather than hoping against hope that the former two will emerge from the complex ontological design of what are, at the end of the day, messaging structures (And heaven help you if thereâs multiple inheritance).*
But even these issues are just part of the problem! In computerising medicine, we are trying to do two things. First, we are trying to introduce efficiencies (as yet largely unrealised) by replacing artisanal, manual methods with a largely computerised workflow (The cautionary tale of Sellen & Harperâs The Myth of the Paperless Office should always be in the front of our minds here). Second, we are trying to improve medicineâoften using revolutionary changes that may not be that well thought out. There are two issues with revolutionary change: clinicians often struggle with it, and by its nature it tends to break inflexible things. âRevolutionsâ work better when everyone was heading in that direction, anyway, or the benefits are trivially obvious. Medicine is in any case generally strongly wedded to traditional structures.
A holographic view
At this point, it may seem that Iâm taking a clinician-based stance against the (possibly) evil forces of encroaching computerisation. Nothing could be further from the truth. In fact, it seems to me that if anything, clinicians and IT experts are collaborating in allowing a dysfunctional computerised system to accrete (But, after all, Larry Weed said this in 1968). I see computerisation as the next logical step if we are to institute continuous quality improvementâbut we need to do things right. (For fifty years, Weed tried to fix things, and failed because he had the wrong base model. The one currently being tacitly implemented?)
Every time I see a group of clinicians asserting that they are somehow uniquely special, and deserve their own computerised registry, or record-keeping system, or set of protocols or whatever, I die a little more internally. Similarly, I look at things like the design of Allergies/Intolerances and feel the same sense of attrition.
As clinicians, weâve broken up the patient into disciplines. This is particularly dysfunctional when it comes to patients who have multi-system disease, and each doctor focuses on âtheirâ part of the problem. But equally dysfunctionalâas an evil complementâis to break up the patient using software constructs. Referring back to that Allergies/Intolerance construct, what I see is that an allergy is just one of many instances of a problem. It can be represented as such. An added benefit is that if you have a generic model of how problems are addressed in software, you donât reify âAllergyâ in terms of a complex ontological construct. So when things change, minimal or no revision is required other than perhaps a few entries in an existing table or two.
Things donât have to be extremely complex.
You wonât get a functioning system if you build it around the hope that a rather complex set of structures intended for messaging (even in the broadest sense) will somehow accrete into a functional systemâespecially if this has obvious deficiencies like those I pointed out at the start. This will work even less well if it impinges on cliniciansâ behaviour and makes them depressed, less efficient and increasingly wedded to their computer console (as weâve seen in the USA following HITECH). A different approach is needed.
In contrast, I think a reasonable starting point is to create a solid, relatively simple, shared design. I believe that doing so is non-trivial, but that it can be done. Iâm happy to sketch out a relational model that can serve as such a basis, if anyone is interested. If nothing else, it can be used as starting point for vigorous criticism. Then only should messaging even be discussed.
Perhaps everyone will disagree. But then I need do no more than point at the existing complexity and incoherence at all levels.
You can try to fix each instance, but this is still just âsymptomatic treatmentâ.
Anyway, thatâs how I see things.
My 2c, Dr Jo.
* The exact antithesis of my solution would of course be to trust that your ontological structure (embodied in FHIR) contains the âright informationâ, and create your âdatabaseâ as a light wrapper around the FHIR structures (perhaps represented as XML), hoping like hell that your semantic engine can pull what you need out of this. But nobody would be that daft, would they?
