Mobile

Apps for Health 2013 at Mohawk College

dondennison Healthcare IT , , , , , , , , , ,

Mohawk1

I had heard good things about this one-day conference, so I decided to take the drive down to Hamilton, ON to check it out. I am glad I did.

Apps for Health has 3 tracks. One focused on Technology, one on Health, and another on Education. They also had keynote speakers to open and close the day of sessions.

To be honest, I was fearing that the recurring trend was going to go something like this: “Healthcare is broken! I love the App Store! Why can’t we get more apps faster!?!” …but the speakers were polished and came with insight and data.

Topics ranged from the needs for a “prescription” for a set of apps for different patient conditions, different levels of safety and risk that apps represent (for physicians and patients), regulatory challenges, privacy, security, and development approaches.

A collection of small and not-so-small vendors had table top displays set up, and attendees (and students) seemed to be routinely interacting with the vendor staff.

Having never been to Mohawk college before, I have to admit that I was quite impressed with the facilities. The buildings are very modern. Everywhere you look, you see technology—on the walls, in the classrooms, in the library, in the hands of the students …everywhere.

One of the more enjoyable parts of my excursion to The Hammer (nickname for Hamilton), was a tour of the Mohawk MEDIC lab. The students demonstrated a complete workflow of a patient’s journey through a referral from her family doctor, to an exam with a specialist (an allergist), and an unfortunate skiing accident in a remote area.

They showed how an EMR—in this case, the open source OSCAR EMR—could accept the referral and share it with the specialist by using an IHE XDS infrastructure. They then showed how the specialist could perform the exam and share the results back to the EMR using the same methods. They also showed the use of mobile technology by EMT and ER staff to review the patient’s records before administering treatment, thus avoiding a potential adverse incident (the allergist report found her allergic to penicillin and other drugs).

Mohawk is serving its students well. They are not only learning about the real world challenges facing healthcare, they are learning about how to build and apply open solutions, and use the latest tools to do it. And they are doing it in a fantastic facility. If you know someone thinking of going there, at least go for the tour—you won’t regret it.

Article – Can a smartphone do what your doctor does?

dondennison Healthcare IT , , , , ,

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.

Blog – FHIR Version 1.0

dondennison Healthcare IT , , , , , ,

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 – ONC chief: Regulation fuels innovation

dondennison Policy , ,

This article debates the impact regulation has on innovation.

My 2 cents: Regulation provides consumer protection; standards provide access to data, which often leads to innovation.

More thoughts and notes…

  • Mobile “apps” seem to always be cited as examples of innovation, but I believe  the Web services (based on REST) that enable mobile and Web access are the key to innovation—the client will change over time (browser, smartphone, downloaded app, HTML5 app, tablet, etc.), but a secure, flexible and reliable API makes the change less painful. Thankfully, standards bodies (DICOM, HL7) are focusing efforts in this area. The Web services and the clients don’t need to be from the same vendor, or even use the same technology—that is the beauty of REST.
  • I like how people that issue regulations make statements about the benefits of these rules, such as driving innovation (they claim). Shouldn’t we ask the people that have to operate (and attempt to innovate) within the interpretation of these guidelines? I intentionally used the word “interpretation”, as different regulatory  professionals seem to have different opinions on what burden of process needs to be met for medical devices.
  • The FDA’s eagerly-anticipated guidance on mobile apps and devices “should be out by October.”

Open mHealth vs. HL7 FHIR

dondennison Healthcare IT , , ,

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.

Articles on Mobile Health Applications and FDA Regulation

dondennison Healthcare IT , ,

Check these out…

Dear FDA: Qualcomm’s Robert Jarrin lists his wishes for FDA regulatory action

Where is the ‘fine line’ between safety and free rein for mobile development?

Some thoughts…

  • At risk of ending up on some government list of subversives, I question how often FDA (or equivalent agency in other countries) regulations actually result in protecting patients when they are applied to health IT products. Yes, good design, development, and validation practices are necessary for quality products. And, yes, health IT products are managing very important, not to mention legally protected, information that—when misused or when a defect affects its operation—can result in improper actions being taken …sometimes with adverse effects. But, for those that have worked for a registered medical device manufacturer, we spend more time with our eyes on paperwork than we should be. Time we could be spending on better design, or additional testing before launch. Too much of the paperwork is about evidence creation, and not about actual quality. Many process and method innovations developed in general IT product development are often difficult to adapt to the expected models in the FDA’s so called good manufacturing practices (GMP), and therefore do not achieve the same benefits/results.
  • If the U.S. government is generating revenue from the new medical device excise tax, is it possible that the FDA may be motivated to determine that more, not fewer, mobile apps are medical devices, and therefore subject to taxation? OK, I may have crossed the line into full-fledged conspiracy theory there. Sorry about that.

 

Article – mHIMSS executives say FDA regulation won’t hold back app innovation

dondennison Healthcare IT , ,

This short Q&A article discusses the role and impact of FDA regulation, as well as the new medical device excise tax.

Some thoughts…

  • Someone explain to me how applications accessed on a tablet or smartphone are so much different than a desktop app being accessed on a netbook on Wifi. A tablet is a computer, typically without a keyboard and mouse. The user input method varies slightly and we have a whole new class of device? I don’t get it. If an application is collecting clinical data (e.g. dermatology photo), it should be subjected to appropriate regulations regardless if the user is using a mobile computer or a full desktop to run the application. This seems to me like a lack of understanding of computing by policy makers.
  • I believe the driving issue are mobile app developers getting into healthcare rather than registered medical device manufacturers getting into building mobile apps. Those familiar FDA regulations (and similar ones in other jurisdictions) generally know the rules. It is the mobile app developers unaware of the FDA regulations that are likely facing the greater challenge (mostly learning the requirements of being a medical device manufacturer). Providing the right guidance to the app developer community could be a growing opportunity for experienced regulatory affairs contractors/consultants.