Cool Technology of the Week

I have long believed that fuel cell technology has the potential to be a high quality, green energy source that gives us alternatives to burning coal or relying on oil imports.

Of course, the promise of fuel cells has been slowed by high costs, and complex technology.

On 60 minutes a few weeks ago, Bloom Energy introduced it's next generation fuel cell technology - the Energy Server.

It's already in production at eBay, Walmart, Staples, and Google.

How does it work?

Here's a flash animation.

The company and its technology are still a bit mysterious. There are detractors who think this may be the next Cold Fusion. There are questions of reliability, maintainability and practicality

Wall Street Journal

Christian Science Monitor

Triple Pundit

Holy grail? Maybe. Cool Technology? Definitely.

Subject Matter Experts

A challenge in all IT organizations is achieving a balance between central control and local/departmental autonomy. Our approach is to clearly define roles and responsibilities such that IT is responsible for infrastructure, databases, security, interfaces, and data integrity while partnering with the business owner for subject matter expertise. Here's the detail:

There are immediate and long-term elements of an application implementation and the ongoing support of the application that are beyond what the IT Department can reasonably be expected to manage, maintain or support.

These may include, but not necessarily be limited to: customer financial responsibilities associated with managing or maintaining the application; vendor or sales contacts and interactions specific to the product lifecycle, licensing or application functionality; user management issues specific to the use, functionality, workflow or impact of the application.

Some of these responsibilities may be assumed by the customer’s or department’s management staff (“Application Owner”) while others may be assumed by a staff member who possesses the depth of knowledge or expertise associated with or required to run the customer’s or department’s daily operation.

This person is usually referred to as the “Subject Matter Expert” or “SME”. The SME is very important to not only assisting in the application’s development and implementation but in also maintaining the long-term use and effectiveness of the application within the department.

The responsibilities outlined below are those that require ownership by the Application Owner and by the SME. They are specific to financial management, vendor relationship management or non-technical maintenance and support requirements that can be most effectively handled by the owner or SME. To clarify the use of the term “non-technical”: there is no requirement or expectation that the owner or SME will possess either knowledge or understanding about the workstation or server operating system, hardware or configuration or the programming, support or configuration of the software application.

A. Solution / Application Financial Management

* Budgeting and procurement of funds associated with the ongoing management and maintenance the Solution/Application throughout its lifecycle, which may include but may not be limited to: hardware, software, licensing, maintenance and support contacts, and other equipment and/or services/agreements that may be required.

* Budgeting and procurement of funds that may be required to secure the services of a third-party vendor(s) for any solution component (hardware or software) that is not supported by the IS Department. The sponsor/ owner is responsible for all expenses and liability associated with any agreement(s) or service(s) contracted between them and the vendor.

B. Vendor Relationship Management

* Manage vendor relationship and maintain current vendor-related information; i.e., Account Manager and contact information

* Maintain product line awareness through routine communications with the vendor or your Sales Account Manager.

* Manage application licensing requirements (identify/forecast needs) and communicate expenses or requirements to your department’s financial resource.

C. Subject Matter Expert (SME) and Use Management

* Possess an understanding of the department’s business or clinical workflow requirements.

* Serve as the contact person to whom any HIPAA or compliance issues may be directed, specifically related to the data being entered into the application.

* Serve as the department’s liaison to the IS Help Desk to facilitate IS involvement in basic troubleshooting, problem identification and escalation paths to technical experts or the vendor.

* Maintain availability as the primary contact to whom the IS Department can communicate outages or technology issues that may impact the area’s productivity or ability to provide critical services.

* Identify, establish and maintain downtime procedures to deal with IT outages that may negatively impact the application’s availability and potentially the department’s productivity or ability to meet its mission or objectives.

* Facilitate departmental user training to ensure efficiency and optimal productivity by providing on-the-job training or working with the vendor to arrange for third-party training.

* Participate with IT staff and vendor representatives in discussions that involve the implementation of application (version) changes that may have an impact the department’s workflow, productivity or the application’s (end-user’s) functionality.

* Maintain (working) knowledge of the application user interface; i.e., the ways in which the product is designed to interact with the user in terms of text menus, checkboxes, text or graphical information and keystrokes, mouse movements required to control the application; as well as, report creation/generation and other information about the use of the application that is essential to the day-to-day operation and productivity of the department.

* Perform any routine vendor-recommended or -required user-related performance or integrity checks.

* Create user-specific policies and/or procedures that may be required to address appropriate departmental use and functionality.

* Describe how critical the application is in meeting the mission and objectives of the department in providing services or in maintaining productivity.

* Maintain awareness of vendor version updates that may impact the department’s workflow, productivity or application’s (end-user’s) functionality.

* The primary contact for vendor and the recipient of media related to application upgrades, updates, patches or other application related materials or information.

* Work with IS to coordinate/facilitate required software upgrades/updates that may impact departmental/user productivity.

* Provide application-level account management responsibilities that may include: Defining user access rights or authorizing user accounts.

* Provide on-site first response for end-user issues related to end-user application performance or functionality issues.

The responsibilities listed above are discussed in detail by IT throughout the application’s implementation and will be reviewed with the SME when the Support Level Agreement (SLA) is finalized. If at any time during these discussions there are items that are unclear, ambiguous or that cannot be adequately managed or maintained by the SME or a resource within the application owner’s department, they should be immediately identified and discussed with the IS Manager.

If, during the application implementation or subsequent support discussions, it is determined that the solution/application is identified as being critical to the provision of patient care or to a core or enterprise-wide critical function, the application owner or SME will be asked to identify a back up Subject Matter Expert.

I hope this is helpful to your application implementations. It works for us!

Introducing NHIN Direct

Over the past 5 years, I've worked with many talented standards developers, implementation guide writers, and software vendor engineers. We've crafted use cases, selected standards, harmonized gaps/redundancies and written interoperability specifications.

I'm very happy with our achievements in content and vocabulary standards. We have excellent momentum and accelerating adoption.

Transmission is still an area requiring work. FHA Connect is a good start, but is challenging for small providers who have different use cases - the push of healthcare data from provider to provider, provider to payer, and provider to public health in support of Meaningful Use. Interoperability specifications and profiles for transmission have been written using combinations of existing standards from many SDOs. The resulting documents are not simple for smaller organizations with limited resources to use.

When I ask about creating simpler approaches, I'm told that these guides were the best that could be done to address the use cases with existing standards.

Here's a very controversial point - what if the standards we are starting with as we write interoperability specifications and profiles are not appropriate for creating simple, easy to use, internet-based data exchange that works for small organizations with limited resources?

The answer - we need a new, simpler approach that leverages REST, simple SOAP, and SMTP for data exchange. I believe NHIN Direct is that approach.

Here's a few highlights from the NHIN Direct FAQ page

What is NHIN Direct?

NHIN Direct is the set of standards, policies and services that enable simple, secure transport of health information between authorized care providers. NHIN Direct enables standards-based health information exchange in support of core Stage 1 Meaningful Use measures, including communication of summary care records, referrals, discharge summaries and other clinical documents in support of continuity of care and medication reconciliation, and communication of laboratory results to providers.

Why NHIN Direct?

There is a need to extend the NHIN to support a broader set of participants and providers through a simple, standards-based, widely deployed and well-supported method for providers to securely transport health information using the Internet in support of the core Meaningful Use outcomes and measures.

What is the relationship between NHIN Direct and the currently described NHIN Architecture?

The currently described NHIN Architecture describes a method for universal patient lookup and document discovery and exchange between National Health Information Organizations, including Federal providers such as the Veterans Health Administration, Department of Defense Military Health System, RHIOs, and large IDNs. NHIN Direct supports cases of pushed communication between providers, hospitals, laboratories, and other health settings of care.

The current members of the NHIN Collaborative will be able to support the NHIN Direct model, and providers and enabling organizations for NHIN Direct will scale to support to support the discovery and exchange use cases. Both models are required and will be in use at the same time for the same participants, depending on the information exchange needs.

Does NHIN Direct replace the current NHIN model? Or is NHIN Direct the current NHIN model on “training wheels”?

No. NHIN Direct and the current NHIN model support different use cases and are coequal in a system of robust nationwide health information exchange.

How will the specifications and standards for NHIN Direct be developed?

The specifications and standards will be developed in a rapid, open process intended to draw from a varied set of stakeholders representing both public and private providers and technology enablers.

What NHIN Direct doesn’t solve

In order to create rapid innovation, we are deliberately constraining the scope of NHIN Direct to a spare set of specifications and standards that solve a well-defined pain point. Unless a particular capability is essential to support the core use cases, we will leave it out or defer it to a later day. In doing so, we do not intent to devalue any particular health information exchange area or need, but merely to define a scope that both advances the state of nationwide health information exchange and is achievable in the short term.

How can I or my organization participate?

There are three basic ways to participate

1. A core group of NHIN Direct stakeholders will come together frequently from March through the end of the year to develop iteratively the core enabling specifications and service descriptions, and test those specifications with working code in both demonstration and real-world implementation contexts. To enable close collaboration, the core group is expected to include 5-8 stakeholders who commit to active participation, code development and contribution, and, most importantly, to implement the resulting specifications and services in a real-world setting that demonstrates the core use cases.

2. The NHIN Direct work will be conducted in an open manner, with ample opportunities for participation. We welcome comment and feedback, working code, code contribution to the open source reference implementation, and implementations of the specifications in different technologies.

3. Technology enablers may passively participate in the standards development work, by monitoring the work and resulting specifications, implementation guides and reference technology implementations, and then actively participate in late 2010 and in 2011 by building the core NHIN Direct services into EHRs, HIEs, and other healthcare technology implementations.

The NHIN Direct effort philosophy is expressed in design rules

The golden standards rule of "rough consensus, working code" will be applied to this effort.

Discuss disagreements in terms of goals and outcomes, not in terms of specific technical implementations.

The NHIN Direct project will adhere to the following design principles agreed to by the HIT Standards Committee from the feedback provided to the Implementation Workgroup

Keep it simple; think big, but start small; recommend standards as minimal as possible to support the business goal and then build as you go.

Don’t let “perfect” be the enemy of “good enough”; go for the 80% that everyone can agree on; get everyone to send the basics (medications, problem list, allergies, labs) before focusing on the more obscure.

Keep the implementation cost as low as possible; eliminate any royalties or other expenses associated with the use of standards.

Design for the little guy so that all participants can adopt the standard and not just the best resourced.

Do not try to create a one size fits all standard, it will be too heavy for the simple use cases.

Separate content standards from transmission standards; i.e., if CCD is the html, what is the https?

Create publicly available controlled vocabularies & code sets that are easily accessible / downloadable

Leverage the web for transport whenever possible to decrease complexity & the implementers’ learning curve (“health internet”).

Create Implementation Guides that are human readable, have working examples, and include testing tools.

I look forward to the efforts of NHIN Direct. As always with emerging technologies, I'm eager to be an early adopter, beta tester, and active contributor.

The HIT Standards Committee Comments on the IFR

On Friday, the HIT Standards Committee submitted its comments on the Interim Final Rule to ONC. Below is a summary of the documents we submitted, which will soon be posted on the publicly available comments site.

Clinical Operations

1. Recognizing that standards evolve and regulations are hard to change, we recommended that the IFR specify broad families of standards, stating the major version of each standard, accompanied by a detailed implementation guide that serves as a floor. For example HL7 Version 2 should be used for laboratory result reporting and the HL7 2.5.1 Implementation Guide is the recommended floor. HL7 2.5.1 will evolve, which is fine, since any new implementation guidance will still be in the HL7 Version 2 family, although it could be HL7 2.6, 2.7 etc. Such an approach futureproofs the regulation. Here are the families of standards we recommended

Patient Summary - HL7 Version 3 Clinical Document Architecture (of which CCD is one example) and the ASTM E2369 CCR

Medications - NCPDP Script

Administrative Transactions - X12 4010 and 5010

Quality Reporting - XML

Population Health including labs, biosurveillance and immunizations - HL7 Version 2

2. The implementation guides we recommended as floors are

Patient Summary - HITSP C32 2.5

Medications - NCPDP 8.1 and 10.6 (realizing that 10.6 is the emerging standard but 8.1 is the Medicare Part D requirement)

Administrative Transactions - CAQH Core 1 Operating rules applied to 4010 and to 5010 as that guidance becomes available

Quality Reporting - PQRI XML 2008 Registry

Public Health Labs

HL7 US Realm Interoperability Specification - Lab Result Message to EHR ORU^R01, HL7 Version 2.5.1, July 2007

HL7 2.5.1 Laboratory Result Reporting to Public Health (Release 1)

Public Health Surveillance

Public Health Information Network HL7 Version 2.5 Message structure specifications for national condition reporting, Final Version 1.0, August 18. 2007, CDC

Message Structure Specification v 1.0 Errate and Clarification 05/23/2008, CDC

Public Health Immunizations

Implementation Guide for Immunization Data Transactions using Version 2.3.1 of the HL7 Standard Protocol (published 6/2006), CDC

3. We also recommended several vocabulary starter sets and mappings to accelerate adoption of controlled terminologies (examples are the NLM SNOMED-CT Core problem set subset, RxNorm, and the LOINC most frequently ordered subset). We also recommended that cross maps be made generally available such as

SNOMED CT to ICD9/10 mapping

SNOMED CT to CPT4/HCPCS mapping

SNOMED CT to LOINC mapping

4. We recommended that Vital Signs be encoded in SNOMED or LOINC

5. We asked for clarification that the scope of required standards is limited to external exchanges between organizations.

Clinical Quality

1. We recommended that 2011 include a controlled vocabulary for medication allergies at the drug level as is needed for drug/allergy interaction checking and reporting. UNII (part of Stage II recommendations) is at the ingredient level, which is more than is needed for 2011 quality measure reporting.

2. We recommended that 2011 include a controlled vocabulary for Vital Signs - SNOMED and LOINC with LOINC preferred. Vital signs are needed in 2011 for hypertension control and body mass index reporting.

3. We recommended that 2011 include standardized Units of Measure - UCUM. Standardized units are required to calculate measures that use lab results, medication dosages, and vital signs.

4. We noted that CCR is a fine patient summary standard, but for other uses such as reporting the actors/actions/events in clinical workflow needed for quality measurement, CCD is preferred over CCR.

5. We noted that changing from paper-based attestation to PQRI XML to a CDA-based reporting standard - 3 changes in 3 years - would be burdensome. We recommended that instead professionals and hospitals follow existing CMS requirements at the time of reporting. For example, hospitals currently have well specified requirements and supporting processes for reporting to the CMS Hospital Compare website.

Privacy and Security

1. Recognizing that EHRs and EHR Modules may be used to achieve meaningful use, we recommended that an organization consider the security implications of using a collection of modules. Some modules may not involve data exchange and thus do not need certain security features such as encryption. Others may need to comply with the same data exchange protections as a complete EHR. Using the same terminology embraced by HIPAA, was suggested that security of EHR Modules should be "addressable" - analyzed and secured appropriately by the implementing organization.

2. The IFR preamble contains lists of example standards. We considered including these examples in the regulation itself but ultimately recommended that they not be specified, since security standards evolve rapidly. Instead we recommended that a list of acceptable technology standards be included in the certification process.

3. The IFR requires providers to implement online access to records for their patients. We felt that the definition of "online" was ambiguous. We recommended that as a floor, the provider should make an electronic copy available to the patient such as via a simple download.

4. There are two popular forms of encryption - Symmetric and Asymmetric (public key). We recommended that both be acceptable and that AES be required when using Symmetric key approaches.

5. I frequently blog about the need for standardized, simple approaches to data transmission. Tomorrow's blog will be about the exciting NHIN Direct effort to accelerate this work. The IFR provides very vague transmission standards guidance - REST and SOAP. There are really two choices - no guidance or very specific guidance. Vague guidance is not helpful. We recommended that the provision listing REST and SOAP without additional detail be removed.

6. We noted that Accounting of Disclosures is a 2015 Meaningful Use criterion yet ARRA requires accounting for disclosure in 2009 (or the date of acquisition) for entities which acquire EHRs after January 1, 2009. We recommend a joint meeting of the Policy and Standards Committee Workgroups on Privacy and Security to align the ARRA, Meaningful Use, and Standards timelines. We also recommended that the Office of Civil Rights consider the ASTM E2147 standard as a simple list of required data elements for audit and disclosure.

The comment period closes in one week and I look forward to the next revision of the Interim Final Rule as it evolves into regulation guiding all our interoperability efforts.

If It's Tuesday, This Must be Tokyo

A quick but eventful trip to Japan from March 3-7. My trip was funded by the University of Tokyo as part of an academic visit and not related to any company or product.

Two hours after landing in Narita, I had dinner with my hosts in Tokyo at La Rochelle, a French-Japanese fusion restaurant run by Iron Chef Hiroyuki Sakai . Chef Sakai prepared several novel vegan dishes for me using fresh Japanese mushrooms and vegetables.

The joy of the 14 hour time difference between the US East Coast and Japan is that I can work the Japanese day and the Boston day in the same 24 hour period. After the welcome dinner, the Boston business day began and I worked on several projects related to Meaningful Use- Federal, State and Local.

The morning brought 12 hours of lecturing, meeting, and greeting with Japanese healthcare policy and technology experts, discussing the Japanese version of the healthcare stimulus plan. (250 billion Yen, which is approximately 2.8 billion dollars). Critical issues for the Japanese are data security, data sharing consent, standards, reducing competitive disincentives to healthcare information exchange, and lack of EHR adoption among ambulatory clinicians.

After a great conference day, I said goodbye to my hosts and had 36 hours on my own before my flight left. My evening was filled with collaboration among members of the HIT Standards Committee to finish the comments on the Interim Final Rule (will be my blog tomorrow) and putting the finishing touches on a Health Affairs article (it seems to be a yearly tradition that I go to Japan and spend my nights writing a Health Affairs article for the annual Healthcare IT issue). At 7am I left the hotel and began the adventure I described in Friday's blog - a traverse of the Takao ridges. A truly remarkable experience.

In case you find yourself in Tokyo, here's my brief description of the hike.

From anywhere in Tokyo, take the Yamanote line to Shinjuku station. From there, transfer to the Keio line, and take a limited express bound for Kitano. Once there, take a local bound for Takao-san-guchi. Exit the station to the right and you'll find yourself at the the trailhead. There are 6 possible trails up Mt. Takao. I recommend trail #1 - the longest, most scenic and less traveled. However, Mt. Takao is a very popular destination, so less crowded is relative. The good news is that few people travel the ridge beyond Mt. Takao. After reaching the top, go to the East end of the summit and take the trail to Shiro-yama, the next summit. At that point, the crowds disappear. The trail to the next peak, Kagenobo-yama is an amazing ridge filled with cedar trees (sugi). The trail to Meio-toge is isolated, wild, and follows the track of the Japanese version of the Appalachian Trail (Kanto Fureai-no-michi). The final peak is Jimba-san and its famous war horse statue. A descent via Wada pass to the Jimba Kogen-shita bus stop, a bus ride on the #32 and #5 buses to Hachioji, and a train from either Keio or JR Hachioji station to Shinjuku completes the day. Book time for the hike is 5-7 hours (plus 3 hours for train/bus travel) and the distance covered is 12 miles, with a few thousand feet of elevation gain.

This morning, I checked out at 6am, took the Chuo line to Shinjuku, stashed my bags in a locker (fully electronic - you are given a PIN number to open the locker instead of a key), took the Yamanote line to Shinagawa station, then the Keihin Kyuko Rapid Limited Express to Miura-kaigan on the Miura Peninsula, an area of wide sandy beaches, rocky coastline, and a great old lighthouse. After walking the Peninsula, I took the Zushi line train to Jimmu station and hiked the temple route (the photo above), passing plum blossoms in bloom, Jizo statues, and the peak of Mt. Takatori. I was completely alone the entire trip.

From there, I took the Keikyu line back to Shinagawa, the Yamanote line back to Shinjuku, picked up my bags, and took the Narita Express to the airport, changing from my hiking clothes into a suit while on the train. I just landed from my 18 hour commute back to Boston.

In all my travels above, a rudimentary knowledge of Japanese really helped, since most signs in the wilderness are only in Japanese, such as this one which indicates the way to the train station (good luck figuring it out since both West and South seem to the be right answers). How did I get by? The following expression:

Sumimasen (fill in the name of where you want to go) wa doko desu ka?

which translates into

Excuse me, (placename) it where is?

This saved the day many times, since maps, signs, and guidebooks were often wrong.

The Japanese people are gracious, helpful, and eager to provide directions to foreign travelers.

I succeeded in my quest to find the road less traveled. Of course, the fact that it was 38 degrees, raining and trails were ankle deep with mud may be have been a disincentive to other travelers.

A great trip! Thanks so much to my friends in Japan who made it happen.