I've written previously about those times in my career when alignment of leadership and resources led to major achievements. High performing teams are a pre-requisite to such achievement and here are a few characteristics of high performing teams I have worked with:
Competence
Domain expertise and an ability to execute assigned tasks are key to ensuring vision is turned into successful implementation. My experience is that "A" players hire "A" players and "B" players hire "C" players. This means that highly competent people surround themselves with skilled people because they do not feel intimated by having subordinates or colleagues who are smarter, more talented, or more successful. No member of a team can do everything, so having a group of smart people working together creates a sum greater than the parts. On the other hand, incompetent people tend to hire even less competent people to shore up their own egos and self image. Leaders need to be very careful when retaining marginally performing teams, because incompetent people hiring less competent people can get the organization in trouble very quickly.
Trust
As a rock climber, I know that my life depends upon the skill and decision making of my climbing partner. No matter how good I am, a mistake by my partner could kill both of us. Every day I think about my teams and ask if I would trust them to hold my rope. A high performing team requires a level of trust and confidence that fosters a joy of collective achievement rather than fear of individual failure. Creating an environment of trust has worked for me as a parent and is an essential part of a optimized team.
Communication
I realize that carrying mobile devices creates the burden of being connected 24 hours a day. I do not inflict my own work schedule on any of my teams (my last true day off was in the summer of 1984). However, creating a level of communication among team members that enables rapid escalation and resolution of issues is essential to high performance. Teams should respect the need for time away but arrange coverage such that email, instant messaging, paging, phone calls, and web-based collaboration can be initiated at a moment's notice for resolution of complex issues that are often precipitated by circumstances beyond the control of the team. Teams should create a level of transparency that keeps all members informed of current priorities, strategies, and challenges using blogs, wikis, and meetings (to the extent necessary). Great communication reduces friction, enhances decision making, and reduces unnecessary work.
Loyalty
Highly functional team members are always there for each other. No matter what happens, they do not throw their colleagues under the bus. They give an early heads up when projects or staff members are in trouble. They accelerate decision making by contributing positively to consensus building. They respect hierarchical boundaries, escalating problems by collaborating with team leaders and managers. The result is a team that is deeply loyal to its members rather than focused on highlighting the success of any one individual.
The Greater Good
In my trip to Japan, I discussed priority setting in the Japanese bureaucracy. At times it appears that ministries set priorities based on sustaining their own power and authority. Bureaus within ministries can set priorities in silos. Rarely is the greater good for the country the driving force that unifies budgeting at every level. Highly functional teams think about the overall goals of the organization and craft their plans around those activities which will create the greatest good for the greatest number. There is not siloed thinking about resources, budgets, or achieving individual goals at the expense of team of goals.
High performing teams are hard to create and sustain, but when they happen, they are to be treasured. There is nothing I will not do for my high performing teams.
Tuesday, 2 August 2011
Monday, 1 August 2011
The Pace of Change
My travels in Japan included lectures in Tokyo and Kyoto, sharing lessons learned from the US health information technology national efforts. I highlighted that the Office of the National Coordinator has to balance the desire for innovation with a pace of change that vendors and clinicians can tolerate.
This led me to think about the pace of change that CIOs are experiencing right now. The IT innovations of the past few years have been dizzying and the cycle between the peak of hype to the trough of obsolescence is now measured in months, not years.
Some examples of rise and fall
1. Blackberry - I was one of the earliest adopters of Blackberry technology, using a small pager-like device for short text messages. As each new model was announced, I welcomed the innovations - the evolution from thumbwheel to joystick to track pad, larger color screens, cameras, video features, and voice memo recording. However, in 2011, my mobile device needs have outpaced Blackberry's engineering. I now need a full featured web browser, a book reader, the ability to zoom/drag via touch screen, and a robust App Store. Until 2010, Blackberry seemed to be unstoppable in the corporate messaging world. Now it is laying of 2500 people as the iPhone and Android devices rapidly replace Blackberries in consumer and business settings. They tried very hard to introduce new devices such as the Storm, the Playbook, and the Torch, but came up short as customer expectations exceed their pace of innovation.
2. MySpace - Remember when personalized portals were hot? At its height, social networking company MySpace had 1500 employees. It was purchased in 2005 by Rupert Murdock for $580 million. It was recently sold for $35 million. At this point, MySpace does not appear on lists of popular social networking destinations. Given that the value of most websites is based on usage and thus potential for selling advertising, shifts in the market can occur almost instantly. Who knows, in a year or two surfing to today's popular sites such as twitter.com may yield the error "URL not found"
3. Google Health - Google is a great company and I have no doubt that it will continue to succeed. Google+ is a wonderful social networking site that is likely to steal some of Facebook's market share. However, like most technology companies, Google now has to deal with the mire of maintenance that comes with a mature set of highly used applications. More resources are spent on operations and less are available for pure innovation. Smaller, more nimble companies are likely to outpace Google and will either be acquired by Google or erode Google's leadership position. Many of my friends and colleagues who joined Google a few years ago (when it was considered unstoppable) have now left Google as the company has matured and its culture has changed. The closing of Google Health is just one symptom of the changes in focus that occur when a company is faced with the maintenance and regulatory burdens of maturing products.
4. Microsoft Windows - In 1995, I remember standing in line at midnight in a Torrance, California electronics store to buy one of the first copies of Windows 95. My early Dell computer (a 386 processor) ran DOS and Windows 3.1, so Windows 95/Office 95 was a remarkable innovation. It was stable and easy to use. Windows 98 Second Edition included built in internet features and was remarkably fast and reliable. Thereafter, Microsoft has introduced new features, but not achieved the same kind of game changing innovation that occurred 1995-2000. How many people stood in line at midnight to buy Microsoft Vista? How eagerly anticipated was Windows 7? How many people brag about their Windows Phone or Windows mobile device? The market share numbers tell the story - as of 2011, the majority of Windows computers in the world still run XP. Microsoft is a great investment - its stock price is low and its product line is very broad. It's Kinect device was the top selling consumer electronics product over the past year. However, the burden of maintaining compatibility with an operating system developed for the IBM XT era has led Microsoft to lose its edge in a cloud-based, mobile centric world.
5. Cisco - The CareGroup network outage of 2002 taught me many lessons about network architecture. In response, we installed an updated end to end Cisco infrastructure, embraced Cisco technical services, and worked closely with Cisco salespeople to plan the lifecycle of the network. Since then, the purchase and maintenance costs of end to end Cisco networks have outpaced Cisco innovation and other companies such as Juniper and HP offer better value on some components. Cisco is laying off 20,000, closing entire businesses such as the Flip camera (a wonderful technology company that Cisco acquired in 2009 for 500 million dollars, then shut down in 2011) and is rethinking its entire consumer product strategy. By becoming a sprawling company and attempting to maintain very high margins, Cisco lost control of its core business. Its competitors are more agile and cost effective.
The general theme is that it's very hard for CIOs to skate where the puck will be when last year's shrewd investment becomes this year's white elephant. A side effect of this accelerating market change is that customer expectations for constant innovation are higher than ever. The CIO gets credit for change, but does not receive kudos for impeccable stability, reliability and security of the existing infrastructure and application stack.
While I was in Japan I had lunch with a leading Japanese business thinker, Professor Ikujiro Nonaka. He told me "If you are doing business as usual, you are falling behind."
Put another way, no matter how good your daily operations, customers in 2011 measure your performance based on the pace of change.
Later this month, I'll take a few of my senior staff to dinner so we can reflect on this challenge. How can we deliver infrastructure and applications services at an accelerating pace of change for reasonable cost while maintaining staff morale, quality, and compliance with escalating regulatory complexity? I'll let you know what we decide.
This led me to think about the pace of change that CIOs are experiencing right now. The IT innovations of the past few years have been dizzying and the cycle between the peak of hype to the trough of obsolescence is now measured in months, not years.
Some examples of rise and fall
1. Blackberry - I was one of the earliest adopters of Blackberry technology, using a small pager-like device for short text messages. As each new model was announced, I welcomed the innovations - the evolution from thumbwheel to joystick to track pad, larger color screens, cameras, video features, and voice memo recording. However, in 2011, my mobile device needs have outpaced Blackberry's engineering. I now need a full featured web browser, a book reader, the ability to zoom/drag via touch screen, and a robust App Store. Until 2010, Blackberry seemed to be unstoppable in the corporate messaging world. Now it is laying of 2500 people as the iPhone and Android devices rapidly replace Blackberries in consumer and business settings. They tried very hard to introduce new devices such as the Storm, the Playbook, and the Torch, but came up short as customer expectations exceed their pace of innovation.
2. MySpace - Remember when personalized portals were hot? At its height, social networking company MySpace had 1500 employees. It was purchased in 2005 by Rupert Murdock for $580 million. It was recently sold for $35 million. At this point, MySpace does not appear on lists of popular social networking destinations. Given that the value of most websites is based on usage and thus potential for selling advertising, shifts in the market can occur almost instantly. Who knows, in a year or two surfing to today's popular sites such as twitter.com may yield the error "URL not found"
3. Google Health - Google is a great company and I have no doubt that it will continue to succeed. Google+ is a wonderful social networking site that is likely to steal some of Facebook's market share. However, like most technology companies, Google now has to deal with the mire of maintenance that comes with a mature set of highly used applications. More resources are spent on operations and less are available for pure innovation. Smaller, more nimble companies are likely to outpace Google and will either be acquired by Google or erode Google's leadership position. Many of my friends and colleagues who joined Google a few years ago (when it was considered unstoppable) have now left Google as the company has matured and its culture has changed. The closing of Google Health is just one symptom of the changes in focus that occur when a company is faced with the maintenance and regulatory burdens of maturing products.
4. Microsoft Windows - In 1995, I remember standing in line at midnight in a Torrance, California electronics store to buy one of the first copies of Windows 95. My early Dell computer (a 386 processor) ran DOS and Windows 3.1, so Windows 95/Office 95 was a remarkable innovation. It was stable and easy to use. Windows 98 Second Edition included built in internet features and was remarkably fast and reliable. Thereafter, Microsoft has introduced new features, but not achieved the same kind of game changing innovation that occurred 1995-2000. How many people stood in line at midnight to buy Microsoft Vista? How eagerly anticipated was Windows 7? How many people brag about their Windows Phone or Windows mobile device? The market share numbers tell the story - as of 2011, the majority of Windows computers in the world still run XP. Microsoft is a great investment - its stock price is low and its product line is very broad. It's Kinect device was the top selling consumer electronics product over the past year. However, the burden of maintaining compatibility with an operating system developed for the IBM XT era has led Microsoft to lose its edge in a cloud-based, mobile centric world.
5. Cisco - The CareGroup network outage of 2002 taught me many lessons about network architecture. In response, we installed an updated end to end Cisco infrastructure, embraced Cisco technical services, and worked closely with Cisco salespeople to plan the lifecycle of the network. Since then, the purchase and maintenance costs of end to end Cisco networks have outpaced Cisco innovation and other companies such as Juniper and HP offer better value on some components. Cisco is laying off 20,000, closing entire businesses such as the Flip camera (a wonderful technology company that Cisco acquired in 2009 for 500 million dollars, then shut down in 2011) and is rethinking its entire consumer product strategy. By becoming a sprawling company and attempting to maintain very high margins, Cisco lost control of its core business. Its competitors are more agile and cost effective.
The general theme is that it's very hard for CIOs to skate where the puck will be when last year's shrewd investment becomes this year's white elephant. A side effect of this accelerating market change is that customer expectations for constant innovation are higher than ever. The CIO gets credit for change, but does not receive kudos for impeccable stability, reliability and security of the existing infrastructure and application stack.
While I was in Japan I had lunch with a leading Japanese business thinker, Professor Ikujiro Nonaka. He told me "If you are doing business as usual, you are falling behind."
Put another way, no matter how good your daily operations, customers in 2011 measure your performance based on the pace of change.
Later this month, I'll take a few of my senior staff to dinner so we can reflect on this challenge. How can we deliver infrastructure and applications services at an accelerating pace of change for reasonable cost while maintaining staff morale, quality, and compliance with escalating regulatory complexity? I'll let you know what we decide.
Friday, 29 July 2011
Cool Technology of the Week
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!
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, 28 July 2011
The Adjustment Bureau
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.
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, 27 July 2011
An Inflection Point in Life Science Computing
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.
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, 26 July 2011
Super Cool Biz
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, 25 July 2011
FDA Mobile Medical Applications NPRM
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."
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:
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."
Subscribe to:
Posts (Atom)
