I read a wide range of articles and posts on a daily basis.Many of them are aimed at software developers and entrepreneurs. At least once each year or so, I run across a blog post that takes the very adamant stance that programming is not really related to math. The interesting thing is that many professional programmers in their comments strongly agree with that sentiment. And, to be honest, I saw no strong connection between programming and mathematics until I tried to get a better understanding of clinical workflow. As it turns out, programming is not simply related to mathematics, programming is mathematics..."CONSIDER TWO SETS"
Susanna Epp, in Discrete Mathematics with Applications, Fourth Edition, offers this view of discrete mathematics.
Discrete mathematics describes processes that consist of a sequence of individual steps. This contrasts with calculus, which describes processes that change in a continuous fashion. Whereas the ideas of calculus are fundamental to the science of technology of the industrial revolution, the ideas of discrete mathematics underlie the science and technology of the computer age.Over the course of one’s math education, many formulas are learned and the algorithms used to compute their results are internalized. But what happens when a function must be computed for sets containing words and no tried-and-true formula exists? An algorithm is still required.
Consider two sets. Set X = {Jones, Green, Smith, …} and represents patients at a large provider organization who must be assigned to a primary care provider. Set Y = {Brown, Doe, Gray, …} and contains the organization’s primary care providers (PCPs). A decision is made to assign each patient to a PCP. Here are the rules: 1) every patient must have a PCP, 2) no patient may have more than one PCP, 3) once a provider has reached 100 patients, no more patients can be assigned until all other PCPs have at least 100 patients.
One way to approach this algorithm might be:
WHILE Unassigned Patients > 0
BEGINThis algorithm computes a function between sets that do not contain numbers. This is math, and this is programming. The rules that constrain the algorithm’s operations are similar to rules such as “no division by zero” or “place the number with the fewest columns on the bottom” when multiplying two numbers.
Select patient from Set X;
IF patient already has a PCP
THEN Select next Patient
ELSE
Select PCP from Set Y
IF PCP has >= 100 Patients
THEN Select New PCP
ELSE Assign Patient to PCP
END …
Discrete mathematics covers many topics. Logic, functions, relations, algorithmic efficiency, graphs, sets, proofs, discrete probability, and combinatorics are taught in typical introductory courses, and usually only to math and computer science majors, which explains why most have never heard of discrete math. The algorithm above makes use of logical implication (IF, THEN), sets, and functions.
Relations are assumed to have been a by-product of relational databases
Functions are a type of relation. Relations are more general and have fewer rules. Relations may occur between an arbitrary number of sets. Like functions, they require algorithms to compute outcomes. The outcome of a relation is a tuple. For example, given the following sets: providers, patients, drugs, and dates, one could create an algorithm for a relation in which a provider selects a drug from a formulary, and assigns it to a patient on a specific date: (Doe, Jones, Lasix, 9/15/2014). The resulting tuple represents the relation “Current Medication List.” The rules are: the provider must be the patient’s PCP; the drug must be in the formulary; and the patient cannot be taking any interacting drugs. From this example, it can be seen that relations are common in health care (problem list, prescription, visit history, etc.). Relations existed prior to the invention of relational databases...
[G]iven the following sets: providers, patients, drugs, and dates, one could create an algorithm for a relation in which a provider selects a drug from a formulary, and assigns it to a patient on a specific date: (Doe, Jones, Lasix, 9/15/2014). The resulting tuple represents the relation “Current Medication List.”Nice. Having begun my white collar career as a 3GL programmer, I understand where he's coming from -- notwithstanding that my "discrete/finite math" acumen is by now a long-atrophied artifact of my distant undergrad days.
OK, let's indeed "consider two sets" (or "n" sets) from a metadata perspective, in light of the foregoing "what happens when a function must be computed for sets containing words and no tried-and-true formula exists?"
Yes, in an EHR we have "structured data" (e.g., integer and floating-point numeric data and "word" acronyms comprising code set entries), and "unstructured data" (e.g., actual "words" comprising free-form narrative fields captured in the RDBMS -- everything from the Admin/Demographics to pieces of FH, SH, PMH, Active Meds, Active dxs, CC, HPI, ROS, and case narratives in the progress note).
Now, on the horse-already-out-of-the-barn "interoperability" front these days, everyone continues to nibble from the outsides in, with a primary focus on jiggering together various kinds of proxy "unique patient identifier," given our political refusal to assign one nationally, like the beleaguered Social Security number (The Medicare HIC number, though, is in effect precisely that; a Social with and alphabet character appended).
One recent comment from the ONC Nationwide Interoperability Roadmap Community Home:
Attribute based identity services are critical given that the US does not have a single identification number per person. Even with a single identifier, there are errors in attribute updates like married name, SSN, or even changes in biometrics. Therefor [sic] a smarter reconciliation solution takes advantage of probabilistic matching algorithms of key attributes of a person. For example: first name, middle name, last name, SSN, DoB, finger print, hand print, retinae, facial recognition. Any 3 of these attributes when correlated provide a 99.999% match. A smart identity service allows for the updating of these attributes as a service (cloud based preferred) so that all applications can subscribe to the service. Moreover, attribute management by the patient enables access by other entities as determined by the patient. This sets the stage for patient empowered, patient driven, patient centered models of care, as all health IT systems ultimately depend on robust “Identity Services”.Gotta love the "99.999%" assertion. Dude, you can't back that soothing claim up empirically. Such recombinant matching efforts may well be fairly precise relative to provincial single key PID alternatives, but in the programming and data world I came from, you claim "99.999%," you have to be ready to show to the auditors that you can discriminate statistically from between "99.998%" and "100%" in repeated trials -- a.k.a. "significant figures rounding."
In a world of students now taking their (subjective ordinal rank) GPA's out to 4 decimal places, we've lost sight of such material nuance.
Irrespective of such pedantic nitpicking, we can all agree that a clean (approaching 100% accurate), "no dupes," no nuls" PID will be critical for interop. Perhaps near-universal deployment of biometric factors into a "two-factor auth" ID will mitigate the concerns (though you can just hear the angry cries from TinFoilHat-istan). But, I see a salient secondary concern as well, one that goes back to my rant regarding The Interoperabiity Conundrum.
One.Single.Core.Comphrehensive.Data.Dictionary.Standard
One. That’s what the word “Standard” means -- er, should mean. To the extent that you have a plethora of contending “standards” around a single topic, you effectively have none. You have simply a no-value-add “standards promulgation” blindered busywork industry frenetically shoveling sand in the Health IT gears under the illusory guise of doing something goalworthy.
One. Then stand back and watch the private HIT market work its creative, innovative, utilitarian magic in terms of features, functionality, and usability. Let a Thousand RDBMS Schema and Workflow Logic Paths Bloom. Let a Thousand Certified Health IT Systems compete to survive on customer value (including, most importantly, seamless patient data interchange for that most important customer). You need not specify by federal regulation (other than regs pertaining to ePHI security and privacy) any additional substantive “regulation” of the “means” for achieving the ends that we all agree are necessary and desirable. There are, after all, only three fundamental data types at issue: text (structured, e.g., ICD9, those within other normative vocabulary code sets, and unstructured, e.g., open-ended free-form SOAP note narratives), numbers (integer and floating-point decimal), and images. All things above that are mere “representations” of the basic data...
Why don’t we do this? Well, no vendors want to have to “re-map” their myriad proprietary RDBMS schema to link back to a single data hub dictionary standard. And, apparently the IT industry doesn’t come equipped with any lessons-learned rear view mirrors.
That’s pretty understandable, I have to admit. In the parlance, it goes to opaque data silos, profitable “vendor lock,” etc. But, such is fundamentally anathema to efficient and accurate reciprocal data interchange (the “interoperability” misnomer) that patients ultimately need and deserve...
Visualize going to Lowe’s or Home Depot to have to choose among 800+ ONC Stage 2 CHPL Certified sizes and shapes of 120VAC 15 amp grounded 3-prong wall outlets.Consider that no clinical datum has any actionable patient or provider value in isolation. For one thing, as a patient, you get a abnormally high lab analyte result back, and you'll be anxiously demanding a re-do promptly. Moreover, the most fundamental measures of, say, BP, pulse, temp, weight, blood or UA parameters, etc derive their dx significance from their mutual context (often in terms of the one-to-many flowsheet trending variety).
Imagine ASCII v3.14.2.a.7. Which, uhh…, no longer supports ASCII v2.05.1 or earlier…
Ya with me here, Vern?
NIST/ANSI/ISO Health IT ICDDS – Interoperability Core Data Dictionary Standard...
For that context (and its diagnostic utility) to be precise over time, you benefit from metadata standardization. Now, within the "walls" of a single EHR, this is not an issue -- with the exception of those posed by data entry errors that are the bane of all digital IT-based enterprise. But, once you venture outside the walled gardens / data silos to exchange patient data (the "interoperability" misnomer), Dr. Carter's "tuples" are vulnerable to the iterative and recursive messes of "error propagation" and dx analytic degradation, as repeated infusions of data from myriad non-metadata-standardized sources frequently dirty up your data.
See also my July 4th post Interoperababble update.
HIT NEWS UPDATES
AMA presses for better EHRsThe usual gripes.
Calls for design overhaul to boost usability
Docs still unconvinced of EHRs' worth
Meanwhile, half of practices are girding for big headaches caused by ICD-10
__
ERRATUM: Medicine 2064 with Dr. Daniel Kraft
This in the video (below) bothered me a bit.
I've read elsewhere that the planet's "carrying capacity" is now estimated to be ~ 9 billion people. From one of my other blogs:
We comprise roughly 5% of world population, while consuming 25% of its resources. As climate scientist Tim Flannery observed in his book "The Weather Makers,"OK, sustainable human population "carrying capacity" may well be a moving target. Nonetheless, one cannot but look at developments such as overpopulation and anthropocene global warming with rational concern. The glorious new future of health care will no doubt have its hands full.
In 1961 there was still room to maneuver. In that seemingly distant age, there were just 3 billion people, and they were using only half of the total resources that our global ecosystem could sustainably provide. A short twenty-five years later, in 1986, we had reached a watershed, for that year our population topped 5 billion, and such was our thirst for resources that we were using all of Earth's sustainable production.In effect, 1986 marks the year that humans reached Earth's carrying capacity, and ever since we have been running the environmental equivalent of a budget deficit, which is sustained only by plundering our capital base. The plundering takes the form of overexploiting fisheries, overgrazing pasture until it becomes desert, destroying forests, and polluting our oceans and atmosphere, which in turn leads to the large number of environmental issues we face. In the end, though, the environmental budget is the only one that really counts...
...By 2001 humanity's deficit had ballooned to 20 percent, and our population to over 6 billion. By 2050, when the population is expected to level out at around 9 billion, the burden of human existence will be such that we will be using -- if they can still be found -- nearly two planets' worth of resources." [pp. 78-79]As I wrote in a prior post in response:
We can choose to continue to drill, mine, cut down, and grind up the planet in pursuit of short-term business-as-usual, unevenly distributed consumerist comforts, but the day of tragically harsh mass reckoning draws ever closer. The lessons to be drawn from Jared Diamond's "Collapse" are compelling in this regard. There is no shortage whatsoever of constructive and remediative work to be done in support of a sustainable and broadly prosperous future for all of humanity. But, let's not kid ourselves that an unregulated "invisible hand free market" alone will suffice to insure its emergence. Recent economic history alone refutes that assertion.Complicating this unsustainably destructive "consuming the future" market ethos, consider this: In this decade, more than 40% U.S. corporate profits have come from the "financial services sector," with perhaps 3/4 of those "profits" accruing from iterative, non-tangible-value-adding, grotesquely leveraged "fee income" that fueled the recent economic bubble and caused the current recession.
Let me repeat what I wrote a few days ago (scroll back up a bit):
"The most excruciating of economic and ethical choices inescapably await us. And, while much of the public continues to sleepwalk into this morally daunting future (abetted by the well-funded stultifyingly fear-stoking fallacies of corporate status quo interests), we really don't have the luxury of time to continue to kick this policy can down the road. Sadly, it appears to a worrisome degree that that is precisely where we're headed at best."
I would love to be wrong. I would love to hear from others, too. I certainly don't have all the answers.
__
INTEROPERABABBLE UPDATE
Hospital execs: Meaningful Use, interoperability discussions can't be separatedDr. Carter makes an interesting observation over at THCB:
September 17, 2014 | By Dan Bowman
Provider-based health IT professionals stated their case for why they need more flexibility for Meaningful Use Stage 2 during a briefing at the Russell Senate Building in the District of Columbia on Tuesday.
The often tension-filled discussion, hosted by the College of Healthcare Information Management Executives, included hospital CIOs Randy McCleese of Morehead, Kentucky-based St. Claire Regional Medical Center and Marc Probst of Salt Lake City-based Intermountain Healthcare, as well as Peter Basch, medical director for ambulatory EHR and health IT policy at MedStar Health in the nation's capital; William Bria, president of the Association of Medical Directors of Information Systems; and ONC Interoperability Portfolio Manager Erica Galvez.
Following comments from Galvez that Meaningful Use is only "one lever" in the push for interoperability and that the industry needs to "shift the conversation from being so Meaningful Use-centered to thinking about other business drivers," Probst said that as much as he'd like to, separating the incentive program and interoperability conversations isn't an option.
"We can't ignore Meaningful Use" because of the incentives and penalties, Probst said. "If indeed we do move on Oct. 1 with a 365-day reporting period ... it leaves very little flexibility. I know we want to move the discussion from Meaningful Use ... but it is part of the discussion and it does make it a challenge to move to this next part of the discussion. ... We're still making decisions about Meaningful Use Stage 3 that we have yet to introduce to the population. I don't think we can ignore the fact that Meaningful Use is sitting over" our heads...
Dr. Carter, in that very comment thread, agreed with my argument for a standard data dictionary, btw.
[U]sability is an important trait of good software. However, current EHR systems are doing exactly what they were designed to do. Current EHR systems were conceived as electronic versions of paper charts. Paper charts are passive; they do not assist in patient care. Rather, they exist to provide a record of what has occurred. Using the paper chart as a design guide resulted in electronic systems that emulated their paper forebears. Thus, EHR systems are geared toward data collection and reporting.
EHR systems do not contain models of clinical work. They do not have user-configurable workflows. They are not aware of the cognitive needs of users, and they have no representation of collaborative care. No, they are what they were designed to be: electronic repositories of patient data. And, since the advent of MU, they have become even more focused on administrative and regulatory requirements.
I am greatly encouraged to see a medical professional organization take an active role in creating software that supports clinical care delivery. However, turning an electronic data repository into a clinical care system that intimately supports clinical work is going to be a huge renovation project. Perhaps it would be better to start from scratch using clinical work as the design paradigm instead of the paper chart. After all, building from scratch is cheaper and less problematic than renovating...
"A data dictionary standard or a standard data set, which might well be the same thing, would be a good start."I would argue that it's fundamental. The reason that math works -- algorithmically -- owes at root to the uniform standardization of what the symbols (operators and operands) mean (the "metadata"). With respect to the "math" that is EHR programming, on the non-integer/rational number side of things in particular, the lack of strict standardization and the random variability among the metadata inevitably begets the interoperababble that dogs our efforts to this day.
AMA ON EHR "USABILITY"
___
The government needs to act quickly to remedy the impaired usability of electronic health records (EHR) if the technology's touted benefits are to be realized, AMA Board of Trustees Chair Steven J. Stack, MD (left), told officials during a federal hearing last week.
"The AMA and most physicians believe that, done well, EHRs have the potential to improve patient care," Dr. Stack, an emergency physician in Lexington, Ky., said during his 30-minute testimony (pdf). "At present, however, these EHRs present substantial challenges to the physicians and other clinicians now required to use them."
He emphasized that many of today's EHR systems require significant changes before they can deliver the promised outcomes. Referring to Medicare's meaningful use program, he pointed to undesired consequences of pushing EHR systems on physicians before the technology was completely ready for prime time.
"Attempting to transform the entire health system in such a rapid and proscriptive manner has compelled providers to purchase tools not yet optimized to the end-user's needs and that often impeded, rather than enable, efficient clinical care," he said.
He noted that physicians are "prolific technology adopters" but that adoption of EHR systems has required federal incentives because the technology still is "at an immature stage of development."
"EHRs have been and largely remain clunky, confusing and complex," he said.
According to a recent survey by AmericanEHR Partners, physician dissatisfaction with EHR systems has increased. Nearly one-third of those surveyed in 2012 said they were "very dissatisfied" with their system, and 39 percent said they would not recommend their EHR system to a colleague—up from 24 percent in 2010.
Dr. Stack spoke at a "listening session" hosted by the Centers for Medicare & Medicaid Services (CMS) and the Office of the National Coordinator for Health Information Technology (ONC), a division of the U.S. Department of Health and Human Services (HHS). The agencies coordinated the session to examine how a marked increase in code levels billed for some Medicare services might be tied to the increased use of EHRs.
Dr. Stack noted that some Medicare carriers have begun denying payment for charts that are too similar to other records.
"In this instance, even when clinicians are appropriately using the EHR, a tool with which they are frustrated and the use of which the federal government has mandated under threat of financial penalty, they are now being accused of inappropriate behavior, being economically penalized, and being instructed ‘de facto' to re‐engineer non‐value‐added variation into their clinical notes," he said. "This is an appalling Catch‐22 for physicians."
Dr. Stack advised officials that three key actions are necessary to rectify these issues with EHR systems:
The AMA will continue to work with federal agencies to improve EHR systems and the Medicare meaningful use program.
- The ONC promptly should address EHR usability concerns raised by physicians and add usability criteria to the EHR certification process.
- CMS should provide clear and direct guidance to physicians concerning use of EHRs for documentation, coding and billing.
- Stage 2 of the meaningful use program should allow more flexibility for physicians to meet requirements as EHR systems are improved.
More to come...
.
