I'm back from Alaska and I'll post several blogs about my Healthcare IT and personal experiences in the 49th state. Sorry for the gap in blog posting last week. Per the photo to the right, I was "Into the Wild" with my wife and daughter, celebrating my daughter's graduation from high school, off grid.
Alaska faces many healthcare challenges given its large area (663,268 sq mi) and population of 710,231 residents (as per the 2010 US Census), approximately half of which live in the Anchorage metropolitan area, making Alaska the least densely populated state. Roads are limited, making boat and small plane the only means of transportation to many locations, especially in the western portion of the state.
The geographical challenge of delivering such widely distributed healthcare makes it a natural location for telemedicine, much of which is ably overseen by Stewart Ferguson CIO, Alaska Native Tribal Health Consortium.
The business case is simple - provider travel to remote villages and patient commuting to downtown clinics is expensive for providers and patients.
Because telemedicine has become part of the culture of Alaskan care delivery, healthcare information exchange is likely to be very successful. When a patient is referred to a specialist, lifetime medical summaries should be sent before the consultation. When the telemedicine encounter is done, a summary of the evaluation should be sent back to the primary care giver or health aide in the village.
Alaska has what I consider the perfect alignment of incentives needed for a successful HIE
a. Complete support of all payers and providers that HIE (coupled with Telemedicine) saves money by reducing travel
b. A universal expectation by providers and patients that HIE will occur following each encounter
c. A population of patients who understands the need for HIE and supports a simple consent model (opt-out)
d. Government support for HIE with strong public-private governance and delegation of HIE operations to a multi-stakeholder non-profit, the Alaska eHealth Network (AeHN) a 501c3 Alaska corporation organized and managed by Alaskans.
e. The stakeholders chose a single vendor, Orion, to provide the backbone which will connect all their EHRs.
A network of networks approach makes great sense for a state with regional centers of excellence and highly distributed broadband like Massachusetts. Alaska has some broadband but relies on satellite and microwave connections, which are limited in bandwidth and very expensive. Alaska does not distribute IT staff and infrastructure support to distant villages. Thus, for Alaska, a single network and a centralized clinical data repository supporting:
Composite Record Viewing
Master Patient Index / Record Locator Service
Audit Trails/Security
Patient Portal
Public Health Reporting
makes great sense.
The folks in Alaska working on HIE, led by Wiiliam Sorrells, are highly motivated, have done a great job with education/communication, and share a common vision.
I predict that Alaska will become one of the most successful HIEs because of its clear business case, alignment of incentives, and broad stakeholder engagement.
I look forward to working with my colleagues in Alaska as we all develop the Nationwide Health Information Network, connecting all the successful state HIEs together.
An Update on Google Health
Google is retiring Google Health per the announcement below.
A few thoughts
*Google Health has the best user interface, feature set, and ease of use of all the stand alone personal health records
*Google Health is truly innovative and broke new ground when it created interfaces to hospitals, labs, and pharmacies in 2008. I was there at the beginning and can definitively state that it was Google's reputation and vision that broke down the political barriers keeping data from patients.
*Google will be using the Direct standards to enable patients to transmit their Google Health data to Microsoft Healthvault and other PHRs
Thank you to Google and the Google Health team. You really moved the industry.
-----------
Dear Google Health Partner,
As we just announced in the Official Google Blog, we will be discontinuing the Google Health service and platform over the next several months. For more context around this announcement, please check out our blog post.
Going forward, we recommend that you notify your team and discontinue any current development around your Google Health integration. Also, you’ll need to remove the integration functionality as well as Google Health related text and logos from your website as of January 1, 2012. Please consider this as our notice to terminate our agreement with you on the Google Health API Terms and Conditions, found at https://services.google.com/fb/forms/googhealthdevelopers.
We truly appreciate your partnership and support of the Google Health service.
Best regards,
The Google Health Team
A few thoughts
*Google Health has the best user interface, feature set, and ease of use of all the stand alone personal health records
*Google Health is truly innovative and broke new ground when it created interfaces to hospitals, labs, and pharmacies in 2008. I was there at the beginning and can definitively state that it was Google's reputation and vision that broke down the political barriers keeping data from patients.
*Google will be using the Direct standards to enable patients to transmit their Google Health data to Microsoft Healthvault and other PHRs
Thank you to Google and the Google Health team. You really moved the industry.
-----------
Dear Google Health Partner,
As we just announced in the Official Google Blog, we will be discontinuing the Google Health service and platform over the next several months. For more context around this announcement, please check out our blog post.
Going forward, we recommend that you notify your team and discontinue any current development around your Google Health integration. Also, you’ll need to remove the integration functionality as well as Google Health related text and logos from your website as of January 1, 2012. Please consider this as our notice to terminate our agreement with you on the Google Health API Terms and Conditions, found at https://services.google.com/fb/forms/googhealthdevelopers.
We truly appreciate your partnership and support of the Google Health service.
Best regards,
The Google Health Team
CMS Clarifies Electronic Transmission
One of the more confusing items about Meaningful Stage 1 is what constitutes a test of electronic record exchange. The HIT Standards Committee did not specify transport standards, so there are no certification criteria to test the ability of an EHR to send data from place to place.
It was unclear what kinds of transport constitute a valid test of data exchange - Bluetooth between iPhones? e-Fax? USB Drives?
Now we know from a new CMS FAQ - any transport standard will do, but physical media will not.
Here's the language:
"To complete step 2, an eligible professional, eligible hospital, or critical access hospital may use any means of electronic transmission according to any transport standard(s) (SMTP, FTP, REST, SOAP, etc.) regardless of whether it was included by an EHR technology developer as part of the certified EHR technology in the eligible professional’s, eligible hospital’s, or critical access hospital’s possession.
Please note that the use of USB, CD-ROM, or other physical media or electronic fax would not meet the measure of this objective and has been addressed in another FAQ (see FAQ #10638) If the test involves the transmission of actual patient information, all current privacy and security regulations must be met."
Now that we know, feel free to send me a secure email (Zixmail, Accellion, Direct, S/MIME, or TLS) and I can validate your test!
It was unclear what kinds of transport constitute a valid test of data exchange - Bluetooth between iPhones? e-Fax? USB Drives?
Now we know from a new CMS FAQ - any transport standard will do, but physical media will not.
Here's the language:
"To complete step 2, an eligible professional, eligible hospital, or critical access hospital may use any means of electronic transmission according to any transport standard(s) (SMTP, FTP, REST, SOAP, etc.) regardless of whether it was included by an EHR technology developer as part of the certified EHR technology in the eligible professional’s, eligible hospital’s, or critical access hospital’s possession.
Please note that the use of USB, CD-ROM, or other physical media or electronic fax would not meet the measure of this objective and has been addressed in another FAQ (see FAQ #10638) If the test involves the transmission of actual patient information, all current privacy and security regulations must be met."
Now that we know, feel free to send me a secure email (Zixmail, Accellion, Direct, S/MIME, or TLS) and I can validate your test!
Hiking Denali
Given the responsibilities I have at BIDMC and HMS, I try to limit my travel. I rarely take vacation time.
This summer is the last time my daughter will be living at home, so we're trying to balance work, family life, and opportunity.
The HIMSS Chapters of Alaska and Hawaii asked that I spend a day with them at the location of my choice - Honolulu or Anchorage. I let my daughter decide. She decided that experiencing the midnight sun, hiking Denali, and reveling in meadows of wildflowers would serve as an extraordinary graduation present.
Next week will be a balance of family time and work time. I'll stay in touch will all my staff at HMS and BIDMC, lecture to the IT professionals of Alaska in person with a video conferencing connection to Hawaii, and explore Alaska with my family.
Here's our itinerary:
Sunday - We'll fly to Anchorage via Chicago enjoying the benefits of a 4 hour time change to arrive in Anchorage at 1pm. We'll be at a latitude of 61 degrees north during the first week of Summer, so sunrise will be at 4:22 AM and sunset will be at 11:42 PM, giving us 20 hour days. After we land, we'll drive to Girdwood, a former gold mining town 40 miles south of Anchorage. It's close proximity to three national parks makes it a great base camp for a few days. We'll hike and explore the area around Mt. Alyeska.
Monday - We'll drive further south to Seward and explore the Exit Glacier. My daughter loves Alaskan Huskies and we'll be visiting a breeder and learning more about the Iditarod sled race
Tuesday - We'll return to Anchorage and I'll be meeting with IT professionals for a lecture and a few hours of informal conversation with the HIMSS Hawaii-Alaska Annual Meeting. The folks from Hawaii will join by video conference.
Wednesday - I'll hike the Chugach Mountains with Steward Ferguson, CIO of the Alaska Native Tribal Health Consortium
Thursday - my family and I will drive north to Talkeetna, the gateway to Denali National Park. We'll spend the day driving the byways, exploring wildflowers, wildlife and the terrain.
Friday - we'll explore Denali national park to the limits of the roads that only touch the limits of the wilderness.
Saturday - we'll go deep into Denali via the shuttles that are the only way to access the remote trailheads
Sunday - we'll make our way back to Anchorage and fly back to Boston.
I'll be on blog holiday next week while I'm traveling. I'll summarize the entire experience as soon as a I return.
Into the Wild!
This summer is the last time my daughter will be living at home, so we're trying to balance work, family life, and opportunity.
The HIMSS Chapters of Alaska and Hawaii asked that I spend a day with them at the location of my choice - Honolulu or Anchorage. I let my daughter decide. She decided that experiencing the midnight sun, hiking Denali, and reveling in meadows of wildflowers would serve as an extraordinary graduation present.
Next week will be a balance of family time and work time. I'll stay in touch will all my staff at HMS and BIDMC, lecture to the IT professionals of Alaska in person with a video conferencing connection to Hawaii, and explore Alaska with my family.
Here's our itinerary:
Sunday - We'll fly to Anchorage via Chicago enjoying the benefits of a 4 hour time change to arrive in Anchorage at 1pm. We'll be at a latitude of 61 degrees north during the first week of Summer, so sunrise will be at 4:22 AM and sunset will be at 11:42 PM, giving us 20 hour days. After we land, we'll drive to Girdwood, a former gold mining town 40 miles south of Anchorage. It's close proximity to three national parks makes it a great base camp for a few days. We'll hike and explore the area around Mt. Alyeska.
Monday - We'll drive further south to Seward and explore the Exit Glacier. My daughter loves Alaskan Huskies and we'll be visiting a breeder and learning more about the Iditarod sled race
Tuesday - We'll return to Anchorage and I'll be meeting with IT professionals for a lecture and a few hours of informal conversation with the HIMSS Hawaii-Alaska Annual Meeting. The folks from Hawaii will join by video conference.
Wednesday - I'll hike the Chugach Mountains with Steward Ferguson, CIO of the Alaska Native Tribal Health Consortium
Thursday - my family and I will drive north to Talkeetna, the gateway to Denali National Park. We'll spend the day driving the byways, exploring wildflowers, wildlife and the terrain.
Friday - we'll explore Denali national park to the limits of the roads that only touch the limits of the wilderness.
Saturday - we'll go deep into Denali via the shuttles that are the only way to access the remote trailheads
Sunday - we'll make our way back to Anchorage and fly back to Boston.
I'll be on blog holiday next week while I'm traveling. I'll summarize the entire experience as soon as a I return.
Into the Wild!
The June HIT Standards Committee Meeting
The June HIT Standards Committee meeting followed the "Summer Camp" schedule precisely, and focused on health information exchange metadata (patient identifiers/provenance/privacy flags), provider directories, patient matching, meaningful use stage 2 standards, quality measures, and feedback how to ease the burden of certification.
Farzad Mostashari, National Coordinator, began the meeting by highlighting the importance of taking first steps on early health information exchange use cases. The notion of creating a standard envelope around data that identifies the patient and the sender of the data enables many transactions. Supporting privacy flags enables the recipient of the data to obtain necessary consents before viewing data and to store the data optimally to respect patient privacy preferences (such as special locked areas for mental health, substance abuse or HIV related data). Privacy flags may not be needed if the patient is the source of the data or the patient gives consent to disclose and consent to view directly to the provider at the point of care.
Stan Huff led the metadata discussion and reviewed the work that has been done to date on patient ID and provenance standards. For patient ID, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header. This XML has nothing healthcare specific such as OIDs in it. For provenance, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header and X.509 certificates for digital signature. The signature could be an institution, a department, or an individual, as needed by the use case. For Privacy we considered many options and recommended a CDA R2 Header with a simple vocabulary to indicate that sensitive data is present. The list of sensitive data types could include mental illness, substance abuse, sexually transmitted disease data, HIV data, domestic violence data etc. or it could be a simple indicator that sensitive data is present. Specifying such a vocabulary is future work.
A robust discussion followed about privacy flags. Here are important clarifications
1. During transmission, the envelope of metadata plus the payload of content is fully encrypted and so the metadata is not readable until it arrives inside the organization or to the person authorized to read it.
2. Much of the time, no privacy flags are needed because the patient will be the source of the data and will elect what to disclose to whom. Privacy flags would likely be needed when data is assembled from multiple sources and is received by a provider who needs to obtain special consent before viewing it or apply special protections before storing it.
3. A privacy flag would enable data to be automatically routed to specially protected areas of the EHR.
4. The CDA R2 header standards are used millions of times per day throughout the world but this subset of them and constrained specifications of how/when they are used should be tested before regulations require them for specific transactions.
5. The recommendation to use CDA R2 headers for metadata is the beginning of a formal ONC process to seek comment, feedback and stakeholder engagement regarding their use.
Based on all these clarifications, the HIT STandards Committee approved the use CDA R2 header for metadata as a formal recommendation to ONC as it begins the NPRM process.
Next, Dixie Baker and Walter Suarez presented Provider Directory recommendations. At last month's meeting, they suggested the use of LDAP/IHE HPD standards and received feedback that these standards were not the best fit for cross organizational/federated directory lookup. They reconsidered the possibilities and examined DNS as a means to find IP addresses and certificates, the concept of a Top-Level-Domain as a means to create a uniform, secure way to retrieve directory information about healthcare organizations (of note, ICAAN announced that such Top Level Domains will soon be very easy to create), and the use of microformats/microdata as a means of creating simple federated lookups for provider directory information that cannot be stored in DNS, such as street address and phone number. Web pages containing such data can be secured with Extended Validation certificates to provide identity verification of the entity publishing the information i.e. it really is Beth Israel Deaconess publishing the directory information about Beth Israel Deaconess. Summarizing their recommendations for provider directories:
1. DNS should be used for certificate retrieval per the Direct Specification plus web pages with microformats/microdata should be used for additional directory information. These web pages can be federated via standard search engine technology.
2. A Top level domain can be considered in the future, but there is no need to implement one now.
The HIT Standards Committee approved this recommendation as input to the S&I framework process.
Next, Doug Fridsma let a discussion of progress on "Summer Camp".
Marc Overhage presented the work on patient matching, noting that the work of the group is to specify those data elements that can be used to match patients, achieving a reasonable balance of sensitivity and specificity i.e. it's ok to occasionally not find a patient's record, but it is very bad to find the wrong record. The team is not specifying the matching algorithm such as exact match, probabilistic match, partial match (first six letters of last name), Soundex or other approaches. Their work to date suggests using patient name, gender, date of birth and numeric identifiers (such as driver's license number, payer member number, last 4 of SSN etc.). It does not preclude the possibility that new identifiers such as an opt in patient healthcare ID, a DIRECT address, or other identifier could be included in the future.
Dixe Baker presented an overview of the Nationwide Health Information Network power team effort which will create a set of building blocks encompassing all the requirements of the existing NwHIN Exchange standards and Direct standards. Their final report will be presented in September.
Steve Posnack presented the Standards and Certification Criteria codeset update that enables the latest version of SNOMED-CT, LOINC and CVX to be included in Certification testing.
George Hripcsak and Josh Seidman presented an overview of Meaningful Use Stage 2. In the next few weeks, ONC will determine what gaps need to be filled with new standards specifications.
Jamie Ferguson and Betsy Humphreys presented the Vocabulary Task Force Update. Soon, standards subsets will be available that will reduce the burden of implementation and compliance with meaningful use vocabulary standards adoption.
Judy Murphy and Liz Johnson presented the Implementation Workgroup Update. They are completing data gathering and analysis of feedback on the certification process and ways in which it can be improved for stage 2.
A very productive meeting. I look forward to the July meeting and the work ahead on Meaningful Use Stage 2 standards.
Farzad Mostashari, National Coordinator, began the meeting by highlighting the importance of taking first steps on early health information exchange use cases. The notion of creating a standard envelope around data that identifies the patient and the sender of the data enables many transactions. Supporting privacy flags enables the recipient of the data to obtain necessary consents before viewing data and to store the data optimally to respect patient privacy preferences (such as special locked areas for mental health, substance abuse or HIV related data). Privacy flags may not be needed if the patient is the source of the data or the patient gives consent to disclose and consent to view directly to the provider at the point of care.
Stan Huff led the metadata discussion and reviewed the work that has been done to date on patient ID and provenance standards. For patient ID, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header. This XML has nothing healthcare specific such as OIDs in it. For provenance, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header and X.509 certificates for digital signature. The signature could be an institution, a department, or an individual, as needed by the use case. For Privacy we considered many options and recommended a CDA R2 Header with a simple vocabulary to indicate that sensitive data is present. The list of sensitive data types could include mental illness, substance abuse, sexually transmitted disease data, HIV data, domestic violence data etc. or it could be a simple indicator that sensitive data is present. Specifying such a vocabulary is future work.
A robust discussion followed about privacy flags. Here are important clarifications
1. During transmission, the envelope of metadata plus the payload of content is fully encrypted and so the metadata is not readable until it arrives inside the organization or to the person authorized to read it.
2. Much of the time, no privacy flags are needed because the patient will be the source of the data and will elect what to disclose to whom. Privacy flags would likely be needed when data is assembled from multiple sources and is received by a provider who needs to obtain special consent before viewing it or apply special protections before storing it.
3. A privacy flag would enable data to be automatically routed to specially protected areas of the EHR.
4. The CDA R2 header standards are used millions of times per day throughout the world but this subset of them and constrained specifications of how/when they are used should be tested before regulations require them for specific transactions.
5. The recommendation to use CDA R2 headers for metadata is the beginning of a formal ONC process to seek comment, feedback and stakeholder engagement regarding their use.
Based on all these clarifications, the HIT STandards Committee approved the use CDA R2 header for metadata as a formal recommendation to ONC as it begins the NPRM process.
Next, Dixie Baker and Walter Suarez presented Provider Directory recommendations. At last month's meeting, they suggested the use of LDAP/IHE HPD standards and received feedback that these standards were not the best fit for cross organizational/federated directory lookup. They reconsidered the possibilities and examined DNS as a means to find IP addresses and certificates, the concept of a Top-Level-Domain as a means to create a uniform, secure way to retrieve directory information about healthcare organizations (of note, ICAAN announced that such Top Level Domains will soon be very easy to create), and the use of microformats/microdata as a means of creating simple federated lookups for provider directory information that cannot be stored in DNS, such as street address and phone number. Web pages containing such data can be secured with Extended Validation certificates to provide identity verification of the entity publishing the information i.e. it really is Beth Israel Deaconess publishing the directory information about Beth Israel Deaconess. Summarizing their recommendations for provider directories:
1. DNS should be used for certificate retrieval per the Direct Specification plus web pages with microformats/microdata should be used for additional directory information. These web pages can be federated via standard search engine technology.
2. A Top level domain can be considered in the future, but there is no need to implement one now.
The HIT Standards Committee approved this recommendation as input to the S&I framework process.
Next, Doug Fridsma let a discussion of progress on "Summer Camp".
Marc Overhage presented the work on patient matching, noting that the work of the group is to specify those data elements that can be used to match patients, achieving a reasonable balance of sensitivity and specificity i.e. it's ok to occasionally not find a patient's record, but it is very bad to find the wrong record. The team is not specifying the matching algorithm such as exact match, probabilistic match, partial match (first six letters of last name), Soundex or other approaches. Their work to date suggests using patient name, gender, date of birth and numeric identifiers (such as driver's license number, payer member number, last 4 of SSN etc.). It does not preclude the possibility that new identifiers such as an opt in patient healthcare ID, a DIRECT address, or other identifier could be included in the future.
Dixe Baker presented an overview of the Nationwide Health Information Network power team effort which will create a set of building blocks encompassing all the requirements of the existing NwHIN Exchange standards and Direct standards. Their final report will be presented in September.
Steve Posnack presented the Standards and Certification Criteria codeset update that enables the latest version of SNOMED-CT, LOINC and CVX to be included in Certification testing.
George Hripcsak and Josh Seidman presented an overview of Meaningful Use Stage 2. In the next few weeks, ONC will determine what gaps need to be filled with new standards specifications.
Jim Walker presented the Clinical Quality Workgroup Update as the group continues to simplify the computation of measures and reduce the level of effort to comply with the quality reporting requirements of meaningful use.
Judy Murphy and Liz Johnson presented the Implementation Workgroup Update. They are completing data gathering and analysis of feedback on the certification process and ways in which it can be improved for stage 2.
A very productive meeting. I look forward to the July meeting and the work ahead on Meaningful Use Stage 2 standards.
Subscribe to:
Posts (Atom)

