Patient Engagement as a Two-Way Street Part 3 – Recommendations

In my last post, I spoke of the importance of “getting to know” the patient and asserted that knowing a person can’t be accomplished only by predefined questions. I also referred to the HIT Policy Committee and HIT Standards Committee’s request for comment on Patient-Generated Health Data (PGHD) for Meaningful Use Stage 3 (MU3). Four Siemens employees (including me) submitted comments on that blog last week. Here’s my own summary of the comments, stated as recommendations.

• MU3 should define criteria for EHRs to accept PGHD, initially in either unstructured or structured formats. (Note: “PGHD” should include data not only from patient but from their care givers such as family members)
• Encourage, but don’t mandate, structured data content standards. Define a clear roadmap for standards to come, compatible with data standards for EHRs.
• Clearly define provenance (data source) metadata requirements to inform providers so they can exercise their clinical judgment on how to use the data.
• Focus on relevance, being careful not to overwhelm people with too much data. Allow provider access to additional PGHD where needed.
• While in typical cases the patient is authoritative on many issues, the provider needs to exercise judgment as to trustworthiness in each SPECIFIC patient interaction.
• Avoid being overly prescriptive on which data to gather, but rather let patients say what’s most important to them. We “don’t know what we don’t know.”  
• Strive for wide adoption and low barriers to entry by evaluating and embracing a variety of data entry and viewing technologies most commonly used by patients
• Define clear purposes, expectations and responsibilities for the review and use of PGHD

PGHD is not new: much of today’s healthcare depends on it already. Still, in an increasingly mobile, connected, socially networked culture, there’s a lot more potential for providers to get to know patients better by collaborating with them through the two-way exchange of information. MU1 and MU2 are weighted toward a one-way flow of information from EHRs to patients, but the HIT PC and HIT SC are, commendably, seeking ways to turn this exchange into more of a “two-way street” with PGHD.

Patient Engagement as a Two-Way Street Part 2 – “Getting to Know You”

One of the purposes of patient-generated health data (PGHD) is to help providers know their patients better than they would have otherwise if they relied only on data captured by providers. In my experience, I appreciate doctors who do more physical exams and tests but know more about me that could help them personalize their treatment. As Rodgers and Hammerstein wrote in The King and I, “Getting to know you, getting to know all about you…”

So it is with PGHD. How can it help providers know us better? I worked with colleagues to write a detailed response, which you can find as a comment on the HIT Policy Committee and HIT Standards Committee's blog requesting input on PGHD. I’ll give some highlights in my next installment. The rest of today’s post, while alluding to that response, is my own opinion.

While a patient-provider relationship is special and not necessarily deeply personal, think about how people get to know each other in general. They talk! In ways that can’t be predefined, prescribed, or pigeonholed. Sure there are facts such as your birthday or address. But the vast majority of emotion, experience, and aspirations are richly expressed through natural language. Would you want to get to know someone by filling out structured forms with multiple-choice questions?! So in response to the blog question “does all PGHD for care management need to be in a structured form?” I’d answer a resounding “no!”  As one working in healthcare standards, I understand and fully support the need for structured data in EHRs, for interoperability, analytics, decision support, quality measures, etc. But even if we could magically get all PGHD structured, standardized, tagged, and automatically imported into EHRs, that wouldn’t necessarily make things great. Structured data has precision, but very little nuance. Very few patients think or communicate via structure, and no amount of standards or government regulation will turn patients into health informaticists.

So I suggest crawling before we walk or run when it comes to PGHD. Let’s lower the barrier to entry by embracing PGHD in whatever formats or devices (PCs, smart phones, basic phones with text messaging, etc.) the patients can create it. Yes, there should be a direction for standards so that appropriate data (such as med lists or glucose levels) can flow from patient-facing systems like PHRs into EHRs and be understood. But let patients express themselves in their own words and preserve this in their health record. And speak to them in plain language that they understand (which won’t be structured XML). Then we’ll have the kind of two-way street that will help my providers “get to know me” and deliver the kind of healthcare relationship that I want for myself and my family.

Meaningful Use Seeking Standards!

Update: 10 minutes after I posted below, the ONC NPRM was issued!
================================================

Hello! I, like many of you, are in the midst of reviewing the Medicare and Medicaid Programs; EHR Incentive Program - Stage 2 Proposed Rule (NPRM) on Meaningful Use Stage 2 (MU2), which was published late yesterday afternoon but was probably not seen by most people until today. The reason I titled this post as I did was because MU2 needs to be “married” to the Standards, but we’re all limited by the fact that the ONC NPRM on Standards and Certification Criteria was not published on the same day as the CMS NPRM. We’re still waiting... So for MU 2, we don’t have the actual standards in our hands yet, which we need in order to understand the criteria and assess their effects on providers, vendors, and others. Since I’ve been following the HIT Standards Committee for months, and there were sneak previews given at HIMSS, I know about many standards that ONC supposedly included such as Consolidated CDA, NwHIN Direct, and SNOMED-CT. But I’d sure like to see the details ASAP.

From CMS’ NPRM, many data elements in the “summary of care record,” “clinical summaries,” and “view and download” overlap but aren’t quite the same. As worded they don’t exactly match terms used in standards. Hopefully someone in ONC did the mapping to translate from the HIT Policy Committee’s and CMS’s phrases into the right “data buckets” in Consolidated CDA, for example. If not, I’m available to help through efforts like ONC’s S&I Framework Transitions of Care workgroups.

Margalit Gur-Arie wrote a helpful MU2 summary that helps distinguish what’s the same, what’s slightly new, what’s really new, etc.

As an interoperability champion, I see that ONC really means it when it talks about a big push for interoperability in MU2. MU2 has no more of those “check the box” tests without real exchange that characterized much of MU1! But stage 1 still has a few more years of life in it, for at least some providers, even if it is just a stage setter, Farzad Mostashari spoke of the “massive river flowing” of advances HIT, and I’ll be glad when real information exchanges flow abundantly among providers and patients, as I wrote about in some of my very first blogs.

Putting the IT in Care TransITions

On Friday, October 14^th, I look forward to attending a meeting in Washington DC called Putting the ‘IT’ in Care Transitions. That will be followed closely by the ONC S&I Framework Face-to-Face meeting in DC on October 18-19, which will also feature a track on Transitions of Care. Meanwhile, Meaningful Use Stage 2 standards definition marches on, as I wrote in my last blog. Many initiatives are converging (I hope).

The October 14^th meeting will consider three specific patient scenarios: an elderly isolated widow with many chronic conditions; a young child with serious asthma and exacerbating home environment; a homeless man with diabetes and schizophrenia. The premise is: “if the system is designed to assist the most complex patients, then the system will function effectively for all.” I agree with the premise as far as capabilities (more complex scenarios often require more robust capabilities), but I don’t think it’s always true from an adoption and usability perspective. How often have you and I felt that a process or a gadget or a computer UI was “over-engineered” because it was designed for a complex but rare scenario, but was cumbersome for the most common scenarios?

The October 14^th meeting also has a premise that “even the most advanced provider and community organizations acknowledge that new innovation is needed to improve the efficiency and effectiveness of delivering transitional care interventions to large numbers of patients, particularly in an environment in which technology adoption is rapidly growing and the state of technology is changing.” Right on, and so I suggest that these are some key areas for “much new innovation:”

1. Innovative and Usable Presentation of a "just right" level of information to clinicians that avoids the extremes of "information overload fatigue" vs. overly aggressive filtering of information, especially when much information exchange occurs. Can HIT be smart enough to anticipate what a clinician needs? Or must HIT be passive and "do no harm" by leaving all decisions up to the clinician?
2. Policies and guidelines for which electronic information a clinician must read, vs. what they do not need to read. While this is often viewed as a bigger problem for HIE/"Pull" models, it’s a concern even for "push" exchanges, especially if a sender sends information to one provider and copies many others on the "care team." 
3. Reconciliation principles for many types of data, not just medications. E.g., lists of problems/diagnoses, allergies, procedures, and immunizations. The risks vs. rewards of merging, aggregation, deduplication, normalizing across multiple information sources whose vocabularies are not fully standardized. Should HIT strive for “a single source of truth” or just accept that “here is what other sources have said?”
4. Who or what makes a care team? The term is used a lot, but is it clear what makes one? Just knowing who other providers are, and even having access to their records, doesn’t necessarily create a team or a care plan. My hometown football team, the Philadelphia Eagles, has so much talent that some dubbed them a “Dream Team” and surely they know each other’s names and roles, but they aren’t an effective team at the moment. And to play off the meeting title, how will putting the T (Technology) into Team result in better patient Care?

I look forward to blogging about the outcome of these next two meetings.

How Would EHRs Matter to Patients?

In my previous post, I said I’d talk next about patient engagement functions that need EHR data vs. those that don’t.

No doubt, there are some “data-less” functions that can still be useful – you need little or no clinical data to request an appointment, e-mail your doc, or a refill (other than your Rx number). Here’s a list, undoubtedly incomplete, of some functions that I think are Not EHR-dependent vs. those that need (or greatly benefit from) EHR data. Several of the items below are “gray areas.”  

Not EHR-Dependent

• Personal Health Record (PHR) – untethered, if patient is willing to enter the data or settle for existing PHR data feeds (e.g., PBM med history)
• Patient self-service functions (e.g., schedule appointment, request drug refill, view clinical data, pay bill)
• Patient-provider communication and collaboration
• Tools for providers to improve the patient experience
• Technologies to make healthcare more accessible for patients, e.g., telemedicine, virtual visits
• Wellness/lifestyle aids (not just "medical", e.g., diet, exercise, recreation)
• “Find a doctor”
• Search for alternatives to provide services (e.g., price comparisons for services not covered by insurance)
• Patient satisfaction surveys
• Bedside communication with family & friends (e.g., Skype video chat, web access)
• Notification/invitation to events (free screenings, symposiums, etc.)

EHR-Dependent (some may also be provided by Health Information Exchanges)

• Patient access to EHR information (e.g., download)
• Personal Health Record (PHR) – tethered; or untethered PHR with data feeds from EHR (to greatly increase usability)
• Patient Portal
• Patient annotations/amendments to their health information
• Patient provision of information to providers (e.g., home device measurements)
• Providers pushing information to patients via patient preference
• Reminder “app” for taking meds, vaccinations, physical exam, etc.
• Other apps or notifications that help patients follow through with what was prescribed/planned
• Tools for patients to act upon their data (trackers, analytics, access to knowledge)

So patients can accomplish quite a bit without EHRs. But you have questions about your lab or imaging tests and their significance, or your many medications, it sure would help to have the actual data and not rely on memory. I doubt that you’d get full benefit from your med list unless you also knew about your problems/conditions and diagnostic results. I, for one, wouldn’t want to take subsets of my data and redundantly enter it into a dozen separate websites.

If I’m a patient who wants a comprehensive and integrated view of my data, how might I get that? More on that next time…

Certification Retrospective Part 4 – Lessons Learned

Note: this blog post concludes my discussion of experiences in CCHIT. The opinions are mine, and do not necessarily reflect the views of CCHIT or Siemens.

In life in general, and in development of software, standards, and certification criteria, we learn and grow more by trial and error than we do when everything goes smoothly. Frederic Brooks’ classic software engineering book The Mythical Man-Month said “Plan to throw one away; you will anyhow.“ Hence we need prototyping and iterative refinement. The CDA Consolidation Project is fresh on my mind. I voted negative in its HL7 ballot, but that doesn’t mean it won’t succeed, only that it has issues to fix. It would have been a miracle to get that complex task right the first time.

So it is with certification. The CCHIT Interoperability Workgroup (IOWG) experienced growing pains in its early years. 2006 produced only a roadmap, 2007 produced the first (modest) interoperability criteria. 2008 had stronger criteria and roadmap, and 2009 was poised to make big strides toward semantic interoperability. What were my main lessons learned through these years?

What We Got Right (IMHO):

• The “methodical march” sequence of building blocks. Putting the horse before the cart sure helps! As described in Method to our Madness?, we proposed a logical sequence for interoperability:

1. Data Capture
2. Liquidity
3. Standardized Content
4. Data Consumption

Our views crystallized especially in 2008-2009. CCHIT’s criteria included many of the standards that were eventually endorsed by ONC. For example, Lab Results, CCD, e-prescribing, vocabularies (LOINC, RxNorm, SNOMED CT), and leveraging HITSP.

• The Roadmap (“Glide Path”) Concept. I love maps (online, GPS, paper) and want to know ahead of time where I’m going and the milestones along the way. CCHIT published roadmaps for the next two years beyond each certification year. Roadmaps aimed to provide adequate lead time and to encourage developers to plan and head in the right direction. While the HIT Standards Committee did a great job proposing a “Glide Path” to more robust standards in their proposals in late 2009 (see Jamie Ferguson’s August 20th 2009 Clinical Operations Workgroup presentation), that concept was mostly lost when the ONC regulations were published (see comments on John Halamka’s Feb. 10, 2010 blog). For interoperability, developers need to know the target standards, more than a high-level meaningful use matrix, to move forward.
• Staying a Course. Once we defined the roadmap, we might adjust timing and provide more detailed criteria in our next development cycle, but overall there was continuity and stability with a minimum of “surprises.”
• Transparency. CCHIT posted responses to every public comment on its website. Of course not everyone would agree, but we thought everyone deserved to know their comments were considered and our rationale for decisions.
• Teamwork. The IOWG built relationships and trust among multiple stakeholders within CCHIT, as mentioned in Part 1. That enabled us to work through differences and get things done, despite conflicting opinions. In contrast, it’s harder to capture the “team” element in groups where 50-100 people are nominally on a project but attendance is sporadic, yet I understand the need for openness and transparency. Ultimately, a small group forms a cohesive team within the larger group. For example, the Documentation and Testing workgroup within the Direct Project gradually developed a “team” spirit similar to what the IOWG had.

Regrets:

• Lack of Opportunity to Finish What We Started. Last week I used football, now here’s my first baseball analogy. CCHIT, as the “starting pitcher” for EHR certification was relieved by ONC in the 6^th inning – enough to get a quality start, but not enough to win the game. Our methodical march didn’t reach its goal, but I hope that ONC will be a good “closer” to save the win for interoperable EHRs, coordination of care, and the good of the patient.
• Lack of End-to-End Coverage. Interoperability involves senders, receivers/requesters, and perhaps intermediaries. To succeed, it must encompass all participants (e.g., EHRs, HIEs, PHRs, labs, pharmacies, public agencies), because so much exchange goes beyond EHRs. We didn’t achieve this in CCHIT, but not for lack of trying! We envisioned covering some end-to-end interoperability through certification programs for HIEs and PHRs in addition to EHRs. Excellent people were in the HIE and PHR workgroups, and the IOWG had good dialogues with both. The HIE program was launched with poor uptake followed by suspension in light of impending ONC program changes. The PHR program was not launched.
• All-or-Nothing Approach. CCHIT pondered a modular certification approach early on, especially for inpatient EHRs, but didn’t implement it until ONC mandated it in the Certification Final Rule. In hindsight, I wish we had done that sooner. I don’t think we needed an “all or nothing” approach. Truth in labeling would have disclosed each product’s gaps, to help people make informed decisions. Vendors with complete EHR functionality could still differentiate themselves as a “one-stop shop” but others (“little guys”) would not be excluded from certification just because they didn’t provide 100% of all capabilities.
• A year in limbo. From mid-2009 through mid-2010, the industry was paralyzed by uncertainty and lost momentum on interoperability. It was clear that CCHIT criteria wouldn’t be adopted as is by ONC, but no one knew what would replace them. There was no assurance of staying a course or a clear glide path, and people who had done their best to follow the CCHIT roadmap were concerned and confused. Interoperability features (such as standardized coding and discrete data consumption) that the IOWG expected to be in products in 2010 have been delayed, possibly to MU Stages 2 or 3.

Whether right or regret, there are lessons learned that can be applied going forward.

• Follow the methodical march – a logical sequence of capture, liquidity, standardization, and consumption.
• Define a roadmap (glide path) with ample lead time.
• Stay the course.
• Take an end-to-end perspective.
• Be transparent.
• Be flexible, not “all or nothing.”

That’s it! This has been a long blog series, and if you made it to the end, thanks!

Certification Retrospective Part 3 – Controversies Along the Way

Note: this blog post continues my discussion of experiences in CCHIT. The opinions are mine only and do not necessarily reflect the views of CCHIT or Siemens. Please bear this in mind especially considering that the topic is “Controversies”

From my last Certification Retrospective post, I promised to share lessons learned and some “agonizing controversies” we faced in the CCHIT Interoperability workgroup (IOWG). I thought I could do both in one post, but now realize that I’ll need a “Fourth Movement” after this. Each controversy could easily take up a post of its own, but I’ll try to squeeze them into this post, deferring Lessons Learned to Part 4.

1. When should HITSP specs be incorporated into certification? Once HITSP was formed, it (not CCHIT) was designated to select standards. CCHIT, however, could decide when/if those standards would be certified, striking a difficult balance between supporting the federal strategy (HITSP was HHS-funded, CCHIT was partially HHS-funded) and yet being pragmatic. It would have been difficult to require EHRs to develop too much at once when certification was “all or nothing” and not modular. From working in both CCHIT and HITSP, CCHIT tended to give more weight to considerations such as market adoption and lead times, not just whether a suitable standard existed. I along with Jamie Ferguson were appointed to co -chair the 10-member HITSP-CCHIT joint working group, whose goal was to coordinate the work of HITSP and CCHIT and address how/when to include HITSP specs in certification. But some HITSP-selected standards were still in “trial implementation” with little adoption, and the approval of a standard (HL7, HITSP, or any other) didn’t mean it should be mandatory within a specific timeframe. And there were just so many of them to digest, let alone certify! Some people weren’t pleased, thinking that CCHIT should be a more aggressive “enforcement arm” of HITSP. In the end, we included more of HITSP in 2008 and 2009 certification criteria than ONC did in its 2011 certification criteria, most notably the HL7 2.5.1 Laboratory results with LOINC vocabulary starting in 2007, C32 CCD starting in 2008 (adding RxNorm, UNII, SNOMED CT vocabularies in 2009) and HITSP TP13 (IHE XDS.b – see point #2 below). But we also roadmapped (2-3 years out) most other HITSP specs when we published our 2009 criteria. I believe this was a sensible middle of the road approach. IMHO, if we had mandated many more HITSP specs in certification, there would be few or zero certified products today!
2. Should certification require transport standards? Fourth & Ten – we’d better punt! Seriously, we debated this during 2008 and 2009. We recognized this as a glaring gap in interoperability, and wanted to make headway, realizing that lack of secure transport standards would hinder interoperability even if content were standardized. The Direct Project didn’t exist back then. We were aware of diverse ways that HL7 messages were transported, that IHE had defined SOAP-based web services for document transport, and that HITSP had selected many IHE specifications. Many vendors had already tested IHE Cross-Enterprise Document Sharing (XDS.b) at Connectathon. So the IOWG approved XDS.b as 2009 certification criteria (along with PIX/PDQ to support it). But the Board of Commissioners decided to designate these as optional interoperability criteria, not required for certification, because despite the IOWG’s recommendation and strong EHRA support, some commented against it. This was the one case I can recall where my workgroup’s recommendation was overridden by the Board, which I know was a tough decision since the Board usually didn’t do that. This was also a case where we were less aggressive in CCHIT than the EHR Association had proposed. EHRA had sometimes criticized CCHIT for not providing enough lead time, but in this case they were very disappointed that CCHIT had not required this in certification. This one still bothers me as a missed opportunity.
3. Should we require discrete data import, and who owns that decision anyway? We felt that the main point of requiring standardized content formats and vocabularies, not just human readability/liquidity, was for the discrete data to be consumable. Following our “methodical march” mentioned in part 2, we thought in 2008 that the time had come to propose discrete data import (e.g., update your medication, allergy, or problem lists using data from other providers). But now we were into a “boundary condition.” Where did interoperability’s “turf” end and functionality begin? We had a series of “discrete data import” meetings between the IOWG and the Ambulatory and Inpatient Functionality workgroups. We recognized that data must not only be exchanged, it needs to be reconciled (medication reconciliation being an example), and that you can’t just “slam in” all meds, allergies, problems from many external sources to automatically update the active med/allergy/problem list. The functionality workgroups didn’t think the time was right to require such capability in certification for 2009 or 2010. But how were we going to keep making progress toward semantic interoperability? In the end, we proposed criteria to import very specific discrete data elements for medications, allergies, demographics, and immunizations (with problems to come later), as described in my last post. But we didn’t define the functionality, as long as the discrete data were stored somewhere. And in any case, reconciliation criteria would belong to the functionality workgroups, not the IOWG. I think this would have been a reasonable “baby step” but because of the change in certification that started in 2009, those roadmap criteria never had the chance to be certified. I hope that similar careful thought will go into decisions in ONC certification, whenever it gets to that point. End-to-end interoperability involves content creation, secure standardized transport, and content consumption, all of which should be considered holistically.
4. Should we push the industry toward a single standard for clinical problems? This was really part of the broader topic of converging on a singular standard vocabulary for each type of data, but SNOMED CT for problems was the lightning rod topic for several reasons: a) the difficulties of getting physicians to create medical problem lists at all; b) ICD-9 diagnosis codes were already required for reimbursement and some physicians systems were built around ICD-9; c) ICD-10 was already complicating things by looming on the horizon; d) anything that imposed more work on physicians could hinder usability and adoption. So though SNOMED CT seemed a clear winner for an interoperable clinical vocabulary and was HITSP-endorsed, we received considerable pushback from some members of the other workgroups as to how fast SNOMED CT could be required. I was pleased that many in the IOWG stepped up to provide statistics and research facts such as analysis of mapping of ICD-9 to SNOMED CT and clarification that standard codes don’t have to be visible in the clinician’s UI. We knew this was a contentious issue, but staked out our positions in the 2009 roadmap and a Q&A document.

The above four were prototypical of the controversies we faced in content, vocabulary, and transport. I could go on with more examples. That’s part of the challenge of interoperability work, as evidenced by the fact that ONC and the HIT Standards Committee still have all of the above issues to ponder for Stages 2 and beyond. I should mention that one more big controversy arose in the very first year, when CCHIT was newly formed and struggling to figure out how to set the interoperability bar. Eyes were upon those first members to resolve the CDA vs. CCR debate. Unlike the four issues above, where we took a stand, we weren’t ready to force a decision in 2006, and then HITSP was formed by ONC to deal with such “standards harmonization” issues. So at least our punt had a receiver (and football wasn’t locked out)!

I promise that Part 4 will really conclude this series with my thoughts on Lessons Learned, proudest accomplishments, regrets, and hopes for the future, stemming from my CCHIT experience. Thanks for listening to my sharing from “inside the trenches” of discussions of which the public was not aware.

Certification Retrospective Part 2 – Method to our Madness?

Note: this blog post will continue discussing my experiences in CCHIT. The opinions are mine, and do not necessarily reflect the views of CCHIT or Siemens.

In Part 1, I talked about CCHIT giving me the privilege to work with great people over the years. But we didn’t volunteer for CCHIT just to meet people, but to do important work to advance the HIT industry. So what did we accomplish, and what were we thinking as we evolved?

One thing I learned is that no group can please all the people all the time. Sometimes, people wondered why we proposed some criteria and not others, or proposed the timeframes that we did. So we tried to explain these “whys” in a white paper Interoperability, Supplying the Building Blocks for a Patient-centered EHR in mid-2009 which still exists on the website of writer John Morrissey. It described the context for what we were doing and the “methodical march” to increasing levels of information interoperability that we proposed. I don’t think this was well understood by the public, who might have thought some of what we did was arbitrary. But here’s what was in our mind (well, I can only speak for myself – mine at least).

Key principles:

• We aren’t starting with a blank sheet of paper. The existing state of adoption (immature as it might be) must be considered, so we started each year with an “environmental scan” on the state of the HIT industry.
• Adequate time must be provided for EHR products to make the transition to a more desirable state. We aimed for 18 months lead time from our first “signal to the market” (new draft criteria) until certification testing of those criteria.

Given these principles, our methodical march followed the path below.

• Data Capture precedes interoperability. You can’t share what you don’t have! When we started CCHIT, not all EHRs even captured all the data that other systems would want, so functionality criteria (ambulatory, inpatient, ED) needed to capture the data elements that could then be shared. Thus in the first certification year, 2006, there were no interoperability criteria required (though several criteria, such as Lab Results and e-prescribing, were roadmapped for later years).
• Information Liquidity (a term we didn’t use, but which implicit in our criteria) is beneficial even prior to semantic interoperability. Thus, the first clinical summaries that CCHIT certified (Continuity of Care Documents, CCDs) in 2008 required human-readable sections for meds, allergies, problems, etc., but not structured data. We were later criticized for this, as if we didn’t care about structured data, but this was always intended as a stepping stone to later stages (as explained in the white paper). Even today (3 years later than the 2008 criteria), many voices espouse liquidity as a more important and realistic for the near-term than semantic interoperability (“don’t let the perfect be the enemy of the good”).  
• Standardized Content (formats and vocabulary). Human-readability is fine for humans, but doesn’t help most EHR systems to “understand” (semantics) and process the information they receive from others. Because of the existing Tower of Babel syndrome most EHRs have been “confounded” in their ability to share information with other EHRs, and to “consume” (not just display) it. So CCHIT supported the goals of ONC and HITSP to progress toward standardization of vocabularies. But it realized that changing an EHR’s vocabulary overnight wasn’t realistic, and that mapping from one vocabulary to another is not simple or foolproof and must be done carefully for patient safety and other reasons. Thus a “glide path” from narrative to standard vocabularies was roadmapped.
• Discrete Data Import (Consumption). When liquidity and standardized content are established, the EHRs that receive or retrieve clinical data can “do something” with the data, more than just file and display it. As early as 2007 criteria, we published certification criteria for ambulatory EHR discrete import of Laboratory Results that referenced the HITSP-endorsed HL7 2.5.1 Lab Results Reporting Implementation Guide, including a common subset of LOINC observation codes. Thus, many of us were disappointed when the ONC Final Rule for certification, published in 2010, lacked a specific HL7 standard and LOINC requirement, not going as far as what CCHIT had been certifying since 2007. There are 127 CCHIT Certified® ambulatory EHRs that already meet this requirement. For CCDs, the challenge of discrete data import is  greater because of the wider variety of data, and multiple applicable vocabularies. Rather than declaring the problem too big to tackle in one shot, we proposed chipping away a few sections at a time, starting in 2010 with discrete import of medications (using RxNorm as specified by HITSP), allergies (using RxNorm and UNII), Immunizations (using CVX) and demographics, then moving on to problems (using SNOMED-CT). These criteria are a matter of public record, and can be found on the CCHIT website: 2008 criteria. See 2008 Criterion IO-AM 11.06 for example, which originally roadmapped discrete data import for 2009, though the date changed to 2010 in the 2009 criteria (published but then withdrawn)***. You can decide based on the facts whether we were too aggressive, or too laggardly, or about right.

So what’s the point of this retrospective? I’ll sum up lessons learned in the next post. I’ll also speak more about how CCHIT’s interoperability criteria compared to ONC’s criteria.

I’ll also discuss some of the agonizing controversies that we faced, particularly in 2008 and 2009 over issues like standardized transport, discrete data import, data reconciliation turf (is it interoperability or functionality or both?) and the feasibility of requiring SNOMED-CT. We wrestled with each of these, and did our best. We might not have succeeded perfectly in all of them, and our criteria development work was superseded by ONC before we could resolve them all, but we learned much in the methodical march!

David

*** (Long Footnote)

The 2009 Ambulatory Certification criteria, along with the CCHIT 2009 certification program, were not launched, since they were in limbo awaiting decisions on ONC-ATCB certification. But eventually most of these criteria (without the roadmap) were relabeled and launched as the 2011 CCHIT Certified® ambulatory criteria. If the 2009 program had proceeded, Criterion IO-AM 11.06 would have required the following in 2010, adding much specificity beyond what had been proposed in the same criterion in 2008:

The system shall provide the ability to display CCD documents, using a subset of the HITSP C32 specification for the Medication and Immunization History module, file them as intact documents in the EHR, and import the discrete data from one or more of the entries in a structured form into the patient record. The system shall provide the ability to import as discrete data the following data elements from the C32 Medications Module: Free text SIG, free text product name, free text brand name, coded product name, coded brand name, product concentration, status of medication, quantity ordered, order date/time, order expiration date/time, prescription number, quantity dispensed, and fill number. (Note: fill number means the number of fills dispensed, not the number of fills prescribed). The “required if known” (R2) data elements will not always be known, and therefore will not be present in every instance of a C32 document, but if present, the system shall be able to import them

More was explained in the Comments column:

Medication and Immunization History-Coded Subset includes the following content modules of the HITSP C32: Person Information, Healthcare Provider, Medications-Prescriptions and Non-Prescription, Information Source, Comments

The intent for 10 Certification is not to require specific capability to use the imported data but only to show the system is capable of processing discrete data elements from a CCD. In future certification years, more functionality criteria to “use” the data may be added. Fulfillment of the 10 Certification criteria may be demonstrated in a variety of ways, including but not limited to any one of the following:

- Reconciliation functionality that allows CCD data to be compared with existing data, and selectively imported into a list

- A display of data captured from external sources, including the imported discrete data. The physical storage location (database table, file, etc.) is at the vendor’s discretion and does not need to be the same location as the active allergies.

- Creation of an CCD that includes the elements previously imported as discrete data

Vendors may innovate and differentiate their products by how well such data are used, but 10 Certification will not limit vendors to any particular approach

“Quickening” the Flow of Health Information – Part Two

Sometimes you just have to be quick. And I wasn’t, so Part Two is later than I planned. Here are some more analogies between Quicken (which I use for my “Electronic Financial Record”) and an Electronic Health Record inasmuch as both require information exchange. Of course, “money” and a relatively small data set are exchanged in financial transactions, rather than the vast array of health information. So with that caveat, here I go.

• Making payments is analogous to Direct Project “push” messages. I enter payments that are pushed to payees in a format that they can accept (some electronic, some paper checks). I can enter these payees’ addresses or have Quicken look some up in a directory. My interaction is simple, but Quicken and the financial network (like a healthcare HISP) securely route the transaction behind the scenes.
• Quicken updates my register pulling relevant data from my bank. To me, the bank is analogous to a Healthcare Information Exchange in that it received and aggregated transactions from many payees, so I don’t have to connect to all the payees. I can download from the bank as needed. Of course, the bank has security and privacy protections for my data, similar to how health data must be protected.
• Balancing my register, which occurs automatically, is comparable to data reconciliation in an EHR (though it is much much simpler for money than for health data!)
• I can set up automatic actions such as reminders and payments, which is analogous to workflow automation features in healthcare, where events (like signing a letter or discharging a patient) can trigger data to be transmitted to others.
• Quicken interfaces to tax preparation software such as Turbo Tax, which then files taxes with the IRS and state. This is analogous to healthcare transmissions to public health and quality reporting agencies.

The bottom line is that I use Quicken because it saves time and money and helps me do things that would be hard to do on my own. Just avoiding the late fee on one credit card bill pays for the software investment. I’ll surmise that healthcare providers would insist on those kinds of benefits and more. If a provider can have an EHR that can do more than just the electronic equivalent of FAX -- like quickly match and autofile incoming messages to the right patient, help reconcile the data, notify the user that new information is available, provide clinical decision support, improve efficiency  – that EHR would ultimately pay for itself with or without incentives. All of us who work on EHRs need to keep that in mind: if my professional livelihood depended on using this EHR, would I use it? Personal Health Records (PHRs) are an even closer analogy to Quicken, and I believe that they too need interoperability and Quicken-like value to deliver on their potential (rather than being something that most consumers don’t have time for).

Interestingly, Dr. Clem McDonald (an HIT pioneer) recently  wrote a similar analogy, that ideally healthcare data import ought to be as easy as importing bank statements to Quicken, in his commentary Clinical Decision Support and Rich Clinical Repositories in the Archives of Internal Medicine (sorry, the link used to be public but now requires membership).

To wrap up… securely pushing information, as simply as e-mail, is good progress. Liquidity of information, whether health or financial, enables value to be realized when software acts upon it. Financial software has progressed far beyond just moving information. Healthcare isn’t nearly as far, but it’s advancing and more options are becoming available. Not all EHRs are right for everyone, but I believe that they’re on the road to being as if they were “healthcare Quickens.”

"Quickening" the Flow of Health Information -- Part 1

Yesterday was a big day for The Direct Project, which I’ve been pleased to be able to participate in. Kudos to those who have started demonstrating successful “pushing” of communication of clinical information across providers! As pointed out by many speakers, it’s great to see collaboration for the common good among many organizations that are competitors in the marketplace. There’s a quickening momentum as the trickle of information exchange grows to become a flood.

As ONC's Dr. Blumenthal aptly said, The Direct Project is “a lane in the information highway.” What he didn’t say was “but it’s not the cars, passengers, or cargo being transported down the highway.” That’s an important distinction that not everyone may realize, since the pilots really showcase much work that is outside the scope of Direct, such as “integrating patient data across provider settings and during transitions of care” as one pilot announcement said. Direct was used to transmit the data, but didn’t integrate it, because it’s the highway, not the cars or the place that the car is going to. It’s secure transport, not data content nor use of the content.

One beauty of Direct is that it is unbiased, neutral, toward the content it is transporting. It uses established standards to securely deliver any content to the right place so that only the intended recipient can read it (it’s an honest mailman who doesn’t read your mail). But the content had to exist in electronic form before Direct can encrypt and send it. The data could have come from EHR, or a scanner, or a person typing an e-mail message, but someone or something created it first, and someone else (not Direct itself) does something useful with it on the receiving end.

To the extent that something wonderful is done with the data that’s being sent securely through Direct, that’s done by innovative and usable applications of one sort or another, and while Direct didn’t make those applications, it sends them something to work with. Applications analogous to Quicken. Why do I say that? Well, I’ve often heard the healthcare industry unfavorably compared to other industries like banking, where everyone lauds the benefits of their interoperability through ATMs and the ability of banks to download data into personal financial software like Intuit's Quicken (which I’ve used for years). I'm sometimes skeptical of such comparisons because health data is so different than money. Nevertheless, there are some very useful parallels.

If my connection to the bank securely delivered images of paper bank statements as PDF files, and images of checks, it would have some value by saving postage, trees, drawer space, and a little time. But no one would be satisfied with only those benefits today. My account data is not just delivered as images of checks or my old monthly paper statements; it’s delivered in a discrete “consumable” form that I can use to write checks, transfer money, set up automatic payments, manage a budget, analyze my expenses, search, import into tax software – all while my ledger is automatically kept up to date and saves me from having to do the dreaded “reconcile the checkbook” chore that I thankfully abandoned long ago. The semantic standards are pretty basic compared to healthcare – we agree on dollars and cents and dates and times, not so much on the payees (I realize I’m oversimplifying).

So my message to end today’s post, which I’ll follow up with part 2 in another day or so, is that the flow of health information is quickening, and I’m happy that the Direct Project is playing an important role in doing that. But it’s health IT's Quicken counterpart at the other end that makes it really useful. I believe that to get the most value out of secure health transport, we need to increasingly send content that is human-readable but also appropriately structured and consumable at the receiving end. Deciding what that content should be is work for other projects ahead. Whatever it turns out to be, the Direct Project will help push it quickly where it needs to go.

"All the World's a Stage"...Two

”All the world's a stage,

And all the men and women merely players:

They have their exits and their entrances;

And one man in his time plays many parts,

His acts being seven ages…”

[As You Like It, William Shakespeare]

Oh no, as if music analogies weren’t enough, now I’m quoting Shakespeare? Actually, I’ll confess that I’ve never read As You Like It but I thought of these lines in the context of Healthcare IT and Meaningful Use (MU) Stages. The monologue quoted above goes on to list seven “ages” (which we would call “stages”) of life: infancy, childhood, the lover, the soldier, the justice, old age, dementia/death. I think HIT has gotten beyond infancy, probably into “childhood” and wants to grow more mature with each Stage (stopping well before dementia and death, of course).

The eyes of the HIT world are watching the “players” from the HIT Policy Committee, who are proposing Stage 2 MU which will start in FY2013. When it’s defined, will it be “as we like it” and will we believe it is taking us on the right path? What’s the vision and strategy to which Stage Two is a stepping stone?

Most of us indeed play many parts (roles). For instance, with respect to HIT, I ‘m a public citizen commenting on regulations, standards developer, interoperability champion, product developer, PHR user, patient, and caregiver. The dedicated people on the HIT PC also play many parts  simultaneously, which may include clinician, developer, researcher, business executive, standards developer, and of course policy maker and patient.

Before submitting detailed comments, I want to share some themes and associated issues that I gleaned from my initial reading of the 19-page HIT Policy Committee Meaningful Use workgroup’s Stage 2 recommendations.

• There’s more recognition of the need for evidence to support objectives. A little over three pages of references are given, though I wish that there were more explicit connections between each objective and the citations. Consider that regulations that affect thousands of providers, hundreds of vendors, and millions of patients have high stakes. So it’s reasonable to expect evidence not only of benefits but of associated costs including impacts upon workflows. The public comment period will undoubtedly cause more evidence to surface (and I encourage everyone who comments to include evidence as to why you agree or disagree, not just assertions or emotions).
• There’s a broader view of the clinical team. I see progress towards a balanced perspective with the focus on medication administration, assessments, longitudinal care plan, and care team members, though there’s a lot of room for interpretation as to what the last two mean. There’s also more clarity of clinical/discharge instructions in Stage 2. It’s good to see the acknowledgement of other professionals such as nurses, pharmacists, and therapists, in addition to physicians.
• Patients are increasingly considered part of the team. I’m all for “engaged” patients and consider myself one. The most challenging Stage 2 objective for patient engagement may be the patient download-upon-demand feature for all EHRs. What do patients want out of the data and how does it improve their health? I’d like to see this addressed in the Evidence Base/Rationale section.
• More and more information will be exchanged. That’s no surprise, and can be a good thing for patients and providers, if…it’s usable and relevant, as I wrote in my three part December series starting with Information Liquidity. As stated by Dr. Lyle Berkowitz who gave testimony to the HIT Standards Committee: “Data sharing alone is never enough. Dr. Reid Coleman from Lifespan had the quote of the day when he said,   ‘Data is like salt water… you need a filter to drink it’. I’d also add that it helps to have good plumbing to connect it to the right facilities, and then also to have plenty of glasses available to make it easy for people to get it to the ‘final foot.’”

The Policy Committee has a tough tightrope to walk – on the one hand they’d like to wait for more early returns, evidence of how the industry is doing adopting Stage 1; they could then incorporate those experiences before finalizing Stage 2. On the other hand, they have heard that everyone need lots of lead time to work Stage 2 into their roadmaps, and needs its requirements finalized “yesterday” or at least 18 months beforehand. So they’re trying to send a “signal to the market” but they can’t guarantee that the signal won’t change. They’ll probably receive hundreds of comments. Interesting times lie ahead!

Finale: Drinking Safely and Healthily from Liquid Information

Happy New Year! If you must drink, do it responsibly and safely. Which brings us to the subject of this Finale to a blog series that started here. How can Health IT systems help clinicians to consume/drink the liquid information that will increasingly flow to them? How can these systems help users protect both patient safety and clinician productivity?

The faucet has been opened. It’s fairly easy to tell developers to send clinical information to others. It’s harder to know what to tell providers to do with what they receive. The trickle of information exchange hasn’t become a flood yet, but let’s be prepared! Clinicians want the information to be usable, not a hindrance. They want to do the right thing, but they can’t afford to reduce their capacity to see patients, and they don’t want to be liable for negligence if they can’t read every word of every available electronic record for the patient. Policies and guidelines for realistic expectations and duties of clinicians to retrieve and read electronic information would be very helpful coming from medical, legal, and health information management professional associations.

Patient safety is impacted both if there’s inadequate information flow but also if there’s too much. We’ve heard of “alert fatigue” in clinical systems, and could face “information overload fatigue” too, where important information is obscured by “noise” that could lead to errors or duplication as occur in the absence of information flow. While the PCAST report on health information technology proposes applying search technology (good idea), that may be helpful but insufficient. I can “Google” anything, but how often do you or I look beyond the first page of results, even when there are thousands of hits? I implicitly rely upon the search engine to display the most relevant links first, since my time is limited. While a patient’s medical records are much less voluminous than data in web searches, even dealing with only 24 clinical documents per my personal health example requires indicators of relevance to aid decision making. If I don’t look at Google search results page 2, it’s probably not a big deal, but the stakes are much higher for patient care: who can decide what’s most important to show for a clinical encounter, especially since that varies depending on the encounter’s purpose?

Thankfully, healthcare and academic organizations realize the need to tackle this challenge. I was fascinated by the findings from this medication reconciliation project at Partners Healthcare: “design of a novel application and the associated services that aggregate medication data from EMR and CPOE systems so that clinicians can efficiently generate an accurate pre-admission medication list.” It was pioneering work at the time, and was a springboard for further research, such as refined aggregation algorithms based on more standardized data, and clinician-vetted UI techniques to reduce cognitive burden and add value.

In 2008 when I helped interoperability and ambulatory workgroups (including physicians, nurses, pharmacists, engineers, and others) write the CCHIT certification criteria and roadmap through 2011, we proposed 2009 as a first step in consumption of discrete data such as medications and allergies from C32 CCDs, but concluded that we shouldn’t be prescriptive about EHR functionality or workflow to handle such data.

Medications are just one example of data that needs to be reconciled after being exchanged. A new clinical data Reconciliation project at IHE offers promise to advance the cause of clinical decision support for reconciling problems, allergies, medications, and more. It’s humbling to acknowledge that HIT isn’t so sophisticated or trusted to make clinical decisions, any more than web search can buy your next car automatically. Instead, we should share the results of research to inform and stimulate innovations that are then tested in multiple care settings, before even thinking about regulating and standardizing functionality. But I’m all for specifying how standardized information exchanges can be inputs to these innovative algorithms and UIs.

To return to my musical analogy, music isn’t just playing the notes in a score: but rather how the score is brought to life to touch the heart through the genius of great performers. We shouldn’t try to turn musicians into robots where every nuance is pre-programmed. Similarly, in HIT MUsic, there’s room for the art as well as the science!

If anyone reading this can point to interesting research and experiences regarding consuming health information that’s exchanged, I’d love to hear about them. The results would benefit providers and developers EHRs and HIEs as well.

Andante: What Happens When the Trickle Becomes a Flood?

This is the second part of a “Symphony in Three Movements” blog. The second movement of a symphony is often the slow movement: Andante literally means “a moderately slow tempo (a walking pace).” The first movement (information liquidity) is Allegro (fast, lively) because there’s a national momentum around Meaningful Use (MU). But using/consuming/”drinking” the information has moved slowly for reasons that I’ll discuss now.

All of us have experienced information overload (too much paper mail, e-mail, so many web sites and so little time). Many messages compete for our attention and go unread. So when we advocate health information liquidity, and it comes, we need to be careful what we wish for!

As a patient, father and grandfather, I want clinicians to be helped, not burdened, by availability of my family’s information. So I’d like to know: what do they consider helpful? To starting think through this question, let’s consider a real world scenario rather than abstractions: myself as a patient (I consent to this disclosure of my health information).

Over the past year, as a relatively healthy person who took four sick days from work, I had the following medical encounters:

• one ER visit followed by an additional day of hospital care for a “transient global amnesia” attack, which hopefully won’t recur
• Two PCP visits: one routine annual physical, plus one following up the hospitalization
• One Neurologist office visit following up the hospitalization
• Two dermatology visits with minor procedures performed
• One GI visit, related to a procedure performed in 2008
• I also had dental and chiropractic visits

That’s 7 medical visits. The hospital has an EHR, and my PCP is starting to use one, but I don’t know about the others. Let’s hypothesize that they all are meaningful users of EHRs. Then they would have produced at least 16 electronic clinical documents: 7 clinical summaries and one discharge summary for the next provider, 7 electronic copies of health information and one discharge instructions document for me. I’m not counting other MU information exchanges such as e-prescriptions, immunization registry updates (one flu shot), nor reportable labs or surveillance. Here I’ll just focus on the clinical documents, realizing that much more information can also be exchanged (results for lab, EEG, EKG, CT, Echo; consult notes, etc.). If 2011 and 2012 are like 2010, then by 2013 I’d have 24 or more electronic clinical documents available to other providers. People with serious or chronic illnesses could have far more. So what should my providers in 2013 look at? All 24 documents? How would they decide what’s important and relevant? Most of these documents will be partly duplicative but may not list exactly the same problems, procedures, allergies, etc. To what extent does this additional information (and the effort to digest it) save time or work elsewhere? As far as I know, these aren’t simple questions with simple answers, but I’d be interested in your thoughts.

At a minimum in 2013 I’d expect the hospital to send (push) electronically a discharge summary and/or a CCD to my PCP and the Neurologist, who will then read them. The Direct Project has received a lot of attention because it has clear applicability to common scenarios like discharges, referrals, and consults. But that’s a drop in the bucket compared to all patient’s electronic health information, so there remains a big challenge about what to do with the rest of it.

As reported in the recent PCAST report, p.15, lack of liquidity and interoperability produces this problem: “In effect, the patient has fragmented into disconnected facts and clusters of symptoms. To prevent the most basic medical errors, some facts are elicited over and over again, to the frustration of patients and healthcare providers alike: ‘Do you have any drug allergies? Have you had any surgeries? Are you taking aspirin or blood thinners?’ This frustrating repetition works, albeit inefficiently, if the patient is cognitively intact and well informed, but not all patients fit that description, especially in the event of a serious or acute illness. Health providers need views of the patient that are less fragmented than at present.” And so along comes information liquidity to remedy the fragmentation – or does it? PCAST report p. 23 says: "A first point to convey is that in virtually all of our use cases, the “user” of the data does not need to be, and indeed should not be, scanning through the entire health record. Instead, the user needs to be looking at an application layer that accesses and presents a limited amount of information from a given health record or set of records."

That “application layer” has slowly been emerging in pockets of HIT, perhaps because the information exchange is still a trickle, not a flood yet. Do clinicians trust a layer to limit the information they see? What’s the right balance between too much and too little? Though I’m a standards advocate, I’m not sure we’re ready for standards in this area, but we do need research, innovation, real-world implementation testing, evidence of what works and what doesn’t, sharing of experiences, policies, and guidance. In my third and final movement of this series, I’ll talk about some promising research and projects underway to improve the usability and benefits of the information that flows. Despite what I said about the challenges, I’m optimistic that we (collectively) will figure this out.

In the meantime, while you await the finale of this symphony, Happy Holidays and Merry Christmas to you!

Opening the "Information Liquidity" Faucet

This starts a mini-series blog, a “Symphony in Two or Three movements.” Movement 1 will discuss what is happening as the information starts to flow “liquidly” as it should, among providers and patients and public health in the healthcare system. Movement 2 will discuss what I think providers will need to avoid drowning when the liquid turns into a flood.

There are now government incentives to exchange information, due to the ARRA HITECH legislation as well as the emergence of accountable care organizations (ACOs). Some advocate high degrees of structured data and vocabularies from the outset. Others say that the most important thing is first to achieve “health information liquidity” – simply get the information to flow freely without much standardization of content – and later to evolve towards higher degrees of interoperability and structure. Right now as I type these words, ONC Chief Technology Officer Todd Park is espousing health data liquidity on ONC’s webcast! CMS will open the incentive money faucet, as providers open their EHRs’ faucets to exchange information.

Up till now, providers receive some health information through manual methods such as patients carrying their paper records or images on CD, or referring providers sending paper mail or FAX. But most of it isn’t in electronic format that they can use in their EHR. And most providers have little or no opportunity to “find” information on their patients if it’s not delivered to them. The bad news is that they’re missing a holistic view of the patient and may waste time searching or repeating questions or tests. The “good news” (not really good) is that they probably aren’t overwhelmed by, nor obligated to discover, all the patient’s previous records.

But now the faucet is opening and the “liquid” is starting to flow. In order for the data to be understood at both ends of an exchange, standards are needed. Many have already been defined and just need to be adopted. ONC has recognized standards in data format (e.g., CCD or CCR format for patient summaries, and HL7 2.5.1 lab result messages for public health) and clinical vocabularies. Partners Healthcare has done encouraging work testing the adequacy of standards (e.g., CCD, RxNorm) to communicate structured codified medication lists among different systems. ONC didn’t select standards for physical transport of the data, but has now recognized the need there, so they’re sponsoring the Direct Project for simple push of data among known recipients (e.g., referrals and discharges) using a secure e-mail protocol (SMTP with S/MIME). Its goal is to be simple, ubiquitous, and accepted as e-mail is today, and a step above current manual methods. But the Direct Project Overview explains how Direct doesn’t to handle every scenario, such as “pulling” data for an emergency visit. There are already standard specifications for patient lookup and record locator services (e.g., IHE PIX and XDS) when querying a Health Information Exchange registry and repository. The ONC-sponsored Nationwide Health Information Network Exchange and Connect projects also leverage IHE. While the Direct Project and IHE both use established standards, there’s still much room to grow in their adoption in the healthcare domain.

Let’s assume that over the next two years that Direct and IHE both thrive: then what will people do with the information that flows to them? As I speak with clinicians, very few care about the formats and transport protocols, but they want the right information at the right time to help them make better decisions to help their patients. They have to use, to consume (or “drink” to preserve the liquid analogy) what they receive. But as the saying goes, “be careful what you wish for.” Who wants to drink from a fire hose? What happens when the electronic information arriving at the clinician’s fingertips, or available through an HIE, is no longer a trickle but becomes a flood? Ah, rather than ending up with a “drinking problem” I prefer to see it as an opportunity for innovation.  More about that in Movement 2 of this blog post.