Its been five years since the start of the symtym blog, this will be the last post. However, the blogging will continue at quanta vie. As many know, it is at times difficult (in terms of content generation) to keep a blog going, let alone trying to keep two blogs going with content. quanta vie was started in January 2009, pretty much as a fresh start, although several factors played significantly:

• desire to start a clean (technically) blog where everything is written in strict XHTML;
• transient problem with Russian porn on symtym (my fault: enabled FTP), resulting in very messed up Google Analytics;
• improved blogging work–flow using MarsEdit and BBEdit;
• no need to go back and clean up all the bad HTML in symtym, lack of tags, etc.; and
• five years for one endeavor seems about right.

I thank you for your patronage and attention over the years here at symtym—please follow the move to quanta vie. Also, I’ll continue to microblog on Twitter.

See EMR Adoption Model

Considering the problem of exsanguination, a physician will look for the anatomical pressure–points to staunch the flow of blood. In this setting, any breach in bodily surface integrity serves as a new conduit of flow for blood diverted from a compressed pressure–point. More breaches increases blood loss and decreases the effectiveness of any singular attempt to control flow with the application of pressure. Jumping from circulation to healthcare information, breaches in the body surface is analogized to the plethora of data silos available to be compromised.

The government is in the process of massively funding the digitalization of the paper–laden healthcare industry. As part of the implementation, every provider: hospital, pharmacy, physician, etc., will be implementing various forms of EHRs. For every singular EHR, pertaining to a single patient–provider pairing, there will be at least two physical representation instances with the potential for compromise. One instance is the physical representation in a permanent data store (i.e., database). One instance is the physical representation on a presenting device to the provider (e.g., monitor or PDA). Both instances constitute a data silo (i.e., a place where data resides), albeit, one permanent and one transitory.

Image 1. N–Silos Problem

More levels of compromise emerge when for any given EHR, pertaining to a single patient–provider pairing, physical instances are created due a need to exchange healthcare information amongst providers. Here, because of the exchange, transient physical instances may exist in a RHIO or HIE and served up to many additional EHRs (e.g., pharmacy, imaging center, consultant, etc.) on a transactional basis. In such a chain of exposure, privacy is protected and security is maintained only to the extent of the weakest link—the N–Silos problem.

Image 2. Single–Silo Problem

Gedankenversuch: the single–silo problem. Can healthcare information be maintained and utilized in a manner that minimizes the privacy and security risks inherent in N–Silos? Attributes:

• Single database environment (e.g., cloud analogy)—the permanent instance
• Transitory instance are transactionally created in secured web–browser (e.g., a device where the only operating software is a web–browser with no data leakage in or out of the browser)
• Secured broadband linkage between permanent and transitory instances.
• HIT infrastructure, with burdens, changes from provider–centric to system–centric and accentuates the primacy of privacy and security issues.

When considering the present understanding of PHR, perhaps the “P” for “personal” is not as important as “P” being for prevention…

In medicine, exsanguination is the uncontrolled loss of blood from the body that will cause death. It’s caused by an external insult to the body (i.e., traumatic injury) or from an internal derangement that compromises the integrity of a bodily surface (e.g., esophageal varices). By either mode, the protective nature of the body is breached leading to death, if left uncontrolled, or potential significant disability even if control is gained. The keys to gaining control in the setting of potential exsanguination are prevention and mitigation—blocking or staunching a breach.

Whether an external or internal breach leads to exsanguination, it can be further characterized in terms of whether the breach was by an intentional act (e.g., gunshot) or by a negligent act (e.g., motor vehicle accident). The distinction is important in that it speaks to issues of prevention.

Dr. Johnson from the Center for Digital Strategies at the Tuck School of Business at Dartmouth as authored a paper: Data Hemorrhages in the Health-Care Sector, (PDF, covered here), that likens the threat of P2P–clients to informational hemorrhage. Johnson discusses two intentional causes for this informational hemorrhage: healthcare fraud and identity theft.

Image 1. “Consequences of Data Hemorrhages” (from Johnson)

Contrary to the conclusion in Image 1, healthcare fraud and identity theft are not the consequences of “data hemorrhages,” but rather the causal events. These causal events may have either an intentional or a negligent nidus. Intentional in terms of installing P2P–clients on hardware with the intent to obtain information by fraud or theft. Negligent in terms of failing to protect one’s hardware from the installion of P2P–clients or failing to control the installation of P2P–clients by third–parties (e.g., employees).

Image 2. Informational Exsanguination

With the current impetus to digitalize the paper–laden healthcare industry with the current governmentally–incentivized move to EHRs, is the movement alone the singular major hurdle? Or, as Johnson suggests, the potential for hemorrhage of healthcare information so great that we are only beginning to appreciate—because of the increasing need to mitigate and staunch the blood flow? The “E” in EHR may, with this appreciate, not stand for the mode of storage, but rather for the ongoing problem—exsanguinating health records…

Doing some three Rs today: reading, ’rithmatic, and ’riting… Just got HIMSS’s Personal Health Records the other day and working my way through the text. Also read an excellent post by John Moore on HIEs, SaaS, and EHRs.

Healthcare on many levels is nothing more than a transactional relationship between a clinician and a patient. The currency is information. What would our present economy look like if currency was still physically married to paper–form. Absurd! Yet we readily accept this absurdity when it comes to the currency of healthcare—marriage to a structural form no less dissimilar from paper. Compounding this conceptual disconnect from modern economies is the equivalent of stuffing one’s money in a mattress—the file, the office, the hospital, the insurer, the pharmacy, etc. Do we need a federal or central conceptualization for our healthcare currency?

Similarly, healthcare transactions are the most personal transactions any person conducts. Yet in comparison to all other personal types of transactions the least under individual control. Not only is one’s money in a mattress, but it’s distributed among many mattresses in many homes. The mattress analogy only goes so far though, suffice it to say it accentuates the need to separate information content (contextual, semantical) from information presentation (i.e., storage). To the point: federal dollars need to be spent on solutions that treat healthcare currency like economic currency. Banks don’t make money by having vaults, they make money when currency is allowed to freely transact. The healthcare economy disparately needs to bust some paradigms.

From HIMSS’s Personal Health Records

The reality of the current HIT adoption landscape is that:

• Most clinicians are not using EMRs.
• The vast majority of healthcare enterprises that have implemented EMRs do not exchange data beyond the enterprise.
• Few if any of the RHIOs developed to date have fundamentally included a PHR.
• The data for other healthcare constituents such as payors, pharmacies and others also generally exist as silos—therefore, it is difficult to aggregate data in a PHR, particularly due to the constraints of limited health data standards facilitating the exchange of complex clinical or behavioral data.

Modified from Chilmark Research

So how would they do it?

Using SaaS solutions HIE vendors would [connect]:

• 200 HIE/RHIOs nationwide
• 6,250 hospitals
• 100 national and regional reference labs
• 660,000 physicians
• Annual software cost: $500M
• Annual operation cost (@2:1 operation:service): $1B

Putative available annual funding for NHIN: $1.5B.

Tethers

A tethered–PHR is a service offered by a heatlhcare enterprise to a patient. At any given time a patient may have incompatible and incomplete tethered–PHRs equal to the number of enterprises where he/she is considered a patient (plus all the enterprises where patient rationships have ended). For any given instance, the number of tethered–PHRs needed in the US is the product of the current population and all the potential enterprises.

1. 306,000,000 residents in the United States
2. 6,250 hospitals
3. 100 national and regional reference labs
4. 660,000 physicians
5. 200 HIE/RHIOs nationwide

A × B × C × D = 1.3 × 10²⁰ tethers
Available funding per tether: $0.000000000012

Pipes

Piping the alphabet–soup of health records and tethered–PHRs is the bailiwick for the (“200”) to–be–funded and constructed HIEs/RHIOs. Most will have a funding nidus in federal or state dollars—perhaps not as rare as hen’s teeth yet. The sustaining funding will be from the enterprises (broadly construed).

1. 306,000,000 residents in the United States
2. 6,250 hospitals
3. 100 national and regional reference labs
4. 660,000 physicians
5. 200 HIE/RHIOs nationwide

A × B × C × D × E = 2.5 × 10²² pipes/tethers
Available funding per pipe/tether: $0.000000000000059

Cloud

Wonder if the tethering, as presently conceived and implemented, is backwards? Wonder if the tethering, instead of being parochial, proprietary, structural and static become functional and dynamic? As now implemented, a PHR is either tethered to an enterprise EHR or a free–product that may have early integrative features with existing enterprise EHRs. Change the anchor point of the tether to the PHR—what better unchanging anchor point is there than the patient. Enterprise–specific EHRs (when necessary) are functionally created dynamically. Tethers become functional instances within the life–span of a PHR. And, the pipes already exists—the internet.

Perhaps the perceptional need for HIEs/RHIOs is the digitial–relic of paper records traveling in pneumatic–tubes. The necessity for the pneumatic tubes is because of our fixed structural conceptualizaiton.

1. 306,000,000 residents in the United States
2. 6,250 hospitals
3. 100 national and regional reference labs
4. 660,000 physicians
5. 200 HIE/RHIOs nationwide

A = 3.06 × 10⁸ cloud instances
Available funding per cloud instance: $4.90

If all we get from the economic stimulus package is $1.5B per year, then it seems $4.90 per year would be more than adequate to give every resident in the United States a PHR in the NHIN—BYOI—bring your own internet… Besides, we get the added benefit of unstuffing the mattresses…

Possibilities:

• CPOE
• EHR
• EMR
• PAPER
• PBHR
• PHR
• ePHR
• RPR
• THR
• QHR
• WHR

Modified (with apologies to Tolkien) from Wikipedia, the free encyclopedia…