Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and HIPAA for FREE!!

Will Medical Device Makers Get Interoperability Done?

Posted on September 20, 2017 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Most of the time, when I think about interoperability, I visualize communication between various database-driven applications, such as EMRs, laboratory information systems and claims records. The truth is, however, that this is a rather narrow definition of interoperability. It’s time we take medical device data into account, the FDA reminds us.

In early September, the FDA released its final guidance on how healthcare organizations can share data between medical devices and other information systems. In the guidance, the agency asserts that the time has come to foster data sharing between medical devices, as well as data exchange between devices and information systems like the ones I’ve listed above.

Specifically, the agency is offering guidelines to medical device manufacturers, recommending that they:

  • Design devices with interoperability in mind
  • Conduct appropriate verification, validation and risk management to ensure interoperability
  • Make sure users clearly understand the device’s relevant functional, performance and interface characteristics

Though these recommendations are interesting, I don’t have much context on their importance. Luckily, Bakul Patel has come to the rescue. Patel, who is associate director for digital health the FDA‘s Center for Devices and Radiological Health, offered more background on medical device interoperability in a recent blog entry.

As the article points out, the stakes here are high. “Errors and inadequate interoperability, such as differences in units of measure (e.g., pounds vs. kilograms) can occur in devices connected to a data exchange system,” Patel writes. Put another way, in non-agency-speak, incompatibilities between devices and information systems can hurt or even kill patients.

Unfortunately, device-makers seem to be doing their own thing when it comes to data sharing. While some consensus standards exist to support interoperability, specifying things like data formats and interoperability architecture design, manufacturers aren’t obligated to choose any particular standard, Patel notes.

Honestly, the idea of varied medical devices using multiple data formats sounds alarming to me. But Patel seems comfortable with the idea. He contends that if device manufacturers explain carefully how the standards work and what the interface requires, all will be well.

All told, If I’m understanding all this correctly, the FDA is fairly optimistic that the healthcare industry can network medical devices on the IoT with traditional information systems.

I’m glad that the agency believes we can work this out, but I’d argue that such optimism may be premature. Patel’s assurances raise a bunch of questions for me, including:

  • Do we really need another set of competing data exchange standards to resolve, this time for medical device interoperability?
  • If so, how do we lend the consensus medical device standards with consensus information system standards?
  • Do we need to insist that manufacturers provide more-consistent software upgrades for the devices before interoperability efforts make sense?

Hey, I’m sure medical device manufacturers want to make device-to-device and device-to-database data sharing as simple and efficient as possible. That’s what their customers want, after all.

Unfortunately, though, the industry doesn’t have a great track record even for maintaining their devices’ operating systems or patching industrial-grade security holes. Designing devices that handle interoperability skillfully may be possible, but will device-makers step up and get it done anytime soon?

Wellpepper and SimplifiMed Meet the Patients Where They Are Through Modern Interaction Techniques

Posted on August 9, 2017 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

Over the past few weeks I found two companies seeking out natural and streamlined ways to connect patients with their doctors. Many of us have started using web portals for messaging–a stodgy communication method that involves logins and lots of clicking, often just for an outcome such as message “Test submitted. No further information available.” Web portals are better than unnecessary office visits or days of playing phone tag, and so are the various secure messaging apps (incompatible with one another, unfortunately) found in the online app stores. But Wellpepper and SimplifiMed are trying to bring us a bit further into the twenty-first century, through voice interfaces and natural language processing.

Wellpepper’s Sugarpod

Wellpepper recently ascended to finalist status in the Alexa Diabetes Challenge, which encourages research into the use of Amazon.com’s popular voice-activated device, Alexa, to improve the lives of people with Type 2 Diabetes. For this challenge, Wellpepper enhanced its existing service to deliver messages over Amazon Echo and interview patients. Wellpepper’s entry in the competition is an integrated care plan called Sugarpod.

The Wellpepper platform is organized around a care plan, and covers the entire cycle of treatment, such as delivering information to patients, managing their medications and food diaries, recording information from patients in the health care provider’s EHR, helping them prepare for surgery, and more. Messages adapt to the patient’s condition, attempting to present the right tone for adherent versus non-adherent patients. The data collected can be used for analytics benefitting both the provider and the patient–valuable alerts, for instance.

It must be emphasized at the outset that Wellpepper’s current support for Alexa is just a proof of concept. It cannot be rolled out to the public until Alexa itself is HIPAA-compliant.

I interviewed Anne Weiler, founder and CEO of Wellpepper. She explained that using Alexa would be helpful for people who have mobility problems or difficulties using their hands. The prototype proved quite popular, and people seem willing to open up to the machine. Alexa has some modest affective computing features; for instance, if the patient reports feeling pain, the device will may respond with “Ouch!”

Wellpepper is clinically validated. A study of patients with Parkinson’s showed that those using Wellpepper showed 9 percent improvement in mobility, whereas those without it showed a 12% decline. Wellpepper patients adhered to treatment plans 81% of the time.

I’ll end this section by mentioning that integration EHRs offer limited information of value to Wellpepper. Most EHRs don’t yet accept patient data, for instance. And how can you tell whether a patient was admitted to a hospital? It should be in the EHR, but Sugarpod has found the information to be unavailable. It’s especially hidden if the patient is admitted to a different health care providers; interoperability is a myth. Weiler said that Sugarpod doesn’t depend on the EHR for much information, using a much more reliable source of information instead: it asks the patient!

SimplifiMed

SimplifiMed is a chatbot service that helps clinics automate routine tasks such as appointments, refills, and other aspects of treatment. CEO Chinmay A. Singh emphasized to me that it is not an app, but a natural language processing tool that operates over standard SMS messaging. They enable a doctor’s landline phone to communicate via text messages and route patients’ messages to a chatbot capable of understanding natural language and partial sentences. The bot interacts with the patients to understand their needs, and helps them accomplish the task quickly. The result is round-the-clock access to the service with no waiting on the phone a huge convenience to busy patients.

SimplifiMed also collects insurance information when the patient signs up, and the patient can use the interface to change the information. Eventually, they expect the service to analyze patient’s symptom in light of data from the EHR and help the patient make the decision about whether to come in to the doctor.

SMS is not secure, but HIPAA does not get violated because the patient can choose what to send to the doctor, and the chatbot’s responses contain no personally identifiable information. Between the doctor and the SimplifiMed service, data is sent in encrypted form. Singh said that the company built its own natural language processing engine, because it didn’t want to share sensitive patient data with an outside service.

Due to complexity of care, insurance requirements, and regulations, a doctor today needs support from multiple staff members: front desk, MA, biller, etc. MACRA and value-based care will increase the burden on staff without providing the income to hire more. Automating routine activities adds value to clinics without breaking the bank.

Earlier this year I wrote about another company, HealthTap, that had added Alexa integration. This trend toward natural voice interfaces, which the Alexa Diabetes Challenge finalists are also pursuing, along with the natural language processing that they and SimplifiMed are implementing, could put health care on track to a new era of meeting patients where they are now. The potential improvements to care are considerable, because patients are more likely to share information, take educational interventions seriously, and become active participants in their own treatment.

Study Offers Snapshot Of Provider App Preferences

Posted on March 20, 2017 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

A recent study backed by HIT industry researchers and an ONC-backed health tech project offers an interesting window into how healthcare organizations see freestanding health apps. The research, by KLAS and the SMART Health IT Project, suggests that providers are developing an increasingly clear of what apps they’d like to see and how they’d use them.

Readers of this blog won’t be surprised to hear that it’s still early in the game for healthcare app use. In fact, the study notes, about half of healthcare organizations don’t formally use apps at the point of care. Also, most existing apps offer basic EMR data access, rather than advanced use cases.

The apps offering EMR data access are typically provided by vendors, and only allow users to view such data (as opposed to documenting care), according to the study report. But providers want to roll out apps which allow inputting of clinical data, as this function would streamline clinicians’ ability to make an initial patient assessment, the report notes.

But there are other important app categories which have gained an audience, including diagnostic apps used to support patient assessment, medical reference apps and patient engagement apps.  Other popular app types include clinical decision support tools, documentation tools and secure messaging apps, according to researchers.

It’s worth noting, though, that there seems to be a gap between what providers are willing to use and what they are willing to buy or develop on their own. For example, the report notes that nearly all respondents would be willing to buy or build a patient engagement app, as well as clinical decision support tools and documentation apps. The patient engagement apps researchers had in would manage chronic conditions like diabetes or heart disease, both very important population health challenges.

Hospital leaders, meanwhile, expressed interest in using sophisticated patient portal apps which go beyond simply allowing patients to view their data. “What I would like a patient app to do for us is to keep patients informed all throughout their two- to four-hours ED stay,” one CMO told researchers. “For instance, the app could inform them that their CBC has come back okay and that their physician is waiting on the read. That way patients would stay updated.”

When it came to selecting apps, respondents placed a top priority on usability, followed by the app’s cost, clinical impact, capacity for integration, functionality, app credibility, peer recommendations and security. (This is interesting, given many providers seem to give usability short shrift when evaluating other health IT platforms, most notably EMRs.)

To determine whether an app will work, respondents placed the most faith in conducting a pilot or other trial. Other popular approaches included vendor demos and peer recommendations. Few favored vendor websites or videos as a means of learning about apps, and even fewer placed working with app endorsement organizations or discovering them at conferences.

But providers still have a few persistent worries about third-party apps, including privacy and security, app credibility, the level of ongoing maintenance needed, the extent of integration and data aggregation required to support apps and issues regarding data ownership. Given that worrisome privacy and security concerns are probably justified, it seems likely that they’ll be a significant drag on app adoption going forward.

E-Patient Update: Patients Need Better Care Management Workflows

Posted on March 10, 2017 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Now and then, I get a little discouraged by the state of my health data. Like providers, I’m frustrated as heck by the number of independent data sources I must access to get a full picture of my medications, care and health status. These include:

* The medication tracker on my retail pharmacy’s site
* My primary care group’s portal
* My hospital’s Epic MyChart portal
* A medication management app to track my compliance with my regimen
* A health tracker app in which I track my blood pressure
* My Google calendar, to keep up with my health appointments
* Email clients to exchange messages with some providers

That’s not all – I’m sure I could think of other tools, interfaces and apps – but it offers a good idea of what I face. And I’m pretty sure I’m not unusual in this regard, so we’re talking about a big issue here.

By the way, bear in mind I’m not just talking about hyperportalotus – a fun term for the state of having too many portals to manage – but rather, a larger problem of data coordination. Even if all of my providers came together and worked through a shared single portal, I’d still have to juggle many tools for tracking and documenting my care.

The bottom line is that given the obstacles I face, my self-care process is very inefficient. And while we spend a lot of time talking about clinician workflow (which, of course, is quite important) we seldom talk about patient/consumer health workflow. But it’s time that we did.

Building a patient workflow

A good initial step in addressing this problem might be to create a patient self-care workflow builder and make it accessible website. Using such a tool, I could list all of the steps I need to take to manage my conditions, and the tool would help me develop a process for doing so effectively.

For example, I could “tell” the software that I need to check the status of my prescriptions once a week, visit certain doctors once a month, check in about future clinical visits on specific days and enter my data in my medication management app twice a day. As I did this, I would enter links to related sites, which would display in turn as needed.

This tool could also display critical web data, such as the site compiling the blood sugar readings from my husband’s connected blood glucose monitor, giving patients like me the ability to review trends at a glance.

I haven’t invented the wheel here, of course. We’re just talking about an alternate approach to a patient portal. Still, even this relatively crude approach – displaying various web-based sources under one “roof” along with an integrated process – could be quite helpful.

Eventually, health IT wizards could build much more sophisticated tools, complete with APIs to major data sources, which would integrate pretty much everything patients need first-hand. This next-gen data wrangler would be able to create charts and graphs and even issue recommendations if the engine behind it was sophisticated enough.

Just get started

All that being said, I may be overstating how easy it would be to make such a solution work. In particular, I’m aware that integrating a tool with such disparate data sources is far, far easier said than done. But why not get started?

After all, it’s hard to overestimate how much such an approach would help patients, at least those who are comfortable working with digital health solutions. Having a coordinated, integrated tool in place to help me manage my care needs would certainly save me a great deal of time, and probably improve my health as well.

I urge providers to consider this approach, which seems like a crying need to me. The truth is, most of the development money is going towards enabling the professionals to coordinate and manage care. And while that’s not a bad thing, don’t forget us!

The Case For Accidental Interoperability

Posted on December 22, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Many of us who follow #HITsm on Twitter have encountered the estimable standards guru Keith Boone (known there as @motorcycle_guy). Keith always has something interesting to share, and his recent article, on “accidental” interoperability, is no exception.

In his article, he describes an aha moment: “I had a recent experience where I saw a feature one team was demonstrating in which I could actually integrate one of my interop components to supply additional functionality,” he writes. “When you build interop components right, this kind of accidental interop shows up all the time.”

In his piece, he goes on to argue that this should happen a lot more often, because by doing so, “you can create lot of value through it with very little engineering investment.”

In an ideal world, such unplanned instances of interoperability would happen often, allowing developers and engineers to connect solutions with far less trouble and effort. And the more often that happened, the more resources everyone involved would have to invest in solving other types of problems.

But in his experience, it can be tough to get dev teams into the “component-based” mindset that would allow for accidental interoperability. “All too often I’ve been told those more generalized solutions are ‘scope expansions,’ because they don’t fit the use case,” and any talk of future concerns is dropped, he says.

While focusing on a particular use case can save time, as it allows developers to take shortcuts which optimize their work for that use case, this approach also limits the value of their work, he argues. Unfortunately, this intense focus prevents developers from creating more general solutions that might have broader use.

Instead of focusing solely on their short-term goals, he suggests, health IT leaders may want to look at the bigger picture. “My own experience tells me that the value I get out of more general solutions is well worth the additional engineering attention,” he writes. “It may not help THIS use case, but when I can supply the same solution to the next use case that comes along, then I’ve got a clear win.”

Keith’s article points up an obstacle to interoperability that we don’t think much about right now. While most of what I read about interoperability options — including on this blog — focus on creating inter-arching standards that can tie all providers together, we seldom discussed the smaller, day-to-day decisions that stand in the way of health data sharing.

If he’s right (and I have little doubt that he is) health IT interoperability will become a lot more feasible, a lot more quickly, if health organizations take a look at the bigger purposes an individual development project can meet. Otherwise, the next project may just be another silo in the making.

ONC Announces Winners Of FHIR App Challenge

Posted on August 3, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

The ONC has announced the first wave of winners of two app challenges, both of which called for competitors to use FHIR standards and open APIs.

As I’ve noted previously, I’m skeptical that market forces can solve our industry’s broad interoperability problems, even if they’re supported and channeled by a neutral intermediary like ONC. But there’s little doubt that FHIR has the potential to provide some of the benefits of interoperability, as we’ll see below.

Winners of Phase 1 of the agency’s Consumer Health Data Aggregator Challenge, each of whom will receive a $15,000 award, included the following:

  • Green Circle Health’s platform is designed to provide a comprehensive family health dashboard covering the Common Clinical Data Set, using FHIR to transfer patient information. This app will also integrate patient-generated health data from connected devices such as wearables and sensors.
  • The Prevvy Family Health Assistant by HealthCentrix offers tools for managing a family’s health and wellness, as well as targeted data exchange. Prevvy uses both FHIR and Direct messaging with EMRs certified for Meaningful Use Stage 2.
  • Medyear’s mobile app uses FHIR to merge patient records from multiple sources, making them accessible through a single interface. It displays real-time EMR updates via a social media-style feed, as well as functions intended to make it simple to message or call clinicians.
  • The Locket app by MetroStar Systems pulls patient data from different EMRs together onto a single mobile device. Other Locket capabilities include paper-free check in and appointment scheduling and reminders.

ONC also announced winners of the Provider User Experience Challenge, each of whom will also get a $15,000 award. This part of the contest was dedicated to promoting the use of FHIR as well, but participants were asked to show how they could enhance providers’ EMR experience, specifically by making clinical workflows more intuitive, specific to clinical specialty and actionable, by making data accessible to apps through APIs. Winners include the following:

  • The Herald platform by Herald Health uses FHIR to highlight patient information most needed by clinicians. By integrating FHIT, Herald will offer alerts based on real-time EMR data.
  • PHRASE (Population Health Risk Assessment Support Engine) Health is creating a clinical decision support platform designed to better manage emerging illnesses, integrating more external data sources into the process of identifying at-risk patients and enabling the two-way exchange of information between providers and public health entities.
  • A partnership between the University of Utah Health Care, Intermountain Healthcare and Duke Health System is providing clinical decision support for timely diagnosis and management of newborn bilirubin according to evidence-based practice. The partners will integrate the app across each member’s EMR.
  • WellSheet has created a web application using machine learning and natural language processing to prioritize important information during a patient visit. Its algorithm simplifies workflows incorporating multiple data sources, including those enabled by FHIR. It then presents information in a single screen.

As I see it, the two contests don’t necessarily need to be run on separate tracks. After all, providers need aggregate data and consumers need prioritized, easy-to-navigate platforms. But either way, this effort seems to have been productive. I’m eager to see the winners of the next phase.

FHIR Product Director Speaks Out On FHIR Hype

Posted on June 6, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

To date, all signs suggest that the FHIR standard set has tremendous promise, and that FHIR adoption is growing by leaps and bounds. In fact, one well-connected developer I spoke with recently argues that FHIR will be integrated into ONC’s EHR certification standards by 2017, when MACRA demands its much ballyhooed “widespread interoperability.”

However, like any other new technology or standard, FHIR is susceptible to being over-hyped. And when the one suggesting that FHIR fandom is getting out of control is Grahame Grieve, FHIR product director, his arguments definitely deserve a listen.

In a recent blog post, Grieve notes that the Gartner hype cycle predicts that a new technology will keep generating enthusiasm until it hits the peak of inflated expectations. Only after falling into te trough of disillusionment and climbing the slope of enlightenment does it reach the plateau of productivity, the Gartner model suggests.

Now, a guy who’s driving FHIR’s development could be forgiven for sucking up the praise and excitement around the emerging standard and enjoying the moment. Instead, though, it seems that Grieve thinks people are getting ahead of themselves.

To his way of thinking, the rate of hype speech around FHIR continues to expand. As he sees it, people are “[making] wildly inflated claims about what is possible, (wilfully) misunderstanding the limitations of the technology, and evangelizing the technology for all sorts of ill judged applications.”

As Grieve sees it, the biggest cloud of smoke around FHIR is that it will “solve interoperability.” And, he flatly states, it’s not going to do that, and can’t:

FHIR is two things: a technology, and a culture. I’m proud of both of those things…But people who think that [interoperability] will be solved anytime soon don’t understand the constraints we work under…We have severely limited ability to standardise the practice of healthcare or medicine. We just have to accept them as they are. So we can’t provide prescriptive information models. We can’t force vendors or institutions to do things the same way. We can’t force them to share particular kinds of information at particular times. All we can do is describe a common way to do it, if people want to do it.

The reality is that while FHIR works as a means of sharing information out of an EHR, it can’t force different stakeholders (such as departments, vendors or governments) to cooperate successfully on sharing data, he notes. So while the FHIR culture can help get things done, the FHIR standard — like other standards efforts — is just a tool.

To be sure, FHIR seems to have legs, and efforts like the Argonaut Project — which is working to develop a first-generation FHIR-based API and Core Data Services specification — are likely to keep moving full steam ahead.

But as Grieve sees it, it’s important to keep the pace of FHIR work deliberate and keep fundamentals like solid processes and well-tested specifications in mind: “If we can get that right — and it’s a work in process — then the trough of despair won’t be as deep as it might.”

The Downside of Interoperability

Posted on May 2, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

It’s hard to argue that achieving health data interoperability is not important — but it comes with risks. And I’ve seen little discussion of the fact that interoperability may actually increase the chance that a major attack could hit a wide swath of healthcare providers. It might be extreme to suggest that we put off such efforts until we step up the industry’s security status, but the problem shouldn’t be ignored either.

Sure, data interoperability is a critical goal for healthcare providers of all stripes. While there’s room to argue about how it should be accomplished, particularly over whether providers or patients should drive health data management, there’s no question it needs to get done. There’s little doubt that most efforts to coordinate care will fall flat if providers are operating with incomplete information.

And what’s more, with the demand for interoperability baked into MACRA, we pretty much have no choice but to make it happen anyway. To my knowledge, HHS has proposed neither carrot nor stick to convince providers to come on board – nor has it defined “widespread” interoperability to my knowledge — but the agency has to achieve something by 2018, and that means change will come.

That being said, I’m struck by how little industry concern there seems to be about the extent to which interoperability can multiply the possibility of a breach occurring. Unfortunately, security is only as good is the weakest link in the chain, and data sharing increases the length of the chain exponentially. Of course, the risk varies a great deal depending on who or what the data-sharing intermediary is, but the fact remains that a connected network is a connected network.

The problem only gets worse if interoperability is achieved by integrating applications. I’m no software engineer, but I’m pretty sure that the more integrated providers’ infrastructure is, the more vulnerabilities they share. To be fair, hospitals theoretically vet their partners, but that defeats the purpose of universal data sharing, doesn’t it?

And even if every provider in the universal data sharing network practices good security hygiene, they can still get attacked. So it’s not a matter of requiring participants to comply with some network security standard, or meet some certification criteria. Given the massive incentives these have to steal health data (and lock it up with ransomware), nobody can hold out forever.

The bottom line is that I believe we should discuss the matter of security in a fully-connected health data sharing network more often.

Yes, we almost certainly need to press ahead and simply find a way to contain the risks. We simply can’t afford our fragmented healthcare system, and data interoperability offers perhaps the best possible chance of pulling it back together.

But before we plunge into the fray, it only makes sense to stop and consider all of the risks involved and how they should be addressed. After all, universal interconnection exposes a virtually infinite number of potential points of failure to cybercrooks. Let’s put some solutions on the table before it’s too late.

This Time, It’s Personal: Virus Hits My Local Hospital

Posted on March 30, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

In about two weeks, I am scheduled to have a cardiac ablation to address a long-standing arrhythmia. I was feeling pretty good about this — after all, the procedure is safe at my age and is known to have a very high success rate — until I scanned my Twitter feed yesterday.

It was then that I found out that what was probably a ransomware virus had forced a medical data shutdown at Washington, D.C.-based MedStar Health. And while the community hospital where my procedure will be done is not part of the MedStar network, the cardiac electrophysiologist who will perform the ablation is affiliated with the chain.

During my pre-procedure visit with the doctor, a very pleasant guy who made me feel very safe, we devolved to talking shop about EMR issues after the clinical discussion was over. At the time he shared that his practice ran on GE Centricity which, he understandably complained, was not interoperable with the Epic system at one community chain, MedStar’s enterprise system or even the imaging platforms he uses. Under those circumstances, it’s hard to imagine that my data was affected by this breach. But as you can imagine, I still wonder what’s up.

While there’s been no official public statement saying this virus was part of a ransomware attack, some form of virus has definitely wreaked havoc at MedStar, according to a report by the Washington Post. (As a side note, it’s worth pointing out that if this is a ransomware attack, health system officials have done an admirable job of keeping the amount demanded for data return out of the press. However, some users have commented about ransomware on their individual computers.)

As the news report notes, MedStar has soldiered on in the face of the attack, keeping all of its clinical facilities open. However, a hospital spokesperson told the newspaper that the chain has decided to take down all system interfaces to prevent the spread of the virus. And as has happened with other hospital ransomware incursions, staffers have had to revert to using paper-based records.

And here’s where it might affect me personally. Even though my procedure is being done at a non-MedStar hospital, it’s possible that the virus driven delay in appointments and surgeries will affect my doctor, which could of course affect me.

Meanwhile, imagine how the employees at MedStar facilities feel: “Even the lowest-level staff can’t communicate with anyone. You can’t schedule patients, you can’t access records, you can’t do anything,” an anonymous staffer told the Post. Even if such a breach had little impact on patients, it’s obviously bad for employee morale. And that can’t be good for me either.

Again, it’s possible I’m in the clear, but the fact that the FUD surrounding this episode affects even a trained observer like myself plays right into the virus makers’ hands. Now, so far I haven’t dignified the attack by calling the doctor’s office to ask how it will affect me, but if I keep reading about problems with MedStar systems I’ll have to follow up soon.

Worse, when I’m being anesthetized for the procedure next month, I know I’ll be wondering when the next virus will hit.

Mobile Health Security Issues To Ponder In 2016

Posted on January 11, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

In some ways, mobile health security safeguards haven’t changed much for quite some time. Making sure that tablets and phones are protected against becoming easy network intrusion points is a given. Also seeing to it that such devices use strong passwords and encrypted data exchange whenever possible is a must.

But increasingly, as mobile apps become more tightly knit with enterprise infrastructure, there’s more security issues to consider. After all, we’re increasingly talking about mission-critical apps which rely on ongoing access to sensitive enterprise networks. Now more than ever, enterprises must come up with strategies which control how data flows into the enterprise network. In other words, we’re not just talking about locking down the end points, but also seeing to it that powerful edge devices are treated like the vulnerable hackable gateways they are.

To date, however, there’s still not a lot of well-accepted guidance out there spelling out what steps health organizations should take to ramp up their mobile security. For example, NIST has issued its “Securing Electronic Health Records On Mobile Devices” guideline, but it’s only a few months old and remains in draft form to date.

The truth is, the healthcare industry isn’t as aware of, or prepared for, the need for mobile healthcare data security as it should be. While healthcare organizations are gradually deploying, testing and rolling out new mobile platforms, securing them isn’t being given enough attention. What’s more, clinicians aren’t being given enough training to protect their mobile devices from hacks, which leaves some extremely valuable data open to the world.

Nonetheless, there are a few core approaches which can be torqued up help protect mobile health data this year:

  • Encryption: Encrypting data in transit wasn’t invented yesterday, but it’s still worth a check in to make sure your organization is doing so. Gregory Cave notes that data should be encrypted when communicated between the (mobile) application and the server. And he recommends that Web traffic be transmitted through a secure connection using only strong security protocols like Secure Sockets Layer or Transport Layer Security. This also should include encrypting data at rest.
  • Application hardening:  Before your organization rolls out mobile applications, it’s best to see to it that security defects are detected before and addressed before deployment. Application hardening tools — which protect code from hackers — can help protect mobile deployments, an especially important step for software placed on machines and locations your organization doesn’t control. They employ techniques such as obfuscation, which hides code structure and flow within an application, making it hard for intruders to reverse engineer or tamper with the source code.
  • Training staff: Regardless of how sophisticated your security systems are, they’re not going to do much good if your staff leaves the proverbial barn door open. As one security expert points out,  healthcare organizations need to make staffers responsible for understanding what activities lead to breaches, or security hackers will still find a toehold.”It’s like installing the most sophisticated security system in the world for your house, but not teaching the family how to use it,” said Grant Elliott, founder and CEO of risk management and compliance firm Ostendio.

In addition to these efforts, I’d argue that staffers need to really get it as to what happens when security goes awry. Knowing that mistakes will upset some IT guy they’ve never met is one thing; understanding that a breach could cost millions and expose the whole organization to disrepute is a bit more memorable. Don’t just teach the security protocols, teach the costs of violating them. A little drama — such as the little old lady who lost her home due to PHI theft — speaks far more powerfully than facts and figures, don’t you agree?