Search the KHIT Blog

Showing posts sorted by relevance for query interoperababble. Sort by date Show all posts
Showing posts sorted by relevance for query interoperababble. Sort by date Show all posts

Thursday, October 2, 2014

Will the API be the savior of Health IT "interoperability"?

From FierceHealthIT:
JASON Task Force pushes for narrowed MU Stage 3 focusing on interoperability
October 2, 2014 | By Susan D. Hall


Meaningful Use Stage 3 requirements should be narrowed to more closely focus on interoperability, the Office of the National Coordinator for Health IT's JASON Task Force recommended in a meeting Wednesday.

At its September meeting, the task force pointed out that the JASON report found that Meaningful Use's Stage 1 and 2 had not achieved "meaningful interoperability" and stressed a need to create a unifying software architecture using application programming interfaces...


'Learning the lessons from Meaningful Use Stage 2, the more we expand the complexity of Meaningful Use requirements, both on providers and vendors, the less capacity they have to do novel things. This is proposing that there be sort of a bargain here, which is to say if we really care about this, we should narrow the scope of Meaningful Use Stage 3 and associated certifications to focus on interoperability … and in return set a higher bar for interoperability, specifically related to the development of public APIs," explained co-chair Micky Tripathi.

The draft report also recommends that ONC develop a public-private vision and roadmap for a nationwide coordinated architecture for health IT. It calls for a coordinated architecture tapping into the dynamism of the market to foster innovation rather than a top-down directive. That architecture should be based on the use of a public API that enables data- and document-level access to EHR-based information.

Its recommendations include prohibiting vendors and providers from blocking access to the public API for competitive or proprietary reasons...
What is an "API"?
In computer programming, an application programming interface (API) specifies a software component in terms of its operations, their inputs and outputs and underlying types. Its main purpose is to define a set of functionalities that are independent of their respective implementation, allowing both definition and implementation to vary without compromising each other.
Below, JASON REPORT Appendix E:  Possible Implementation Pathway for Public API
The following diagram maps current standards and approaches to JASON-specified gaps.


More "Interoperababble"?
Addressing problems through better EHR designs cannot be done piecemeal. It requires a holistic view of clinical work that can be modeled and then used as a basis for EHR design. 

- Jerome Carter, MD
To the extent that a "holistic view of clinical work" necessarily has to include structured data and narrative data transparency and seamless data exchange (the "interoperability" misnomer), a comprehensive (non-piecemeal) data dictionary standard would comprise the simplest and sturdiest interop foundation, IMO (and, no, it would not be a panacea).

Now, for the sake of simplicity, assume n(n-1) "API sets" (each defining the complete data interchange specs for all data variables comprising the elements of the respective point-to-point EHRs). As of today, (Oct 2nd) ONC-CHPL lists 456 "Complete ambulatory and inpatient 2014 Certified systems" alone (in contrast to 1,848 total systems, modular and complete).

Let's make it simpler. List, say, 10 popular EHRs at random:
  1. eClinicalWorks
  2. e-MDs
  3. Amazing Charts
  4. athenaHealth
  5. NextGen
  6. Practice Fusion
  7. Epic
  8. Cerner
  9. SOAPware
  10. Allscripts
Never mind "versions / releases." Just 10 EHR products. Each of them will have to interface via unidirectional APIs with 9 others. n(n-1), 10(9)=90.

You might well counter "screw point-to-point; do a hub and spoke translation architecture." OK, I'd buy that, nominally. Nonetheless I fail to see the material difference.


The point-to-point data element exchange translation would still have to happen somewhere.
__

FROM INTEROPERABABBLE TO HADOOP-IGOOP

Does Hadoop Mean the End of the Data Model?
by Richard Gerbrandt and Steve Dine, OCT 2, 2014


The development of Hadoop and the Hadoop Distributed File System has made it possible to load and process large files of data in a highly scalable, fault tolerant environment. The data loaded into the HDFS can be queried using a batch process provided by MapReduce and other cluster computing frameworks, which will parallelize jobs for developers by distributing processing to the data located on a pool of servers that can be easily scaled.

The Hadoop environment makes it easy to load data into the HDFS without needing to define the structure of the data beforehand. The usage of the Hadoop environment naturally raises the question:

Does Hadoop mean that data models are no longer required?
The answer to this question lies in the purpose of a data model and the needs of this type of environment.

The Hadoop Method

Assuming data is [sic] processed using MapReduce, the definition, or layout of the data structure that was loaded into HDFS, is defined within the MapReduce program. This is referred to as “late-binding” of the data layout to the data content. This approach frees the developer from the tyranny of the early-binding method, which requires that a data layout be defined first, often in the form of a data model. This is the approached used by relational databases, which also supports constraints for enforcing business rules and data content validation.

The natural result of separating the data content from the data structure is that the MapReduce program becomes the place where the two are linked. Depending on the data processing needs, this may or may not be a complete data structure definition. In addition, each developer will define this mapping in slightly differing ways, which results in a partial view that makes unified definition hard to assemble.

The late-binding of data content to the data structure essentially places the developer as the middleman between the data and the data consumer since most data consumers are not MapReduce trained. Hadoop requires that the developer know how the data is laid out in the file, its format, whether it is compressed or not, and the name of the file(s), every time a new MapReduce program is developed. This late-binding approach requires the same work be repeated over and over again...
Lordy. Read all of it. Fetch some Advil and Dramamine first.
...The use of a Data Structure Model provides a means to capture data source definitions, capture the appropriate metadata and define any relationships that exist between the data sources. The Data Structure Model can provide data source definitions to both the big data and enterprise data architecture worlds.

The use of Hadoop has not brought an end to the need for data models but rather requires them to provide a connection to enterprise data architecture environment.
Do I really have to spell out the potential Health IT problems here? Yeah, let's "repeat the same work over and over again," via legions of "middlemen." Kinda like, well, point-to-point or hub-spokes API's? At some point, you have to have data map / metadata consistency, early vs late binding theory notwithstanding (scroll down in the link). What might suffice tolerably for aggregated population health Big Data studies is a far cry from what Dr. Carter refers to above as the need for a patient encounter level "holistic view of clinical work" aided by seamless, accurate data exchange ("interoperability").

MORE INTEROPERABABBLE

From Health Data Management:
Fridsma: Health IT Requires Different Types of Interoperability

At a minimum, there are three types of interoperability required to achieve an interoperable health IT ecosystem, according to Doug Fridsma, M.D., ONC’s outgoing chief science officer.

Speaking this week at AHIMA’s 2014 conference in San Diego, Fridsma made the case that health IT requires all three types of interoperability--semantic, syntactic, and information exchange. “If you exchange the information and the codes don’t match or it’s a proprietary set of codes, you’ve got the information but you have no idea what those codes mean,” he argued. “Semantic interoperability is about the vocabularies and syntactic interoperability is about the structure.”

The end result, Fridsma said, is to have the ability of systems to exchange information and to use the information that has been exchanged, while taking advantage of both the structuring of the data exchange and the codification of the data including vocabulary—with the receiving systems able to interpret the data.

According to Fridsma’s definition, interoperability is the “ability to exchange information and the second part is to use the information that’s been exchanged,” and “being able to use it is all about semantic interoperability and understanding the information that’s there.”...
Yeah, of course, take some blinding-glimpses-of-the-obvious concepts and glom them up with obtuse ivory tower nitpicky jargon. At root, we need a data/metadata dictionary standard -- as Dr. Carter would say, "standard data." Perhaps Dr. Fridsma's ONC geek-speak is a necessary and good thing at some level, but absent a solid foundation, it's difficult to see how we erect a durable and useful complex "interoperable" health IT/HIE structure based on myriad proprietary elements.

Visualize going to Lowe’s or Home Depot to have to choose among 1,848 ONC Stage 2 CHPL Certified sizes and shapes of 120VAC 15 amp grounded 3-prong wall outlets.
Yeah, I know, it's not a perfect analogy (analogical perfection is what's known as "redundancy" or "tautology"). Still, the "data" that comprise electricity are free electrons on the move. They have two fundamental attributes, volume (amperes) and pressure (voltage; recall "W=VA"?). Health IT data are ASCII collated binary voltage state representations (ignoring the legacy EBCDIC) comprising numeric and textual symbols (images being specific encodings of the former).

120VAC electrons are rather effortlessly "interoperable." Only proprietary opacity keeps health IT from achieving similar efficient, utilitarian "patient-centered" convenience.
 __

CODA

From THCB:


Comment below the post:
Those of us using EHRs in clinical practice are painfully aware of the fact that they are not designed to ensure that the most pertinent and important information is readily available, let alone hard to miss. If avionics and commercial jet cockpits were engineered the way the EHR is, the carnage would be catastrophic. Three simple examples. (1) The absence of a search function, requiring that one scroll through hundreds of entry titles to learn if/when the patient had Test X or saw specialist Z; (2) Alerts where the infrequent important alert about a serious risk is hidden amidst a veritable flood of noise; (3) checklists and drop downs that turn a coherent clinical narrative into a meaningless collection of unrelated factoids, resembling a parts list without assembly instructions.

The EHR does the job for which it is designed and purchased: documentation for audit and billing. It is not designed as a clinical care tool...
Thank You, Sir! May I have another?
EHR design is terrible and obstructs communication. The medical record is absolutely polluted with useless information. Using the EHR is distracting and masquerades as effective communication, care collaboration, and all those buzz words. It is all bull. Physicians have been wailing about this. Would someone like to pay attention now? If the nurse and physician had not been lost in endless button clicking and metric meeting, they may have had a chance to talk to each other.
From Healthcare IT News:
In an Oct. 2 statement, Texas Health officials said that in the "interest of transparency," they confirmed the chain of events leading up to Duncan's travel history not being initially known by or communicated to physicians.

"We have identified a flaw in the way the physician and nursing portions of our electronic health records (EHR) interacted in this specific case. In our electronic health records, there are separate physician and nursing workflows," Texas Health officials explained in the Oct. 1 media statement. "As designed, the travel history would not automatically appear in the physician's standard workflow."
Another "Epic" situation? This story will likely have no legs unless additional Ebola cases emerge, documentably traced back to this particular Liberian vector dude. Nonetheless, the oversight is noteworthy, and the EHR haters will no doubt crawl out from under every rock.
___

More to come.

Thursday, October 16, 2014

The latest Interoperababble news

We interrupt our regularly scheduled  24/7 Ebola panic for a bit of other news...

'Actionable' steps to interoperability
JASON task force offers its final report to ONC
Tom Sullivan, Healthcare IT News, October 16, 2014


JASON, a group of independent scientists who advise the federal government, issued a November 2013 report to the Department of Health and Human Services, the Office of the National Coordinator for Health IT and the Agency for Health Research and Quality on the matter of interoperability...

Here are the half-dozen recommendations the JASON task force made to ONC, as co-chairs David McCallie, vice president of medical informatics at Cerner, and Micky Tripathi, CEO of the Massachusetts eHealth Collaborative, explained them:
  1. Focus on interoperability. ONC and CMS should re-align the meaningful use program to shift focus to expanding interoperability, and initiating adoption of Public APIs.
  2. Establish an industry-based ecosystem. A Coordinated Architecture based on market-based arrangements should be defined to create an ecosystem to support API-based interoperability.
  3. Set up Data Sharing Networks. The architecture should be based on a Coordinated Architecture that loosely couples market-based Data Sharing Networks.
  4. Enable the Public API as basic conduit of interoperability. The Public API should allow data- and document-level access to clinical and financial systems according to contemporary Internet principles
  5. Create Priority API Services. Core Data Services and Profiles should define the minimal data and document types supported by Public APIs
  6. Institute the government as market motivator. ONC should assertively monitor the progress of exchange and implement non-regulatory steps to catalyze the adoption of Public APIs.
"Market motivator? Hmmm... No more federal money. "Non-regulatory" incentive steps? "Loosely couples market-based Data Sharing Networks?" "Loosely?" Oh, yeah, that's swell.

What's not to love?

Expect several more years of wheel-spinning and cludge-fix outside-in band-aids. After which we'll issue ONC Ten Year Interoperability Plan 2.0 (assuming their budget hasn't been zeroed out by then).

Clinic Monkey
Thus endeth today's edition of The Interoperababble News.


WE NOW RETURN YOU TO YOUR REGULARLY SCHEDULED NIGHTMARE

America doesn’t have an Ebola epidemic, but it’s been infected with a whole lot of fear-mongering, finger-pointing and downright nonsense lately. Politicians, in particular, have unleashed a whirlwind of irresponsible speculation and policy prescriptions with no basis in reality.

Senator Rand Paul is telling reporters that you can catch Ebola at a cocktail party — an unlikely prospect, unless if, for some reason, you manage to make contact with the bodily fluids of someone who’s actively sick with the disease. Todd Kincannon, the former general counsel and executive director of the South Carolina Republican Party, declared that the “immediate humane execution” of U.S. Ebola patients would somehow save lives. Lawmakers on both sides of the aisle continue to push for travel bans, despite experts’ warnings that they could make the crisis worse. And a vocal contingent of conservatives is convinced that the threat of an infectious disease from West Africa warrants sealing the U.S.-Mexico border — an enormously expensive and probably impossible to execute solution...

Sanity.

Ever-predictable insanity:


Infographic from Sermo: The problem withe Ebola preparedness.

SATURDAY MORNING UPDATE:
ALL EBOLA ALL THE TIME

From my email inbox.


Also:
The Ebola Voter
Thirteen ways Democrats and Republicans are exploiting the virus for political gain.
___

More to come...

Monday, February 15, 2016

500,000+ hits on KHIT. Thank you.


Milepost, for whatever it's worth.


I'm still small fry. Iconoclastic lone wolf independent, no monetization. Some blogs get 100,000 hits a month. I get maybe 15,000 on a good month.

I just continue to do it because it's important. I guess some people agree.

All of it; EHRs per se, the much-unloved Meaningful Use (the core topic which launched this blog), UX, HIE, "Interoperability," "mHealth," the "Upstream," Analytics, Privacy, Workflow/Process QI, Organizational/Workforce Culture, Public Policy and Law, Markets (including IP and Health IT Venture Capital), Medical Science (including the "Omics," and applied science more broadly), "AI/IA," and Clinical Pedagogy -- each of the foregoing topics worthy of (and the subject of) blogs and books of their own, all of them vexaciously, n-dimensionally intertwined, overlapping, and frequently mutually cross-purpose confounding.

Maybe now with my 2015 cancer dx and tx fading into an unpleasant memory, I can get back up to speed (though I will yet have a couple of eye-rolling recent BCBS/RI time-wasting "shards" doozies to recount).

In two weeks I'll be covering HIMSS 2016. They granted my press pass for the 5th time.


I first covered HIMSS in 2012, in Vegas. There will be a lot of significant (watershed?) import on tap this year.

Stay tuned. And again, thank you for coming here.

Next up, I guess I'll title it "Syntactic and Semantic Interoperababble 2016." Spurred to a great degree by this recent THCB post "Interoperability Form and Function: Interview with Doug Fridsma." My comment thereunder:
I see “interoperababble” is alive and well, inclusive of leaving out a key phrase in the IEEE definition of interoperability: “…without special effort on the part of the user.” No amount of calling n-dimensionally interfaced “data exchange” “interoperability” will make it so.

Moreover, with respect to “SOAP.” it would properly be “SOAPe” (kudos to my former Sup Keith Parker at my QIO/REC/HIE for the observation), wherein the “e” refers to “evaluation” — i.e., “outcome” eval of the assessment and plan. In PDSA terms, the “e” would be the “S,” the “Study” component of science-based QI.
___________

More to come...

Thursday, July 24, 2014

Interoperababble update update

Lack of EHR interoperability 'fraud' against taxpayers
July 22, 2014 | By Marla Durben Hirsch


Electronic health record vendors--particularly Epic--may not deserve Meaningful Use incentive money because their systems hinder data sharing, according to physician-turned-lawmaker Rep. Phil Gingrey (R-Ga.). 

In a July 17 hearing of the House Energy and Commerce Committee's subcommittee on Communications and Technology and Health, Gingrey questioned whether the nation is currently on a path of interoperability or whether changes to the law need to be made. He expressed concern that according to a recent RAND report, more than half of the $24 billion spent by the Meaningful Use program has gone to Epic, a vendor operating a "closed platform."

Pointing out that the committee has jurisdiction over the Office of the National Coordinator for Health IT and the HITECH Act--which created the Meaningful Use program--Gingrey said that if the RAND report is true, "we have been subsidizing systems that block information instead of allowing for information transfers, which was never the intent of the [HITECH] statute...
"It may be time for this committee to take a closer look at the practices of vendor companies in this space given the possibility that fraud may be perpetrated against the American taxpayer," he added...
I'm not a big fan of this hyperpartisan reactionary Gingrey fellow (who recently -- falsely -- claimed that central American child refugees were bringing Ebola into the U.S.), but even a broken clock is right twice a day.

Epic has certainly Made Bank on MU. In large measure that owes to Efficient Markets Hypothesis 101: Opacity (plus barriers to entry, I would add) = Margin. The most transparent markets are by definition the least profitable, according to standard economic theory (rational actors all pursuing self-interest, each possessing "perfect information," "market clearing price," and all that).


I refer you yet again to my Interop rant. See also my related antecedent "Interoperababble update" post.

apropos,
Health IT Now recommends HHS, Congress take steps against non-interoperable systems
June 18, 2014 | By Marla Durben Hirsch


Health IT Now, buoyed by RAND's recent report on electronic health records, has called on the U.S. Department of Health and Human Services and Congress to "decertify systems that require additional modules, expenses, and customization to share data," and to investigate business practices that prohibit or restrict data sharing in federal incentive programs...
I won't be holding my breath.

Who are these people?

HealthITnow.org

I've been one of their twitter followers. They have not reciprocated thus far.
 __

HEALTHCARE MARKET DISRUPTION UPDATE
This CEO is out for blood
by  Roger Parloff, Fortune

Elizabeth Holmes founded her revolutionary blood diagnostics company, Theranos, when she was 19. It’s now worth more than $9 billion, and poised to change health care...

Theranos today is a potentially highly disruptive upstart in America’s $73 billion diagnostic-lab industry, which performs nearly 10 billion tests a year and is estimated to provide the basis for about 70% of doctors’ medical decisions. Medicare and Medicaid each pay roughly $10 billion annually on reimbursements for these tests...
I read this yesterday in my wife's hardcopy. Pretty interesting. Brilliant young woman. This lab-on-a-chip market is a rather crowded space, though (but, they're likely to push back "that's not our business line"). See my posts from the Health 2.0 Conference in Santa Clara last fall.

One more reason to short Quest and Labcorp.
___

More to come...

Friday, June 14, 2019

June 2019 EHR interoperababble update


From THCB:
Electronic health records (EHRs) are a polarizing issue in health reform. In their current form, they are frustrating to many physicians and have failed to support cost improvements. The current round of federal intervention is proposed rulemaking pursuant to the 21st Century Cures Act calls for penalties for “information blocking” and for technology that physicians and patients could use “without special effort.”

The proposed rules are over one thousand pages of technical jargon that aims to govern how one machine communicates with another when the content of the communication is personal and very valuable information about an individual. Healthcare is a challenging and unique industry when it comes to interoperability. Hospitals spend lavishly on EHRs and pursue information blocking as a means to manipulate the physicians and patients who might otherwise bypass the hospital on the way to health reform. The result is a broken market where physicians and patients directly control trillions of dollars in spending but have virtually zero market power over the technology that hospitals and payers operate as information brokers...
----
The draft rules for interoperability, CMS, ONC, TEFCA, USCDI are over a thousand pages. Most of the complexity stems from a design that avoids direct patient direction and transparency the way we expect banking and other automated services. This approach fragments the patient and physician experience and poses privacy and security risks that may never be solved. On the other hand, an interoperability design based on patient-designated sharing with clinicians that voluntarily post their digital contact info (personal, group, or institution) works across the full range of patient data (behavioral, HIPAA, patient-generated) and provides patients and family caregivers the transparency and accountability over health services that we need. Allowing patients to specify their authorization server further simplifies things by enabling competition for the authorization service – a digital concierge – that would give market power to individuals and deliver the pro-competitive benefits the Rule seeks.
"Banking and other automated services?" I have to voice some dubiety with respect to that apples-to-oranges analogy. "Allowing patients to specify their authorization server further simplifies things by enabling competition for the authorization service." Right, so we'll still have multiple competing architectures.

"Interoperababble?"

A hardy perenennial.
No amount of calling point-to-point interfaced data exchange "interoperability" will make it so.

Interestingly, I've spent a good bit of the day trying (with frustratedly limited success) to download my medical records in anticipation of my first patient visit next week at Kaiser. Muir (my last provider system) is on Epic. Kaiser is on Epic. You'd think that would be easy. You'd be wrong. My hernia surgery a year ago was via a surgeon at Bass Medical Group. Owned now by Muir, but on a different platform still. The urologist who dx'd my prostate cancer in 2015 was with NorCal Urology. Bought by Muir, but using NextGen (I think they've now migrated). My radiation oncology tx group was Diablo Valley Oncology and Hematology. Yet another EHR platform, one whose patient portal is useless.

I'm just going to have to write my own summary "progress note," comprised of Active Problems, Active Meds, CC, PMH, PSH, HPI, FH, SH, etc., to save the new M.A. a bit of intake time.
_____________

More to come...

Wednesday, March 18, 2015

March 2015 Senate committee Interoperababble hearing


I'm not sure how long the video will be up on the committee website. They have pdf files of the prepared witness testimonies on the site. There's a short edited hearing excerpt on YouTube here:


I watched the entire hour and 45 minutes. I've emailed to inquire as to whether there will be a transcript. It was a good hearing, as these things go. Very collegially bipartisan. Lots of concerns aired about the progress and status of the Meaningful Use program, specifically aimed around the continuing lack of effective and widespread "interoperability"/data exchange. (What I have coined as "Interoperababble®.")

UPDATE

As reported by iHealthBeat:
Senate Committee Addresses Meaningful Use, Interoperability

During a Senate Health, Education, Labor and Pensions Committee hearing on Tuesday, senators and stakeholders discussed issues regarding the meaningful use program and barriers to achieving interoperability, Healthcare Informatics reports.

Under the 2009 economic stimulus package, providers who demonstrate meaningful use of certified electronic health records can qualify for Medicaid and Medicare incentive payments (Perna, Healthcare Informatics, 3/17).


Hearing Details on Meaningful Use
In an opening statement, Senate committee Chair Lamar Alexander (R-Tenn.) said that "evidence suggests" that while the meaningful use program has spent $30 billion, it has so far failed to deliver on its promises to "improve care, improve coordination and reduce costs."


Specifically, Alexander noted that eligible professionals and hospitals have struggled with the program to the point where CMS has been forced to delay or update its requirements three times. He added, "Half of physicians have not met the requirements of the program and are now facing penalties"...
Yeah, OK, "so far failed to deliver..."

From my March 6th post:
For one thing, I have noted before what I call "Health IT Policy ADHD." Major legislation gets passed and funded, and when we don't get immediate, dazzling results, we go sour on it, lamenting its "failure," and calling for its demise. HITECH is not that old. There have really only been four years of full-bore boots-on-the-ground operation. REC contracts were let in 2010, and the RECs spent most of their first year getting their sea legs under them and scurrying about hustling skeptical clinical participants.
__

BUT WAIT! THERE'S MORE...

Gotta love it. From Healthcare IT News.
Epic trades jabs with CommonWell Health Alliance
Epic's 'rhetoric is a slap in the face'


Comments by Epic's head of interoperability in a Senate HELP Committee Tuesday have triggered members of the CommonWell Health Alliance, the subject of some of the comments, to fire back at the Verona, Wisconsin-based EHR giant.

Peter DeVault, Epic's director of interoperability, spoke before the Senate committee on the topic of interoperability and Epic's role in moving it forward. In the questions portion of the hearing, Senator Tammy Baldwin, D-Wisconsin, shifted the conversation, asking DeVault candidly: Why isn't Epic a part of CommonWell?...
The two-year old CommonWell has 1,000 physicians live on it, he said, compared to 100,000 physicians on Epic's Care Everywhere. Healthcare IT News reached out to CommonWell officials for the most up-to-date number but did not receive a response by publication time.
 
DeVault's comments didn't sit well with one of CommonWell's founding members (and one of Epic's chief competitors), Cerner.
 
His "rhetoric is a slap in the face to many parties working to advance interoperability," according to a statement released by Cerner officials shortly after the committee hearing. "It was discouraging to hear more potshots and false statements when it's clear there is real work to be done. We're committed to CommonWell as a practical, market-led way to achieve meaningful interoperability."
 
There's been tension between Epic and CommonWell ever since the latter group's launch at the 2013 HIMSS Annual Conference & Exhibition.
 
At that HIMSS13 announcement, athenahealth CEO Jonathan Bush emphasized that anyone was invited to CommonWell – even a vendor of "epic proportions."...
Kumbaya...

More, from Modern Healthcare:
'Doc fix' bill would overhaul health IT policy, too
By Darius Tahir  | March 19, 2015
 

The bill introduced Thursday to replace Medicare's sustainable growth-rate formula for physician pay would also significantly alter federal policy on health information technology...

Lawmakers have ... used the legislation to take aim at obstacles to realizing the benefits of IT in healthcare, particularly the lack of interoperability, or data-sharing, between electronic health records.

The SGR bill establishes a July 2016 deadline for HHS to develop metrics to quantify progress toward more data-sharing among hospitals and other providers. HHS would have to account for the progress by December 2018...
This bears watching. A long road yet to an actual law, though.
___

More to come...

Thursday, March 3, 2016

#HIMSS16 Day 3

BREAKING!  In my email inbox today!


Lucky me! I may have to leave the conference early! (Love the "tommorrow" spelling.)

But, first, a bit of snark.


I searched "Uber" on the Conference website. No match. Thank you.

Attended the #HITsm panel / interactive discussion. Excellent.

Mandi Bishop moderating

The panelist on the right is Drew DeFord. He brought up "Lean." BobbyG was all smiles. Color me an Evangelistic Believer. See my coverage of last year's Lean Healthcare Transformation Summit in Dallas. The 2016 Summit will be in Miami this June. A tremendous value. Highly recommend you go if you can. Interact with the leaders in progressive, science-based health care process QI.

In response to a question asked of the panel and audience regarding "what you you think will be the innovation that will have the most significant impact of the health care industry going forward?" my response was "that of 'AI' or 'IA' (artificial intelligence / intelligence augmentation)." See my prior posts on the topic.

It's somewhat of a close call, But, overall, with respect to the "health care industry" writ large, that would be my view.

Below, at #HITsm, Chuck Workflow Man Webster, commenting while doing a Periscope live stream.


INTEROPERABILITY

Shlepped down to the rear of Level 1 to area 11954.


Sequoia Project presentation.
"In 2012, The Sequoia Project, previously Healtheway, was chartered as a non-profit 501(c)(3) to advance the implementation of secure, interoperable nationwide health information exchange.  The Office of the National Coordinator for Health Information Technology, part of the US Department of Health and Human Services, transitioned management of its eHealth Exchange to The Sequoia Project for maintenance.  Since 2012, the Exchange has grown to become the largest health information exchange network in the country.  In 2014, we began to support additional interoperability initiatives beginning with Carequality.

We have assembled, through these initiatives, and our engagement with government and industry, experts who can identify the barriers to interoperability and pioneer processes to make health information exchange work on a national level. We are a neutral body, inclusive of diverse participants, which allows us to create practical solutions to data exchange problems. As a nonprofit operating in the public interest, our governance process insures transparent oversight of this work.

Our vision is to make the right health information accessible at the right place and time to improve the health and welfare of all Americans."
Yeah. Good a time as any to review some of Fred Trotter's 2011 book "Hacking Healthcare."
Chapter 11. Interoperability

The first thing to keep in mind when thinking about interoperability is not a particular standard or technology, but motivations for instituting data exchange. Widescale interoperability has been technically possible for more than 20 years, and major hospitals have had data worth exchanging for at least that long. But as with EHRs, exchanging health data has stalled due to conflicting and backward incentives. 

Historically (with a few notable exceptions) most healthcare institutions have found little motivation for interoperability. There is a lot of motivation to profess interest in healthcare interoperability, which costs nothing. This creates confusion among those outside the healthcare industry. For example, if the hospital CEO says that interoperability is “critical,” why is there no health data being exchanged? 

For most clinics and hospitals, making patient data portable makes the patient portable. Why would anyone invest in a technology that makes it easier for patients to migrate to competitors? For any healthcare provider, a patient represents a financial asset that is expensive to replace. And the easy exchange of records lowers one of the main barriers to patients leaving— information about their medical histories. For centuries, a doctor-patient relationship was something very difficult to replicate. Patients understood that their current doctor was familiar with their health story, and moving would mean losing that familiarity. In a world without portable healthcare records, that relationship is priceless to the patient and difficult to rebuild. Changing doctors will still be hard, even when the health record is movable, but it will become a tractable problem. 

Similarly, health IT vendors lack motivation to properly support interoperability standards. If the data for a single patient can easily be exported from an EHR, then the data for every patient can also be exported easily. True interoperability means that it is much simpler for one EHR to replace another, and therefore one EHR vendor to be replaced by another. As it stands, without widespread interoperability, it is almost impossible to migrate from one EHR to another. Again, interoperability will not make migration between EHR systems easy, but it will make it possible. EHR vendors know this, and have a similarly mixed motivation regarding interoperability. Most EHR vendors claim that they are interoperable because they provide tools to migrate data into their EHR system. Generally, the motivation for interoperability drops for vendors substantially when they see that it creates a path away from the vendor. 

Many EHR vendors charge extra for modules designed to export data, and this fee often becomes a kind of “severance pay” for EHR vendors. When purchasing an EHR, it is critical to request that any modules required for data exchange be included in up-front pricing. Neglecting this often ensures that you have to pay your vendor for the privilege of firing them...

Trotter, Fred; Uhlman, David (2011-10-07). Hacking Healthcare (pp. 167-168). OReilly Media - A. Kindle Edition.
That was five years ago. (I first reviewed Fred's book in March 2012). Are we still stuck largely with "Free Beer Tomorrow?" "Interoperababble?" (See all of my "Interoperababble" rants here.)


Or, are we on the cusp of a beneficent, "transformative" exponential Hockey Stick Function interop uptick?

One hopes.

"HOCKEY STICK?"

OK, quick analogy (of sorts). Say you're some penny-ante geezer who comes to Vegas in flip-up shades, Hawaiian shirt, cargo shorts, sandals, and black knee socks. You play the penny slots, and maybe bet a penny on an NBA game with your friend (absurd; bear with me). Your strategy? Double your bet if you lose to get your money back.

What would be the consequence of a 24-game losing streak? I quickly drop some stuff into an Excel sheet to illustrate.



After 12 losses you're only out about 41 bucks. No biggie. But, as you can see, the upslope really gets going thereafter. Hockey Stick neck really cranes up around loss #19. Hard to believe that final number. Don't take my word for it, screen-scrape and paste this exponential expression into Google: ".01*2^24="

Consider that the longest NBA team losing streak is 28 games (76'ers). Longest NFL losing streak, 26 games (Tampa Bay). Consider had you started out wagering not with a penny, but $100.

LOL.

I used to play street hoops in Vegas at a NW side city park with these low-life degenerate sports book gambler dudes (the ones who weren't in iterative jail repose at the time). This guy "Doc" explained his "double-down" M.O. to me. I thought, "yeah, bro', that's why you're habitually on the verge of being homeless."

So (flipping the analogy from losses to wins), in terms of significant interop progress, maybe we're getting close to the Hockey Stick neck.

One hopes.
___________

More to come...

Friday, July 4, 2014

Interoperababble update

From JAMIA: (pdf)

EHR adoption and Meaningful Use
EHR use in the USA has risen rapidly since 2009 with certified EHRs now used by 78% of office based physicians and 85% of hospitals. Meaningful Use (MU), a staged federal incentive program enacted as part of the American Recovery and Reinvestment Act of 2009, has paid incentive of US$21 billion to hospitals and physicians for installing and using certified EHRs pursuant to specific objectives. Stage 1 of the program (MU1) commenced in 2011, Stage 2 (MU2) in 2014, and Stage 3 is expected by 2017.


While the term interoperability can refer to messages, documents, and services, MU provides several objectives that prioritize document interoperability. Although multiple document standards existed prior to MU1, providers with installed EHRs rarely had the capability to send structured patient care summaries to external providers or patients, as noted by the President’s Council of Advisors on Science and Technology and the Institute of Medicine. MU1 advanced document interoperability by requiring Continuity of Care Document (CCD) or Continuity of Care Record (CCR) implementation as part of EHR certification. Many vendors chose the CCD, which was created to harmonize the CCR with more widely implemented standards. In MU2, the C-CDA, an HL7 consolidation of the MU1 CCD with other clinical document types, became the primary standard for document-based exchange...
Putting aside the "interoperability" misnomer (it's really just about data exchange among 2014 CEHRT systems; no one's remotely operating another's EHR from across town or from the other side of the nation), the unsurprising answer to the title question is "no."
ABSTRACT
Background and objective Upgrades to electronic health record (EHR) systems scheduled to be introduced in the USA in 2014 will advance document interoperability between care providers. Specifically, the second stage of the federal incentive program for EHR adoption, known as Meaningful Use, requires use of the Consolidated Clinical Document Architecture (C-CDA) for document exchange. In an effort to examine and improve C-CDA based exchange, the SMART (Substitutable Medical Applications and Reusable Technology) C-CDA Collaborative brought together a group of certified EHR and other health information technology vendors.
Materials and methods
We examined the machine-readable content of collected samples for semantic correctness and consistency. This included parsing with the open-source BlueButton.js tool, testing with a validator used in EHR certification, scoring with an automated open-source tool, and manual inspection. We also conducted group and individual review sessions with participating vendors to understand their interpretation of C-CDA specifications and requirements.
Results
We contacted 107 health information technology organizations and collected 91 C-CDA sample documents from 21 distinct technologies. Manual and automated document inspection led to 615 observations of errors and data expression variation across represented technologies. Based upon our analysis and vendor discussions, we identified 11 specific areas that represent relevant barriers to the interoperability of C-CDA documents.
Conclusions
We identified errors and permissible heterogeneity in C-CDA documents that will limit semantic interoperability. Our findings also point to several practical opportunities to improve C-CDA document quality and exchange in the coming years.
"615 observations of errors and data expression variation"? In one small study? Now, perhaps some of the data expression "variability" is nominally trivial (the errors are certainly not), but this is pretty disturbing.

I refer you to my February 23rd post, "The Interoperability Conundrum: Arguing for a std data dictionary."


I've pretty much lost that fight, I know. Nonetheless...

__

apropos,


Interesting paper. Free, but registration required for access.
While Big Data enjoys widespread media coverage, not enough attention has been paid to what practitioners think — data scientists who manage and analyze massive volumes of data.
We wanted to know, so Paradigm4 teamed up with Innovation Enterprise to ask over 100 data scientists for their help separating Big Data hype from reality. What we learned is that data scientists face multiple challenges achieving their company’s analytical aspirations. The upshot is that businesses are leaving data — and money — on the table...
  • We’ve all heard how hard it is to analyze massive and rapidly growing data volumes. But data scientists say variety presents a bigger challenge. They are at times leaving data out of their analyses as they wrestle with how to integrate and analyze more types of data such as time-stamped sensor, location, image and behavioral data as well as network data.
  • For complex analytics, data scientists are forced to move large volumes of data from existing data stores to dedicated mathematical and statistical computing software. This time-consuming and coding-intensive step adds no analytical value and impedes productivity.
  • While Hadoop has garnered widespread media coverage, 76 percent of data scientists have encountered serious limitations using it. Hadoop is well suited for embarrassingly-parallel problems but falls short for large-scale complex analytics.
  •  Incorporating the diverse data types into analytical workflows is a major pain point for data scientists using traditional relational database software.
The overwhelming volume of corporate and organizational data continues to generate headlines but it’s the diverse types of data that pose a bigger challenge. Nearly three-quarters of data scientists — 71 percent — said Big Data had made their analytics more difficult and data variety, not just volume, was the challenge.
Many new analytical uses require significantly more powerful algorithms and computational approaches than what’s possible in Hadoop or relational databases. Data scientists increasingly need to leverage all data sources in novel ways, using tools and analytical infrastructures suitable for the task. As we have already seen in this survey, organizations are moving from simple SQL aggregates and summary statistics to next-generation analytics such as machine learning, clustering, correlation, and principal components analysis on moderately sized data sets. The move from simple to complex analytics on Big Data presages an emerging need for analytics that scale beyond single server memory limits and handle sparsity, missing values and mixed sampling frequencies appropriately. These complex analytics methods can also provide data scientists with unsupervised and assumption-free approaches, letting all the data speak for itself [sic]...
Well, at the end of the day, BI and clinical users of data are still only interested in three types of data: [1] text (both "structured" and unstructured narrative), numbers (integers and floating-point), and [3] images (both static and dynamic). How they originally get defined, and the interop problems of such heterogeneity, points directly back to the issue of dictionary standardization. It is indeed less of problem of data magnitude and more one of the n-dimensional translation issues inherent in the heterogeneity.

Interoperababble.
___

More to come...