Diabetes mellitus of mother complicating pregnancy childbirth or the puerperium unspecified as to episode of care

also known as ICD9 code 648.00. They select or type Pregnancy in Diabetes or perhaps the longer Diabetes Mellitus, in Pregnancy.

Here are two worlds – the space of say-it-many-ways, human expression and the very different, sometimes tongue-twisting formality of official medical concepts. These two spaces shouldn’t be conflated and in properly designed EHRs they aren’t.

Take the VA’s VistA. At its heart is something called the Lexicon. The Lexicon distinguishes between Expressions used by doctors and the formal concepts or Codes of medical standards and it maps between them.

It knows about Diabetes Mellitus, in Pregnancy and maps it to ICD 9 648.00. Doctor types Diabetes … and thanks to the Lexicon VistA understands ICD9 648.00.

The Lexicon identifies Preferred Expressions which it calls Major Concepts. To the Lexicon, the other term mentioned above, Pregnancy in Diabetes, is preferred and Diabetes Melliutus, in Pregnancy is its synonym.

1, 2, 3: synonyms and acronyms map to preferred expressions which map to codes …

         [Synonyms, Acronyms ...] ---> Preferred Term ---> [Codes]

Codes. More than one? Yep, the Lexicon can map any preferred term into many formal schemes. One term could have a related concept in all of ICD 9, ICD 10, SNOMED and so on.

Um. Imagine a world about to make a big upgrade, one about to go from a scheme numbered 9 to one with a 10. Could something like the Lexicon help? Hey Doc – express yourself as you always have but now out pops ICD 10, not ICD 9! Ah – the power of future-proof indirection.

10 to 12% of statements in VistA patient records assert a date.

We refuse no patient care statement – all are welcome. A statement may begin life in an EHR like VistA or in a HL7 v2 message or in the tags of a Continuity of Care Document (CCD), but as long as it asserts something about a patient’s care, we don’t care. The medium is not the message. We massage statements out of their native formats and into a triple store and in there, we analyse and restate.

In any record of patient care, many statements date and name …

   :15422 :occurred-on "2008-10-17T16:08:21Z"  // the procedure with id 15422 occurred on this date
   :12311 :name "Fred Jones" // the name of the person with id 12311 is ...

but many others, some of the most useful, identify concepts …

   :55666 :diagnosis valex:757-12329 // diagnosis in an encounter was "hypertension" (VA Lexicon: 757-12329)

and to understand such statements, we need to understand the concepts they use. What does hypertension connotate? How does it relate to other concepts in statements about the same patient?

On top of the need for concept definition, we need concept matching. Healthcare’s multi-lingual. The concept “hypertension” is defined in many schemes – ICD9, SNOMED, VA Lexicon, VA NDFRT (MeSH), VA VUID … When you look at a sizable set of care statements, many overlapping concept schemes show up. You’re presented with different identifiers for synonymous or near synonymous concepts.

Managing concepts – defining them, matching from one scheme to another, isolating useful selections – is the key to making sense of patient care statements. Without concept management, collections of care statements amount to megabytes of mush.

So today we’re pushing out the first preview of Knowledge in Triples (K3), our web-of-data based medical knowledge management service.

When a concept scheme like the VA’s Lexicon is hosted in K3, its concepts can be fully defined and matched to others and select subsets can be identified based on the ways concepts are used in practice.

Now, K3 isn’t the first web-based concept management service, nor is it the first based on the triples motif and it’s not the first to be SPARQL accessible, but it is the first designed for patient-statement publication in the web-of-data. Concepts in K3 aren’t abstractions, curiosities for the learned: they are alive. Patient care statements link to them directly.

With both care-statements and medical knowledge in triples, both concrete statements about patients and the concepts used in those statements live in one medium, the web-of-data, with a common query mechanism, SPARQL. There are no distinct APIs, no specialized web services. The plumbing that dominates and slows I.T. falls away as statements link directly to the concepts they use. It’s a world where you focus on content, not formats. That’s liberating.

One highlight of Preview 1 is the five national VA Concept Schemes.

Pick a statement-of-concept that starts in VistA and more often than not, it will use a concept from one of these schemes. Of course, like everything practical, there are redundancies – at least three hypertension definitions – and wouldn’t we rather statements with SNOMED? Perhaps, though dive in there and you’ll find a mixed bag too.

Why these flavors of “VistA-ese?”. Because VistA is our reference EHR and as the VA’s schemes are well thought out, they provide an excellent point of comparison for the great-hopes-of-health informatics like SNOMED. Real world EHR, real world statements in it, real-world concept schemes – what more could a patient data miner ask for?

But there’s more inside RxNORM’s awful release format, a hefty gem from the VA called National Drug File, Reference Terminology (NDFRT). With NDFRT, drugs like Warfarin are matched to disorders …

     :N0000148057 :contraindicated-for :N0000000988  # Warfarin is contraindicated for Diverticulitis 
...
     :N0000148057 :may-prevent :N0000004160  # Warfarin may prevent Stroke 
...
     :N0000148057 :may-treat :N0000000507  # Warfarin may treat Atrial Fibrillation

and it tells you what drug combinations to watch out for …

     [] :participant :N0000148057 # Warfarin
        :participant :N0000146291 # Hydrocortisone
        :severity "SIGNIFICANT"

or watch out! The interaction between Warfarin and Hydrocortisone may be significant.

NDFRT gets us beyond drug x has ingredient y. We’re told what a drug is for and what to watch out for.

Is it perfect? No. One biggie – it uses MeSH for disorders and while there are maps to SNOMED, some of these are questionable and others are to obsolete concepts (162 of 1099 mapped).

It can also surprise. Did you know the VA can make you live forever? NDFRT declares …

    :N0000146382 may_prevent :N0000000903 # Antiven may prevent Death

Antiven,Micrurus Fulvius, the immortality pill.

But putting quirks aside, it shows once again that VistA and the VA terminologies are a treasure-throve for next-generation EHRs. Decision-support everybody?

    The problem is Hypertension
                   of-patient "Joe Smith"
                   recorded-on 2011-10-21
                   diagnosed-by "Dr Fred Jones"

… one triple after another, capturing a patient’s health, and so a key metric for us is how many triples does a typical patient get? Without a figure, we can’t know how big a patient triple store would be or how big a complete CCD or Caregraf is.

For an answer, we need access, direct unencumbered access, to an EHR and thanks to FMQL we can have that for the VA’s VistA, the most widely deployed EHR. Of course, we’d need FMQL on a real VistA, not just on our demo system and thanks, indirectly (ssh!), to the VA themselves, we have that too.

So some numbers. Take a very sick man …

     Number of Visits: 116
     Number of Problems: 38
     Number of Orders: 240
     Number of Concepts: 1478
...
     Number of Triples: 44,281
     Size of Caregraf (turtle format): 2.7 MB

44,281 – that’s a lot of statements. But hold on, you say, number of orders?. That means you’re counting the process of care, health-care workflow, as opposed to just descriptions of a patient’s health. True and worse, we’re also capturing billing information. In fact, for this man, we’re capturing 163 types of medical fact. Yes Prescription, but Order and Billing information too. If we hone in on “facts about patient health”, we end up with 19,352 triples which is still a lot. Can we pair down more?

Well, if we exclude many inpatient medications, IVs and their ilk, nix inactive problems, cut out the nursing notes, cut all the stuff of immediate care that isn’t relevant for subsequent care – down comes the number to 5000 or so.

We’ve dealt with hospitals with information on 200,000 patients and in the unlikely event that all their patients were 5000 triples sick, that adds up to 1 billion triples. Doable? Can current triples stores handle a billion?

dbpedia, which holds the structured information of Wikipedia – has over a billion triples in its store. In W3C’s discussion of large triple stores, five to fifteen billion triples is commonplace and one trillion is the new benchmark. On top of this, add that SPARQL, the SQL of triple stores, now supports distributed querying and you have the scale of the web itself on your side.

Which gets me back to the VA. They have medical data on nine million people. If these were all 5000-triple sick then we get 45 billion triples. Not a trillion, not close. The VA could put all their patient data in one triple store and query away. Begone so much plumbing, this-and-that custom extraction mechanism. One store, to answer anything. Why not?

104419|ENG||||||2701592|2701592|104419||RXNORM|SBD|104419|24 HR Felodipine 5 MG Extended ...
104419|ENG||||||2701593|2701593|104419||RXNORM|SY|104419|24 HR Plendil 5 MG Extended ...

It doesn’t jump out but find TTY, the lynchpin of the RRF format – each element of the normalized form can be identified by the value of the TTY [Term Type] field. It’s the column with values SBD which means Semantic branded drug and SY which means Synonym. In the first row, TTY holds the type of a concept (Semantic Branded Drug) but in the next, it holds the type of the label of that concept (Synonym). One field, two different uses. Processors beware!

The above looks like this in RDF …

rxnorm:104419 skos:broader rxnorm:SBD ;
              skos:prefLabel "24 HR Felodipine 5 MG Extended Release Tablet [Plendil]" ;
              skos:altLabel "24 HR Plendil 5 MG Extended Release Tablet" ;
              rxnorm:quantified_form_of rxnorm:844417 ;
              rxnorm:has_ingredient rxnorm: 203016;
              rxnorm:has_dose_form rxnorm:316945 ;
              rxnorm:tradename_of rxnorm:402696 ;
              ...

Much better I think you’ll agree and, for the technical, quiet readable. And notice there are properties other than name and type, tradename and its ilk. While names and types of concepts come from the RRF concepts file, these started in the RRF relationships file. With RDF, everything about a concept ends up in one place. What’s more, this same format works for other vocabularies from ICD 9 to SNOMED. In scheme definition, custom specification formats can be banished. One size does fit all.

The RXNORM Overview comes with a list of example queries – it has you traversing the RRF data (or its SQL equivalent) but we’ll SPARQL our RDF instead …

SELECT ?concept
WHERE {?concept skos:prefLabel 'Amoxicillin'}

SELECT ?concept ?conceptLabel
WHERE {?concept skos:prefLabel ?conceptLabel ;
       rxnorm:form_of rxnorm:723}

SELECT ?concept ?conceptLabel
WHERE {?concept skos:prefLabel ?conceptLabel ;
       rxnorm:tradename_of rxnorm:723}

SELECT ?concept ?conceptLabel
WHERE {?concept skos:prefLabel ?conceptLabel ;
       rxnorm:has_ingredient rxnorm:723 ;
       skos:broader rxnorm:SCDC}

SELECT ?concept ?conceptLabel
WHERE {?concept skos:prefLabel ?conceptLabel ;
       rxnorm:has_ingredient rxnorm:723 ;
       skos:broader rxnorm:SCDF}

Oh, how easy it is when RXNORM (and SNOMED and …) become RDF! Shouldn’t they just come in RDF in the first place?

     :finding snomed:160245001; # No current problems or disability
     :finding snomed:160244002; # No known allergies
     :finding snomed:182850000; # Drugs not issued
or the more general ...
     :finding snomed:408350003; # Patient not on self medications

and such an explicit endorsement of health is very different from saying you don’t know about a person’s health …

      :finding snomed:396782006; # medical history unknown
or the precise
      :finding snomed:182904002 # drug treatment unknown

I suppose I don’t know is one step better than leaving a record empty: it snuffs out any hope of something being found in some out of the way filing cabinet.

Meaningful-use doesn’t like empty records. A CCD without at least one allergy, one medication and one problem entry is not conformant. To make a CCD for the healthy, we need to put our “findings of absence” to work, though it’s a little counter-intuitive …

Our one problem is a diagnosis of no problems …

     <code code="282291009" displayName="Diagnosis" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
                  ...
     <value xsi:type="CD" code="160245001" codeSystem="2.16.840.1.113883.6.96" displayName="No current problems or disability" codeSystemName="SNOMED CT">

but our one allergy is a stretch: we’re saying ‘Propensity to an adverse reaction’ is ‘No reactions’. The simpler ‘Diagnosis’ is ‘No known allergies’ makes more sense but allergy markup won’t allow it …

     <code code="420134006" codeSystem="2.16.840.1.113883.6.96" displayName="Propensity to adverse reactions (disorder)" codeSystemName="SNOMED CT"/>
                  ...
     <value xsi:type="CD" code="160244002" codeSystem="2.16.840.1.113883.6.96" displayName="No Known allergies" codeSystemName="SNOMED CT">

and our one medication? Normally medications are all about declaring the drug, the substance administered and the markup doesn’t start with a code like “Drugs Issued”, but as we need to declare absence, in comes a code …

     <code code="182850000" codeSystem="2.16.840.1.113883.6.96" displayName="Drugs not issued" codeSystemName="SNOMED CT"/>

Of course, all this means that no man, not even the healthiest, gets an empty medical record.

Terminologies are said to be granular things, meant to handle every medical nuance. They’re said to shine when precision is called for but to be too chatty for summary. That’s why billing calls for Classifications, which capture only the essential. It’s such a neat split – express any and all clinical findings in expansive terminology, but state bills and summarize care in succinct classification but is it too neat?

Consider SNOMED’s definition of Nuclear sclerotic cataract …

a Disease (64572001) with
    :finding_site :56707006 # Nucleus of lens
    :associated_morphology :128305008 # Opacity

You see a terminology doesn’t just give you a concept – it builds it from more primitive definitions. What’s more, though some building is done for you, the assumption is that there will always be more to say and that you need to be able to roll your own. So though basic SNOMED doesn’t come with Senile Nuclear sclerotic cataract pre-canned, you can make it yourself. Just enhance Nuclear scleroitic cataract with …

    :occurrence :271872005 # old age

and hey presto Senile Nuclear sclerotic cataract!

And a classification like good ol’ ICD 9, what does it have to say? Senile nuclear sclerosis (366.16), that’s what. Take that SNOMED! Now being a classification, I9 doesn’t build up slowly to this concept, no layering attribute on attribute for it. A few jumps down its rigid hierarchy gives you …

    Cataract (366)
        Senile Cataract (366.1)
            Senile nuclear sclerosis (366.16)

and though this path provides little for analytical tools, the end result has the same nuance as our newly fired SNOMED.

What’s more ICD 10 is even more expansive. It adds which eye is affected to make Age-related nuclear cataract, right eye. Not only do we get a condition, not only do we get the stage in life of the patient but we also get the eye. Your answer SNOMED?

    :finding-site 
        [ a :56707006 # Nucleus of lens
          :laterality :24028007 # right
        ]

or the disease in question is found in the nucleus of the right lens..

This ability to keep defining means SNOMED won’t loose the contest for breath, no matter how many expressions the ICDs gobble up, but who now gets to lift the cup for essence? Classification-bloat belies our neat split – Classification for essentials, Terminology for expressiveness.

Today, it may be better to say that a Terminology provides a man with some fish and a rod to catch more while a Classification aims to give him all the fish he can eat, ever. Here are two approaches to comprehensive expression and ironically, it’s the terminology that, at its core, is more succinct.

But where, oh where does this leave billing? Using the latest Classification of course. That’s what ICD 10 CM is for and it’s just the size to fit the bill, isn’t it?

    :finding snomed:268912009 # you're senile!

after all …

    :observable snomed:423493009 # age at diagnosis
    :value "65"

BTW, in SNOMED, senile state is also an observable thing, a peer of age at diagnosis. They’re both examples of age or growth periods. So SNOMED implies there’s a scale to senility, a little bit at 65 and by 90, wow. Anyhow, I digress …

You’ve a problem …

    :disease snomed:193570009 # cataracts

but because you’re senile the doc could say …

    :disease snomed:39450006 # senile cataracts

Yep, senile cataracts is a disorder, the elderly child of cataracts.

Now in lay speak, senile is a favorite pejorative that calls brain function into question. You’re on your way to senile dementia or you’ve arrived. But let’s give SNOMED a break and presume there’s nothing insulting about the word. This is just one more catch-all for old-age, a friend of geriatric and elderly or the softly softly age-related. Adding this six letter word to a disorder just puts its cause down to your decrepitude. How decrepit? Let’s just go with the flow. Let’s accept that 65 pensions you off to senility.

The more general problem here is redundancy of expression. After all, …

pair
    :disease snomed:193570009 # cataracts 
with
    :observable snomed:423493009 # age at diagnosis
    :value "65"   
and you get 
    :disease snomed:39450006 # senile cataracts

and I’d argue that the pairing of your age and your condition trumps a composition that tries to capture both stage in life and condition, at least for machine reasoning where numeric ranging comes into its own.

And such compositions raise a bigger issue for all concept schemes: how much concept-mashing should they go for – the fancy name is ‘pre-coordination’. How much expression to strive for in a single concept? When you add senile to cataracts, you capture two thoughts, but apply this pattern to all ailments which mainly effect the elderly and rarely strike the young and a scheme would balloon.

if a substance CAN BE the cause of an Allergy then it is an Allergen

In other words, Allergen is a grouping concept for substances that can cause allergies. Or is it?

SNOMED disorder axis has 1597 allergies to substances but only 1133 of those substances are classed as Allergens. In other words, SNOMED comes with allergies to substances that it doesn’t consider to be Allergens. Examples include Allergy to Oats whose cause, Oats, isn’t classed as an Allergen.

And the choice of what is and what isn’t an Allergen seems arbitrary. Of 54 fresh fruits, only 9 are said to be allergens. Strawberries are in, Raspberries out. Try a little meat. Pork is in, but its peer, Lamb is out.

And there’s more. Allergen itself breaks into Drug Allergen and Food Allergen. Surely a Food Allergen is a Food and a Drug Allergen, a Drug. But here are 25 foods that make it into Drug Allergen, including that well know drug, the Cherry.

All in all, in this condition, neither Allergen nor its specializations are good for anything.

Update: So I posted a variation of the above to the Substance Hierarchy Reworking group of SNOMED’s master, the IHTSDO and here’s what Matthew Cordell wrote …

Realistically it’s impractical/impossible to define the range of substance that “could” cause an allergy in “somebody”. Consequently such relationships aren’t really “defining” … defining something as being an “allergen” is actually saying a “a potential allergen” – which is circumstantial. … the allergen categories will most likely be retired

Circumstantial, not Defining, that says it all. Now, our SNOMED dataset has to reflect this. In general, it needs to do a better job at hiding or downgrading clutter.

Fortunately, Nonsense is only the lowest of three levels of correct CCD. I’ll talk about the creme de la creme later, but now let me discuss Mr. In Between, what I think of as “CCDs for Tourists”.

As always let’s begin in the weeds, again with good old allergy to strawberries …

"Allergy" is the disorder and "les fraises" sont la cause

les fraises? It’s French for strawberries. But why two languages? Why not just stick to English, say strawberries is the cause? After all, English isn’t limited to labeling disorders – such mixing and matching makes the listener focus on the form of expression rather than what’s being said!

Here’s CCD markup for this allergy, using concept schemes recommended by the powers that be …

<code code="106190000" displayName="Allergy" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED" />
...
<value xsi:type="CD"/>
<participant typeCode="CSM">
    <participantRole classCode="MANU">
        <playingEntity classCode="MMAT">
            <code code="4J2TY8Y81V" codeSystem="2.16.840.1.113883.4.9" codeSystemName="Unique Ingredient Identifier (UNII)" displayName="strawberry" />
            <name>strawberry</name>
        </playingEntity>
    </participantRole>
</participant>

We declare the disorder with SNOMED and the cause using the FDA’s Unique Ingredient Identifier scheme (UNII). Here’s two different concept schemes or languages if you will. Why two? Why not identity substance with SNOMED too?

<code code="106190000" displayName="Allergy" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED">
     <qualifier>
         <name code="246075003" displayName="causative agent" />
         <value code="102261002" displayName="strawberry" />
     </qualifier>
</code>

English and French, SNOMED and UNII, la même chose? Multi-lingual CCDs or CCDs for tourists.

Tourists? Ever waded through street vendors in the face of English, German, local labels and pointing, as you and they try to get your point across? This form of expression works but only for simple communication. It’s the world of Adam in the garden, labeling one plant after another, without any thought for the overarching concept plant, the world of stand-alone labels, not coherent expression.

Like most who’ve played with CCDs, I expect meaningful-use 2 to consign the Nonsense to the scrap heap but I’d go further and throw the Tourists in there too. But perhaps, I’m being too narrow-minded, too much of the “English should be our one and only language”, “let them eat SNOMED” sort. Why not live happily in babel? Because I want to do something with these patient-data dumps, damn it and I’d rather do it without a dictionary in hand.