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 – CHIME presses HHS for HIE certification

This makes sense.

If we are going to certify EMR technology, HIE should be held to the same standard. Especially as more physicians turn to their HIE to provide basic EMR-like access to patient records (mostly because the HIE interface is better than their own EMR’s, the collaboration tools are better, and there is more of their patient’s data from more sources in the HIE).

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.

Article – EHR Adoption Report: The Latest Trends

EHR Adoption Report: The Latest Trends

Some interesting tidbits…

The Office of the National Coordinator (ONC) for Health Information Technology’s most recent data briefs, reporting hospital adoption of EHR technology based on American Hospital Association (AHA) data, indicated the number of nonfederal acute-care hospitals with EHR systems–also known as electronic medical record (EMR) systems–has more than tripled since 2009, increasing from 12.2 percent to 44.4 percent.

Use of electronic active medication lists and clinical decision support rules increased to 87 percent, from 62 percent and 66 percent, respectively. The percentage of hospitals using computerized provider order entry (CPOE) jumped 167 percent, from 27 percent in 2008 to 72 percent in 2012.

The ACP/AmericanEHR study showed user satisfaction fell 12 percent from 2010 to 2012, with the percentage of very dissatisfied clinicians increasing by 10 percent. Thirty-nine percent of physicians would not recommend their EHR to a colleague. The numbers were similar for physicians in a variety of practice settings.

…physicians do not like being forced to use electronic technologies and that EHRs do not measure up to what they are used to in their day-to-day lives, which include iPad apps and smartphones, saying that record systems are fairly rigid with a flat interface.

Article – At Healthcare Experience Design conference, designers rethink ‘broken processes’

In this article, the topic of user experience design in Electronic Medical Record (EMR) applications is explored. They also briefly discuss the use of EMR technology by patients.

Some thoughts…

  • The fact that EMR user interfaces are often hard-to-use, and are undesirable by the user community they are intended to serve, is not news. EMRs are often, at their core, records management systems, presenting medical records generated by other systems, or by users typing data into the EMR. It is no surprise that information is presented like a big electronic filing cabinet. Niche players are trying to layer solutions on top of the EMR to present the information relevant for a given interaction in a more meaningful way. Often, if the EMR is not built with an open architecture (with APIs for external applications to discover and access information), a copy of (some of) the data is kept in a secondary system. Hopefully, IHE FHIR succeeds and enables an integration ecosystem for EMR add-ons that is tantamount to the platform needed to have an “App Store”.
  • Designing applications for trained medical professionals is hard enough. Trying to build a user interface that makes sense to, and it optimized for the use by, both an Oncologist and my grandmother is near impossible. Medical terminology alone is enough to confuse most patients. Then consider the questions and concerns of the patient as they start to review their CT images and wonder what that little whitish spot might be. In this article, many of the docs surveyed expressed concern over patient access to their own electronic medical records (which is why Personal Health Records were created, friends).

Survey: Doc dissatisfaction with EHRs grows

I enjoy articles like this because so much focus is on the expected benefits of healthcare IT, but as the old marketing tale goes, sometimes ‘the dogs just don’t like the dogfood’. If users won’t use the tools, the outcomes won’t be realized. As is often the case with products, the specialist is not well understood or served. The same applies for imaging consumers–the average imaging consumer using an EHR is quite different than the specialist that needs advanced visualization, navigation and measurement tools. Niche vendors will attempt to fill the gaps.

Most EHR user interfaces resemble an electronic filing cabinet, organizing information by type or service / organizational unit that created the data. Vendors could learn a lot from the design of social networking platforms, which are quite adept at coordinating activities in complex interactions among disparate users.

Article from HIMSS: PACS will not remain a self-contained data silo

Have a read (may need an account).

Some thoughts…

  • The shift of the “archive” out of PACS has been well-discussed and is occurring today with the maturation of the VNA market; though these primarily serve PACS.
  • I believe that the next evolution will be a significant advancement in the ease at which a medical imaging record may be discovered and accessed. And these records will be dynamically transformed and provided to the wishes of the consumer (user or application). This will come through new REST-based Web protocols, such as those being defined in DICOM WG-27 and the HL7 FHIR initiative; as well as modern full text search methods.
  • With these new methods the lines between records in DICOM, document, or structured data formats will be blurred and the content much easier to cross-index and normalize.
  • The same evolution (easy to find, access, use) will occur to resources, such modalities and clinical specialists. The freedom I have to find and reserve a flight among dozens of providers within seconds compared to the ability to book an appointment for a CT exam would be laughable, were it not depressing.