Article – DoD yanked from health records project

This article is intriguing (and a bit depressing).

First, because it shows once again that the amount of money (say like, US$1 billion) that you throw at a problem does not assure success. Aligning goals and system design principles—and getting firm commitment from all stakeholders—is critical, and it doesn’t seem like that happened here.

Also, there is no mention of the use of commercial HIE technology for record exchange. The article mentions the exploration of commercial EMR technology vs. a custom (“home grown”) EMR, like the VA’s VistA. How is the ONC—a government agency—promoting the use of HIE solutions as part of their patient record evolution, but the VA and DoD not looking at the same approach?

Finally, the vision of an open system is not flawed. And by open, I mean interoperable with modern Web-based APIs. It could even mean open source.

Article – AMA: EHRs create ‘appalling Catch-22’

I enjoyed this article.

Often, policymakers and executives debate the merits of an initiative. What is often lost in the shuffle are the important lessons and optimizations that make the program a success.

In the article, a number of folks discuss the implications of an EMR after implementation, including the possibility of fraud, or the incorrect perception that it has occurred.

My thoughts…

  • Fraud is easier to detect the more the information is electronic and coded. In fact, any pattern is easier to detect if extensive, well-structured data is available. Algorithms that detect possible fraud patterns will emerge, just as they did for credit card transactions. I recall a investigative news show on Medicare fraud where the agent stated that the move to electronic transactions and ‘smarter and smarter’ alogrithms have made their job easier. False positives will be a problem for a while until they get it right.
  • Coding of records is about to become a huge push. Beyond regulations for coding of data, there are several initiatives to provide codes for orderable procedures, lab/clinical observations, medical terms, diseases, medical/surgical/diagnostic services, and even imaging workflow concepts. Other groups are working to provide practical guidance on how to best use these codes in different contexts. This article talks about the need for better and more coding.

And here is an article on a Web site where EMR users can rate their EMR. There are some interesting comments in the article.

Also, an Accenture survey finds a significant increase in the use of EMR and HIE technology by physicians.

Article – Can a smartphone do what your doctor does?

This article provides a summary of medical devices and apps that connect to your smartphone and collect physical examination information. The author is a doctor and provides a good explanation of the utility and necessity of the different tests.

The devices assessed by the article’s author include…

  • Blood Pressure Monitor by Withings and Blood Oxygen Monitor by iSp02
  • ECG Cellphone Case by AliveCor
  • iExaminer by Welch Allyn
  • SpiroSmart

From her assessment, it seems that the medical tricorder is slowly becoming a reality. I do agree that having a separate app to view the results from each device is a PITA, but this should not last long. With Bluetooth and WiFi connected devices wireless tethered to the smartphone, and new data formats and protocols popularized in HTML5, the shift to storing the collected information into the EMR or HIE will be soon.

Article – CHIME seeks Stage 2 delay, defends MU

So, the U.S. government—CMS/ONC and some Senators—and CHIME (College of Healthcare Information Management Executives) are “discussing” the merits and best timing of HITECH and Meaningful Use.

This article provides a good summary of the questions and recommendations posed.

Some key points from the article and my thoughts…

  • The Senators are fairly looking for evidence of results from the significant investment of taxpayer dollars. The reality is that this change is large and multifaceted. It will take time to reap the benefits once operations are normalized and productivity is enhanced.
  • CHIME believe that there are merits to the government’s programs, but wants to slow the pace of change. I know from personal conversations with smart, effective folks working for respected providers that they are reeling from the number of implementation projects driven by ACO, MU and other initiatives that they have going right now. The troops may indeed need a short break and to reflect on lessons learned from the initial change.
  • “CHIME also urged Congress to request an update from ONC regarding what technologies, architectures and strategies exist to mitigate patient matching errors” …it is interesting that CHIME is looking for this, as MPI (Master Patient Index)—also known as PIX (Patient Identifier Cross-Referencing) in the IHE Technical Framework—has been around for years and used in many projects to enable sharing of patient records across patient ID domains

Blog – FHIR Version 1.0

Check out this blog discussing FHIR. While the initial post seeks to simplify the intent of FHIR to a practical application (essentially a summary document), if you read the author’s own comments on their post, they are already starting to realize the real value of FHIR.

FHIR creates the platform, and the summary document is an application of the platform.

Article – HIStalk Interviews Keith Figlioli, SVP Healthcare Informatics, Premier

A friend shared this interview with me. Worth the read.

Some thoughts…

  • Keith (BTW, I have never met him) has a unique perspective having spent time on the vendor side, then the provider side, and is now also involved in policy. I think his points are spot on.
  • I believe that some of the EMR monolith disruption will come from HIE vendors. They are slowly taking more parts of the EMR, and generally have newer architectures than most EMR systems. This will allow them to adapt to new standard APIs and protocols, such as those being defined in HL7 FHIR. They are also more open—they have to believe in openness, because without data sharing, they have no business.
  • HIE vendors also typically have some form of clinical data repository, which can act as the data warehouse that Keith mentions. Adding moderns APIs to these can open the door to information freedom (without compromising security and privacy, BTW), without waiting for EMR vendors to do it.
  • I like the analogy to the transformation that the travel industry went through. I make this comparison often. I also look at how banking and telecommunications have transformed themselves to provide new and improved services. The lessons for healthcare are all out there—we just need the leadership.

Article – Enterprise Imaging: Beyond Cloud-based Image Sharing

Read this, seriously.

Some thoughts…

  • I agree with most of what the article covers. I believe that Radiologists will be more consultant than owner of the Enterprise Imaging (EI) platform.
  • One topic that is not covered is the informatics around the metadata to collect at the time of capture. DICOM and IHE provide guidance as to what metadata we want to capture and include when doing a CT exam, but what needs to be captured when a clinical images are captured and stored is far less defined (though this will evolve as EI is adopted). Hopefully, we can start defining this by using some standard lexicons and codes (like SNOMED CT), as these are more mature now than when we started defining metadata values for traditional radiology modalities.
  • There needs to be close attention paid to the indexing of metadata in the EMR and the EI platform; more than is traditionally done when doing a basic EMR and PACS viewer integration. If an HIE is in place or planned, this also needs to be considered. Not all systems will be capable of managing all the desired metadata (including unique identifiers).
  • The EI platform should be considered a component of the EMR and managed as such–don’t put EI in your radiology PACS; just don’t.
  • We need to develop EI professionals through education and shared experiences, if we want to succeed. I may be biased, but I believe that SIIM is one of the organizations well-positioned to provide this. Check out my two-part blog post (part 1, part 2) on the SIIM web site.

UK study: Telehealth not cost effective

UK study: Telehealth not cost effective …I have two thoughts on this.

One, telehealth is not only about cost reduction—it is also providing patients access to scarce resources, such as a cardiac specialist. Patients with chronic disease in rural or otherwise under served areas can use telehealth to get services where they otherwise would go without. In this case, telehealth costs equal to, or even a premium above, standard costs may be warranted (or, at least, a comparison to average costs is unfair considering the inflated costs to provide equal services in an area where resources would need to travel to the patient).

Two, costs will come down. And, an 80% reduction in costs (as cited in the article) is not that difficult to achieve if one compares dedicated enterprise solutions to consumer solutions (e.g. smartphone apps). The cost of a widely shared set of web services in the cloud accessed by off-the-shelf, multipurpose consumer devices, like smartphones and tablets, is much lower than deploying and maintaining dedicated vendor-proprietary solutions.

Open mHealth vs. HL7 FHIR

OK, so check this out. I signed up to the mailing list for Open mHealth, an initiative that promotes the use of designs and technologies that I believe in, like REST APIs and JSON. They have started to post some documentation and specs, and have even have published some early implementation code. They have some discussion going on in a Google Group.

But what I am trying to figure out is how this relates to HL7’s FHIR. They seem to be using the same tools with similar missions.

It will be interesting to see which one gets traction:

  • the open initiative (seemingly) driven by the user community (doctors and people working in hospitals), or;
  • the standard from the well-established and accepted healthcare standards body

It reminds me of MINT (open community) and DICOM Working Group 27‘s (standards body) output (but in this case it was many of the same people involved in both).

In general, the open community moves faster, drives rapid innovation, and gets lots of attention, but the established healthcare IT vendor community often waits for the responsible standards body committee to provide a formal, consensus-driven specification (with design controls and governance around it to prevent unexpected changes), before implementing the API. Also, initiatives like IHE will typically only reference final standards in their integration profiles.

Article – Mostashari, policy committee take critical look at CommonWell

Mostashari, policy committee take critical look at CommonWell

Something to watch as it evolves in the coming months and years, but here is an excerpt of the alliance’s goals…

  • Enabling providers to unambiguously identify patients – but not with a national patient identifier;
  • Providing a way to match patients with their healthcare records as they transition through care facilities;
  • Using existing unique identifiers (salted/hashed) such as cell phone number, email addresses or driver’s licenses for identity management;
  • Enabling patients to manage consent and authorization;
  • Creating a HIPAA-compliant and patient-centered means to simplify management of data-sharing consents and authorizations, focusing initially on the most common treatment situations;
  • Helping providers to find the location of patient records across care locations via a secure nationwide records locator service;
  • Enabling providers, with appropriate authorization, to issue targeted (directed) queries that provide for peer-to-peer (e.g., EHR to EHR) exchange.