Friday, July 29, 2011

As I traveled from Tokyo to Kyoto to Hiroshima this week, I rode the Shinkansen using my Japan Rail Pass (only available to foreign visitors).   The quality, safety, and efficiency of the Shinkansen are inspiring - no loss of life in billions of rides and an average deviation from the published time table that is less than 6 seconds.   My experience with train travel in the US is that a 6 minute deviation would be considered superlative.

If only the Boston, New York, and Washington DC corridor could have a Shinkansen - I'd never fly again!

Japan Railways will implement a truly cool technology over the next 10 years, a maglev Shinkansen  between Tokyo and Osaka.

The trains will travel at 500 kilometers per hour (300 mph) and cover the distance between Tokyo and Kyoto in about an hour.  

An equivalent train on the Eastern Seaboard would make an end to end train ride between Boston and Washington shorter than the typical US Airways Shuttle flight.

The idea behind maglev is simple - use fixed magnets in the train and electromagnets in the track to lift the train 1-10cm of the track, creating an nearly frictionless sliding surface.  Electromagnets also are used to alter the field creating forward motion.   There no "engine" pulling the train, thus no fossil fuels are required.  

A 300 mph frictionless train that links distant cities without the hassle of airport security and congestion.  That's cool!

Thursday, July 28, 2011

On my flight to Tokyo, I watched The Adjustment Bureau, a Philip K. Dick inspired film about a supernatural team of agents who ensure each person's path through life (their fate) is followed according to plan.

I've written about Regression to the Mean and the need for constant reinvention which makes life seem entirely non-linear.   When I consider the circuitous path I've taken in my career, it's interesting to think about the inflection points - my own adjustment bureau that led me to where I am today.

Here are five random but pivotal events:

1.  In the early 1970's my parents were admitted to law school in Southern California.   I had free time after school to explore my own interests while they were taking classes.  I rode my bicycle to a local surplus store that specialized in integrated circuits discarded by local defense contractors but still completely functional.   By the age of 12, I taught myself digital logic, analog signal processing, and the basics of microprocessors.  I learned to program in machine language and built an Altair microcomputer in 1979, becoming the first student with a dorm-room based computer at Stanford University.   My parents' law school admission led to my IT expertise - a non-obvious association.

2.  While I was an undergraduate at Stanford and a medical student at UCSF, I ran a 35 person company which specialized in business process automation software.  It enabled me to purchase a house in Marin Country and anchored me to the San Francisco Bay Area.   The Dean of Students at UCSF during that time did not believe that a medical student doing advanced clinical rotations should be allowed to run a company simultaneously and gave me a choice - divest the company or defer medical school.   I recognized that medicine was my future and divested the company, which eliminated my Northern California ties and ultimately led to my taking a job at Beth Israel Deaconess and Harvard.   A Dean of Students with a strong opinion about medical student entrepreneurial activities led to my career in Boston - another non-obvious association.

3.  On December 10, 1997 while working in the Emergency Department at BIDMC, my cell phone rang and the CEO of CareGroup informed me that I was going to serve as the CIO of CareGroup beginning at 8am the next day.   The external auditors at the time told the CEO that giving a CIO job to an unproven Emergency Physician was administrative malpractice.   The CEO firmly believed that a clinically focused, web-savvy, risk taker was better than a traditional process oriented CIO.  Nearly 15 years later, many people believe he was right.   A CEO who took a very controversial risk on a 35 year old with limited leadership experience resulted in my career as a CIO - a challenging outcome to predict based on my life history up to that point.

4.  In 2001, the new Dean for Medical Education at Harvard Medical School had a dream - moving the entire medical school curriculum to the web and mobile platforms (early Palm technology).   He asked for my advice given my experience at BIDMC moving clinical records to the web.  Although I had no experience in educational technology, I worked with a team of students, faculty and IT developers to collaboratively create the Mycourses learning management system, serving as a part time Associate Dean in addition to my CareGroup CIO role.   The project went well and I was eventually asked to serve as part time Harvard Medical School CIO, which the CareGroup Board gave me permission to do (I became a 1.5 FTE, 100% at CareGroup and 50% at Harvard simultaneously).   A sojourn into educational technologies led to my becoming responsible for 10 years of infrastructure and application work at Harvard Medical School, including the evolution of high performance computing and storage clusters to support the life sciences, unique challenges that were not even imagined in 2001 - a definite non-linear path.

5.  In 2005, I took a call from ANSI, asking if I would attend a meeting to discuss harmonizing standards as part of program conceived by the first national coordinator for IT, David Brailer.  Although I did not consider myself a standards expert, I agreed to serve as chair of HITSP.  As a consequence of 5 years of work with healthcare standards I became part of many national, regional, and state healthcare IT projects.   A phone call about standards led to my federal and state roles, which became the basis for my Harvard professorship.    A call from ANSI and a Harvard professorship - very hard to predict that!

What's next?  At BIDMC, the Chief Executive Officer selection process will result in new leadership this Fall.   New mergers and acquisitions will result in an accountable care organization built around BIDMC.   Complex healthcare information exchange, registries, and business intelligence tools needed to support healthcare reform will accelerate my hospital CIO, state, and national activities.

All of this is happening while I'm working on replacing my Harvard Medical School CIO role with a full time successor.

It's July of 2011 and hard to know exactly how the inflection point of my evolving Harvard role will affect the future,  but I feel powerful forces are aligning to create a quantum leap forward in electronic health records and health information exchange technology.

A year from now, I'll look back and assess what The Adjustment Bureau had in mind for me.

Wednesday, July 27, 2011

Jacob  Farmer, the CTO of Cambridge Computer and an industry recognized expert on storage, recently shared with me his draft whitepaper which highlights the life sciences as experiencing the pain of storage growth more than any other industry.

Here's his very thoughtful observation

"Detailed Problem Statement
Until quite recently, life sciences research would not typically have been described as 'data intensive', certainly not in comparison with other scientific disciplines, such as high energy physics or weather modeling. In the last few years, however, new data-intensive modalities such as spectrometry, next-gen sequencing, and digital microscopy have entered the mainstream, thus unleashing an unprecedented tsunami of unstructured data.

Life Sciences IT professionals have been caught off guard. Having not grown up with data intensive research, life sciences IT professionals have had to improvise. When they look to their peer institutions for guidance, they find that their peers are in the same predicament. The institutions at the cutting edge  are constantly in triage mode, throwing money at the problem in order to keep their heads above water. On the one hand, these institutions are presenting at conferences and being heralded as examples for the rest of the industry. On the other hand, they are the first to admit that there are many problems left to be solved. Their experiences serve to warn the industry that things are going to get worse before they get better!"

One of the most significant IT leadership challenges is deciding when to change and when not to change.   Some technology projects in your portfolio should be on the bleeding edge, but not all, mitigating the risk that you'll implement technologies that are more hype than lasting innovation.

For example, in the 1990's BIDMC chose not adopt client/server technologies.  Instead it embraced the cutting edge web in 1996, skipping an entire generation of products.   Being late to client/server and early to the web created a great trajectory that has served us well.

Life Sciences is at an inflection point as Jacob notes.  Harvard Medical School has been an early adopter of high performance computing clusters but has proceeded cautiously on research storage.   A large investment in SAN over the past few years would have been too expensive.  A significant investment in early NAS would not scaled.   We've made and will continue to make moderate investments in high performance NAS backed by SSD drives for metadata management, ensuring that we meet the current needs of our customers.  However, we're going to step back and ask ourselves where the balance of cost, performance, capacity, information life cycle, and security needs to be in the future.   We'd rather be cutting edge on demand management/reporting tools/chargeback approaches but a fast follower on storage technology.

In the conference I'm speaking at today in Tokyo, Professor Nonaka described the 6 characteristics of a wise leader based on his May 2011 Harvard Business Review Article.  One of his major arguments is that leaders need to have explicit (factual) and tacit (practical/intuitive) knowledge.   I believe that the inflection point in storage technologies requires life science IT leaders to rely on their intuition, since user needs and storage technologies, per Jacob's comments, are changing too fast to rely on the facts.

Thanks to Jacob for sharing his insight.  I'm confident that life sciences IT leaders will experience disruptive innovation over the 18 months. Some will make wise investments and others will be less fortunate.   I'm optimistic that Harvard Medical School can navigate the rough waters ahead, accelerating technology adoption or putting on the brakes in response to the evolving environment.

Tuesday, July 26, 2011

Today I'm in Tokyo lecturing and meeting with industry, academic, and government leaders.

The weather is 85-90F with 85% humidity and 4mph winds.   It's hot and power is limited.

The Japanese are a very resilient people, so it's interesting to see how they have worked together to conserve energy.

In the Fujitsu offices where I was visiting with Professor Ikujiro Nonaka, the Super Cool Biz poster pictured above lined the entrance.

Here are the basic ideas

1.  Office thermostats are set to 82F.

2.  Office attire is relaxed with fewer ties and suits.   Super Cool Biz encourages polo shirts, Hawaiian shirts, running shoes and even appropriate T-shirts, jeans and sandals.

3. Switching off lights and unplugging computers that are not in use is encouraged.

4. Shifting work hours to the morning and taking more summer vacation than usual is suggested.  The Tokyo metropolitan government, for example, begins shifts at  7:30, 8 or 9 a.m. rather than at 8:30, 9 or 9:30.

5.  Store and restaurant hours are shifted so that they open later when the weather is cooler.  In my hotel, all power and air conditioning is shut off when I leave the room.  Businesses hand out fans at the door.

Everyone does their part to conserve and it works.

I'm dressed in my lightest weight black clothing and have abandoned my suit jacket.

Off to a day of lecturing and Super Cool Biz!

Monday, July 25, 2011

Many have asked me for an analysis of the new FDA Mobile Medical Applications NPRM.

The FDA will not seek to regulate mobile medical apps that perform the functionality of an electronic health record system or personal health record system.   However, the FDA defined a small subset of mobile medical apps that may impact the functionality of currently regulated medical devices that will require oversight.   Here's a thoughtful analysis by Bradley Merrill Thompson of Epstein Becker Green, which he has given me permission to post:

"Today, FDA published the long-anticipated draft guidance on the regulation of mobile apps—more specifically, what the agency calls “mobile medical apps”.  This draft reflects significant efforts by FDA in a fairly short amount of time, and we applaud that work.  Much of the framework of the FDA guidance is consistent with the work the mHealth Regulatory Coalition (MRC) published on its website earlier this year (www.mhealthregulatorycoalition.org).  While FDA has done a good job getting the ball rolling, there are a number of areas that require further work.  We all (including FDA) recognize that this draft guidance is certainly not the end of the story.

 The regulatory oversight recommended in today’s draft guidance applies only to a small subset of mobile apps, which FDA defines as any software application that runs on an off-the-shelf, handheld computing platform as well as web-based software designed for mobile platforms.  To be regulated, as a first step the app would have to first meet the definition of a medical device and then as a second step either (1) be used as an accessory to another regulated device or (2) “transform” the handheld platform into a device, such as by using the platform’s display screens or built-in sensors.

 The problem with the first step is that this guidance doesn’t explain how to determine whether the apps meet the medical device definition in areas where the MRC has questions about intended use. In our policy papers, we explain that many of the mHealth apps operate in the gray areas between treating disease and managing wellness.  But the guidance simply states that apps intended for general health and wellness purposes are not regulated.  That, unfortunately, doesn’t provide the clarity we need.  We already knew that.  Instead, we need to understand what types of claims a company can make about health and wellness that also implicate a disease before we can determine whether the app is regulated or not.

The second step has a number of ambiguities too.  First there’s the question of accessories.  At least for now, the FDA kept the old rule of treating apps that “connect” to regulated medical devices as accessories that are regulated in the same device classification as the “parent” device.  The problem with this approach is that it produces over-regulation in mHealth systems, particularly where there are a number of different medical devices and non-clinical products involved.  Fortunately, FDA appears to recognize that this approach could lead to over-regulation of low-risk apps, and seems open to considering other approaches.  Indeed, the agency specifically requested comment on how to improve this framework.  The MRC is developing an alternative approach that involves creation of classification regulations for specific types of mHealth apps so that these apps will be classified separately from the parent device.  This approach will require rulemaking activities, which we believe is the reason FDA did not address it in the proposed guidance.

 And then there are the apps that transform a mobile platform into a medical device: there are a bunch of good nuggets in the guidance, but still some uncertainty and slightly puzzling aspects. I think everyone (though perhaps no one more than the folks at iTunes, Blackberry App World, and Android Market) is excited to hear that FDA doesn’t plan to regulate as manufacturers those who “exclusively distribute” the app.  Likewise, the smartphone manufacturers can breathe a sigh of relief that they too will not be considered regulated manufacturers so long as they merely distribute or market their platform with no device intended uses.  What’s interesting is that FDA “expects” these distributors to cooperate with the regulated app developers in the event of a correction or a recall.

 In the category of puzzling aspects, the FDA for example says that an entity that provides app functionality through a “web service” or “web support” for use on a mobile platform is considered a manufacturer.  But at first blush, this type of entity may or may not meet the agency’s own definition of manufacturer because the web-service provider might not be responsible for initiating the specifications or designing, labeling, or creating the software system.

 The agency offered some examples of what it believes to be outside of this guidance, including electronic copies of medical textbooks, health and wellness apps, apps that automate general office operations, general aids that assist users, and electronic/personal health records.  In addition, FDA specifically indicated that it is exercising its enforcement discretion and will not currently regulate apps that automate common medical knowledge available in the medical literature or allow individuals to self-manage their disease or condition.  This is helpful, but there remain a number of other types of apps that should be specifically identified as being outside of FDA regulation.

 You need to read the draft guidance carefully, because if you are not familiar with medical device law, there is a category you might miss: clinical decision supports systems fall.  This falls under the rubric of an app that would cause the mobile platform to become a device.  I suppose most people instantly think of things like an electronic stethoscope where a senor is added to a phone, in addition to software.  But no hardware needs to be added to a mobile platform to make it a medical device.  Many people may not realize that a simple computer system of any type that runs software used to analyze clinical data to advise a healthcare professional can, in certain circumstances, be a regulated medical device.  So an app that doesn’t run any hardware other that the mobile platform itself can be regulated.

This draft guidance has no doubt generated a ton of questions. So, the timing of the release is perfect! On July 27th, a large group of individuals involved in the mobile health space will be congregating at the Continua/ATA Summit to discuss regulation of mHealth products.  Bakul Patel, the mobile health policy guru at FDA, will be there to discuss the details of this guidance, as will the mHealth Regulatory Coalition, which is set to release its own version of proposed mHealth guidance in the coming weeks.  The discussion will surely be lively and informative.  There’s still time to register and I hope to see you there."

Friday, July 22, 2011

In February I visited Japan a few days before the Tohoku earthquake to complete my research on the state of healthcare IT in Japanese hospitals and private practices.

Since then I have worked with the US Center for Strategic International Studies (CSIS) and the Japanese Health and  Global Policy Institute (HGPI) to develop a national healthcare IT plan for Japan in response to the earthquake, tsunami and nuclear reactor crisis.

Here's the finished report, issued by CSIS today.

I'm flying to Japan tonight and will be meeting with government, academic, and industry leaders in Tokyo and Kyoto until August 4.  

As readers of my blog know, my life is devoted to making a difference.   If I can share lessons learned from the US experience to accelerate healthcare IT in Japan, I will have repaid all my Japanese colleagues for the kindness they have shown me over the years.

My blogs next week will be sporadic as I travel the country as a missionary for healthcare IT.
Powered by Blogger.

Popular Posts

Blog Archive