“We should not prescribe specific functionality for the EHR other than interoperability and security.” - John Halamka

“We should not prescribe specific functionality for the EHR other than interoperability and security.”
 - John Halamka

__

Updated, annotated: on the (misnomer) “interoperability” side (which I sometimes refer to as "interoperababble"), from my recurring blog rant.

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 (e.g., text lengths, datetime formats, Boolean/logical, .pngs, bmps, .tiffs, .jpegs etc).

Actually, all digital data are simply collections of “representations” of values coded in the binary ASCII (or the legacy EBCDIC) collating sequence (“under the hood” of all this stuff at the bit/byte level). Yeah, I’m givin’ away my age.

You can’t tell me that a world that can live with, e.g., 10,000 ICD-9 codes (going up soon by a factor of 5 or so with the 2015 migration to ICD-10) would melt into a distraught puddle on the floor at the prospect of a requisite standard data dictionary comprised of perhaps a similar number of metadata-standardized, “strongly typed” data elements spanning the gamut of administrative and clinical data definitions cutting across ambulatory and inpatient settings and the numerous medical specialties. We’re probably already a good bit of the way there given the certain overlap across systems, just not in any organized fashion.

Think about it.

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.

Yet, the alternatives to a data dictionary standard are our old-news, status quo, frustratingly entrenched, Clunkiness-on-Steroids, Nibble-Endlessly-Around-the-Edges Outside-In workarounds — albeit quixotic efforts that keep armies of Health IT geeks employed starting and putting out the fires they themselves started.

Resources better devoted to actual clinical care.

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.

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.

I’m still awaiting substantive pushback (my Twitter pal Chuck Webster thinks an ICDDS would “inhibit innovation”). And, I know – ok? -- that there will still be much programming work to do, even with a truly uniform Data Dictionary Standard in place (that’s a good thing). Moreover, as with any comprehensive, prevailing standard, there will be necessary advances requiring revisions. But, there are conceptually really only two alternatives given the current paradigm: [1] expensive n-dimensional custom point-to-point data mapping, from EHR 1 to EHRs 2-n, or [2] a central data mapping/routing “hub,” into which EHRs 1-n send their data for translation for the receiving EHR.

The complications arising from these two alternative scenarios ought to be obvious, data truncation or otherwise misinterpretation, or “not-found” chiefly among them.

__

As I wrote back in November while attending the NYeC conference:

I have some lingering Interop questions. One goes to the humorous phrase proffered by one of the presenters:

“Smiling Almighty Jesus.”

The point was miscommunication resulting from information garble over time between people. The above refers to a dx of “Spinal Meningitis,” which the fictional elderly patient in the slide got wrong. As it goes to HIE, this aligns with my chronic rant about a data dictionary standard. As I have observed by way of analogy:

True interoperability requires a comprehensive data dictionary standard. Without it, information can become “garbled.” That is, altered during iterative/sequential transmissions. For example, what if you took these sentences and ran them through Google Translate from one language to another — say, [1] from English to Spanish, [2] then from Spanish to French, [3] then from French to German, [4] then from German to Greek, [5] then from Greek to Swedish, [6] then from Swedish to Portuguese, and [7] then back to English?

1. Verdadero interoperabilidad requiere un amplio diccionario de datos estándar. Sin ella, la información puede llegar a ser “confusa”. Esto es, alterado durante las transmisiones secuenciales. Por ejemplo, ¿qué pasa si usted tomó estas frases y las pasó por Google traducir de un idioma a otro – por ejemplo, del Inglés al Español, a continuación, del español al francés, después del francés al alemán, después del alemán al griego, luego del griego al sueco, luego del sueco al portugués, y luego de nuevo a Inglés?
2. Véritable interopérabilité requiert une vaste série de dictionnaire de données. Sans elle, l’information peut devenir “confus”. C’est, séquentielle modifié pendant la transmission. Par exemple, si vous avez pris ces mots et a traversé Google traduire d’une langue à l’autre – par exemple, de l’anglais à l’espagnol, puis l’espagnol vers le français, puis du français en allemand, puis de l’allemand vers grec , puis du grec au Suédois Suédois Portugais après, puis revenir à l’anglais?
3. Echte Interoperabilität erfordert eine breite Palette von Data-Dictionary. Ohne sie können die Informationen zu “verwirrt”. Dies wird sequenziell während der Übertragung verändert. Zum Beispiel, wenn Sie mir das Wort und ging durch Google übersetzen von einer Sprache in die andere – zum Beispiel aus dem Englischen ins Spanische und Spanisch in Französisch und von Französisch ins Deutsche und Deutsch auf Griechisch, dann aus dem Griechischen ins Schwedisch Portugiesisch nach dann wieder auf Englisch?
4. True διαλειτουργικότητα απαιτεί ένα ευρύ φάσμα του λεξικού δεδομένων. Χωρίς αυτά τα στοιχεία για να “σύγχυση”. Αυτό είναι διαδοχικά αλλαχτούν κατά τη μεταφορά. Για παράδειγμα, αν η λέξη και μου περπάτησε μέσα από το Google μετάφραση από τη μία γλώσσα στην άλλη – για παράδειγμα, από τα αγγλικά στα ισπανικά και ισπανικά στα γαλλικά και από Γαλλικά σε Γερμανικά και Γερμανικά σε Ελληνικά, στη συνέχεια, από τα ελληνικά στα Σουηδικά Πορτογαλικά σε συνέχεια πίσω στα Αγγλικά;
5. Verklig driftskompatibilitet kräver ett brett spektrum av data dictionary. Utan denna information till “förvirring.” Detta successivt förändras under transporten. Till exempel, om ordet och promenerade mig genom Google översättning från ett språk till ett annat – till exempel från engelska till spanska och spanska till franska och från franska till tyska och tyska till grekiska, sedan från grekiska till Svenska Portugisiska in sedan tillbaka till engelska?
6. Plena interoperabilidade exige uma ampla gama de dicionário de dados. Sem esta informação a “confusão”. Isso mudou gradualmente em trânsito. Por exemplo, se a palavra e me atravessou tradução do Google a partir de uma língua para outra – por exemplo, de Inglês para Espanhol e Espanhol para Francês e de Francês para Alemão e Alemão para o grego, depois do grego para o Português Sueco em seguida, de volta para Inglês?

And, finally full circle back to English:

7. Full interoperability requires a broad range of data dictionary. Without this information to “confusion.” This gradually changed in transit. For example, if the word and I went through Google translation from one language to another – for example, from English to Spanish and Spanish to French and from French to German and German to Greek, then from Greek to Portuguese Swedish in then back to English?

__

Ouch.

Pull up Google Translate, try it yourself. Pick additional languages. The results can often be quite amusing. (Broadly, Google “Sapir–Whorf hypothesis” for the more general linguistic implications that go to the point.)

As it goes to HIE/”Interoperability,” what I don’t yet know is whether a CDA-compliant CCD/CCR ePHI transmission arrives as “read-only” in every instance, or whether it can go from the incoming HL7 message and be parsed into the destination EHR database fields where the data can subsequently be edited (“read-write” — I would require appending a new record in order to preserve the original data. It’s an ePHI “chain of custody” issue).

There are HIPAA considerations here, specifically 45 CFR 164.312 (Technical Safeguards — data authentication), and requisite audit log capture. Moreover, given the lack of a single HIT RDBMS Data Dictionary standard, might ePHI undergo slip-through-the-cracks modifications strictly resulting from point A to point “n” sequential transmission? Now, if a HIE CDA transmission is read-only, garble concerns would be allayed (assuming a data dictionary standard), but…

I will defer to others further down in the weeds on this issue.

___

CODA:  Perhaps a condition of ONC/CHPL EHR certification ought be the handing over of your data dictionaries comprising yor RDBMS schema – with confidentiality stipulations, of course – so that ONC/NIST could study and assess precisely how much de facto metadata standardization already exists informally, in order to obtain a clearer picture of just how much full interop data standardization work needs to be done.

It might well be less than we think. But, until we examine the data dictionaries, we cannot know. Something worthy of federal study, IMHO.

Below, OpenEMR dictionary/schema snippet, from my July 2012 post "Analytics - SAS, R, SQL, EHR database schema. An old school data miner's ramble involving the intersections of workflow, audit logging, and CER, etc."

UPDATE 

Tangentially apropos?

5 examples of how the languages we speak can affect the way we think
___

More to come...