The proposed Stage 2 Meaningful Use Recommendations include numerous patient engagement features: patient communication preference, electronic self management tools, EHR interfaces to PHRs, patient reporting of care experiences online, and patient generated data incorporation into EHRs.
I've long felt that a barrier to patient engagement is the lack of common approach to transfer data between EHRs and PHRs as well as to send reminders/alerts/communications to patients.
Patients lack a Health URL or Health Email Address which would enable any EHR or HIE to route data securely among providers and patients.
There's a solution in sight, enabled by the Direct project.
Last week, Microsoft announced that it will provide a health email addresses (your_name@direct.healthvault.com) to every user of Healthvault. Also, they've provided an innovative way to sign up users who do not yet have a Healthvault account - just send an email to newuser@direct.healthvault.com with a subject line containing the patient's existing email account. The patient will be sent instructions to set up an account and receive their secure health message.
All of this uses the Direct S/MIME secure email approach for transport.
If Google, Dossia, and other PHR vendors support a similar Direct approach, then all we need to do to support the patient engagement aspects of Meaningful Use Stage 2 is capture each patient's secure health email address at registration or capture their regular email address and send an enrollment message to the PHR of their choice.
Instead of proprietary software development for every PHR, the Direct approach creates a single one time implementation for hospitals and EHR vendors.
Sean Nolan at Microsoft and have been exchanging email about the implementation details. Below, he outlines the details and the options
"1. For sending the message:
a. If you have an existing product that supports S/MIME, feel free to use it as long as it can encrypt AND sign outbound messages. (BIDMC uses a Proofpoint appliance for email security management and it may support Direct S/MIME requirements out of the box.)
b. You can also generate the S/MIME message outside of the email system and then submit it as any other message to your existing Exchange server for delivery. You could use something like the smime utility that comes with openssl, or there are commercial components such as IP*Works S/MIME. This avoids any changes to your infrastructure and concentrates the work in the code that generates the outbound message.
c. You can install an instance of the C# or Java gateways that have been created as part of the Direct project. For outbound messaging, your message generating code could send plain-vanilla SMTP to the gateway, and it could do the sign/encrypt and forward it through your existing email system.
2. For managing certificates:
Two sides to this … your certificate (for signing the message) and ours (for encrypting it).
For encryption --- we can simply give you the HealthVault organizational public certificate to use. If you go with 1C, you can install this in the gateway software. For 1A or 1B you’ll use different approaches to storing it.
For signatures --- we’ll need a copy of your organizational public certificate, and then you’ll need to sign outbound messages with the private key. Again, for 1C above you can just add your private and public keys to the gateway; for 1A and 1B you’ll manage differently.
3. Testing:
You can self-provision HealthVault test accounts and Direct addresses here, which connects to our “pre-production environment” where all of our developers build and test code. The Healthvault staging certificates can be downloaded from here."
If Direct truly creates a single mechanism for healthcare stakeholders to exchange content - summaries, reminders, homecare device data etc, then we'll finally get enough endpoints connected to demonstrate the value of HIE. With Meaningful Use Stage 2 as a motivator and HIE funding as a catalyst, let's hope the country can converge on a common transport approach.
Wednesday, February 9, 2011
Tuesday, February 8, 2011
A Multi-Layered Defense for Web Applications
The internet can be a swamp of hackers, crackers, and hucksters attacking your systems for fun, profit and fraud. Defending your data and applications against this onslaught is a cold war, requiring constant escalation of new techniques against an ever increasing offense.
Clinicians are mobile people. They work in ambulatory offices, hospitals, skilled nursing facilities, on the road, and at home. They have desktops, laptops, tablets, iPhones and iPads. Ideally their applications should run everywhere on everything. That's the reason we've embraced the web for all our built and bought applications. Protecting these web applications from the evils of the internet is a challenge.
Five years ago all of our externally facing web sites were housed within the data center and made available via network address translation (NAT) through an opening in the firewall. We performed periodic penetration testing of our sites. Two years ago, we installed a Web Application Firewall (WAF) and proxy system. We are now in the process of migrating all of our web applications from NAT/firewall accessibility to WAF/Proxy accessibility.
We have a few hundred externally facing web sites. From a security view there are only two types, those that provide access to protected health information content and those that do not. Fortunately more are in the latter than the former.
One of the major motivations for creating a multi-layered defense was the realization that many vendor products are vulnerable and even when problems are identified, vendors can be slow to correct defects. We need "zero day protection" to secure purchased applications against evolving threats.
Technologies to include in a multi-layered defense include:
1. Filter out basic network probes at the border router such as traffic on unused ports
2. Use Intrusion Prevention Systems (IPS) to block common attacks such as SQL Injection and cross site scripting. We block over 10,000 such attacks per day. You could implement multiple IPSs from different vendors to create a suite of features including URL filtering which prevent internal users from accessing known malware sites.
3. A classic firewall and Demilitarized Zone (DMZ) to limit the "attack surface".
Policies and procedures are an important aspect of maintaining a secure environment. When a request is made to host a new application, we start with a Nessus vulnerability scan.
Applications must pass the scan before we will consider hosting them. We built a simple online request form for these requests for access to both track the requests and keep the data a SQL data base. This provides the data source for an automated re-scan of each system.
Penetration testing of internally written applications is a bit more valuable because they are easier to update/correct based on the findings of penetration tests.
One caveat. The quality of penetration testing is highly variable. When we hire firms to attack our applications, we often get a report filled with theoretical risks that are not especially helpful i.e. if your web server was accidentally configured to accept HTTP connections instead of forced HTTPS connections, the application would be vulnerable. That's true and if a meteor struck our data center, we would have many challenges on our hands. When choosing a penetration testing vendor, aim for one that can put their findings in a real world context.
Thus, our mitigation strategy is to apply deep wire based security, utilize many tools including IPS, traditional firewalls, WAF and proxy servers, and perform periodic re-occurring internal scans of all systems that are available externally to our network.
Of course, all of this takes a team of trained professionals.
I hope this is helpful for your own security planning.
Clinicians are mobile people. They work in ambulatory offices, hospitals, skilled nursing facilities, on the road, and at home. They have desktops, laptops, tablets, iPhones and iPads. Ideally their applications should run everywhere on everything. That's the reason we've embraced the web for all our built and bought applications. Protecting these web applications from the evils of the internet is a challenge.
Five years ago all of our externally facing web sites were housed within the data center and made available via network address translation (NAT) through an opening in the firewall. We performed periodic penetration testing of our sites. Two years ago, we installed a Web Application Firewall (WAF) and proxy system. We are now in the process of migrating all of our web applications from NAT/firewall accessibility to WAF/Proxy accessibility.
We have a few hundred externally facing web sites. From a security view there are only two types, those that provide access to protected health information content and those that do not. Fortunately more are in the latter than the former.
One of the major motivations for creating a multi-layered defense was the realization that many vendor products are vulnerable and even when problems are identified, vendors can be slow to correct defects. We need "zero day protection" to secure purchased applications against evolving threats.
Technologies to include in a multi-layered defense include:
1. Filter out basic network probes at the border router such as traffic on unused ports
2. Use Intrusion Prevention Systems (IPS) to block common attacks such as SQL Injection and cross site scripting. We block over 10,000 such attacks per day. You could implement multiple IPSs from different vendors to create a suite of features including URL filtering which prevent internal users from accessing known malware sites.
3. A classic firewall and Demilitarized Zone (DMZ) to limit the "attack surface".
Policies and procedures are an important aspect of maintaining a secure environment. When a request is made to host a new application, we start with a Nessus vulnerability scan.
Applications must pass the scan before we will consider hosting them. We built a simple online request form for these requests for access to both track the requests and keep the data a SQL data base. This provides the data source for an automated re-scan of each system.
Penetration testing of internally written applications is a bit more valuable because they are easier to update/correct based on the findings of penetration tests.
One caveat. The quality of penetration testing is highly variable. When we hire firms to attack our applications, we often get a report filled with theoretical risks that are not especially helpful i.e. if your web server was accidentally configured to accept HTTP connections instead of forced HTTPS connections, the application would be vulnerable. That's true and if a meteor struck our data center, we would have many challenges on our hands. When choosing a penetration testing vendor, aim for one that can put their findings in a real world context.
Thus, our mitigation strategy is to apply deep wire based security, utilize many tools including IPS, traditional firewalls, WAF and proxy servers, and perform periodic re-occurring internal scans of all systems that are available externally to our network.
Of course, all of this takes a team of trained professionals.
I hope this is helpful for your own security planning.
Monday, February 7, 2011
Volatility, Uncertainty, Complexity and Ambiguity
In the era of healthcare reform when accountable care organizations, global payments, and partial capitation are the buzzwords filling Board rooms, healthcare executives are wondering what to do next.
The answer came from Dr. Gene Lindsey, President and CEO of Atrius Health during a recent retreat.
It's about accepting and managing VUCA.
V = Volatility. The nature and dynamics of change, and the nature and speed of change forces and change catalysts.
U = Uncertainty. The lack of predictability, the prospects for surprise, and the sense of awareness and understanding of issues and events.
C = Complexity. The multiplex of forces, the confounding of issues and the chaos and confusion that surround an organization.
A = Ambiguity. The haziness of reality, the potential for misreads, and the mixed meanings of conditions; cause-and-effect confusion.
The common usage of the term VUCA began in the military in the late 1990s, but it's been applied to corporate and non-profit leadership by several authors, especially Bob Johansen, former CEO of the Institute of the The Future.
I recommend two books by Johansen - Get There Early and Leaders Make the Future.
Johansen suggests that strong leaders turn volatility into vision, uncertainty into understanding, complexity into clarity, and ambiguity into agility.
He concludes that
1. VUCA will get worse in future.
2. VUCA creates both risk and opportunity.
3. Leaders must learn new skills in order to create the future.
Dr. Lindsey and I discussed these ideas and he added two of his own.
4. Leaders need to turn ambiguity into action. How many times have you heard "I do not have enough data to make a fully informed decision". Not acting makes you a target in a VUCA world.
5. Johansen notes that the most difficult VUCA competency for the future is "commons building". Dr. Lindsey related this to Don Berwick's concept of the medical commons. Berwick, when he was CEO of IHI, wrote about the need for a medical commons to accelerate the Triple Aim in healthcare. He wrote, "Rational common interests and rational individual interests are in conflict. Our failure as a nation to pursue the Triple Aim meets the criteria for what Garrett Harden called a 'tragedy of the commons.' As in all tragedies of the commons, the great task in policy is not to claim that stake- holders are acting irrationally, but rather to change what is rational for them to do. The stakes are high. Indeed, the Holy Grail of universal coverage in the United States may remain out of reach unless, through rational collective action overriding some individual self-interest, we can reduce per capita costs."
Let's explore the issue of "commons building" with a healthcare IT example. 15% of the lab and radiology tests done in Eastern Massachusetts are redundant or unnecessary. Ensuring all test results are available electronically among all providers (especially between competing organizations) will cost millions in EHR, HIE, and interface implementation. Thus, we'll have to spend money to reduce all our incomes. It's the right thing to do, but the medical IT commons will be at odds with individual incentives in a fee for service world. The right answer - change the incentives and pay individuals for care coordination, not ordering more tests.
I've thought about Dr. Lindsey's comments and realized that I've had my own VUCA challenges in the past as well many VUCA challenges in the present.
Let's turn back the clock to 2008. The Obama campaign suggested that EHRs and HIEs were the right thing to do. We had all the signs that ARRA and HITECH would be coming, but large scale EHR rollouts require significant lead time. We had to act. BIDMC decided that Software as a Service (Saas) EHRs were the right thing to do and created a Private Cloud. The concept of the Private Cloud really did not existing in 2008 and we did not know enough to predict it. We just did what we thought was right - keep all software and data on the server side rather than in the doctor's office. Today, people look at our Community EHR SaaS model and congratulate us on our foresight to build a cloud. I'll be honest - it was not planned or forecasted. We just had intuition based on the market forces and technology trajectory we saw and we guessed. I would really like to say we built a private cloud on purpose. It was a serendipitous guess. In the future, there may be cloud providers that offer business associate agreements for high reliability, cost effective, secure EHR hosting. We should think about migrating our private cloud to such services in the future.
Also, 3 years ago, BIDMC decided to focus our Clinical Systems efforts on CPOE, Medication reconciliation, HIE, Quality measurement, and advanced Ambulatory function instead of inpatient clinical documentation or nursing workflow. Meaningful Use Stage 1 was a perfect reflection of what we did. I have no influence on the Policy Committee's focus nor did we have amazing insight. It was a best guess. Stage 2 is likely to include electronic medication administration records/bedside medication verification, enhanced vital signs capture, and more clinical documentation to provide data for quality measures. We'll want to focus our future efforts there.
ICD-10 is required by 2013, new payment models based on quality and care coordination with incentives to share savings will begin in 2012, and pressure to reduce cost via guidelines/protocols/care plans will increase. Our governance committees will have to make hard choices about what not to do in the VUCA world of the next 3 years. Maybe the future is going to include more ambulatory and ICU care with ward care moved to home care. We'll have to guess again where the puck is going to be.
As a leader, my time needs to divided among Federal, State, and Local initiatives so that my governance committees, my staff, and I can make the guesses for the future. None of us know what healthcare reform will bring or what the reimbursement models will really be. However, we need to act now to be ready for the next two years. That's VUCA.
On occasion I tell my wife that someday the VUCA I face every day will get better. She reminds me that it will only get worse. If I'm doing my job properly, I will accept and manage the VUCA, so that my staff can focus on the work we need to do to stay on the cutting edge.
The answer came from Dr. Gene Lindsey, President and CEO of Atrius Health during a recent retreat.
It's about accepting and managing VUCA.
V = Volatility. The nature and dynamics of change, and the nature and speed of change forces and change catalysts.
U = Uncertainty. The lack of predictability, the prospects for surprise, and the sense of awareness and understanding of issues and events.
C = Complexity. The multiplex of forces, the confounding of issues and the chaos and confusion that surround an organization.
A = Ambiguity. The haziness of reality, the potential for misreads, and the mixed meanings of conditions; cause-and-effect confusion.
The common usage of the term VUCA began in the military in the late 1990s, but it's been applied to corporate and non-profit leadership by several authors, especially Bob Johansen, former CEO of the Institute of the The Future.
I recommend two books by Johansen - Get There Early and Leaders Make the Future.
Johansen suggests that strong leaders turn volatility into vision, uncertainty into understanding, complexity into clarity, and ambiguity into agility.
He concludes that
1. VUCA will get worse in future.
2. VUCA creates both risk and opportunity.
3. Leaders must learn new skills in order to create the future.
Dr. Lindsey and I discussed these ideas and he added two of his own.
4. Leaders need to turn ambiguity into action. How many times have you heard "I do not have enough data to make a fully informed decision". Not acting makes you a target in a VUCA world.
5. Johansen notes that the most difficult VUCA competency for the future is "commons building". Dr. Lindsey related this to Don Berwick's concept of the medical commons. Berwick, when he was CEO of IHI, wrote about the need for a medical commons to accelerate the Triple Aim in healthcare. He wrote, "Rational common interests and rational individual interests are in conflict. Our failure as a nation to pursue the Triple Aim meets the criteria for what Garrett Harden called a 'tragedy of the commons.' As in all tragedies of the commons, the great task in policy is not to claim that stake- holders are acting irrationally, but rather to change what is rational for them to do. The stakes are high. Indeed, the Holy Grail of universal coverage in the United States may remain out of reach unless, through rational collective action overriding some individual self-interest, we can reduce per capita costs."
Let's explore the issue of "commons building" with a healthcare IT example. 15% of the lab and radiology tests done in Eastern Massachusetts are redundant or unnecessary. Ensuring all test results are available electronically among all providers (especially between competing organizations) will cost millions in EHR, HIE, and interface implementation. Thus, we'll have to spend money to reduce all our incomes. It's the right thing to do, but the medical IT commons will be at odds with individual incentives in a fee for service world. The right answer - change the incentives and pay individuals for care coordination, not ordering more tests.
I've thought about Dr. Lindsey's comments and realized that I've had my own VUCA challenges in the past as well many VUCA challenges in the present.
Let's turn back the clock to 2008. The Obama campaign suggested that EHRs and HIEs were the right thing to do. We had all the signs that ARRA and HITECH would be coming, but large scale EHR rollouts require significant lead time. We had to act. BIDMC decided that Software as a Service (Saas) EHRs were the right thing to do and created a Private Cloud. The concept of the Private Cloud really did not existing in 2008 and we did not know enough to predict it. We just did what we thought was right - keep all software and data on the server side rather than in the doctor's office. Today, people look at our Community EHR SaaS model and congratulate us on our foresight to build a cloud. I'll be honest - it was not planned or forecasted. We just had intuition based on the market forces and technology trajectory we saw and we guessed. I would really like to say we built a private cloud on purpose. It was a serendipitous guess. In the future, there may be cloud providers that offer business associate agreements for high reliability, cost effective, secure EHR hosting. We should think about migrating our private cloud to such services in the future.
Also, 3 years ago, BIDMC decided to focus our Clinical Systems efforts on CPOE, Medication reconciliation, HIE, Quality measurement, and advanced Ambulatory function instead of inpatient clinical documentation or nursing workflow. Meaningful Use Stage 1 was a perfect reflection of what we did. I have no influence on the Policy Committee's focus nor did we have amazing insight. It was a best guess. Stage 2 is likely to include electronic medication administration records/bedside medication verification, enhanced vital signs capture, and more clinical documentation to provide data for quality measures. We'll want to focus our future efforts there.
ICD-10 is required by 2013, new payment models based on quality and care coordination with incentives to share savings will begin in 2012, and pressure to reduce cost via guidelines/protocols/care plans will increase. Our governance committees will have to make hard choices about what not to do in the VUCA world of the next 3 years. Maybe the future is going to include more ambulatory and ICU care with ward care moved to home care. We'll have to guess again where the puck is going to be.
As a leader, my time needs to divided among Federal, State, and Local initiatives so that my governance committees, my staff, and I can make the guesses for the future. None of us know what healthcare reform will bring or what the reimbursement models will really be. However, we need to act now to be ready for the next two years. That's VUCA.
On occasion I tell my wife that someday the VUCA I face every day will get better. She reminds me that it will only get worse. If I'm doing my job properly, I will accept and manage the VUCA, so that my staff can focus on the work we need to do to stay on the cutting edge.
Friday, February 4, 2011
Cool Technology of the Week
I'm a late adopter when it comes to camcorder technology. Over the course of my life, I've see VHS, 8mm, Hi-8, and MiniDV camcorders revolutionize the market, only to be replaced by completely solid state storage (SSD, Compact Flash, iPod, etc).Since I've only purchased 2 camcorders in my life, I've been insulated from all this change. I had an 8mm simple camcorder (a water resistant "Sport" model) from the late 1980's and a MiniDV from the early 2000's.
My daughter lives in the Facebook generation and she recently asked me about the best way to connect our MiniDV camcorder to her Macbook, iMovie and YouTube. The answer is - time to retire our tape based camcorders and purchase and under $200 a "Shoot and Share Camcorder".
A quick survey of the market suggests that Cisco's Flip UltraHD/MinoHD, Kodak's Playsport/Playtouch/Zi8, and Sony's Bloggie are the market leaders.
Each of these is pretty cool - 720p or 1080p HD video in a smartphone sized package under 5 ounces for $100-$200.
After reading the reviews, I got the sense that the Sony is the most full featured, the Kodak takes still photos, is waterproof and outdoors-friendly, and the Flip is the easiest to use.
After briefly looking at these at Best Buy, my sense was the easiest to use and support was my chief requirement, so I did further research into the Flip. A few of my colleagues in Corporate Communications/Public Affairs use Flips to create web content and seemed happy with their functionality, video quality and value.
The UltraHD 8G (avoid the 4G which lacks many features) and the MinoHD 8G have the same features and performance. The only differences are that the UltraHD is a bit larger with a removable battery and tactile buttons while the MinoHD is a bit smaller with an internal battery and capacitance (touchable) buttons.
I found the user interface of the UltraHD more intuitive and liked the idea of removable/replaceable batteries.
When you purchase a Flip Ultra, you'll likely want to purchase the power supply to charge the battery when the Flip is not connected to the computer and a micro HDMI cable (note this is not the standard Flip HDMI cable which is a mini-HDMI)
A pocket sized, easy to use, less than $200 camcorder with excellent video quality that works well with modern video editing tools and online video posting sites. That's cool!
Thursday, February 3, 2011
Shoveling Snow
I moved to New England from California 15 years ago and have been shoveling snow from December to March ever since. Managing snow, especially this winter with over 5 feet of snow fall in Wellesley, is more complex than it seems.
There are many different kinds of snow - light powder, wet/heavy gluelike snow, wintry mix of rain/sleet/ice, the "crud" left by snowplows, and the corn snow leftover from freeze/thaw cycles.
I'd like to say that New Englanders have even more words for snow than the Eskimos, but the whole notion that any language has a vast number of words for snow is an urban myth.
Here's my recommendation for the equipment you need to shovel snow in New England
1. An Ergonomic snow pusher . When snow first falls, you need a shovel to push it down the driveway. I typically cut a path to the street and then use the pusher to move snow to the sides of the driveway. Then, I can use my scoop shovel to move it into piles.
2. A Scoop Shovel . A pusher is great for moving snow but not so good for picking up chucks or larger amounts of consolidated snow to create piles (actually, it looks more like a canyon at this point in Wellesley) next to the driveway. Scoop shovels were originally invented to move grain, but they work perfectly for snow. I highly recommend Aluminum scoops because the poly shovels bend and break.
3. An Ice Chipper/scraper - Freeze/thaw cycles create a consolidated mixture of ice and snow that's as hard as concrete. An Ice Chipper is create to break up the chunks as well as scape the ice/snow that sticks to asphalt and creates a hazard. Of course you can salt your driveway to soften the ice before chipping it.
4. A Spading Fork - Although it seems like an odd tool to use for snow management, a Spading Fork helps break up the large frozen piles of snow, ice, sand, and salt that the snowplows leave in your driveway. I use a spading fork to turn the snowplow mound into smaller, manageable pieces, then the scoop shovel to move them to the piles.
5. A Sno-Broom - Using a shovel, a chipper or a fork on your car is a really bad idea. A Sno-broom enables you push ice and snow off your car without scratching the finish. An ice scraper for the windows is also a good idea.
Some of you may be thinking that a snow blower or thrower would be a better idea. But where's the fun in that!
There are many different kinds of snow - light powder, wet/heavy gluelike snow, wintry mix of rain/sleet/ice, the "crud" left by snowplows, and the corn snow leftover from freeze/thaw cycles.
I'd like to say that New Englanders have even more words for snow than the Eskimos, but the whole notion that any language has a vast number of words for snow is an urban myth.
Here's my recommendation for the equipment you need to shovel snow in New England
1. An Ergonomic snow pusher . When snow first falls, you need a shovel to push it down the driveway. I typically cut a path to the street and then use the pusher to move snow to the sides of the driveway. Then, I can use my scoop shovel to move it into piles.
2. A Scoop Shovel . A pusher is great for moving snow but not so good for picking up chucks or larger amounts of consolidated snow to create piles (actually, it looks more like a canyon at this point in Wellesley) next to the driveway. Scoop shovels were originally invented to move grain, but they work perfectly for snow. I highly recommend Aluminum scoops because the poly shovels bend and break.
3. An Ice Chipper/scraper - Freeze/thaw cycles create a consolidated mixture of ice and snow that's as hard as concrete. An Ice Chipper is create to break up the chunks as well as scape the ice/snow that sticks to asphalt and creates a hazard. Of course you can salt your driveway to soften the ice before chipping it.
4. A Spading Fork - Although it seems like an odd tool to use for snow management, a Spading Fork helps break up the large frozen piles of snow, ice, sand, and salt that the snowplows leave in your driveway. I use a spading fork to turn the snowplow mound into smaller, manageable pieces, then the scoop shovel to move them to the piles.
5. A Sno-Broom - Using a shovel, a chipper or a fork on your car is a really bad idea. A Sno-broom enables you push ice and snow off your car without scratching the finish. An ice scraper for the windows is also a good idea.
Some of you may be thinking that a snow blower or thrower would be a better idea. But where's the fun in that!
Wednesday, February 2, 2011
USB Modems
I was recently asked about the reliability of 4G USB Modems such as the LG VL600 or the Pantech UML290 as a replacement for Broadband, especially in areas that have intermittent cable connections or slow DSL.
I asked my staff about their experience with USB Modems in general and here is what they said:
"I have had very good luck with the Verizon 3G service. The coverage and performance has been good but my experience is limited to the north of the city. I have not tested the 4G service yet. I do know that all of the towers in the greater Boston area received all new equipment within the last 6 months to support the 4G and they upgraded the land line circuits to support increased demand by a minimum of 3 fold and more in some locations. It turns out it was the schedule of the land line upgrades the controlled the 4G roll out schedule."
"I use the Verizon 3G service for remote connectivity. I have had two of the USB versions of the device and moved to the MiFi version about 9 months ago. I use it daily to work on the train and other locations for at least 2 hours a day.
I find it very useable but there are areas of low/no signal. The device works via USB or wireless and lets up to 5 users/devices connect via the 3G.
I find it most useful for heavy Internet use and remote access to my work desktop. It is not very useful for video viewing unless you cache and then play them. It is fine for email, Internet searching and working on / moving office files.
4G is available in the Boston area but I will need to get another device to take advantage of this upgrade. The 4G performance should be better (at least twice as fast at this time). Pricing on 4G seems the same as 3G and the USB modems will switch to 3G if/when 4G is not available. "
There you have it - 3G and 4G USB Modems and MiFi are credible alternatives for some uses when Broadband is not available. One of our clinician sites is in a location with very poor access to any ISP. We are now investigating the possibility of using 4G as the internet connection for that office as part of implementing our software as a service electronic health record.
I asked my staff about their experience with USB Modems in general and here is what they said:
"I have had very good luck with the Verizon 3G service. The coverage and performance has been good but my experience is limited to the north of the city. I have not tested the 4G service yet. I do know that all of the towers in the greater Boston area received all new equipment within the last 6 months to support the 4G and they upgraded the land line circuits to support increased demand by a minimum of 3 fold and more in some locations. It turns out it was the schedule of the land line upgrades the controlled the 4G roll out schedule."
"I use the Verizon 3G service for remote connectivity. I have had two of the USB versions of the device and moved to the MiFi version about 9 months ago. I use it daily to work on the train and other locations for at least 2 hours a day.
I find it very useable but there are areas of low/no signal. The device works via USB or wireless and lets up to 5 users/devices connect via the 3G.
I find it most useful for heavy Internet use and remote access to my work desktop. It is not very useful for video viewing unless you cache and then play them. It is fine for email, Internet searching and working on / moving office files.
4G is available in the Boston area but I will need to get another device to take advantage of this upgrade. The 4G performance should be better (at least twice as fast at this time). Pricing on 4G seems the same as 3G and the USB modems will switch to 3G if/when 4G is not available. "
There you have it - 3G and 4G USB Modems and MiFi are credible alternatives for some uses when Broadband is not available. One of our clinician sites is in a location with very poor access to any ISP. We are now investigating the possibility of using 4G as the internet connection for that office as part of implementing our software as a service electronic health record.
Tuesday, February 1, 2011
The Safety of HIT-Assisted Care
I was recently asked by an Institute of Medicine committee to comment about the impact of healthcare information technologies (HIT) on patient safety and how to maximize the safety of HIT-assisted care.
"HIT-assisted care" means health care and services that incorporate and take advantage of health information technologies and health information exchange for the purpose of improving the processes and outcomes of health care services. HIT-assisted care includes care supported by and involving: EHRs, clinical decision support, computerized provider order entry, health information exchange, patient engagement technologies, and other health information technology used in clinical care.
There are two separate questions:
1. What technologies, properly used, improve safety?
2. Given that automation can introduce new types of errors, what can be done to ensure that HIT itself is safe?
To explore these topics, let's take a look at Health Information Exchange (HIE). What HIE technologies improve safety and how can we ensure the technologies are safe to use?
At Beth Israel Deaconess Medical Center we exchange many types of data for care coordination, patient engagement, and population health. Below is a detailed summary of the HIE transactions implemented in our recently certified hospital systems.
Most of these transactions are sent via the New England Healthcare Exchange Network (NEHEN) using AES256 and SHA-1 to encrypt and hash data, ensuring the privacy and integrity of information shared among payers, providers, patients, and government in Massachusetts.
1. Patient Summary Exchange for Transitions of Care
We produce a Continuity of Care Document for each patient handoff i.e. from inpatient, ED and outpatient (coming soon) to home, skilled nursing facilities, or other hospitals. The CCD includes
Problems
Procedures
Medications
Allergies and Adverse Reactions
Results
Encounters
Safety is improved by ensuring each provider has a complete problem list, medication list, allergy list, and recent results. Such a document is useful for medication reconciliation, drug/drug and drug/allergy decision support, and managing the entire patient by understanding all active problems.
However, summaries exchanged at a point in time are just that - a summary or abstract of the lifetime record that is accurate at a point in time. They do not provide access to the complete record such as inpatient notes, operative notes, history and physicals, and historical data such as discontinued medications or resolved problems. Many clinicians believe that a patient summary at a point in time is good enough for transitions of care, so the risk introduced by abstracting the record into just the salient handoff details may be minimal. A compromise may be a fresh look at what elements should be required for transitions of care. Last week, Massachusetts was awarded an ONC challenge grant to study this question by piloting innovative additions to the standard CCD using CDA Templates.
Here's a CCD for transitions of care, displayed in human readable form via a stylesheet.
2. Patient Summary Exchange from EHRs to PHRs
We produce a Continuity of Care Record when a patient initiates a transfer of their records from our EHR to the PHR of their choice (Google or HealthVault). The CCR includes
Demographics
Problems
Medications
Allergies
Additional Information About People and Organizations
Safety is improved by sharing data between providers and patients, making the patient the steward of their own records. This transparency encourages a dialog about treatment plans, patient care preferences, and the accuracy of data in the medical record.
However, most commercial Personal Health Records do not provide for exchange of clinician office notes such as we've piloted in BIDMC's Patientsite OpenNotes Project, nor do they include a consistent way to map EHR data to PHR displays. For example, BIDMC's EHR considers an allergy list entry to be the substance, the reaction, the observer (doctor, nurses, your mom), and the level of certainty. Google considers an allergy to be the substance and a mild/severe indictor. Thus, a transmission of an allergy "Penicillin, Hives, Doctor, Very Certain" to Google results in "Penicillin" with no other information. Use of an agreed upon list of data elements (i.e. what constitutes an allergy list) for data exchange would resolve this problem.
Here's a CCR transmitted from an EHR to a PHR, displayed in human readable form via a stylesheet.
3. Patient Summary Exchange for Discharge Instructions
We produce a Continuity of Care Document with discharge instructions for patients via a multidisciplinary web application used by doctors, nurses, social workers, and case managers. The CCD includes
Discharge Medications
Discharge Instructions
Final Diagnosis
Recommended Follow-up
Major Surgical or invasive procedures
Condition at discharge
Safety is improved by ensuring the patient understands the next steps after they are discharged from the hospital. Inpatient medications are reconciled with outpatient medications, dietary or activity restrictions are noted, and followup appointments are documented.
However, at present, Meaningful Use does not require a specific electronic format for patient discharge communications. Patient discharge instructions are generated by humans and include a distillation of the record, not a complete copy of the record. A printed report, a PDF, or a web page all suffice. Although we have used the Continuity of Care Document format, it is not optimized for structured discharge instructions. Likely CDA Templates with specific fields for the data elements most commonly used in discharge communications would be better.
Here's a CCD for patient discharge instructions, displayed in human readable form via a stylesheet.
4. Patient Summary Exchange for Quality Measurement
We produce a Continuity of Care Document with key process and outcomes measures for transmission to the Massachusetts eHealth Collaborative (MAeHC) Quality Data Warehouse. MAeHC computes all our ambulatory PQRI measures and all our pay for performance metrics. The CCD includes
Payers
Problems
Procedures
Results
Medications
Encounters
Safety is improved by providing our clinicians, administrators, and government agencies with the metrics needed to evaluate our process and outcomes quality.
However, quality measures require precise coding of concepts into SNOMED-CT and other vocabularies. It is up to the clinician to translate their observations into the correct structured data and this is challenging. Better tools to automatically map physician plain language into controlled vocabularies would help.
Here's a CCD for quality measurement, displayed in human readable form via a stylesheet.
5. Patient Data Exchange for Public Health Activities
We produce numerous submissions to government agencies to support population health and public health goals. The messages are sent to public health in batch every day based on results filed into patient records. They are exact duplicates of patient results, diagnoses, and immunization records without any loss of completeness.
Reportable lab results are sent to the Department of Public Health and Boston Public Health Commission. Here's the HL7 2.5.1 for labs.
Syndromic Surveillance is sent to the Department of Public Health and Boston Public Health Commission. Here's the HL7 2.5.1 for surveillance.
Immunizations are sent Department of Public Health and Boston Public Health Commission. Here's the HL7 2.5.1 for immunizations.
Safety is improved through monitoring of results, symptoms, and immunizations in support of public health.
However, syndromic surveillance is limited by the accuracy of the structured signs and symptoms data captured by EHRs. Ensuring that clinician observations are captured in an accurate, structured and timely way, then transmitted to public health requires more advanced vocabulary tools than exist in many EHRs.
Summarizing my observations:
1. Summary data is an abstract captured at a moment in time. Data corrections/updates are not sent. Thus, data about the patient becomes incomplete and stale over time. However, for the purpose intended, ensuring a transition of care is safe, a point in time summary may be good enough.
2. Enhanced vocabulary tools that translate clinician observations into structured data (such as Kaiser's recent contribution of its intellectual property) are useful to convey the meaning of information exchanged.
3. Implementation guides that specify required data elements are important so that receivers can accurately display the information exchanged.
4. Testing approaches already used as part of the certification process validate that data in the EHR is exported into interoperable formats accurately. NIST tools ensure that interoperable formats are compliant with standards. The challenge is getting the data into structured electronic form to begin with and deciding what to exchange for a given purpose
5. Although not specifically discussed above, patient identification can be a challenge given the lack of a national patient identifier or an agreed upon way to link the same patient's data among multiple institutions. The combination of labs, medications, and summaries from multiple sources might indicate a safety issue. Having a consistent approach to link these records would be helpful.
A number of these issues are part of the PCAST Workgroup discussion - should data be sent in context rich documents or separated into individual "atomic" data elements? How granular is an atom - is it a problem list, a single problem, or a single field within a single problem (i.e. problem onset date)? How should patient matching be done? How should searching be done? Should data be structured and vocabulary controlled or unstructured?
The IOM, ONC, and the PCAST efforts are raising all the right issues. I believe the Standards and Certification criteria for Stage 1, exemplified by all the standards samples documented above, is moving the country on the right trajectory to enhance the safety of care while ensuring HIT-assisted care is safe.
"HIT-assisted care" means health care and services that incorporate and take advantage of health information technologies and health information exchange for the purpose of improving the processes and outcomes of health care services. HIT-assisted care includes care supported by and involving: EHRs, clinical decision support, computerized provider order entry, health information exchange, patient engagement technologies, and other health information technology used in clinical care.
There are two separate questions:
1. What technologies, properly used, improve safety?
2. Given that automation can introduce new types of errors, what can be done to ensure that HIT itself is safe?
To explore these topics, let's take a look at Health Information Exchange (HIE). What HIE technologies improve safety and how can we ensure the technologies are safe to use?
At Beth Israel Deaconess Medical Center we exchange many types of data for care coordination, patient engagement, and population health. Below is a detailed summary of the HIE transactions implemented in our recently certified hospital systems.
Most of these transactions are sent via the New England Healthcare Exchange Network (NEHEN) using AES256 and SHA-1 to encrypt and hash data, ensuring the privacy and integrity of information shared among payers, providers, patients, and government in Massachusetts.
1. Patient Summary Exchange for Transitions of Care
We produce a Continuity of Care Document for each patient handoff i.e. from inpatient, ED and outpatient (coming soon) to home, skilled nursing facilities, or other hospitals. The CCD includes
Problems
Procedures
Medications
Allergies and Adverse Reactions
Results
Encounters
Safety is improved by ensuring each provider has a complete problem list, medication list, allergy list, and recent results. Such a document is useful for medication reconciliation, drug/drug and drug/allergy decision support, and managing the entire patient by understanding all active problems.
However, summaries exchanged at a point in time are just that - a summary or abstract of the lifetime record that is accurate at a point in time. They do not provide access to the complete record such as inpatient notes, operative notes, history and physicals, and historical data such as discontinued medications or resolved problems. Many clinicians believe that a patient summary at a point in time is good enough for transitions of care, so the risk introduced by abstracting the record into just the salient handoff details may be minimal. A compromise may be a fresh look at what elements should be required for transitions of care. Last week, Massachusetts was awarded an ONC challenge grant to study this question by piloting innovative additions to the standard CCD using CDA Templates.
Here's a CCD for transitions of care, displayed in human readable form via a stylesheet.
2. Patient Summary Exchange from EHRs to PHRs
We produce a Continuity of Care Record when a patient initiates a transfer of their records from our EHR to the PHR of their choice (Google or HealthVault). The CCR includes
Demographics
Problems
Medications
Allergies
Additional Information About People and Organizations
Safety is improved by sharing data between providers and patients, making the patient the steward of their own records. This transparency encourages a dialog about treatment plans, patient care preferences, and the accuracy of data in the medical record.
However, most commercial Personal Health Records do not provide for exchange of clinician office notes such as we've piloted in BIDMC's Patientsite OpenNotes Project, nor do they include a consistent way to map EHR data to PHR displays. For example, BIDMC's EHR considers an allergy list entry to be the substance, the reaction, the observer (doctor, nurses, your mom), and the level of certainty. Google considers an allergy to be the substance and a mild/severe indictor. Thus, a transmission of an allergy "Penicillin, Hives, Doctor, Very Certain" to Google results in "Penicillin" with no other information. Use of an agreed upon list of data elements (i.e. what constitutes an allergy list) for data exchange would resolve this problem.
Here's a CCR transmitted from an EHR to a PHR, displayed in human readable form via a stylesheet.
3. Patient Summary Exchange for Discharge Instructions
We produce a Continuity of Care Document with discharge instructions for patients via a multidisciplinary web application used by doctors, nurses, social workers, and case managers. The CCD includes
Discharge Medications
Discharge Instructions
Final Diagnosis
Recommended Follow-up
Major Surgical or invasive procedures
Condition at discharge
Safety is improved by ensuring the patient understands the next steps after they are discharged from the hospital. Inpatient medications are reconciled with outpatient medications, dietary or activity restrictions are noted, and followup appointments are documented.
However, at present, Meaningful Use does not require a specific electronic format for patient discharge communications. Patient discharge instructions are generated by humans and include a distillation of the record, not a complete copy of the record. A printed report, a PDF, or a web page all suffice. Although we have used the Continuity of Care Document format, it is not optimized for structured discharge instructions. Likely CDA Templates with specific fields for the data elements most commonly used in discharge communications would be better.
Here's a CCD for patient discharge instructions, displayed in human readable form via a stylesheet.
4. Patient Summary Exchange for Quality Measurement
We produce a Continuity of Care Document with key process and outcomes measures for transmission to the Massachusetts eHealth Collaborative (MAeHC) Quality Data Warehouse. MAeHC computes all our ambulatory PQRI measures and all our pay for performance metrics. The CCD includes
Payers
Problems
Procedures
Results
Medications
Encounters
Safety is improved by providing our clinicians, administrators, and government agencies with the metrics needed to evaluate our process and outcomes quality.
However, quality measures require precise coding of concepts into SNOMED-CT and other vocabularies. It is up to the clinician to translate their observations into the correct structured data and this is challenging. Better tools to automatically map physician plain language into controlled vocabularies would help.
Here's a CCD for quality measurement, displayed in human readable form via a stylesheet.
5. Patient Data Exchange for Public Health Activities
We produce numerous submissions to government agencies to support population health and public health goals. The messages are sent to public health in batch every day based on results filed into patient records. They are exact duplicates of patient results, diagnoses, and immunization records without any loss of completeness.
Reportable lab results are sent to the Department of Public Health and Boston Public Health Commission. Here's the HL7 2.5.1 for labs.
Syndromic Surveillance is sent to the Department of Public Health and Boston Public Health Commission. Here's the HL7 2.5.1 for surveillance.
Immunizations are sent Department of Public Health and Boston Public Health Commission. Here's the HL7 2.5.1 for immunizations.
Safety is improved through monitoring of results, symptoms, and immunizations in support of public health.
However, syndromic surveillance is limited by the accuracy of the structured signs and symptoms data captured by EHRs. Ensuring that clinician observations are captured in an accurate, structured and timely way, then transmitted to public health requires more advanced vocabulary tools than exist in many EHRs.
Summarizing my observations:
1. Summary data is an abstract captured at a moment in time. Data corrections/updates are not sent. Thus, data about the patient becomes incomplete and stale over time. However, for the purpose intended, ensuring a transition of care is safe, a point in time summary may be good enough.
2. Enhanced vocabulary tools that translate clinician observations into structured data (such as Kaiser's recent contribution of its intellectual property) are useful to convey the meaning of information exchanged.
3. Implementation guides that specify required data elements are important so that receivers can accurately display the information exchanged.
4. Testing approaches already used as part of the certification process validate that data in the EHR is exported into interoperable formats accurately. NIST tools ensure that interoperable formats are compliant with standards. The challenge is getting the data into structured electronic form to begin with and deciding what to exchange for a given purpose
5. Although not specifically discussed above, patient identification can be a challenge given the lack of a national patient identifier or an agreed upon way to link the same patient's data among multiple institutions. The combination of labs, medications, and summaries from multiple sources might indicate a safety issue. Having a consistent approach to link these records would be helpful.
A number of these issues are part of the PCAST Workgroup discussion - should data be sent in context rich documents or separated into individual "atomic" data elements? How granular is an atom - is it a problem list, a single problem, or a single field within a single problem (i.e. problem onset date)? How should patient matching be done? How should searching be done? Should data be structured and vocabulary controlled or unstructured?
The IOM, ONC, and the PCAST efforts are raising all the right issues. I believe the Standards and Certification criteria for Stage 1, exemplified by all the standards samples documented above, is moving the country on the right trajectory to enhance the safety of care while ensuring HIT-assisted care is safe.
Subscribe to:
Posts (Atom)