When I became CIO of CareGroup/BIDMC in 1998, I promised to listen to all my staff and collaboratively embrace technologies that would benefit patients while also enabling employee career growth. The IT team worked together to implement new infrastructure and new applications. Success led to an upward spiral of success. Other groups such as Media Services, Knowledge Services, and Health Information Management joined IS. We continued to grow in scope and capability.
My sense at the time was that additional authority, budget and span of control were great - more was better.
However, in my nearly 15 years as CIO, I've learned that while more authority may bring more opportunities to succeed, it also brings increased responsibility and with it, additional risk.
In a world of increasing regulatory pressures and compliance requirements, the likelihood of something bad happening every day in a large organization is high. The larger your role, the larger your risk.
Today in my BIDMC role I oversee
83 locations
18000 user accounts
9000 desktops/laptops/tablets
3000 printers
600 iPads
1600 iPhones
450 servers (200 physical, 250 virtual)
1.5 petabytes of storage
serving over a million patients.
If one employee copies data to a USB drive and loses it, a potential breach needs to be reported. If one workstation is infected with malware that could have transmitted clinical data to a third party, a potential breach needs to be reported. If one business associate loses an unencrypted laptop, a breach needs to be reported. 30,750 such breaches have been reported since HITECH took effect All breaches are the CIO's responsibility.
If one IT project is over time or over budget, it's the CIO's responsibility.
If one IT employee goes rogue, it's the CIO's responsibility.
If one server, network, or storage array fails, it's the CIO's responsibility
If one application causes patient harm, it's the CIO's responsibility
Life as a CIO can have its challenges!
At the same time that responsibilities are expanding, the number of auditors, regulators, lawyers, compliance specialists, and complex regulations is growing at a much faster rate than IT resources.
There are three solutions
1. Spend increasing amounts of time on risk identification and mitigation
2. Reduce your responsibility/accountability and thus your risk footprint
3. Find a nice cabin in the woods and homestead as far away from regulatory burdens as possible
I'm doing #1 - about 20% of my day is spent on matters of risk, compliance, and regulation. I'm doing #2 by transitioning my CIO role at Harvard Medical School to a successor. #3 sounds appealing but I'm not there yet!
As healthcare CIOs face new regulations for e-prescribing of controlled substances, FDA device safety requirements, 5010 implementation, ICD-10, new privacy rules, and Meaningful Use stages 1-2-3, the magnitude of the challenges ahead may at times seem overwhelming. I sometimes long for the days when all I had to do was write innovative software and create a nurturing environment for my staff!
There are 3 negative consequences that can result from overzealous regulation:
1. The joy of success can turn into a fear of compliance failure
2. Compliance can create such overhead that we lose our competitiveness
3. We'll become less entrepreneurial because the consequences of non-compliance, such as loss of reputation, penalties, and burden of responding to agencies enforcing regulations, become a deterrent to innovation.
For now, I have accepted the risks that come with all my responsibilities, but at some point, the balance may become more challenging to maintain. As we move forward, I hope that policymakers in Washington and at the state level will be mindful of the unintended consequences of regulatory complexity.
BIDMC's Accountable Care Organization IT Strategy
No one really knows what an Accountable Care Organization is, but many provider organizations want to be one.
As a CIO, I've been asked to create the financial and clinical analytics needed to support high value care (low cost, high quality), population health, and care coordination across the community.
I believe that Accountable Care Organizations will be based on healthcare information exchange and analytics. BIDMC's approach is accelerate our health information exchange work and continue our existing work on financial and clinical data warehouses.
Here's how it will work.
There are over 1800 clinicians in the Beth Israel Deaconess Physicians Organization (BIDPO). Some are owned, some are private. The BIDPO Board of Directors mandated that a certified Electronic Health Record be in use at every BIDPO practice by December 2010 as a condition of participation in payer contracting efforts. Those payer contracts require "clinical integration" - all clinicians must be knit together by IT. To accomplish this goal, we implemented a cloud-based EHR which was offered to each practice that did not yet have a certified EHR. We required all clinicians, owned and private, to send a standardized, structured summary of each visit to a central quality registry.
As each encounter is completed and signed, eClinicalWorks, Altos Solutions, and webOMR, send a very specific Clinical Document Architecture (CDA) summary containing all the data necessary to compute quality and performance metrics to a statewide Quality Data Center, hosted at the Massachusetts Medical Society and operated by the Massachusetts eHealth Collaborative.
That warehouse is used to generate PQRI measures, the 44 meaningful use measures, and ad hoc reporting via web-based business intelligence tools.
For the financial data warehouse, all private payers claims from BIDPO patients are forwarded to a single financial data warehouse where Extract/Transform/Load tools are used to normalize the data into a single schema.
Data mining and reporting is done by Healthcare Data Services.
The interesting recent development is that all the clinical data transfers from heterogeneous EHRs pass through the New England Healthcare Exchange Network (NEHEN) gateway, such that the Quality Data Center is just a node on the HIE. Anyone can send any data from any EHR using the standards mandated by Meaningful Use.
NEHEN also transmits summaries to the next provider of care, ensuring clinical integration. We have live connections among Atrius, Childrens, BIDMC, and Northeast. In a few weeks, Partners Healthcare will go live with the ability to receive transactions.
As of last week, we have exchanged over 16,000 production clinical messages for care coordination and quality measurement.
All the Public Health transactions will soon be live on the NEHEN infrastructure.
Healthcare reform is causing hospitals, practices, payers, and government to align their healthcare IT efforts in support of the data sharing and analytics needed by new reimbursement models.
It's happening very fast in Boston/Eastern Massachusetts.
I'll continue to share all my lessons learned as BIDMC implements an entire suite of IT solutions on the road to Accountable Care nirvana.
As a CIO, I've been asked to create the financial and clinical analytics needed to support high value care (low cost, high quality), population health, and care coordination across the community.
I believe that Accountable Care Organizations will be based on healthcare information exchange and analytics. BIDMC's approach is accelerate our health information exchange work and continue our existing work on financial and clinical data warehouses.
Here's how it will work.
There are over 1800 clinicians in the Beth Israel Deaconess Physicians Organization (BIDPO). Some are owned, some are private. The BIDPO Board of Directors mandated that a certified Electronic Health Record be in use at every BIDPO practice by December 2010 as a condition of participation in payer contracting efforts. Those payer contracts require "clinical integration" - all clinicians must be knit together by IT. To accomplish this goal, we implemented a cloud-based EHR which was offered to each practice that did not yet have a certified EHR. We required all clinicians, owned and private, to send a standardized, structured summary of each visit to a central quality registry.
As each encounter is completed and signed, eClinicalWorks, Altos Solutions, and webOMR, send a very specific Clinical Document Architecture (CDA) summary containing all the data necessary to compute quality and performance metrics to a statewide Quality Data Center, hosted at the Massachusetts Medical Society and operated by the Massachusetts eHealth Collaborative.
That warehouse is used to generate PQRI measures, the 44 meaningful use measures, and ad hoc reporting via web-based business intelligence tools.
For the financial data warehouse, all private payers claims from BIDPO patients are forwarded to a single financial data warehouse where Extract/Transform/Load tools are used to normalize the data into a single schema.
Data mining and reporting is done by Healthcare Data Services.
The interesting recent development is that all the clinical data transfers from heterogeneous EHRs pass through the New England Healthcare Exchange Network (NEHEN) gateway, such that the Quality Data Center is just a node on the HIE. Anyone can send any data from any EHR using the standards mandated by Meaningful Use.
NEHEN also transmits summaries to the next provider of care, ensuring clinical integration. We have live connections among Atrius, Childrens, BIDMC, and Northeast. In a few weeks, Partners Healthcare will go live with the ability to receive transactions.
As of last week, we have exchanged over 16,000 production clinical messages for care coordination and quality measurement.
All the Public Health transactions will soon be live on the NEHEN infrastructure.
Healthcare reform is causing hospitals, practices, payers, and government to align their healthcare IT efforts in support of the data sharing and analytics needed by new reimbursement models.
It's happening very fast in Boston/Eastern Massachusetts.
I'll continue to share all my lessons learned as BIDMC implements an entire suite of IT solutions on the road to Accountable Care nirvana.
The NwHIN Power Team
At the September meeting of the HIT Standards Committee, we'll finalize the content, vocabulary and transport standards for Stage 2 of Meaningful Use.
I've written many posts and articles about the importance of specific implementation guides for transport standards. When every provider is connected to every provider, payer and patient, novel transactions will emerge and volume will increase per Metcalfe's law.
The NwHIN Power Team, a subcommittee of the HIT Standards Committee, has been working all Summer to analyze the NwHIN Exchange (SOAP) and Direct (SMTP/SMIME) specifications specifications using a truly brilliant methodology. Each specification (10 Exchange, 2 Direct) was scored against the following criteria:
Need for specified capability
Maturity of the specification
Maturity of the underlying technology used in the specification
Deployment and Operational Complexity
Industry adoption
Available alternatives
Initial scores were assigned by the ONC, with inputs from the NeHIN Exchange Coordinating Committee and the National Institute for Standards and Technology (NIST). The Power Team reviewed and refined these scores through several iterations, most recently after hearing testimony from individuals with first-hand experience implementing the Exchange specifications for the DOD and VA. From these scores, they identified specifications for which the business need is low. They also identified those specifications that are in early or moderate stages of development, and that use technologies which are in the declining phase of their life-cycle. Finally, they evaluated the specifications on deployment/operational complexity and industry adoption.
They considered alternatives using the same criteria as those used for NwHIN and Direct specifications.
Their detailed analysis will be presented on September 28, but there are two interesting conclusions in the draft report that I'd like to share now.
Industry adoption of the NwHIN and Direct specifications for health information exchange between organizations is low. Pilots have been successful, but large scale adoption has not yet occurred. So the scalability and workflow compatibility of these specifications have yet to be proven.
RESTful interfaces such as those used by Google, Facebook, and Amazon are appealing. However, REST is not a standard, but a style that uses the HTTP to provide a simpler alternative to SOAP for accessing web services. Not all RESTful implementations are implemented in the same way and thus we need a specification for secure RESTful transport of healthcare information. Such an implementation guide would ensure that RESTful implementations for healthcare information exchange are predictable and secured.
The Power Team has one more meeting to finalize its recommendation, but I am confident that they will present a thoughtful path forward that embraces the existing NwHIN and Direct specifications for some use cases and suggests further development for other use cases if we want large scale adoption and ease of implementation.
I'm truly impressed by the work of this team and look forward to their final recommendations.
I've written many posts and articles about the importance of specific implementation guides for transport standards. When every provider is connected to every provider, payer and patient, novel transactions will emerge and volume will increase per Metcalfe's law.
The NwHIN Power Team, a subcommittee of the HIT Standards Committee, has been working all Summer to analyze the NwHIN Exchange (SOAP) and Direct (SMTP/SMIME) specifications specifications using a truly brilliant methodology. Each specification (10 Exchange, 2 Direct) was scored against the following criteria:
Need for specified capability
Maturity of the specification
Maturity of the underlying technology used in the specification
Deployment and Operational Complexity
Industry adoption
Available alternatives
Initial scores were assigned by the ONC, with inputs from the NeHIN Exchange Coordinating Committee and the National Institute for Standards and Technology (NIST). The Power Team reviewed and refined these scores through several iterations, most recently after hearing testimony from individuals with first-hand experience implementing the Exchange specifications for the DOD and VA. From these scores, they identified specifications for which the business need is low. They also identified those specifications that are in early or moderate stages of development, and that use technologies which are in the declining phase of their life-cycle. Finally, they evaluated the specifications on deployment/operational complexity and industry adoption.
They considered alternatives using the same criteria as those used for NwHIN and Direct specifications.
Their detailed analysis will be presented on September 28, but there are two interesting conclusions in the draft report that I'd like to share now.
Industry adoption of the NwHIN and Direct specifications for health information exchange between organizations is low. Pilots have been successful, but large scale adoption has not yet occurred. So the scalability and workflow compatibility of these specifications have yet to be proven.
RESTful interfaces such as those used by Google, Facebook, and Amazon are appealing. However, REST is not a standard, but a style that uses the HTTP to provide a simpler alternative to SOAP for accessing web services. Not all RESTful implementations are implemented in the same way and thus we need a specification for secure RESTful transport of healthcare information. Such an implementation guide would ensure that RESTful implementations for healthcare information exchange are predictable and secured.
The Power Team has one more meeting to finalize its recommendation, but I am confident that they will present a thoughtful path forward that embraces the existing NwHIN and Direct specifications for some use cases and suggests further development for other use cases if we want large scale adoption and ease of implementation.
I'm truly impressed by the work of this team and look forward to their final recommendations.
The Impact of 9/11 on Healthcare IT
On September 11, 2001, I was sitting in my Harvard Clinical Research Institute office (I was CIO there from 2001-2007 as part of my Harvard Medical School CIO duties). A staff member ran into my office and told me that a plane had crashed into a World Trade Center Tower. This sounded like a horrible accident. Then, the second tower was hit and we knew this disaster was planned. News of the Pentagon and Pennsylvania crashes trickled in. I gathered all the staff and told them to focus on their families and personal safety, to go home and stay in touch virtually as we learned more about the day's events.
What impact has 9/11 had on my healthcare IT world since then?
9/11 had a profound impact on our culture, making us all understand our vulnerability.
The loss of life gave us an appreciation of the preciousness of each day we have on the planet, putting the problems of our work lives in perspective.
The loss of infrastructure, including many data centers, was a wake up call that redundancy goes beyond servers, networks, and storage. Whole buildings can disappear in an instant through natural or manmade disaster.
Since 9/11, Beth Israel Deaconess has invested over $10 million dollars to create a redundant IT infrastructure that includes geographically disparate data centers, remote hosting of our financial applications, and data replication of a petabyte with less than a minute of loss in the case of a major disaster.
We support remote, web-based access of all our applications and data so that our mission can continue even if travel into Boston is restricted.
Our healthcare information exchange efforts have created a foundational backbone for care coordination in the event of a disaster.
The events of 9/11 are felt throughout the country, but especially in Boston, the takeoff point for the planes that were flown into the World Trade Center towers. At my daughter's recent Tufts University matriculation ceremony, the Dean reflected that 3 members of her freshman class lost parents on 9/11.
Our homage to the events of 9/11 is a resilient IT infrastructure that can support our patients, regardless of the disasters that may strike. Disaster recovery, security, and emergency support efforts will continue, inspired by the memories of those who perished 10 years ago.
What impact has 9/11 had on my healthcare IT world since then?
9/11 had a profound impact on our culture, making us all understand our vulnerability.
The loss of life gave us an appreciation of the preciousness of each day we have on the planet, putting the problems of our work lives in perspective.
The loss of infrastructure, including many data centers, was a wake up call that redundancy goes beyond servers, networks, and storage. Whole buildings can disappear in an instant through natural or manmade disaster.
Since 9/11, Beth Israel Deaconess has invested over $10 million dollars to create a redundant IT infrastructure that includes geographically disparate data centers, remote hosting of our financial applications, and data replication of a petabyte with less than a minute of loss in the case of a major disaster.
We support remote, web-based access of all our applications and data so that our mission can continue even if travel into Boston is restricted.
Our healthcare information exchange efforts have created a foundational backbone for care coordination in the event of a disaster.
The events of 9/11 are felt throughout the country, but especially in Boston, the takeoff point for the planes that were flown into the World Trade Center towers. At my daughter's recent Tufts University matriculation ceremony, the Dean reflected that 3 members of her freshman class lost parents on 9/11.
Our homage to the events of 9/11 is a resilient IT infrastructure that can support our patients, regardless of the disasters that may strike. Disaster recovery, security, and emergency support efforts will continue, inspired by the memories of those who perished 10 years ago.
Cool Technology of the Week
Two years ago, my daughter was walking in a Rhode Island park with a friend. They stopped at a bench to chat and she put her purse containing an iPhone 3GS on the ground. Across the street, two men watched them from the porch. My daughter and her friend continued their walk but she left her purse behind. When she returned 15 minutes later, the iPhone was gone.
She was convinced that the men watching her pilfered it, but she had no way to prove it.
If only my daughter would have lost an iPhone5, then recovery would have been easy :-)
Earlier this year, I wrote about laptop recovery via nanny cam.
I've written about BIDMC's use of our wireless network to locate 5000 devices throughout the hospital.
Now there is an entire suite of tools for mobile devices including remote camera activation, automated file replication to the cloud, and GPS reporting that help locate lost or stolen devices.
The use of mobile devices in healthcare is growing exponentially at the same time that compliance requirements to protect these devices are becoming more stringent. It's clear that new mobile devices are going to include the geolocation tools necessary to reduce anxiety in CIOs and users.
Self recovery of your mobile device - that's cool!
She was convinced that the men watching her pilfered it, but she had no way to prove it.
If only my daughter would have lost an iPhone5, then recovery would have been easy :-)
Earlier this year, I wrote about laptop recovery via nanny cam.
I've written about BIDMC's use of our wireless network to locate 5000 devices throughout the hospital.
Now there is an entire suite of tools for mobile devices including remote camera activation, automated file replication to the cloud, and GPS reporting that help locate lost or stolen devices.
The use of mobile devices in healthcare is growing exponentially at the same time that compliance requirements to protect these devices are becoming more stringent. It's clear that new mobile devices are going to include the geolocation tools necessary to reduce anxiety in CIOs and users.
Self recovery of your mobile device - that's cool!
Subscribe to:
Posts (Atom)