The electronic health record problem list - how I'd do it for the third time

I did corporate research and development in clinical software for about 20 years. During that time I couldn’t write about informatics ideas.

In my current job I have more scope. I can’t write about anything specific to my work, but I can share some general thoughts on medicine and health informatics. Like my idle thoughts about how I’d implement an electronic health record problem list if I were doing one for the third time. (Of my two previous efforts I liked the first one best; this proposal is an improvement on it.)

One problem with the patient “problem list” is it’s a “roach motel”. Easy to enter, hard to leave. It gets cluttered up with obsolete junk nobody dares clean out. Another problem is one man’s poison is another man’s wine — orthopods aren’t interested in minor eye disease findings. A third problem is that problem lists are typically assembled from “billing codes” (ICD-9/ICD-10) that are often misleading and a treacherous basis for decision support. Unfortunately, because of the way we use it, ICD-10-CM is worse than ICD-9-CM. A fifth problem is that every minor variant of Diabetes gets its own entry, cluttering the list. Lastly to get real value out of the problem list it should be useful in automated decision support and population health monitoring, but again ICD-10-CM does poorly.

So here’s what I’d do:

1. I’d base my problem list on a SNOMED subset (wait, I can explain).
2. The SNOMED subset would be quite small, probably less than 1,500 concepts.
3. I’d choose the concepts based on the ICD-10-CM codes that are “containers” (non-leaf) for leaf codes. This is far less than the total number of ICD-10-CM codes. I’d also restrict my coverage to those ICD-10-CM “container” codes that map to SNOMED CT Findings.
4. The only time I’d go finer grained than this high level set would be if I had a decision support rule that needed more definition (most won’t).

Given these constraints the ICD-10-CM back maps are easy to build and maintain. Any ICD-10-CM code associated with an encounter would have a corresponding SNOMED concept. In the UI I’d support displaying all ICD-10-CM codes historically associated with the problem concept — so the detail would be available on request. Clinical rules would be written off the small space of problem list concepts.

I’d give problems an algorithmic lifetime — unless the provider explicitly makes them “sticky”. If a related ICD-10-CM code doesn’t reappear for two years the problem becomes “historic”. All decision support rules that are declined would have an option to say the “problem” no longer applies — that would remove the item.

If a problem were marked “sticky” it could still be removed manually or by the decision support action — but the provider who made it “sticky” would be get a message about the change. They could choose to investigate or ignore it.

I doubt I’ll get a third go round at this problem, but that’s what I’d like to try.

Informatics core: US genomic and healthcare standards have a common problem.

My current work means I’ve spent many hours plumbing details of major American and international health care standards, particularly FHIR, HL72, CCDA/HL73 and NCPDP. 

It reminds me of a project from the late 00s when I was exploring genomics database.

There’s too much documentation.

Specifically, there are too many information sources that are not well maintained. There’s always funding to create a repository or database or web app, there’s never funding to sustain it. All the partly implemented solutions create a misleading cloud of chaff.

One has to dig through to the core source — if it exists. The core sources for HL7 3 are, unfortunately, very hard to work with (lots of reasons for that, including the way HL7 used to be funded). FHIR core sources are easier to navigate — but already there are various extensions and fissures. Best not to mention use of the Federal Registry as a reference information source.

The structure and maintenance of knowledge sources is a core informatics problem. We need to get back to our roots in the National Library of Medicine and library science. That would require funding though…

Systemic failure in American medicine: combining ICD-10-CM with "leaf code" reimbursement rules

This is very much “inside baseball”. It’s related to professional work I do. It’s incomprehensible to most people, but it’s having a big impact on your healthcare. An impact that the vast majority of healthcare workers and administrators won’t understand. Only the coding specialists in unlit basement rooms know what’s going on.

For several decades American physicians have used a system of codes to justify procedures and bills. They’re like the occupation codes you might use to fill out your tax form, but there are thousands of them. They are called diagnostic codes, the old system was called ICD-9-CM. (ICD codes are also used in public health, epidemiology, research and information exchange, but that’s not what I’m writing about.)

For various reasons, which I personally think were unwise, the ancient ICD-9-CM system was recently replaced with a less ancient ICD-10-CM system. That was a disruptive change with limited value, but the change in coding systems by itself wasn’t the disaster. Yes, I know many physicians think the coding system change was the disaster, but they’re wrong. There are more codes, but there are ways that software systems could have made that proliferation manageable. The real problem is more subtle.

The disaster was that Medicare (CMS) and payers retained an old ICD-9 rule. A rule that only the “leaf” (most detailed) codes in the ICD-10-CM system could be accepted for payment. If you want to know what I mean by “leaf” check out this example from the ICD-10-CM codes for Type 2 Diabetes Mellitus:

Doesn’t it look a bit like branches of a tree? Only the little green arrow codes can be accepted for payment. They are “most detailed”. They have “no children”. They are “leaves”.

If you’re with me so far, here’s the punchline. ICD-9-CM had “leaf” codes that essentially meant the same as the “root” code, ICD-10-CM doesn’t. (In the example above E11 is a root code.)

I’m simplifying a bit here. ICD-9-CM was a mess. It didn’t always have “unspecified” or “not otherwise specified” leaf codes that meant the same as the root code, but it mostly did. Diabetes Mellitus 250.00 meant the same as 250. 

ICD-10 is more intelligent, it doesn’t have these duplications. If you want to just say a patient has Type 2 Diabetes Mellitus you could just say E11.

Except you can’t get paid for saying E11. Because of the leaf rule. So that’s not an option in health record or billing systems. Instead physicians must choose between:

But what if they don’t know or care if the patient has complications? Maybe they’re seeing them for a cold. Maybe the patient doesn’t know if they have DM complications. They have to choose one at random. It’s the same everywhere.

This is madness. The problem isn’t ICD-10-CM. It isn’t even the leaf code requirement. It’s the combination of the two.

In a sane world the fact that we combined an essential healthcare code system that lacked redundant leaf codes with a payment system that required leaf codes would be treated as a systemic failure. There would be congressional hearings and root cause analysis.

Instead we stagger on into the fog.

Apple's CareKit (HealthKit) - what kinds of clinical data does it work with?

I thought Apple had given up on HealthKit, but recently we learned that it’s been rebranded as CareKit and it seems to be going forward.

Since my professional work is in “health informatics”, specifically medical knowledge applications, I was curious what “ontology” (data dictionary, terminology, etc) Apple was using for it’s CareKit work. The concept set is somewhat hidden within Apple’s HealthKit Constants Reference documentation. I auto-expanded the symbols (nice web app Apple!) and make a quick pass at organizing the strings.

For someone like me it’s a fascinating set. The discussion of privacy and FDA device identifiers is noteworthy — in an early implementation it was apparently possible to trace HealthKit data to an individual device (not good, obviously - bold below).

I liked the use of Fitzpatrick Skin Type instead of trying to describe ethnicity/race.

It’s a fun list to scan:

HKMetadataKeyBodyTemperatureSensorLocation
HKMetadataKeyCoachedWorkout
HKMetadataKeyDeviceManufacturerName
HKMetadataKeyDeviceName
HKMetadataKeyDeviceSerialNumber
HKMetadataKeyDigitalSignature
HKMetadataKeyExternalUUID
HKMetadataKeyFoodType
HKMetadataKeyGroupFitness
HKMetadataKeyHeartRateSensorLocation
HKMetadataKeyIndoorWorkout
HKMetadataKeyMenstrualCycleStart
HKMetadataKeyReferenceRangeLowerLimit
HKMetadataKeyReferenceRangeUpperLimit
HKMetadataKeySexualActivityProtectionUsed
HKMetadataKeyTimeZone
HKMetadataKeyUDIDeviceIdentifier
HKMetadataKeyUDIProductionIdentifier
HKMetadataKeyWasTakenInLab
HKMetadataKeyWasUserEntered
HKMetadataKeyWorkoutBrandName

HKCategoryTypeIdentifierAppleStandHour
HKCategoryTypeIdentifierCervicalMucusQuality
HKCategoryTypeIdentifierIntermenstrualBleeding
HKCategoryTypeIdentifierMenstrualFlow
HKCategoryTypeIdentifierOvulationTestResult
HKCategoryTypeIdentifierSexualActivity
HKCategoryTypeIdentifierSleepAnalysis

HKBiologicalSexFemale
HKBiologicalSexMale
HKBiologicalSexNotSet = 0
HKBiologicalSexOther

HKBloodTypeABNegative
HKBloodTypeABPositive
HKBloodTypeANegative
HKBloodTypeAPositive
HKBloodTypeBNegative
HKBloodTypeBPositive
HKBloodTypeNotSet = 0
HKBloodTypeONegative
HKBloodTypeOPositive

HKBodyTemperatureSensorLocationArmpit
HKBodyTemperatureSensorLocationBody
HKBodyTemperatureSensorLocationEar
HKBodyTemperatureSensorLocationEarDrum
HKBodyTemperatureSensorLocationFinger
HKBodyTemperatureSensorLocationForehead
HKBodyTemperatureSensorLocationGastroIntestinal
HKBodyTemperatureSensorLocationMouth
HKBodyTemperatureSensorLocationRectum
HKBodyTemperatureSensorLocationTemporalArtery
HKBodyTemperatureSensorLocationToe

HKCategoryValueCervicalMucusQualityCreamy
HKCategoryValueCervicalMucusQualityDry = 1
HKCategoryValueCervicalMucusQualityEggWhite
HKCategoryValueCervicalMucusQualitySticky
HKCategoryValueCervicalMucusQualityWatery

HKCategoryValueMenstrualFlowHeavy
HKCategoryValueMenstrualFlowLight
HKCategoryValueMenstrualFlowMedium
HKCategoryValueMenstrualFlowUnspecified = 1

HKCategoryValueSleepAnalysisAsleep
HKCategoryValueSleepAnalysisInBed

HKCharacteristicTypeIdentifierBiologicalSex
HKCharacteristicTypeIdentifierBloodType
HKCharacteristicTypeIdentifierDateOfBirth
HKCharacteristicTypeIdentifierFitzpatrickSkinType
HKCorrelationTypeIdentifierBloodPressure
HKCorrelationTypeIdentifierFood

HKFitzpatrickSkinTypeI
HKFitzpatrickSkinTypeII
HKFitzpatrickSkinTypeIII
HKFitzpatrickSkinTypeIV
HKFitzpatrickSkinTypeNotSet = 1
HKFitzpatrickSkinTypeV
HKFitzpatrickSkinTypeVI

HKHeartRateSensorLocationChest
HKHeartRateSensorLocationEarLobe
HKHeartRateSensorLocationFinger
HKHeartRateSensorLocationFoot
HKHeartRateSensorLocationHand
HKHeartRateSensorLocationWrist

HKQuantityTypeIdentifierActiveEnergyBurned
HKQuantityTypeIdentifierAppleExerciseTime
HKQuantityTypeIdentifierBasalBodyTemperature
HKQuantityTypeIdentifierBasalEnergyBurned
HKQuantityTypeIdentifierBloodAlcoholContent
HKQuantityTypeIdentifierBloodGlucose
HKQuantityTypeIdentifierBloodPressureDiastolic
HKQuantityTypeIdentifierBloodPressureSystolic
HKQuantityTypeIdentifierBodyFatPercentage
HKQuantityTypeIdentifierBodyMass
HKQuantityTypeIdentifierBodyMassIndex
HKQuantityTypeIdentifierBodyTemperature
HKQuantityTypeIdentifierDietaryBiotin
HKQuantityTypeIdentifierDietaryCaffeine
HKQuantityTypeIdentifierDietaryCalcium
HKQuantityTypeIdentifierDietaryCarbohydrates
HKQuantityTypeIdentifierDietaryChloride
HKQuantityTypeIdentifierDietaryCholesterol
HKQuantityTypeIdentifierDietaryChromium
HKQuantityTypeIdentifierDietaryCopper
HKQuantityTypeIdentifierDietaryEnergyConsumed
HKQuantityTypeIdentifierDietaryFatMonounsaturated
HKQuantityTypeIdentifierDietaryFatPolyunsaturated
HKQuantityTypeIdentifierDietaryFatSaturated
HKQuantityTypeIdentifierDietaryFatTotal
HKQuantityTypeIdentifierDietaryFiber
HKQuantityTypeIdentifierDietaryFolate
HKQuantityTypeIdentifierDietaryIodine
HKQuantityTypeIdentifierDietaryIron
HKQuantityTypeIdentifierDietaryMagnesium
HKQuantityTypeIdentifierDietaryManganese
HKQuantityTypeIdentifierDietaryMolybdenum
HKQuantityTypeIdentifierDietaryNiacin
HKQuantityTypeIdentifierDietaryPantothenicAcid
HKQuantityTypeIdentifierDietaryPhosphorus
HKQuantityTypeIdentifierDietaryPotassium
HKQuantityTypeIdentifierDietaryProtein
HKQuantityTypeIdentifierDietaryRiboflavin
HKQuantityTypeIdentifierDietarySelenium
HKQuantityTypeIdentifierDietarySodium
HKQuantityTypeIdentifierDietarySugar
HKQuantityTypeIdentifierDietaryThiamin
HKQuantityTypeIdentifierDietaryVitaminA
HKQuantityTypeIdentifierDietaryVitaminB6
HKQuantityTypeIdentifierDietaryVitaminB12
HKQuantityTypeIdentifierDietaryVitaminC
HKQuantityTypeIdentifierDietaryVitaminD
HKQuantityTypeIdentifierDietaryVitaminE
HKQuantityTypeIdentifierDietaryVitaminK
HKQuantityTypeIdentifierDietaryWater
HKQuantityTypeIdentifierDietaryZinc
HKQuantityTypeIdentifierDistanceCycling
HKQuantityTypeIdentifierDistanceWalkingRunning
HKQuantityTypeIdentifierElectrodermalActivity
HKQuantityTypeIdentifierFlightsClimbed
HKQuantityTypeIdentifierForcedExpiratoryVolume1
HKQuantityTypeIdentifierForcedVitalCapacity
HKQuantityTypeIdentifierHeartRate
HKQuantityTypeIdentifierHeight
HKQuantityTypeIdentifierInhalerUsage
HKQuantityTypeIdentifierLeanBodyMass
HKQuantityTypeIdentifierNikeFuel
HKQuantityTypeIdentifierNumberOfTimesFallen
HKQuantityTypeIdentifierOxygenSaturation
HKQuantityTypeIdentifierPeakExpiratoryFlowRate
HKQuantityTypeIdentifierPeripheralPerfusionIndex
HKQuantityTypeIdentifierRespiratoryRate
HKQuantityTypeIdentifierStepCount

HKWorkoutActivityTypeAmericanFootball = 1
HKWorkoutActivityTypeArchery
HKWorkoutActivityTypeAustralianFootball
HKWorkoutActivityTypeBadminton
HKWorkoutActivityTypeBaseball
HKWorkoutActivityTypeBasketball
HKWorkoutActivityTypeBowling
HKWorkoutActivityTypeBoxing
HKWorkoutActivityTypeClimbing
HKWorkoutActivityTypeCricket
HKWorkoutActivityTypeCrossTraining
HKWorkoutActivityTypeCurling
HKWorkoutActivityTypeCycling
HKWorkoutActivityTypeDance
HKWorkoutActivityTypeDanceInspiredTraining
HKWorkoutActivityTypeElliptical
HKWorkoutActivityTypeEquestrianSports
HKWorkoutActivityTypeFencing
HKWorkoutActivityTypeFishing
HKWorkoutActivityTypeFunctionalStrengthTraining
HKWorkoutActivityTypeGolf
HKWorkoutActivityTypeGymnastics
HKWorkoutActivityTypeHandball
HKWorkoutActivityTypeHiking
HKWorkoutActivityTypeHockey
HKWorkoutActivityTypeHunting
HKWorkoutActivityTypeLacrosse
HKWorkoutActivityTypeMartialArts
HKWorkoutActivityTypeMindAndBody
HKWorkoutActivityTypeMixedMetabolicCardioTraining
HKWorkoutActivityTypePaddleSports
HKWorkoutActivityTypePlay
HKWorkoutActivityTypePreparationAndRecovery
HKWorkoutActivityTypeRacquetball
HKWorkoutActivityTypeRowing
HKWorkoutActivityTypeRugby
HKWorkoutActivityTypeRunning
HKWorkoutActivityTypeSailing
HKWorkoutActivityTypeSkatingSports
HKWorkoutActivityTypeSnowSports
HKWorkoutActivityTypeSoccer
HKWorkoutActivityTypeSoftball
HKWorkoutActivityTypeSquash
HKWorkoutActivityTypeStairClimbing
HKWorkoutActivityTypeSurfingSports
HKWorkoutActivityTypeSwimming
HKWorkoutActivityTypeTableTennis
HKWorkoutActivityTypeTennis
HKWorkoutActivityTypeTrackAndField
HKWorkoutActivityTypeTraditionalStrengthTraining
HKWorkoutActivityTypeVolleyball
HKWorkoutActivityTypeWalking
HKWorkoutActivityTypeWaterFitness
HKWorkoutActivityTypeWaterPolo
HKWorkoutActivityTypeWaterSports
HKWorkoutActivityTypeWrestling
HKWorkoutActivityTypeYoga

HKWorkoutSessionLocationTypeIndoor
HKWorkoutSessionLocationTypeOutdoor
HKWorkoutSessionLocationTypeUnknown = 1

Using Gmail and the link to correspond with patients -- HIPAA 2013 clarification

HIPAA is designed to protect patient confidentiality. It’s widely misunderstood, not least because of the scary fines for violations. I think on balance it’s a good law, but it needs regular adjustment.

Happily in 2013 a major adjustment was made. Rule makers allowed use of conventional email applications, perhaps without robust encryption, for patient communications if informed consent is given and recorded. I recently put together a set of references on this:

https://personcenteredtech.com/2013/10/06/clients-have-the-right-to-receive-unencrypted-emails-under-hipaa/
Covers the 2013 final rule changes.

http://blog.securitymetrics.com/2014/05/hipaa-email-encryption.html
Pretty good discussion of implications

http://www.austinmedclinic.com/hipaa-and-email.pdf
Example of a patient consent to receive unencrypted email

http://www.gpo.gov/fdsys/pkg/FR‐2013‐01‐25/pdf/2013‐01073.pdf
HIPAA language is on page 5634 (I didn’t confirm this, just copied from the Austin Med Clinic consent form.

I’d still worry about risks associated with using Gmail (though communication is now actually well encrypted for most users) — the message will be both sender and receiver’s server forever unless it’s deleted. Tricky business!

Still, it’s encouraging to see this clarification. I hope the HIPAA rules continue to be adjusted. Having robust encryption built into laptops helps — at least until the FBI forces backdoors which will, of course, be widely exploited by hackers.

Google Trends: Across my interests some confirmation and some big surprises.

I knew Google Trends was “a thing”, but it had fallen off my radar. Until I wondered if Craigslist was going the way of Rich Text Format. That’s when I started playing with the 10 year trend lines.

I began with Craigslist and Wikipedia...

• Craigslist is looking post-peak
• Wikipedia looks ill, but given how embedded it is in iOS I wonder if that’s misleading.

Then I started looking at topics of special relevance to my life or interests. First I created a set of baselines to correct for decliniing interest in web search. I didn’t see any decline

• Cancer: rock steady, slight dip in 2009, slight trend since, may reflect demographics
• Angina: downward trend, but slight. This could reflect lessening interest in search, but it may also reflect recent data on lipid lowering agents and heart disease.
• Exercise: pretty steady
• Uber: just to show what something hot looks like. (Another: Bernie Sanders)

Things look pretty steady over the past 10 years, so I decided I could assume a flat baseline for my favorite topics.That’s when it got fascinating. 

• Inline skating (I do this) is dead and so is skateboarding
• Microsoft Excel is stable, but Google Sheets is way way up. Apple Numbers is doing a lot better than I expected.
• Special Needs has a slight downwards trend but Downs Syndrome has plummeted - perhaps due to America's eugenics program. I wonder if the fading of Downs syndrome is responsible for the modest decline in special needs searches.
• Cycling for exercise is somewhat down, with a nice seasonal spike pattern. Mountain biking has declined significantly.
• Cross Country Skiing varies (bet it’s snow depth) but seems constant at a low level
• CrossFit has probably peaked but is still popular.
• AI (artificial intelligence), much to my surprise, is way down.
• Growing use of searches on “Apple Quality” — probably not in a happy way (I’m betting this is Apple corp, not Apple fruit).
• Dementia is a slowly growing concern
• Backpacking is in a gentle decline
• Google seems to have flatlined and even Android is trending down, but Facebook has fallen off a cliff (hard to interpret, it’s so ubiquitous), Apple has slow growth but iPhone is only holding steady. Weirdly, Twitter looks rather like Facebook - not healthy at all.
• RSS. Sob.
• Health Informatics, my professional discipline, has had a big decline since 2004. It feels that way. SNOMED CT is in a lesser decline. On the other hand, family medicine is pretty stable (one weird 2011 peak) even as Geriatrics is in decline (WTF?)
• Carbon tax is off the radar and interest in global warming is way down. Be afraid.
• eBooks are post-peak - a failure to takeoff (I blame the DRM).

Some of these findings line up with my own expectations, but there were quite a few surprises. It’s illuminating to compare Excel to Google Sheets. The Downs Syndrome collapse is a marker for a dramatic social change — the world’s biggest eugenics program — that has gotten very little public comment. I didn’t think interest in AI would be in decline, and the Facebook/Twitter curves are quite surprising.

Suddenly I feel like Hari Seldon.

I’ll be back ...

See also:

• Research the past 200 years of memetic propagation: Google Books ngram viewer 12/2010

Automating medical error: misadventures in medication reconciliation

I recently enjoyed a nasal surgery procedure. More on that in a later post, this one is about a medical error that followed the surgery. It’s a kind of error that fits my professional work in clinical computing (“medical informatics”).

The error, actually multiple errors, showed up in a part of my computer generated post-operative discharge summary labeled “CONTINUE taking these medications”. In the clinical computing industry this is the “medication reconciliation” or “medrec” section…

AHRQ Patient Safety Network - Medication Reconciliation

Patients often receive new medications or have changes made to their existing medications at times of transitions in care—upon hospital admission, transfer from one unit to another during hospitalization, or discharge from the hospital to home or another facility. Although most of these changes are intentional, unintended changes occur frequently for a variety of reasons. For example, hospital-based clinicians might not be able to easily access patients' complete pre-admission medication lists, or may be unaware of recent medication changes. As a result, the new medication regimen prescribed at the time of discharge may inadvertently omit needed medications, unnecessarily duplicate existing therapies, or contain incorrect dosages. These discrepancies place patients at risk for adverse drug events (ADEs), which have been shown to be one of the most common types of adverse events after hospital discharge. Medication reconciliation refers to the process of avoiding such inadvertent inconsistencies across transitions in care by reviewing the patient's complete medication regimen at the time of admission, transfer, and discharge and comparing it with the regimen being considered for the new setting of care.

Most of the electronic health record (EHR) industry more-or-less automated medrec in the 00s. Typically a physician (usually this is a physician task) reviews a list of “existing” (tricky term!) medications as well as “new” meds and, in theory, produces a reconciled list that  fits the patient’s current sate.

That’s the theory; in practice the “existing” medication list is often incorrect.  Additionally, it’s usually quite easy to, with a click or two, replicate the “existing” medication list without the tedious work of actually reviewing it.

Both errors, and more, showed up in the “continue” list I was given for:

• Afrin 2 sprays 2 times a day
• Flonase 50 mcg/actuation
• fluticasone 50mcg 1 spray into each nostril daily
• azelastine 137 mcg 2 sprays into each nostril two times a day.

Let’s count the errors:

• None of these meds are appropriate for my post-op fully obstructed nose. The Afrin and steroid sprays are theoretically harmful, but in practice none of them would go anywhere anyway. So that’s 3-4 errors depending on how one treats Flonase/fluticasone. These is most likely either physician inattention or a process error.
• Flonase and fluticasone are Brand and Unbranded names for the same medication. This is a software error or a data entry/design error (accepting free text meds rather than “coded" meds).
• The Afrin dose and frequency is incorrect, it would be dangerous to use it so often. This is likely a physician error. (I actually corrected this during an office visit, but my correction was evidently ignored.)
• The list omits QNasl. This almost certainly an error in compiling the “existing medication” list, but like all the others it shouldn’t have been on the list post-of. I’ll count this as an error anyway.

So in one medication reconciliation process we have 7 errors, 1 which is probably software (Flonase/fluticasone resolution) and 6 which are physician/process errors likely facilitated by poor software design.

In this case no harm was done. My wife and I are both physicians; we knew to ignore the errors. There might have been a small potential for harm with a non-expert patient, but in practice the nasal meds aren’t going to get far in a post-op obstructed nose. Obviously there’s potential for harm in different cases, which is why “medrec” has been a patient safety goal for the past … well … 25 years or so.

This isn’t a new problem — Emily and I both remember common medication reconciliation errors in the pen and paper era. I suspect, however, that quick-click list merges may make it faster and easier to make the same old mistakes.

It would be nice to think about what we could do differently…

Gene-environment interactions and the modesty of 2014 personalized medicine: Obesity, Reefer madness

Between 2007 and 2008 my work life got unusually exciting. Most of the time I work on software development in well understood aspects of medicine, but back then we were, once again, super-excited about genomics and “personalized medicine”. I made a couple of funded trips to meet with Stanford research teams maintaining genomic ontologies. I had a blast using exciting tools for navigating poorly maintained and unreliable massive web UI databases of gene-phenotype relationships.

At last we were going to realize the NIH predictions of 1994 — 10 years late, but better late then never.

Then the hammer fell. My 2008 post on schizophrenia [1] doesn’t talk about the work I was doing then, but it explains why we gave up. The disorders we cared about, schizophrenia, diabetes, lipid disorders, depression and so on, didn’t have a handful of generic recipes. Turns out there are hundreds, or thousands, or “recipes” for schizophrenia made up of environment (especially intra-uterine) and lots and lots of interacting genes. Even worse — lots of seemingly “normal” minds run on brains built with buggy genomics. Turned out “family” (genetic relative) history was a much more useful guide to predicting disease and treatment than genomic analysis — and that didn’t justify big investments.

Everything stopped, and then health care IT turned from the excitement of personalized medicine to the painful tedium of “meaningful use” and the more scientifically tractable domain of population health.

I still follow the field of course, and there has been slow but interesting progress …

Gene Linked to Obesity Hasn’t Always Been a Problem, Study Finds

… In 2007, researchers discovered that people with a common variant of FTO tend to be heavier than those without it. … Two copies of the gene bring 7 extra pounds — and increase a person’s risk of becoming obese by 50 percent.

… A new study shows that FTO became a risk only in people born after World War II.

… A variant of a gene called AKT1, for example, can raise the risk of psychosis — but only if the carrier smokes a lot of marijuana….

Small progress admittedly, but scientifically interesting. Exercise is good for most things — but we know that for most people moderate exercise [2] doesn’t add much to dietary control of weight. For people with the FTO gene though, exercise might indeed control weight. People with AKT1 are susceptible to persistent Reefer Madness — they really shouldn’t use marijuana [3]. In a related vein, there’s some evidence that the dementia protection of exercise is much stronger in the 14% of Americans with the APOE4 gene variant [4] than in APOE4 negative populations.

Progress — but darned slow. At this rate it will take decades to build what we expected before the year 2000.

- fn -

[1] Quite a good post, if I say so myself. I’d forgotten autism was once considered a variant of pediatric schizophrenia. We’re again merging both of those diagnostic categories.

[2] Extreme exercise is another matter, but one that’s rather hard to study. Though there is this recent NYT article on super-short higher intensity workouts that are to CrossFit as a snack is to a smorgasbord.

[3] Incidentally, marijuana legalization will be a boon to addiction medicine. Investors now include rehab clinics in the category of cannabis business opportunities.

[4] Why is a nasty gene so prevalent? The Wikipedia article mentions APOE4 helps with Vitamin D update — a particular problem in northern europeans. We presume it does have some survival advantage in some settings.

Usability of electronic health records: test cognitive cost first

Obama raised mileage standards for my industry.

Ok, so it wasn’t him personally, and it’s not mileage, and I don’t exactly own the health care “IT” industry. Even so, I can better imagine now what it was like to work for GM in the 70s when mileage standards were first set.

For my industry the ‘mileage standards’ are known as ‘meaningful use’, as in MU1, MU2 and MU3. Despite the confusing name these are effectively increasingly stringent performance standards for electronic health records, akin to mileage and emission standards for automobiles. They’re reshaping the industry, sometimes for better and sometimes for worse. (Should we, for example, measure the value of all of our measuring before we do more measuring?)

The industry has moved through MU1 and is now digesting MU2 with MU3 on the horizon (assuming Obama wins, though Gingrich was a great fan of this sort of thing.) MU3 is still under construction, but one consideration is the inclusion of ‘usability standards’.

For various reasons I’m not thrilled with the idea of setting usability standards, but the term is broad enough to include something I think we really ought to study: The impact of complex clinical documentation and workflow systems on the limited cognition and decision making budget of the human brain…

I’ve written about this before …

Gordon's Notes- Electronic health record use and physician multitasking performance 4/2010

Llamas and my stegosaurus: Living with a limited brain
Some interesting research has come out recently about the processing capacity of brains. For example, that the medial prefrontal cortex can only handle two tasks at once, or that working memory can only handle about 7 items at a time (but what's an item?), or that when people are actively trying to remember something complicated, their impulse control is reduced…

Since then this topic has gotten a bit more attention, particularly from a study of Israeli judges …

Do You Suffer From Decision Fatigue- - NYTimes.com 8/2011

… There was a pattern to the parole board’s decisions, but it wasn’t related to the men’s ethnic backgrounds, crimes or sentences. It was all about timing, as researchers discovered by analyzing more than 1,100 decisions over the course of a year. Judges, who would hear the prisoners’ appeals and then get advice from the other members of the board, approved parole in about a third of the cases, but the probability of being paroled fluctuated wildly throughout the day. Prisoners who appeared early in the morning received parole about 70 percent of the time, while those who appeared late in the day were paroled less than 10 percent of the time…

… Decision fatigue helps explain why ordinarily sensible people get angry at colleagues and families, splurge on clothes, buy junk food at the supermarket and can’t resist the dealer’s offer to rustproof their new car. No matter how rational and high-minded you try to be, you can’t make decision after decision without paying a biological price….

… These experiments demonstrated that there is a finite store of mental energy for exerting self-control. When people fended off the temptation to scarf down M&M’s or freshly baked chocolate-chip cookies, they were then less able to resist other temptations….

Patient care is an endless series of decisions (though over time more behavior, for worse and for better, becomes automatic). All physicians start with a cognitive budget for decision making, and every decision depletes it. Unfortunately using an EHR also consumes decision making capacity – perhaps far more than use of a paper records. There’ve been a few studies over the past fifteen years hinting at this, but they’ve gone largely unnoticed.

So, if we’re going to study ‘usability’, let’s specifically study the impact of various electronic health records on cognitive budgets. We now know how to do those experiments, so let’s put some of that MU3 money to good use, towards supporting tools that enable better decisions – because they’re less tiring.

Think of it as meeting mileage standards through aerodynamic design.

The sharing challenge: access, topic and identity. Why G+ fails.

Setting aside the act of mass datacide that moved Google up my corporate evil scale, G+ suffers from a fundamental Circle problem. It may be an attempt to work around Facebook patents rather than a misguided design, but either way it doesn't work.

G+ provides these tools for publication and subscription:

• A single identity. (In this case, identity is equivalent to a maximal set of Identity-Circles + Public)
• Circle: both Access Control and Topic definition and Subscription-filter option
• Person level blocks

These aren't sufficient. They put far too much of a burden on the publisher to create and maintain a multitude of Circles that pre-coordinate Access Control and Topic definition [1]. The pre-coordination work fails due to combinatorial explosion [2].

A full set of controls looks like this.

• Multiple identity: where identity is a set of access controls and topic definitions.
• Access controls: who can see what.
• Topic definitions: what are the topics, so subscribers who can see a stream can choose what they follow within that stream
• Person blocks: hide all comments from a person

A full set of controls seems more complex, but the workload largely falls on the Publisher, not the consumer -- and the combinatorial explosion problem is resolved. Subscribers choose which topic to follow. Unfollowing all topics is equivalent to blocking a person's posts but not their comments.

Google Reader Social had no access controls (that I remember), but it did allow multiple identities (an identity is equivalent to a subset of topics). The topic controls were very weak (subscribe to tags - almost never used), but the UI made it very easy to pick items of interest from a large stream. The G+ UI makes the combinatorial problem much more significant.

Google has promised pseudonym support. That will be roughly equivalent to a subset operation on Circles. Boolean operations on Circles would also somewhat alleviate the publisher combinatorial problem.

Alleviate, but not eliminate. Sooner or later, G+ will need to separate access control from topic definition.

(I'm grateful to a G+ comment from Peter C that helped me think this through.)

[1] Note too the 3 people on earth who'd probably appreciate this. This is identical to the pre- and post-coordination problems that bedevil anyone who works with concept based knowledge representation ontologies, including clinical terminologies/vocabularies like SNOMED and (yech) ICD-10-CM and ICD-10-PCS.
[2] A Sept 2011 WSJ post on "injury by falling turtle" in ICD-10-CM causes of injury illustrates this also. See #1.