This is the next post in my series of Do’s and Don’ts Healthcare IT. As we all know, some of our most important citizens live in rural settings, small cities, the countryside, or remote areas. These areas have smaller populations and less direct access to vital healthcare resources. In the past 15 years or so we’ve made some great strides in remotely accessible healthcare; these offerings, called telemedical tools, provide important clinical care at a distance. Here are some do’s and don’ts of telemedicine:
- Do use commonly available web meeting and online video tools bring expert caregivers anywhere. WebEx, GotoMeeting, Adobe Connect, Skype, and a variety of other “web meeting” tools used mostly in professional office settings and remote sales pitches are wonderful tools to connect caregivers in populated communities to their rural patients. A simple $30 to $50 per month account on the physician side with almost no direct cost for the patient is an excellent way to engage with patients. These kinds of web meetings can happen securely either at the patient’s home or patients can be brought into satellite offices with high-quality telepresence. Then, instead of waiting for days or weeks for a health professional to travel to an area or patients having to take off many hours or entire days traveling to experts in big cities, care can be given almost immediately with less inconvenience. Don’t assume that kinds of web meeting solutions are HIPAA compliant out of the box; however, do realize they can be made HIPAA compliant with appropriate protections.
- Do use medical devices for remote monitoring of in-home care improve clinical observations. While web meetings are great for basic primary care, it’s not perfect for elder care, long-term care, and other types of clinical requirements. There is a new class of devices that can put near-hospital-quality patient monitoring devices into patient homes and “beam” that data to monitoring centers that can watch for important events across many patients in different geographical areas. Toss in a nurse or other caregiver that can visit once a week or once a month to calibrate the devices and you can see how much more convenience patients can have and have their physicians, wherever they may be, have immediate access to their actual vitals and clinical status.
- Don’t assume that medical device connectivity will be fast or easy to do on your own — you’ll need something like Qualcomm’s 2net platform. 2net is a trustable, Class I FDA-listed, standalone gateway with an embedded cellular component that sends clinical data truly “in the cloud” without requiring local internet connectivity. Medical data can be sent from devices in the same way that e-books can be read on Kindle devices – using 3G cellular, from mobile phones, and software APIs.
- Don’t always send patients to labs; instead, take labs to patients with mobile imaging and lab specimen collections that allow remote reading and web-based report distribution. It’s difficult for many rural communities to have their own full diagnosticians but mobile imaging centers and lab specimen “kiosks” can do the X-rays, take pictures, and perform collections and then send the data electronically to large populated centers where they can be “read” and analyzed; the reports can be distributed via secure e-mail or other web-based applications to doctors in the rural areas or physicians remotely available and connected through web meeting or other similar tools.
- Do try and make behavioral health, mental health, and related care made more accessible. Veterans of our foreign wars are coming home with many problems that can be easily diagnosed with proper access and many of the veterans live in rural communities; while primary care and specialty care is difficult to get in smaller population regions, behavioral and mental health is even harder to access. Telemedical assistance through online chat, Skype-like video conversations, and secure online messaging can provide quick relief.
- Don’t leave patients on their own and encourage them to join online communities. Online community building tools allow populated city citizens to meld with their rural counterparts. Patients helping other patients is a terrific approach to extending care; sometimes what a patient needs is not necessarily a health professional but a curated session with fellow patients going through the same problems. Online, electronic, community tools such as PatientsLikeMe.com can connect geographic communities and bring them closer together without increasing costs or requiring anything more than a simple mobile phone or computer.
What do’s and don’ts would you add to a telemedicine strategy? Drop me a comment below.
I recently wrote, in Do’s and Don’ts of hospital health IT, that you shouldn’t make long-term decisions on mobile app platforms like iOS and Android because the mobile world is still quite young and the war between Apple, Microsoft, and Google is nowhere near being resolved. A couple of readers, in the comments section (thanks Anne and DDS), asked me to elaborate mobile and mHealth strategy for healthcare professionals (HCPs) and hospitals.
A couple of the key points were:
- (Anne) how can you avoid making long-term mobile decisions at this point? After all, hospitals that don’t steer their doctors are going to be managing whatever technology the doctors invest in, aren’t they?
- (DDS) the risk is that people will take this to mean that they shouldn’t move at all on mobile app platforms, and this would be a mistake. This is the perennial issue with health IT; if it’s not perfect, then wait.
The approach I recommend right now for mobile apps, if you’re developing them yourself, is to stay focused on HTML5 browser-based apps and not native apps. So, to answer Anne’s and DDS’s question specifically, no you shouldn’t wait to allow usage of mobile apps by anyone; but, if you’re looking to build your own apps and deploy them widely (not in simple experiments or pilots) then you shouldn’t write to iOS or Android or WP7 but instead use HTML5 frameworks like AppMobi and PhoneGap that give you almost the same functionality but protect you from the underlying platform wars. In the end, HTML5 will likely win and it’s cross-platform and quite functional for most common use cases. If you’re not developing the apps yourself and using third-party apps, then of course you must support the use of iOS native, Android native, and soon Windows native apps on your network.
So, from a general perspective you should embrace mHealth but do so in a strategic, not tactical manner. Here are the most critical questions to answer in a mHealth strategy — it’s not a simple one size fits all approach:
- How will you allow doctors’ or patients’ own devices within your hospitals / organizations — simply by providing connectivity and wireless access on the production network or some other means?
- How will you allow doctors’ own devices to connect to hospital IT systems?
- How will you extend hospital IT systems via hospital-owned mobile devices?
- How will you allow the hospital or organization to “prescribe” the use of apps to patients and track the usage of apps?
- How will you approve or deny the use of certain apps that may not meet FDA regulations if they get close to MDDS or Class 1/2/3 devices?
If there is interest in this topic, I will expand on my list of Do’s and Don’ts — mHealth is a very complex topic and requires a good strategy. Just saying that you allow the use of mobile devices like smartphones in your hospital is not an mHealth strategy. 
In case you haven’t seen it, MU attestations data is now available on Data.gov and it includes analyzable vendor statistics.
The data set merges information about the Centers for Medicare and Medicaid Services, Medicare and Medicaid EHR Incentive Programs attestations with the Office of the National Coordinator for Health IT, Certified Health IT Products List. This new dataset enables systematic analysis of the distribution of certified EHR vendors and products among those providers that have attested to meaningful use within the CMS EHR Incentive Programs. The data set can be analyzed by state, provider type, provider specialty, and practice setting.
The data set does not include dollar amounts or the difficulty of attestation (e.g. how many times it took to pass). I’ll try and find out if that data might be available in the future. It’s also unclear whether the provider counts were broken up into each line (meaning one provider per row) or if multiple providers were aggregated into lines (meaning multiple providers were grouped).
The dataset is available now on Data.gov at http://www.data.gov/raw/5486 and is worth checking out. Since the file has been downloaded over 75 times, it’s clear some of you already know about this so if you’ve done some analysis with it; if you’ve done any analysis or posted results please drop me a note below so that everyone can benefit.
Last year I started a series of “Do’s and Dont’s” in hospital tech by focusing on wireless technologies. Folks asked a lot of questions about do’s and dont’s in other tech areas so here’s a list of more tips and tricks:
- Do start implementing cloud-based services. Don’t think, though, that just because you are implementing cloud services that you will have less infrastructure or related work to do. Cloud services, especially in the SaaS realm, are “application-centric” solutions and as such the infrastructure requirements remain pretty substantial – especially the sophistication of the network infrastructure.
- Do consider programmable and app-driven content management and document management systems as a core for their electronic health records instead of special-purpose EHR systems written decades ago. Don’t install new EHRs that don’t have robust document management capabilities. Do consider EHRs that can be easily integrated with document and content management systems like SharePoint or Alfresco.
- Do go after virtualization for almost all apps – as soon as possible, make it so that no applications are sitting in physical servers. Don’t invest more in any apps that cannot easily be virtualized.
- Do start looking at location-based asset tracking and app functionality; your equipment should be aware of where it’s physically sitting and be able to “find itself” and “track itself” using location-based awareness. Don’t invest heavily in systems that can not support location-based awareness (like potentially allow or disallow logins based on where someone is logging in from as well as enable / disable certain features in applications on where logins are occurring).
- Do start implementing single sign on and common identity management with CCOW integration. Don’t invest in any systems that cannot meet common identity or SSO requirements.
- Don’t make long-term decisions on mobile app platforms like iOS and Android because the mobile world is still quite young and the war between Apple, Microsoft, and Google is nowhere near being resolved. A platform that looks strong today may be weak tomorrow and become legacy quickly; however, HTML5 is not going anywhere and will be ultimate winner of the next 15 years just like HTML4 is the winner from 1995 to now. Do start investing in HTML 5 and CSS3 and away from HTML4. Don’t install any more apps that require IE6/7 or older browsers and don’t invest in systems that don’t have HTML5 in their roadmaps.
- Don’t write applications on top of legacy EHR platforms; write applications with proper HL7 connectivity and platform independence. Most EHR platforms are using technologies that are either ancient or need to be replaced; by integrating deeply but remaining independent of their technologies you’ll get the best of both worlds.
- Don’t buy any medical devices from vendors that don’t have a deep and thorough medical device to healthcare IT enterprise connectivity strategy. If a device doesn’t have wired or wireless TCP/IP access, doesn’t have data export or HL7 connectivity is not worth purchasing.
- Don’t buy any thick-client applications that do not have thin-client “remote viewers” available.
