Telemonitoring for the Home

As Accountable Care Organizations and medical homes start thinking about alternative quality contracts that reimburse for keeping patients healthly and not for delivering more care, it's likely that wellness care will include home telemonitoring between clinician visits.

Devices will include electronic scales for measuring fluid retention in CHF patients, blood pressure measurement for refractory hypertension, glucometers for diabetics, and home spirometry for patients with COPD or asthma.

I recently tested a home monitoring product that illustrates the future of consumer healthcare devices, emerging approaches to interoperability, and the need for consistent transport standards.

The Withings Internet Connected Body Scale incorporates several mainstream technologies to achieve a highly functional result. Here's how it works:

After taking the scale out of the box, you connect it to your USB port (only used during setup) and launch the scale configuration website. You specify the wireless access point and security settings to use and link the scale to a web-based account. You set up users in your account and provide basic height/age/preferred method for body mass index calculation. Technologies used - WiFi with WEP or WPA security, HTTPS, and USB.

Once the scale is associated with your account, using it is simple. When you stand on the scale, it wirelessly uses a RESTful protocol to compare your weight with the list of known scale users on your account, probabilistically choosing the right user by matching weights. It retrieves demographic information, calculates body mass index, and % body fat, then sends the data to the user account.

Once posted, there are multiple data options - graphing over time, PDF of measured weights, automated posting to Google Health, automated posting to Microsoft Healthvault, and even posting in realtime to Twitter (I'm not sure who would want to do this). Technologies used include PDF rendering, calling the Google API, and calling the Microsoft Health API.

I had my Withings scale updating my Google Health account (shown above) in real time via WiFi in about 5 minutes after opening the box. No programming or technical knowledge was required. This illustrates the power of standardized APIs.

Here's the technical detail of how the scale's API works.

A few observations on interoperability.

Although Withings did something remarkable by incorporating WiFi, WEP, WPA, HTTPS, REST, Google Health, Microsoft Health, and PDF in one product, it does require that the device posts to the Withings website and that this website manages interoperability with other website APIs.

Per the discussion by the NHIN Direct Implementation Group, imagine a world in which all vendors have agreed on a consistent RESTful or SMTP-based transport protocol using a well defined addressing mechanism, such as described in my Health URL blog. Imagine that the payload adhered to a consistent, vocabulary controlled format such as the work being done by the Continua Alliance. The scale could directly interact with Google, Microsoft or other vendor sites. The only scale configuration needed is to specify the Health URL of each user.

As Beacon Communities focus on advanced interoperability that engages patients and families for disease management, I'm confident that devices such as the Withings scale will be widely deployed in homes.

Over the next few years, I'm hopeful that devices will evolve from interoperability that works by embracing multiple proprietary APIs to a single simple interop that begins with common transport and addressing standards and progresses to demand for rapid adoption of common content standards.

Kudos to the Withings engineering team for great steps on the journey to bring interoperability to the home.

The iPad goes live at BIDMC

The following is a guest post from Dr. Larry Nathanson MD, who leads BIDMC's Emergency Medicine Informatics efforts. (Note that the photo contains only fictitious patient names):

I had been anxiously awaiting the arrival of my iPad --This is the form factor I have been asking (begging) of all the vendors for years. I'm very happy to say that it appears to be living up to my high expectations.

The screen is gorgeous. It's very clear and bright, I had no trouble seeing the screen in bright outdoor light. The machine seems extremely responsive -- it reacts immediately to user input and the browser renders pages as fast as my laptop. In landscape mode, its surprisingly easy to type on the on screen keyboard. I wouldn't call it "touch typing" but the autocorrection fixes almost all of the typos that are introduced when I just let my fingers fly. It turns out to be much easier to enter data than I expected, and in fact this entire review was typed completely on my iPad.

I tested it today during my shift in the ER. Initial tests with our clinical applications went amazingly well. The ED dashboard, WebOMR and Provider Order Entry all appear to function well without modification. The popup blocker does try to get in the way of new windows, but it's a only a minor annoyance. The EKGs look better onscreen than on paper. It was great having all of the clinical information right at the bedside to discuss with the patient. The only problem was that the increase in efficiency was offset by the patients and family who wanted to gawk at it.

The battery life is one of the most astounding features. I don't know how they did it but the claimed 10 hour run time might actually be more accurate than the usual inflated claims that I'm used to for mobile devices. The device arrived at full charge and after testing all day and leaving it playing several full length movies the battery still had 40% left. This could easily make it through an entire ER shift on one charge, eliminating the need for hot swappable batteries.

I am a little concerned about how well it will hold up in a clinical environment, particularly the abuse it will get in the ER. The case is very smooth and the rounded bottom makes it easy for it to slide out of a hand or off a table. I don't get the feeling it will be as forgiving of drops as some better padded (albeit heavier) devices. I'm hoping someone will create a case that has a hand strap on the back (like the Panasonic MCA has).

One problem that plagues all tablets that I've used clinically is the difficulty entering strong passwords. The onscreen keyboards of mobile devices makes it much harder to quickly enter numbers, symbols and mixed case and is, in my opinion, one of the biggest barriers to medical tablet adoption. A biometric, or other creative way of addressing this will likely be needed.

From a consumer electronics point of view I'm also impressed. When just web surfing or watching video I do like that I can just lean back and hold the iPad as I would a book or magazine. My wife found that she preferred the iPad Kindle program to the actual Kindle device. (That bodes poorly for my plans to develop software on it!)

In summary, I'm very excited -- the form factor is close to perfect and it's robust enough to keep up with a busy ER. I think this is one of the most promising developments in medical mobile computing in a long time.

There is one major drawback however: Now my iPhone seems slow and inadequate!

Sent from my iPad

Rethinking Clinical Documentation

Over the past 5 years, I worked with HITSP and the HIT Standards Committee to select standards for exchanging clinical summaries. But what exactly is a clinical summary?

There is common agreement about the need to exchange codified, structured data for problem lists, medications, allergies, and labs.

However, what is the role of unstructured clinical documentation text?

Some have suggested that unstructured text is hard to navigate, at times repetitious, and challenging for computers to interpret.

I believe the exchange of free text notes such as operative reports, history&physicals, ED charts, consult notes, and discharge summaries is very important.

Consider this example.

A 40 year male with no family history of heart disease presents to the ED at 3am with a chief complaint of chest pain and left arm numbness. The EKG is normal, a stress test is normal, labs are normal, and a cardiology consult is completed. The patient is discharged on H2 blockers with a diagnosis of gastritis.

A summary which only includes a problem and med list may state a Problem List of Gastritis and a Medication List of Prilosec OTC.

When the patient next visits an Emergency Department, no one will know about the cardiology consult, the differential diagnosis considered, and the thought process that led to the diagnosis of gastritis to explain the chest pain.

An entire workup will be started from scratch.

There is a great article in the March 25, 2010 of the New England Journal of Medicine "Can Electronic Clinical Documentation Help Prevent Diagnostic Errors?" by Gordon D. Schiff, M.D., and David W. Bates, M.D. in which the authors note:

"Free-text narrative will often be superior to point-and-click boilerplate in accurately capturing a patient's history and making assessments, and notes should be designed to include discussion of uncertainties."

I agree.

Notes should be included as part of clinical summaries.

However, we should do all we can to improve the quality of notes.

Over the next year, we hope to try a radically different approach to clinical documentation at BIDMC which we think will leverage all the strengths of the full text note as described by Drs. Schiff and Bates without the repetition and navigation issues.

Today's inpatient charges are a collection of SOAP notes written by the medical student, intern, resident, fellow, attending, and consultants largely for billing and medico-legal purposes.

What if the chart was recast as a communication vehicle for the entire team that summarized the day's events and collective wisdom on next steps?

Our answer - a daily Wiki entry for each patient authored by the entire team and signed/locked by the attending at the end of each day.

How will this work?

Think of it as a private wikipedia build inside our clinical systems and hosted in our data center.

Each member of the care team will use our Team Census application to view the list of patients for whom the team is responsible.

Clicking on any patient name will bring up the daily Wiki. Each member can add documentation, revise existing text, and leverage the work of others on the team until the attending makes the final edits and signs/locks the day's documentation. Just like a wiki, a complete journal shows all all edits/changes/deletes, so no information is lost. Importantly the day's wiki entry has one physical exam, one assessment, and one plan - not 17 repetitive entries saying the same thing that often appears in today's paper charts.

The idea of a daily wiki entry for each patient creates highly readable succinct documentation authored by the entire team with a medical legal record of the process that was used to generate it. It's a perfect single document to share with the referring clinician and the patient/patient's family.

After our initial pilot work, I'm guessing we'll also engage the patient and families to add to the Wiki, reflecting the shared decision making between the team, the patient, and the patient's family.

We're in the design stage now, but I'll report back on how it goes.

A daily patient Wiki as unified clinical documentation, exchanged with the team, other providers, and the patient. I bet even the free-text naysayers will agree that this should be part of the clinical summary!

Cool Technology of the Week

I've written about my Strida folding bike for commuting between meetings in Boston. It's worked very well for my use case - pedaling a few miles on flat ground on city streets.

What if your commute is longer, the terrain is more hilly, and you need to go a bit faster?

The Yike Bike from New Zealand is a masterpiece of engineering. It's a fully electric foldable bike weighing about 20 pounds with a top speed of 15mph.

Here's the detailed overview.

It's not yet in production and will be pricy - about $4500, but it's definitely an intriguing technology as we consider greener ways to commute and strategies to avoid traffic delays.

The Segway seemed like a good idea at the time but its competition with pedestrians for sidewalk space has been problematic. The YikeBike should be no different than an urban bicycle, using city streets and existing bike laws. It will be interesting to see how cities react to it.

Of course, a helmet should always be worn, despite the lack of them in the demonstration video. Definitely a cool technology design!

The Greatest Good for the Greatest Number

In my career I've had many roles. I've been a consensus builder and a disruptive innovator. Sometimes I'm a leader and sometimes I'm a follower.

No matter what I've done in academia, industry, or government, I've been guided by a few basic principles:

*The Boston Globe test (customize to the locale of your choice) - if your actions were published as a front page article, would they seem fair and reasonable to the average reader?

*The Sister Mary Noel test (my second grade teacher at St. James Catholic School) - if you had to explain your actions to Sister Noel, would you pass her sense of right and wrong or be rapped on the knuckles with a ruler?

*The Sunday night phone call with parents test - when you describe your week to your mom, will your actions seem noble?

*The Senate testimony test - when describing your actions to a Senate panel, is there any reason to say "I have no recollection of those events Senator"

*The Greatest Good for the Greatest Number test - will your actions have a lasting impact on your organization, your state, or your country without direct personal benefit. Although it's true that actions on behalf of others can indirectly bring notoriety to you, fame is not the primary motivation for what you do.

Unfortunately, in our modern society many people I encounter seem more interested in their fame, their fortune, and their reputation.

It could be the economy. It could be competition for resources. It could be a biased sample selection.

How many people have you encountered today who put their co-workers, neighbors, and society first?

When the topic of healthcare reform is discussed, the first question is - what will it mean to my benefits, my costs, and my retirement rather than what will it mean for the 32 million uninsured, future generations, and our nation's competitiveness.

We're only on this planet for 80 years. We cannot take anything with us. If happiness can be measured by making a difference during our short tenure, I hope that more people will ask big picture questions focused on the world around us rather than the size of their house, the speed of the car, or the stylishness of their bling.

I'm not suggesting that we have blind faith in authority or that we all embrace socialism as the solution to every policy problem.

I am suggesting that we move beyond a narrow self focus in all that we do. We should evaluate policy with the lens of the greatest good for the greatest number in our communities, states, and country. We need to move past special interest thinking, including our own.

Change is hard and fear of the unknown can be unsettling. As I've written previously in my blog about your Karma account balance , the good guy (or gal) can lead a life where accounts received exceeds the balance due (borrowed from a Janis Ian song)

If we guide our behavior each day based on choices that look good to the Boston Globe, Sister Noel, our Moms, public scrutiny, and our fellow humans, the world will be a better place.

The ONC Whitepaper on Consent

Last week was a busy one for healthcare IT. In addition to the DEA Interim Final Rule on e-prescribing of controlled substances, the launch of NHIN Direct, and the introduction of new ONC interoperability framework processes, HHS released the Whitepaper on Consent.

The entire document and its 3 appendixes are worth reading. The Executive summary contains a great classification of consent models found throughout the world:

No consent

Health information of patients is automatically included—patients cannot opt out

Opt-out

Default is for health information of patients to be included automatically, but the patient can opt out completely

Opt-out with exceptions

Default is for health information of patients to be included, but the patient can opt out completely or allow only select data to be included

Opt-in

Default is that no patient health information is included; patients must actively express consent to be included, but if they do so then their information must be all in or all out

Opt-in with restrictions

Default is that no patient health information is made available, but the patient may allow a subset of select data to be included.

Appendix A is a very helpful list of State-Led Examples of Exchange in the U.S

For more details about the Massachusetts efforts to date, including the educational materials we used, see my blog about patient privacy preferences.

Appendix B is an overview of Selected State Laws which can be empowering as we implement consent models.

Appendix C contains examples of Exchange in Other Developed Countries.

I've worked closely with the county council in Jonkoping, Sweden which has a very high percentage of EHR and hospital information system adoption

The consent whitepaper was timed perfectly to align with the HIT Standards Committee review of existing standards for storing and transmitting consent preferences.

Well done!

The ONC Interoperability Framework

In my summary of the March HIT Standards Committee meeting I mentioned the new ONC Interoperability Framework and the related RFPs. Here's the detail I promised in my previous blog about ONC. Thanks to Doug Fridsma for this overview and his hard work on it.

ONC announced several projects to support Standards and Interoperability Framework and Nationwide Health Information Network (NHIN).

Over ten requests for proposals were released in February 2010 under the existing contract vehicle: National Institutes of Health (NIH) Information Technology Acquisition and Assessment Center (NITACC) CIO-SP2 Task Order. The funding will support activities for two years that are designed to develop the standards, tools, interoperability framework, and technical infrastructure to support the overall goals of improving adoption of HIT. Key areas for RFP include:

Use case development and functional requirements for interoperability

ONC anticipates leveraging the National Information Exchange Model (NIEM) for health care and develop consistent process for use case development. Working closely with consumers, providers, government organizations and other stakeholders, ONC will identify real-world needs, prioritize them through a governance process, and create explicit, unambiguous documentation of the use cases, functional requirements and technical specifications for interoperability.


Harmonization of standards and interoperability specifications

The harmonization process integrates different views of health care information into a consistent view. This process will include merging related concepts, adding new concepts, and mapping concepts from one view of health care information into another view. This process will also identify gaps that can point the way towards development of new interoperability standards. ONC anticipates leveraging NIEM process to support data exchange harmonization.


Standards Development

In order to meet the needs of the use cases and increased use of HIT, there will be a need to modify or extend the existing standards or develop new standards. ONC will work with standards development organizations and with research organizations to extend existing ones, or develop new standards as necessary. 



Tools and Standards Repository

To accelerate the development, use, maintenance and adoption of interoperability standards across the industry, and to spur innovation, ONC will develop tools to facilitate the entire standards lifecycle and maximize re-use of concepts and components, including tools and repository for browsing, selecting, and implementing appropriate standards.


Interoperability Specifications

In order to be able to test and implement the standards in real-life settings, they must be specified to a higher degree of detail. This project will focus on the development of interoperability specifications that are independent of specific software architecture (a platform-independent model, or PIM) as well as interoperability specifications that are specific to the NHIN architecture (a platform-specific model, or PSM). 


NHIN Architecture Refinement and Management

The NHIN architecture is a specific network architecture that realizes health information interoperability specifications based on open standards. This project will focus on the refinement and management of the NHIN Architecture to meet emerging needs of the health care market.

Reference Implementation

A reference implementation is the fully instantiated software solution that is analyzed to be compliant with the standards and serves as a “reference” to other software developers of what an interoperable solution looks like. The reference implementation will be accessible as a public resource with compiled code, source code and supporting documentation. 


Integration Testing

The current NHIN testing infrastructure needs to be refined to test and validate emerging needs of the network and planned NHIN capabilities as they are identified. ONC will work with NIST where NIST will provide testing tools to validate that particular implementation conforms to a set of standards specification; and ONC will support the development of an integration testing “harness” that will test how a particular component that has satisfied conformance testing requirements integrates into the reference implementation. 


NHIN Demonstrations and Emergent Pilots

Although a reference implementation provides value to the community through a thorough assessment of the technology; support for established standards, and vetting within the HHS, consumer, and other stakeholders, a reference implementation will need to be refined through real-world pilots and demonstrations. ONC will support efforts in the refinement of the reference implementation and interoperability specifications, through limited number of real world demonstration and pilots. 


NHIN Operations and Infrastructure

This project will focus on activities related to operational and infrastructure support for the ongoing demonstrations and production pilots of health information exchange across a trusted network. 


Each project will focus on specific activities within each area as well as collaboration across all other projects addressing overall effectiveness of the Standards and Interoperability framework, certification and NHIN that is critical to the wider adoption of HIT. ONC expects to award one contract for each project for a two-year project period to qualified applicants.