Single Source of Truth

The Consolidated CDA implementation guide defines nine different types of commonly used CDA documents, including:

• Continuity of Care Document
• Consultation Notes
• Discharge Summary
• Imaging Integration, and DICOM Diagnostic Imaging Reports
• History and Physical
• Operative Note
• Progress Note
• Procedure Note
• Unstructured Documents

Each of these nine documents has a document template defined in The Consolidated CDA implementation guide, which will now be the single source of truth for implementing these CDA documents.

___

Dr. Farzad Mostashari / National Coordinator for Health Information Technology

Meaningful Use Stage 2 and Health Information Exchange Highlights

Common Standards and Implementation Specifications for Electronic Exchange of Information: The Meaningful Use Stage 2 final rules define a common dataset for all summary of care records, including an impressive array of structured and coded data to be formatted uniformly and sent securely during transitions of care, upon discharge, and to be shared with the patient themselves. These include:

• Patient name and demographic information including preferred language (ISO 639-2 alpha-3), sex, race/ethnicity (OMB Ethnicity) and date of birth
• Vital signs including height, weight, blood pressure, and smoking status (SNOMED CT)
• Encounter diagnosis (SNOMED CT or ICD-10-CM)
• Procedures (SNOMED CT)
• Medications (RxNorm) and medication allergies (RxNorm)
• Laboratory test results (LOINC)
• Immunizations (CVX)
• Functional status including activities of daily living, cognitive and disability status
• Care plan field including goals and instructions
• Care team including primary care provider of record
• Reason for referral and referring provider’s name and office contact information (for providers)
• Discharge instructions (for hospitals)

In addition, there are a host of detailed standards and implementation specifications for a number of other transactions including quality reporting, laboratory results, electronic prescribing, immunizations, cancer registries, and syndromic surveillance (see below for a detailed list).

What does this mean? It means that we are able to break down barriers to the electronic exchange of information and decrease the cost and complexity of building interfaces between different systems while ensuring providers with certified electronic health record (EHR) technology have the tools in place to share, understand, and incorporate critical patient information. It also means that providers can improve workflow and dig deeper into the data. Certified EHR technology must be able to support identity reconciliation—matching the right record to the right person—and will give doctors the tools to reconcile a new document with the information already on file, for instance by incorporating medications and problems identified by another provider into a patient’s record,  thus creating a single source of truth. [emphases mine - BG]

___

"In Information Systems design and theory, as instantiated at the Enterprise Level, Single Source Of Truth (SSOT) refers to the practice of structuring information models and associated schemata such that every data element is stored exactly once (e.g., in no more than a single row of a single table). Any possible linkages to this data element (possibly in other areas of the relational schema or even in distant federated databases) are by reference only. Thus, when any such data element is updated, this update propagates to the enterprise at large, without the possibility of a duplicate value somewhere in the distant enterprise not being updated (because there would be no duplicate values that needed updating)."

"ADT 44"

From an email I found online today, embedded in a RHIO pdf document (it's an HL7 messaging error thing):

ADT A44 (Move account information — patient account number)
The intention of these messages is to move an account number, which may or may not have associated documents, from one patient to another.

These types of messages could result from inadvertently selecting "John Doe SR", as opposed to "John Doe JR", for example. Whereas "John Doe JR" is the correct patient. Once the patient is changed/corrected, the resulting A44 message initiates a move of all the documents associated with this account to the corrected patient ID.

In this example, the correct Patient ID = "John Doe JR", and the Prior Patient ID = "John Doe SR".

Investigation
Historic data analysis for all A44 messages received for CFRHIO:

• Total A44 messages received thru 7/31 = 6,417
• Total "Prior Patient IDs" with associated documents = 368
• FHO = 213
• OH = 155
• Total associated documents accessed = 0

Action Plan
A44 message processing moving forward:

• Short-Term: (Complete) Manually disable the viewing of documents for the "Prior Patient ID" or MRG-1, as specified in the A44 messages.
• Medium-Term: (In Progress) Manually process the account move for all A44 messages, both historic and new inbound.
• Long-Term: (Investigating) Implement non-manual process to properly process new A44 messages.

Thank you for your understanding.

Interesting. Maybe it should have been subjected to the RDBMS equivalent of "rigorability." I'm not at liberty to discuss what specifically brought this issue to my attention, but, it points up the widespread chronic data linkage problem posed by a continuing lack of a unique (no-dupes, no nuls), secure national patient identifier (Like, you know, a HIC number writ large).

NO DUPES, NO NULS, 
AUTHENTICATED PRIMARY KEY IDENTIFIER

What shall be the reliable identifier? to wit, the much unloved SSN:

What happens to the money assigned to people using false identities, or names matched with the wrong Social Security Number (SSN), or newlyweds who forgot to register their name changes with the Social Security administration?

The answer lies in a little-known aspect of the Social Security behemoth known as the Earnings Suspense File (ESF).

A necessarily dynamic probabilistic combination of Last/First/DoB/Gender/SSN?

I worked for a number of years in the Risk Management Department of a credit card bank. Among my duties was ongoing portfolio modeling, management, and fraud monitoring, all which entailed a good bit of data mining, repeatedly running SAS code against millions of customer account records.

Wherein, as I wrote in 2002,

...our department has the endless and difficult task of trying to statistically separate the “goods” from the “bads” using data mining technology and modeling methods such as factor analysis, cluster analysis, general linear and logistic regression, CART analysis (Classification and Regression Tree) and related techniques.

Curiously, our youngest cardholder is 3.7 years of age (notwithstanding that the minimum contractual age is 18), the oldest 147. We have customers ostensibly earning $100,000 per month—odd, given that the median monthly (unverified self-reported) income is approximately $1,700 in our active portfolio.

Yeah. Mistakes. We spend a ton of time trying to clean up such exasperating and seemingly intractable errors. Beyond that, for example, we undertake a new in-house credit score modeling study and immediately find that roughly 4% of the account IDs we send to the credit bureau cannot be merged with their data (via Social Security numbers or name/address/phone links).

I guess we’re supposed to be comfortable with the remaining data because they matched up -- and for the most part look plausible. Notwithstanding that nearly everyone has their pet stories about credit bureau errors that gave them heartburn or worse...

In addition to credit risk modeling, an ongoing portion of my work involves cardholder transaction analysis and fraud detection. Here again the data quality problems are legion, often going beyond the usual keystroke data processing errors that plague all businesses. Individual point-of-sale events are sometimes posted multiple times, given the holes in the various external and internal data processing systems that fail to block exact dupes. Additionally, all customer purchase and cash advance transactions are tagged by the merchant processing vendor with a 4-digit “SIC code” (Standard Industrial Classification) categorizing the type of sale. These are routinely and persistently miscoded, often laughably. A car rental event might come back to us with a SIC code for “3532- Mining Machinery and Equipment”; booze purchases at state-run liquor stores are sometimes tagged “9311- Taxation and Monetary Policy”; a mundane convenience store purchase in the U.K. is seen as “9711- National Security”, and so forth.

Interestingly, we recently underwent training regarding our responsibilities pursuant to the Treasury Department’s FinCEN (Financial Crimes Enforcement Network) SAR program (Suspicious Activity Reports). The trainer made repeated soothing references to our blanket indemnification under this system, noting approvingly that we are not even required to substantiate a “good faith effort” in filing a SAR. In other words, we could file egregiously incorrect information that could cause an innocent customer a lot of grief, and we can’t be sued.

 He accepted uncritically that this was a necessary and good idea.

I spent inordinate episodic FoxPro and SAS coding time (re) "cleaning the data," cross-referencing and correcting thousands of bad entries (Last, First, DOB, Gender, SSN) -- chiefly and most important among them bad "Socials" (the result of the legion input keystroke errors).

Then, we hired this enthusiastic but in some ways hapless H-1B crew to establish an Oracle data warehouse, and they thereupon had the brilliant idea to store SSNs as integers in lieu of character strings. So, were a cardholder Social to have been something like "012-34-5678," you now gotta write logic that will take #12345678 and convert/parse/substring re-concatenate it back to char(11) "012-34-5678" for proper ASCII collation and ease of view.

Now, in those circumstances of crapped-up but unremediated primary keys maybe the worst case upshot (in addition to my recurrent cube rants) would have been someone being denied a credit line increase or APR decrease.

In the case of a HL7 "ADT 44," on the other hand, someone could get the wrong meds dose and die from it.**

Close Only Counts in Horseshoes and Hand Grenades.

** and, yes, to be fair, I know that "Last+First+DoB+Gender+Social" would itself be imperfect (and highly variable; See Latanya Sweeney's work). Maybe someday we'll have Genes+Retinal Scan ID proxies. Maybe. But, we can do way better than the current cludgy "Master Patient Index" databases currently in use.

apropos,
MY LIGHT BEDTIME READING FOR TONIGHT

CMMI® for Development, Version 1.3
CMMI-DEV, V1.3 CMMI Product Team
Improving processes for developing better products and services
November 2010 TECHNICAL REPORT
CMU/SEI-2010-TR-033
ESC-TR-2010-033
Software Engineering Process Management Program
Unlimited distribution subject to the copyright.
http://www.sei.cmu.edu

and

(Amazon Kindle Ed)

Close to another 1,200 pages of reading Now, with respect to the former, my interest has been piqued by this "Agile" thing. The Fad of The Year?

From CMMI V1.3:

All of the notes begin with the words, “In Agile environments” and are in example boxes to help you to easily recognize them and remind you that these notes are examples of how to interpret practices and therefore are neither necessary nor sufficient for implementing the process area.

Multiple Agile approaches exist. The phrases “Agile environment” and “Agile method” are shorthand for any development or management approach that adheres to the Manifesto for Agile Development [Beck 2001].

Such approaches are characterized by the following:

• Direct involvement of the customer in product development
• Use of multiple development iterations to learn about and evolve the product
• Customer willingness to share in the responsibility for decisions and risk

Many development and management approaches can share one or more of these characteristics and yet not be called “Agile.” For example, some teams are arguably “Agile” even though the term Agile is not used. Even if you are not using an Agile approach, you might still find value in these notes. PDF pg 70
___

• In Agile environments, configuration management (CM) is important because of the need to support frequent change, frequent builds (typically daily), multiple baselines, and multiple CM supported workspaces (e.g., for individuals, teams, and even for pair-programming). Agile teams may get bogged down if the organization doesn’t: 1) automate CM (e.g., build scripts, status accounting, integrity checking) and 2) implement CM as a single set of standard services. At its start, an Agile team should identify the individual who will be responsible to ensure CM is implemented correctly. At the start of each iteration, CM support needs are re-confirmed. CM is carefully integrated into the rhythms of each team with a focus on minimizing team distraction to get the job done. PDF pg 151
  
• In Agile environments, product integration is a frequent, often daily, activity. For example, for software, working code is continuously added to the code base in a process called ―continuous integration.‖ In addition to addressing continuous integration, the product integration strategy can address how supplier supplied components will be incorporated, how functionality will be built (in layers vs. ―vertical slices‖), and when to ―refactor.‖ The strategy should be established early in the project and be revised to reflect evolving and emerging component interfaces, external feeds, data exchange, and application program interfaces. PDF pg 270
  
• In Agile environments, the sustained involvement of customer and potential end users in the project’s product development activities can be crucial to project success; thus, customer and end-user involvement in project activities should be monitored. PDF pg 287
  
• For product lines, there are multiple sets of work activities that would benefit from the practices of this process area. These work activities include the creation and maintenance of the core assets, developing products to be built using the core assets, and orchestrating the overall product line effort to support and coordinate the operations of the inter-related work groups and their activities. In Agile environments, performing incremental development involves planning, monitoring, controlling, and re-planning more frequently than in more traditional development environments. While a high-level plan for the overall project or work effort is typically established, teams will estimate, plan, and carry out the actual work an increment or iteration at a time. Teams typically do not forecast beyond what is known about the project or iteration, except for anticipating risks, major events, and large-scale influences and constraints. Estimates reflect iteration and team specific factors that influence the time, effort, resources, and risks to accomplish the iteration. Teams plan, monitor, and adjust plans during each iteration as often as it takes (e.g., daily). Commitments to plans are demonstrated when tasks are assigned and accepted during iteration planning, user stories are elaborated or estimated, and iterations are populated with tasks from a maintained backlog of work. PDF pg 294
  
• In Agile environments, teams tend to focus on immediate needs of the iteration rather than on longer term and broader organizational needs. To ensure that objective evaluations are perceived to have value and are efficient, discuss the following early: (1) how objective evaluations are to be done, (2) which processes and work products will be evaluated, (3) how results of evaluations will be integrated into the team’s rhythms (e.g., as part of daily meetings, checklists, peer reviews, tools, continuous integration, retrospectives). PDF pg 315
  
• In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated. Requirements are documented in forms such as user stories, scenarios, use cases, product backlogs, and the results of iterations (working code in the case of software). Which requirements will be addressed in a given iteration is driven by an assessment of risk and by the priorities associated with what is left on the product backlog. What details of requirements (and other artifacts) to document is driven by the need for coordination (among team members, teams, and later iterations) and the risk of losing what was learned. When the customer is on the team, there can still be a need for separate customer and product documentation to allow multiple solutions to be explored. As the solution emerges, responsibilities for derived requirements are allocated to the appropriate teams. PDF pg 339
  
• In Agile environments, requirements are communicated and tracked through mechanisms such as product backlogs, story cards, and screen mock-ups. Commitments to requirements are either made collectively by the team or an empowered team leader. Work assignments are regularly (e.g., daily, weekly) adjusted based on progress made and as an improved understanding of the requirements and solution emerge. Traceability and consistency across requirements and work products is addressed through the mechanisms already mentioned as well as during start-of-iteration or end-of-iteration activities such as ―retrospectives ‖ and ―demo days. ‖ PDF pg 354
  
• In Agile environments, some risk management activities are inherently embedded in the Agile method used. For example, some technical risks can be addressed by encouraging experimentation (early ―failures ‖) or by executing a ―spike ‖ outside of the routine iteration. However, the Risk Management process area encourages a more systematic approach to managing risks, both technical and non-technical. Such an approach can be integrated into Agile’s typical iteration and meeting rhythms; more specifically, during iteration planning, task estimating, and acceptance of tasks. PDF pg 362
  
• In Agile environments, the focus is on early solution exploration. By making the selection and tradeoff decisions more explicit, the Technical Solution process area helps improve the quality of those decisions, both individually and over time. Solutions can be defined in terms of functions, feature sets, releases, or any other components that facilitate product development. When someone other than the team will be working on the product in the future, release information, maintenance logs, and other data are typically included with the installed product. To support future product updates, rationale (for trade-offs, interfaces, and purchased parts) is captured so that why the product exists can be better understood. If there is low risk in the selected solution, the need to formally capture decisions is significantly reduced. PDF pg 386
  
• In Agile environments, because of customer involvement and frequent releases, verification and validation mutually support each other. For example, a defect can cause a prototype or early release to fail validation prematurely. Conversely, early and continuous validation helps ensure verification is applied to the right product. The Verification and Validation process areas help ensure a systematic approach to selecting the work products to be reviewed and tested, the methods and environments to be used, and the interfaces to be managed, which help ensure that defects are identified and addressed early. The more complex the product, the more systematic the approach needs to be to ensure compatibility among requirements and solutions, and consistency with how the product will be used. PDF pg 414

I have much yet to learn. In particular, a simple explanation of the foregoing graphic as it pertains to an effective methodology for HIT development. Dubiety endures, and suspicion of bamboozlement reeks more broadly.

concern, to wit:

Because the companies using QFD [Quality Function Deployment] are already fairly sophisticated in their approaches to quality control, the apparent success of QFD as a software quality approach may be misleading. 

QFD is a very formal, structured group activity involving clients and product development personnel. QFD is sometimes called “the house of quality” because one of the main kinds of planning matrices resembles the peaked roof of a house. 

In the course of the QFD sessions, the users’ quality criteria are exhaustively enumerated and defined. Then the product’s quality response to those requirements is carefully planned so that all of the quality criteria are implemented or accommodated. 

For the kinds of software where client quality concerns can be enumerated and where developers can meet and have serious discussions about quality, QFD appears to work very well: embedded applications, medical devices, switching systems, manufacturing support systems, fuel-injection software controls, weapons systems, and the like. 

Also, QFD requires development and QA personnel who know a lot about quality and its implications. QFD is not a “quick and dirty” approach that works well using short-cuts and a careless manner. This is why QFD and Agile are cited as being “antagonistic.” 

The QFD software projects that we have examined have significantly lower rates of creeping requirements and also much lower than average volumes of both requirements and design defects than U.S. norms. However, the kinds of software projects that use QFD typically do not have highly volatile requirements.

Jones, Capers; Bonsignour, Olivier (2011-07-19). The Economics of Software Quality (Kindle Locations 3299-3311). Pearson Education (USA). Kindle Edition.

All very interesting.

QFD requires development and QA personnel who know a lot about quality and its implications. QFD is not a “quick and dirty” approach that works well using short-cuts and a careless manner. This is why QFD and Agile are cited as being “antagonistic.” 

UPDATE

Ran across an interesting website and blog post:

Leadership Skills: Building Collaborative Teams

Work teams can be very effective. They can also be a disaster, as anyone with even a passing knowledge of organizational dynamics understands. In today’s world of instant information, many of these impediments to real team performance are being overcome, while new challenges are emerging. New teams must be highly communicative, collaborative, mutually supportive, multitalented, and quick to respond, often without having a complete picture of the “facts.” New teams must be able to act with relative autonomy, demanding higher levels of accountability, unparalleled access to information, and commensurate authority. Team leadership can shift as demands for expertise change, although accountability remains with the titular team leader. The new team leader, therefore, must be both highly talented and politically savvy to survive and thrive as organizations adapt to new models. He or she must either have the stature or authority to withstand great pressure to avoid producing the “same old stuff,” which is tantamount to team failure.

In organizations with traditional structures and loyalties, teams are easily compromised by the often divergent pull from multiple constituencies that provide lip service to team success while providing minimum support or even actively working to sabotage team efforts. Teams that cannot pull themselves loose through the efforts of a strong, grounded leader or who have a patron high up in the organization often are teams in name only...

I forwarded this around our shop. We suffer from having too many "teams," all frequently busily doing "Work About The Work About the Work." A rather common affliction, unfortunately (including ASQ Divisions).

ERRATUM...

OK...
AGILE LEAN SIX SIGMA QFD RAPID-CYCLE PDSA CQI TQM!

One of my long favorite philosophers is the late Alan Watts, who once wryly observed something to the effect that "a problem with Christianity is that people have replaced the religion of Jesus with a religion about Jesus."

"Six Sigma" accords us a couple of lovely metaphors: [1] the boundary within plus or minus six standard deviations around a process average, assuming a perfectly Gaussian ("bell curve") dispersion, and [2] all those cool martial-arts green and black "Belts."

A "religion" "about."

In the software realm, "Agile" ups the allusive ante.

Will this be a hot new business line of professional certifications? Lordy. Agile Grasshoppers to Agile Samurai? And, to further jumble the metaphors, will they be donning rubgy attire for "scrums" and track gear for "sprints"?

Back to Jones and Bonsignour:

The phrase Six Sigma, which originated at Motorola, refers to defect densities of 3.4 “opportunities” for defects per million chances. The approach was originally used for complex manufactured devices such as cell phones but has expanded to scores of manufactured products and software, too. 

The original Six Sigma approach was formal and somewhat expensive to deploy. In recent years subsets and alternatives have been developed such as “lean Six Sigma” and “Six Sigma for software” and “design for Six Sigma.” 

Because the Six Sigma definition is hard to visualize for software, an alternative approach would be to achieve a cumulative defect removal efficiency rate of 99.999999% prior to delivery of a product. This method is not what Motorola uses, but it helps to clarify what would have to be done to achieve Six Sigma results for software projects. 

Given that the current U.S. average for software defect removal efficiency is only about 85%, and quite a few software products are even below 70%, it could be interpreted that software producers have some serious catching up to do. Even top-ranked software projects in the best companies do not go beyond about 98% in cumulative defect removal efficiency.

Jones, Capers; Bonsignour, Olivier. The Economics of Software Quality (Kindle Locations 3381-3384).

"[D]efect densities of 3.4 “opportunities” for defects per million chances." Yeah, as a process average, one assuming a perfectly Gaussian distribution,

which, of course, exists only on college chalkboards and in textbooks (and, of course, on Wall Street -- and, we see where that got them).

Color me presumptively Chebyshev-ista.

"Chance is lumpy." - Abelson's Laws

Consequently, your outer bound is 2.78% defect rate at 6 sigma (percent, not per million) under Chebyshev.

It gets worse when you go all 3+ dimensional. Think about it.

I guess here's the cut-to-the-chase point (in addition to and beyond the Watts analogy): I can pretty quickly convey the essentials of "Lean" to the average assemblage of high school- educated clinic front office staff. Priesthoods of belt-laden QI In-Tongue speakers, well, on the other hand, makes for a nice market in books and webinars.
___

REMINDER

Money on the table.
___

INTERESTING NEWS

Meaningful Use Consulting Firms Booming and Delivering 

Demand for meaningful use (MU) assistance has exploded, increasing competition between third-party consulting firms--most of whom are excelling in MU-related work.

Not one word about RECs.

We just can't get any love these days. In my email inbox this morning:

MORE NEWS

 Which components of health IT will drive financial value?

A framework that describes the ability of specific health information exchange (HIE) and EHR functionalities to drive financial savings could help efforts to develop meaningful use measures and measure the financial impact of health IT, according to research published in the August issue of the American Journal of Managed Care.

“Previous work in this area has largely modeled the financial effect of whole health IT applications, assuming that the effects of those applications were similar across different contexts,” wrote lead researcher Lisa M. Kern, MD, MPH, of Weill Cornell Medical College in New York City, and colleagues. “This assumption may not be true because health IT is an inherently heterogeneous intervention. EHRs and HIE are themselves applications composed of functionalities that are variably implemented, configured and used.”...  

Courtesy of Cardiovascular Business. Full Journal article here.

___

BTW - 

"We support technology enhancements for medical health records and data systems while affirming patient privacy and ownership of health information."

- GOP 2012 Platform. That's it. The only reference to Health IT.
___

AUGUST 31 UPDATE:
YET ANOTHER "HEALTHCARE TRANSFORMATION" INSTITUTE

I got a LinkedIn email heads-up about these people today. Pretty interesting report, actually (in light of what I've perused thus far).

Like a person suffering from a debilitating disease, healthcare delivery in the United States is ailing. The U.S. spends significantly more per capita and a higher percentage of GDP on healthcare than other developed nations, yet our patient outcomes (e.g., mortality, safety, access to medical care) are disparate and inconsistent. Moreover, the rapidly rising costs of healthcare delivery are making medical care increasingly unaffordable to the average citizen and threaten our national financial viability.

How did we get here? Although unhealthy lifestyles and the growing and aging population are undoubtedly contributing to the rise in healthcare costs, two key factors must not be underestimated: a) advances in medical technology and b) powerful system incentives that inadvertently advance unchecked utilization throughout the healthcare delivery system.

So what can we do?

Where do we start? Read some Dr. John Toussaint (e.g., see my August 4th post), along with this report.

Read on.
___

TROUBLEMAKER in the TWITTERVERSE

Details shortly.

SEPT 2nd REC ASS'N AMBER ALERT

 ___

More to come...

Healthcare Lean Transformation Summit 2015, a reflection

If you don't have this book, get it and study it.

Delivering 
better healthcare, 
an introduction

...Every day hundreds or thousands of people come to medical providers with illness and injury only to be mistreated and overcharged. 98% of the time this harm is not the fault of individual caregivers but of our healthcare system in general. Our processes for treating people are so fundamentally broken that mistakes are inevitable.

The debate over whether the nation has a sustainable healthcare system is over. Decades of rising costs and poor quality proved it does not.

The question has been how to address the problems. This is no small query. Not only do we need to mend our disjointed processes for delivering care, we in healthcare need to respond to an array of changing laws, new payment proposals, and quality measures. Those who are not adaptive are about to get run over.

… So many hospitals and health systems are using lean tools that lean healthcare has become a movement of sorts sometimes it is a punchline, unfortunately, because the bad news is that these programs have a fundamental flaw that threatens to derail even the most muscular efforts. In one hospital after another, I see the quest for positive change isolated as a discrete project, divorced from the daily work of managers, separate from the “real” business of the organization. People are stopping at reform when a revolution is required. The result is a vicious cycle of energetic hope followed by failure to create sustainable change…

...I am seeing hope and failure in nearly equal measure teams of clinicians and administrators using lean thinking are making breakthroughs every week as they increase quality and reduce costs. But the essential transformation of the organization is not happening due to some basic misunderstandings about lean in healthcare.

The most common problem I see is that leaders failed to recognize the magnitude of change that will be required and that change extends to the leaders on a personal level. People set out on a lean journey thinking that improvement work will be the job a few staff experts or consultants who will guide some projects. These projects will improve operations; people will learn how to initiate new improvements; and gradually, the theory goes, the organization will become lean. When I see this kind of attempt taking place, it always looks to me like the leaders have simply handed over the keys to the consultants or the improvement staff and expected them to return with something new, high-performing, and sustainable in the place of the old organization. This does not work.

Lean cannot be grafted onto an organization like the limb of a different tree…

So, for the record, lean healthcare is not an improvement program. It is an operating system within a management system that requires a complete.e cultural transformation… The CEO is support staff; his or her job is to identify and remove barriers so that problem solvers, such as inpatient hospitalist physicians and the newest x-ray technicians, can see and solve problems.

Most healthcare organizations could not look more different from the lean model. Management thinking is mostly dissented from how Fred Sloan, the General Motors CEO and dominant force in 20th century business practices in the United States… Sloan philosophies created Management by Objectives.  this common style of leadership creates a situation in which a CEO tells a senior leader, “go out and start a lean initiative. Do what ever it takes. Go fast. We will judge you based on lean's success.”

And that is the beginning of a lean healthcare failure...

At the front line of care, working on teams, I saw that lien would utterly transform our culture if we did this right. Here was an improvement methodology that engaged our front-line people — the same ones who knew the problems he intimately…

…Our leaders should have been learning strategy deployment, visual management, and how to support the model cell. We should have been redesigning the tasks and patterns of our work lives. Instead, we were using old leadership methods and expecting new results...

Now, I know from visiting dozens of hospitals and clinics struggling with the exact same issues that these are symptoms of management by objectives in a lean environment, which simply does not work. Lean demands real, systemwide change by every manager,  starting at the top. Senior leaders cannot delegate a profound cultural shift; they cannot expect others to embrace change while they continue working in the same old command–and–control style, checking the numbers without really understanding how the numbers were or were not achieved…

Now I am ready to say that there is a right way to embark on a lean journey. We…Have discovered a model for a lean transformation networks, and this book describes it through the people who are doing the work. It is a story of many journeys joined together and told through the best practices and fresh ideas found in hospitals and clinics across North America.  The organizations in these pages have not followed precisely the steps I will lay out in this book, but what others and I have learned from their journeys has helped inform this path...

Newly designed processes helped physicians complete all note taking and close patient files while still in the exam room with the patient. Physicians agreed that their documentation was better in this new process, since they did not have to remember the details of many appointments over a busy day…

“Lien has been a tipping point toward cultural integration for us,… we always had a culture focused on service. Now we all know how to make improvements, too. Physicians assistants and nurses — they know how to identify a problem and create an action plan. We are speaking a common language.” (Michael Conroy, MD)...

Values are the highest beliefs and aspirations of the leaders; these are what steer the company… Principles guide behavior, which should always lead toward satisfying the organizations values…

Remember that values should strike at the heart of our humanity. “Becoming lean” is not a value…

Redesign your management system to support the lean transformation….

After personally witnessing a few epic battles between lean change agents and the good people of human resources I recommend that you forge an early partnership with HR…

One of the hallmarks of a lean transformation: support services — HR, finance, IT — shift focus from producing their own inward looking reports to actively supporting the organization’s improvement efforts…

Everyone  in a healthcare organization goes to work every day to save lives, to restore health, to avoid harm…

This is the path [lean] we have discovered for transformation: lay the foundation, building models sell, establish the values and principles that will guide the work, create a central improvement office, redesign the front line management system, and spread the work throughout the system. Then realign the organization’s policies and practices, especially in human resources, finance, and information technology, to support this work there will be barriers and curveballs, such as new payment schemes and medical education system that keeps churning out heroes instead of team players but we will work through those, too.

This pass goes beyond the action plan that I laid out in my 2010 book, On the Mend,  to focus more clearly on management and the entire organization…

Leaders rarely consider changing the interconnected system. Just as a patient’s health is not limited to a heart or kidney alone, it is true that healthcare improvement is not just about new cancer therapies or central line infection reduction projects. Lean healthcare is about creating a biologic organism in balance. Let’s get started.

Indeed. Time's a'wastin'.

There were 5 Keynotes and 18 concurrent Learning Sessions during #HCsummit15. Below, the title slides from those I was able to witness.

The Learning Sessions were all packed with Lean projects outcomes data. I was already a believer, but in the wake of these presentations, I think the positive evidence is pretty overwhelming (though some might raise a "publication bias" objection).

I have to say, I have new respect for the RIE (Rapid Improvement Event) tactical component method sometimes called "Agile" after attending the Salem Health session. I had a bit of skeptical sport with "Agile" and "Six Sigma" a few years back in my post "Single Source of Truth." 

Six Sigma" accords us a couple of lovely metaphors: [1] the boundary within plus or minus six standard deviations around a process average, assuming a perfectly Gaussian ("bell curve") dispersion, and [2] all those cool martial-arts green and black "Belts."...

In the software realm, "Agile" ups the allusive ante.

Will this be a hot new business line of professional certifications? Lordy. Agile Grasshoppers to Agile Samurai? And, to further jumble the metaphors, will they be donning rubgy attire for "scrums" and track gear for "sprints"?

While still always wary of Dilbert Zone fad potential, the folks from Salem taught me something.

I hated to miss out on the other Learning Sessions. I've downloaded all of the presentation slide decks and will study them all closely. The decks alone comprise a ton of material. I have Adobe Acrobat Pro XI, so I combined all of the slide deck PDFs. The result was a 70.4 mb, 557 page master document.

I keyword-searched for "Just Culture," and the only place I found it cited was in Beth Daley Ullem's amazing Keynote address.

The presenters from Salem Health in particular stressed the priority of "people and processes" (in that order) over the "magic boxes" of technology. I could not agree more, notwithstanding that I am nominally a "Health IT" guy.

apropos, consider John Toussaint on page 171 of "Management on the Mend."

I strongly recommend that any organization using lean thinking as an organizing methodology build its principles using the Shingo model.

• Respect every individual;
• Lead with Humility;
• Seek perfection;
• Ensure quality at the source;
• Employ scientific thinking;
• Focus on process;
• Think systematically;
• Create constancy of purpose;
• Achieve transparency through visual management.

[Bullet list breakout mine. A lot of that is Deming 101.]

Bullet points 1-3 in particular are pure "Just Culture." I'll repeat my "Talking Stick" observation of about a year ago.

My recent posts have ruminated on what I see as the underappreciated necessity for focusing on the "psychosocial health" of the healthcare workforce as much as focusing on policy reform (e.g., P4P, ACOs, PCMH), and process QI tactics (e.g., Lean/PDSA, 6 Sigma, Agile), including the clinical QI Health IT-borne "predictive analytics" fruits of ""Evidence Based Medicine" (EBM) and "Comparative Effectiveness Research" (CER). Evidence of psychosocially dysfunctional healthcare organizational cultures is not difficult to find (a bit of a sad irony, actually). From the patient safety-inimical "Bully Culture" down to the "merely" enervating emotionally toxic, I place it squarely within Dr. Toussaint's "8th Waste" (misused talent).

Again, healthcare delivery, particularly in the acute care setting, is an irreducibly, persistently high cognitive burden enterprise. Avoidable interpersonal conflict and stress is inimical to effectiveness, and is at its worst a patient safety issue.

See also my post of June 20th, 2014, "Continuing on the three-legged stool riff: more on "Just Culture," workforce engagement, and leadership in healthcare."

"SEEK" perfection, indeed. But, David Marx reminds us that errors are inevitable notwithstanding our best prophylactic efforts. Reducing their frequency and consequences is contingent on both the way we construct our fault-mitigating systems and the way we react toward others when mistakes occur. Reflexively disrespecting others-- either as a cultural ethos generally or  in the wake of error (e.g., the still far-too prevalent "Shame and Blame" culture) -- is not Shingo, not Lean. "Leading" autocratically and judgmentally is not Shingo, not Lean.

BTW: on the topic of "error," I highly recommend this delightful book.

Elevator speech: We all pretty much think we're right about everything all of the time, and are episodically mortified to be publicly found to be wrong. Assuming we're right about everything is a fundamental source of human conflict, given that those who disagree must be either woefully ignorant, intractably stupid, or evil.

Why is it so fun to be right? As pleasures go, it is, after all, a second-order one at best. Unlike many of life’s other delights—chocolate, surfing, kissing—it does not enjoy any mainline access to our biochemistry: to our appetites, our adrenal glands, our limbic systems, our swoony hearts. And yet, the thrill of being right is undeniable, universal, and (perhaps most oddly) almost entirely undiscriminating. We can’t enjoy kissing just anyone, but we can relish being right about almost anything. The stakes don’t seem to matter much; it’s more important to bet on the right foreign policy than the right racehorse, but we are perfectly capable of gloating over either one. Nor does subject matter; we can be equally pleased about correctly identifing an orange-crowned warbler or the sexual orientation of our coworker. Stranger still, we can enjoy being right even about disagreeable things: the downturn in the stock market, say, or the demise of a friend’s relationship, or the fact that, at our spouse’s insistence, we just spent fifteen minutes schlepping our suitcase in exactly the opposite direction from our hotel. 

Like most pleasurable experiences, rightness is not ours to enjoy all the time. Sometimes we are the one who loses the bet (or the hotel). And sometimes, too, we are plagued by doubt about the correct answer or course of action—an anxiety that, itself, reflects the urgency of our desire to be right. Still, on the whole, our indiscriminate enjoyment of being right is matched by an almost equally indiscriminate feeling that we are right. Occasionally, this feeling spills into the foreground, as when we argue or evangelize, make predictions or place bets. Most often, though, it is just psychological backdrop. A whole lot of us go through life assuming that we are basically right, basically all the time, about basically everything: about our political and intellectual convictions, our religious and moral beliefs, our assessment of other people, our memories, our grasp of facts. As absurd as it sounds when we stop to think about it, our steady state seems to be one of unconsciously assuming that we are very close to omniscient...

What is true of our collective human pursuits is also true of our individual lives. All of us outgrow some of our beliefs. All of us hatch theories in one moment only to find that we must abandon them in the next. Our tricky senses, our limited intellects, our fickle memories, the veil of emotions, the tug of allegiances, the complexity of the world around us: all of this conspires to ensure that we get things wrong again and again. You might never have given a thought to what I’m calling wrongology; you might be the farthest thing in the world from a wrongologist; but, like it or not, you are already a wrongitioner. We all are.

Schulz, Kathryn (2010-05-25). Being Wrong: Adventures in the Margin of Error (pp. 3-4, 9). HarperCollins. Kindle Edition.

"Wrongology," LOL. Gotta love it.

OFF-TOPIC ERRATUM

I would love to just keep writing this morning, but PG&E has notified us that we're fixin' to have a protracted (~ 4-6 hr) neighborhood power outage shortly for some repairs. Swell. gonna be the hottest day of the year here thus far (~102F in my 'hood), and still no rain in sight.
__

PM UPDATE

Power's back on. Good thing; feels like Vegas outside today.

How about an excerpt from Chapter 10 of Management on the Mend?

Barriers to the work

Barriers are like enemies. We need to know them — what they look like and where they hide — in order to successfully navigate the trouble they cause. And some of the barriers are hidden behind pretty good camouflage.

Numerous obstacles to a lean transformation come from within an organization, many of which have been described in previous chapters. But the most difficult barriers may be lurking outside of healthcare. The three biggest barriers are medical education programs that churn out heroic individuals instead of team players, the lack of publicly available outcomes data for quality and cost, and perverse payment incentives. To be fair, most of these barriers are in direct response to the way doctors traditionally practiced medicine.

Physicians said that doctors should be solely in control of patient care and the doctors know best. Medical schools have been churning out autocratic, heroically minded positions ever since. Physicians have not collected data on patient outcomes and have entered contracts with insurers to keep secret all Payment information. So the public is largely blindfolded while making healthcare choices. The medical profession clings to a system in which providers are paid for work piecemeal and Bill separately for each instance of service. So we have a system that pays for procedures instead of for health.

These arrangements are now outdated and counterproductive, especially for lean systems that have invested significant resources to improve patient care. In lean health systems, we have to spend time retraining positions to see waste and potential for harm. We work hard to get patients into and out of treatment faster — reducing waiting times, creating shorter hospital stays — and therefore get paid less...

Together, we need to pressure academia, the centers for Medicare and Medicaid services (CMS), and private insurers to correct their incentives and align with a lean system that puts patients first and is always working toward better quality at lower cost...

OK, let's stop right there. apropos of the foregoing, specifically the latter paragraph and directly in line with Doug McKeever's CalPERS Keynote, comes this Academy Health article.

The latest on reference pricing
by THE INCIDENTAL ECONOMIST on JUNE 8, 2015
 
However you feel about reference pricing, the latest paper on the subject by James Robinson, Timothy Brown, and Christopher Whaley is worth knowing about. As Robinson and Brown found in an earlier study, the approach can make a large impact on the market — affecting market shares and prices — at least for specific, elective procedures.

As Nicholas Bagley and I explained, with reference pricing, “insurers set the price they’re willing to pay for a given service or procedure, typically pegging it to a price at which it can be obtained at good quality.” Policyholders then pay the difference if they obtain that service or procedure for a higher price. That is, in contrast to copayments for a fixed amount for a procedure, with reference pricing, the policyholder is on the hook for the entire amount (the marginal price) above whatever the insurer pays. That’s why it only makes sense for elective procedures for which consumers can conceivably shop and plan, and in markets for which there is ample competition so they can do so.

The recent study considers reference pricing* by the California Public Employees’ Retirement System (CalPERS) for cataract removal surgery, which began in 2012. This is in the context of the use of reference pricing by CalPERS for hospital outpatient procedures more generally: it set those prices to those charged by ambulatory surgical centers for the same procedures.

I can see the motivation: the difference in price level between hospitals and surgical centers is stunning...

Timely.

With respect to Dr. Toussaint's allusions to medical pedagogy and "heroic doctors," I refer you to my "Back Down in the Weeds'" section of my April 22nd post "Doctors and nurses in the trenches."

NEWS ITEM

Interesting. Ran across this link in a THCB post comment. From "How The Ruling Class Impacts Your Health Care and Why They Need To Be Stopped"

...When the managers took over they decided to replace some of the department heads at the periphery.  Suddenly there was no longer a certain department that people counted on and their duties were subsumed by another department. The dislocated clinicians either quit in frustration or were relegated to a more peripheral role in the clinic or hospital. They could no longer support a teaching mission and suddenly that block of knowledge was no longer available to students. These experts were consulted in complicated cases to back up the generalists who were now seeing their patients. The next step by the managers was to suggest that productivity in the larger departments was uneven. They suggested that they had a metric so that would assure that everyone in the department was pulling their weight. When I first heard that explanation, I looked around and concluded it was a myth. Everyone in my department was a hard worker and that was borne out by the actual numbers. The numbers were the real story. The rhetoric had allowed the managers to introduce a system to manage productivity that was completely subjective. But that was all the managers needed to develop a system to manage knowledge workers like production workers even to this day.

Why would anyone want to be a manager? Well it seems like easy work if you can get it. Instead of dealing with complex problems that require you stay current in a certain body of knowledge, interact with people in an ethical way, and have extremely high levels of accountability why not just manage numbers and tell people what  to do - especially people who are as politically inept as physicians and their professional organizations. If I ask physicians that question, I usually hear that being a manager or studying business would just be "too boring." That may be applying a medical metric to business that could be far from the mind of managers. Some business educators and critics have pointed out that over the past 2 decades, there is evidence that managers have developed who are focused on short term results and in some cases "the pursuit of short-term shareholder interest, as well as naked self-interest on the part of managers, into managerial virtues." (reference 2). Instead of a manager who knew and was promoted from within the business and who had a vested interest in the quality of the services and interests of the employees, we now have a class of managers who are mobile, highly paid, and have no particular expertise in the affected business. Piketty notes that the United States has invented a "hypermeritocratic society" of "supermanagers". These supermanagers are typically executives of large firms who have been able to obtain "historically high, unprecedented compensation packages for their labor." He also concludes that "the vast majority (60-70%) of the top 0.1 percent of the income hierarchy in 2000-2010 consists of top managers."(p. 302). I don't know Piketty well enough to say what his conclusions about why this meritocracy exists.  He does point out that it is twice as likely to occur in the financial services industry.

There are interesting parallels in the management of financial services and medicine. In both cases, the managing class came about largely as an invention of federal and state governments. The invention of the manager's tools in medicine (billing and coding, utilization management, prior authorization, managed care) parallels the development of credit reporting and the ability of financial manager to put your savings and retirement funds at risk all of the time without offering you any compensation for the use of your money. Both of these systems are subsidized by huge hidden tax subsidies from American taxpayers...

Definitely not Shingo.

P.S.

Anxiety over the looming SCOTUS ruling on "ObamaCare" is seriously ramping up in Punditistan. See my March 4th post on the specious waste of time comprising King v. Burwell.

Also, from the tech front...

"Clinical software designs traditionally overemphasize data capture and data storage—user interfaces, usability, patient safety, and clinical algorithms are add-ons modeled after data are specified. And, like most add-ons, they are not as robust as they might be if they were part of the initial design thinking."

From the always excellent postings of EHR Science author Jerome Carter, MD: "The Challenges of Improving EHR Designs for Patient Safety"

Might Health IT benefit from some serious "A3 Thinking"? Some serious Gemba face time by those writing the code?

Just in...

Lesser consensus, though, on EHR impact on other aspects of care (pdf).
___

More to come...

DeSalvo gets a salvo

The natives are restless.
___

January 21, 2015 

Karen B. DeSalvo, MD, MPH
National Coordinator for Health Information Technology
Office of the National Coordinator for
Health Information Technology
U.S. Department of Health and Human Services Hubert H. Humphrey Building, Suite 729D
200 Independence Avenue, SW
Washington, DC 20201 

Dear Dr. DeSalvo: 

The undersigned organizations are writing to elevate our concern about the current trajectory of the certification of electronic health records (EHRs). Among physicians there are documented challenges and growing frustration with the way EHRs are performing. Many physicians find these systems cumbersome, do not meet their workflow needs, decrease efficiency, and have limited, if any, interoperability. Most importantly, certified EHR technology (CEHRT) can present safety concerns for patients. We believe there is an urgent need to change the current certification program to better align end-to-end testing to focus on EHR usability, interoperability, and safety. We understand from discussions with the Office of the National Coordinator for Health Information Technology (ONC) that there is an interest in improving the current certification program. For the reasons outlined in detail below, we strongly recommend the following changes to EHR certification:

1. Decouple EHR certification from the Meaningful Use program;
2. Re-consider alternative software testing methods;
3. Establish greater transparency and uniformity on UCD testing and process results;
4. Incorporate exception handling into EHR certification;
5. Develop C-CDA guidance and tests to support exchange;
6. Seek further stakeholder feedback; and
7. Increase education on EHR implementation.

Entire nine page letter here (pdf)

"Ensuring patient safety is a joint responsibility between the physician and technology vendor and requires appropriate safety measures at each stage of development and implementation. While training is a key factor, the safe use of any tool originates from its inherent design and the iterative testing processes used to identify issues and safety concerns. Ultimately, physicians must have confidence in the devices used in their practices to manage patient care. Developers must also have the resources and necessary time to focus on developing safe, functional, and useable systems.

Unfortunately, we believe the Meaningful Use (MU) certification requirements are contributing to EHR system problems, and we are worried about the downstream effects on patient safety..."

Opportunities for EHR Science?
__

IN OTHER HEALTH NEWS

This is sad.

Ebola Is Wiping Out the World’s Gorillas
In just four decades, Ebola has wiped out one third of the world’s chimp and gorilla populations. If it continues, the results will be devastating.

While coverage of the current Ebola epidemic in West Africa remains centered on the human populations in Guinea, Sierra Leone, and Liberia, wildlife experts’ concern is mounting over the virus’ favorite victims: great apes. 

Guinea, where the epidemic originated, has the largest population of chimpanzees in all of West Africa. Liberia is close behind. Central Africa is home to western lowland gorillas, the largest and most widespread of all four species. Due to forest density, the number of those infected is unknown. But with hundreds of thousands of ape casualties from Ebola, it’s doubtful they’ve escaped unscathed.

Animal activists are ramping up efforts to find an Ebola vaccine for great apes, but with inadequate international support for human research, their mission could be seen as competing with one to save humans. Experts from the Jane Goodall Institute of Canada insist such apprehension would be misplaced. Two streams of funding—one for humans, one for apes—can coexist in this epidemic, they assert, and must.

“The media was really focusing on human beings,” Sophie Muset, project manager for JGI, says. “But it has been traumatic to [the great ape] population for many years.”...

The dwindling population of both species, combined with outside poaching threats, means Ebola poses a very real threat to their existence. To evaluate the damage thus far, the Wild Chimpanzee Foundation is conducting population assessments in West Africa, with the goal of getting a rough estimate of how many have died. Given the combined damage that Ebola has inflicted on this population, the results are likely to be troubling.

In a way, great apes are Ebola’s perfect victims. Acutely tactile mammals, their dynamic social environments revolve around intimacy with each other. Touching hands, scratching backs, hugging, kissing, and tickling, they are near constantly intertwined—giving Ebola a free ride...

Wow. It ain't all about us.
__

INTEROPERABABBLE UPDATE

From Healthcare IT News.

The experience of interoperability thus far
Support from EHR developers for clinically relevant workflow will be critical
John Halamka

...HL7 messaging addresses lab result and public health use cases very well. Lab results interfaces are straight forward, however there is still some need to reduce optionality in implementation guides so that the average lab interface costs $500 and not $5000. Public health transactions for immunizations, reportable lab, and syndromic surveillance are standardized from a content perspective but  there is still a need to specify a single transport mechanism for all public health agencies.

CCDA documents address transitions of care use cases reasonably well. CCDA is easier to work and parse than CCD/C32 because it has additional constraints and specifications, but there is still enough optionality that merging CCDA data into an EHR can be challenging. In addition, most EHRs generate a CCDA automatically and include all data that may possibly be relevant. In some cases, this leads to CCDAs that are rendered at 50+ pages. We need to reduce optionality so that CCDAs are easier to generate correctly and parse. EHR workflow needs to better support the creation of clinically relevant documents with narrative and data more specific to transitions.

Direct was a good first step for transport -- we needed to pick something. We could have required sFTP, REST, SOAP, SMTP/SMIME or even Morse Code as long as it was completely standardized. Unfortunately, we picked multiple options. Some EHRs use XDR (a SOAP transaction) and some use SMTP/SMIME. Whenever standards have an "OR", all vendors must implement an "AND". XDR must be translated into SMTP/SMIME and SMTP/SMIME must be translated into XDR.  The reality of Direct implementation has shown us that this optionality provides a lot of plumbing challenges. Certificate and trust issues are still an ongoing project. Getting data from medical devices via Direct is challenging since devices tend to use heterogeneous transmission protocols. Finally, SMTP/SMIME was never designed for large payloads of multiple files, so sending datasets greater than 10 megabytes can be a struggle. The use of XDM for zipping files before they are sent is overly complex to use as part of a transport protocol.

Although Direct works, it is often not well integrated into the EHR workflow.

FHIR, as discussed in multiple recent posts, can help address these challenges and leverage the lessons learned. The FHIR concept is that every EHR will provide a standardized interface for the query, retrieval, and submission of specific data elements and documents using a web-based RESTful transport mechanism and OAuth security. This use case can easily support unique modules or “bolt on” application functionality to EHRs. It significantly simplifies the interfacing challenge, works for large payloads, and minimizes optionality. There are no multiple transport options, no certificates to manage, and the query/retrieve processes can occur behind the scenes, enabling smoother workflow.

FHIR can even be helpful as a transition strategy while Direct is still used for pushing payloads between EHR. If FHIR/REST/OAuth replaced the XDR/XDM options of Direct, that provides a glide path to the eventual end to end replacement of Direct with FHIR

Once FHIR is available, EHR vendors should design a user experience that follows the IEEE definition of interoperability -- “the ability of a system or a product to work with other systems or products without special effort on the part of the customer."...

 My concerns regarding FHIR® persist. Beyond seamlessly integrating these "interfaced" data into "clinically relevant workflows" in ways that [1] don't put more sand in the workflow gears, and [2] don't leave the "imported" data reposed somewhere outside the recipents' RDBMS -- begging the question of easily assembling of the most recently updated complete legal patient record (vis the clinician acting upon the imported data elements) -- who is going to have to pay for all of this coding and QA validation work? Will FHIR ex/im functionality come to be required for ONC EHR certification, on the vendors' dime?

While I would say "yes," color me dubious.

What about HIPAA audit trail "chain of custody" data considerations?

I'm just asking. Below, from survey findings I recently saw in "API Integrity is a 'Must-Have' in the API Economy."

INTERESTING ASQ MEETING PRESENTATION

Cheryl and I attended the ASQ East Bay Section 0618 meeting Thursday evening. Very nice.

Please welcome our newest distinguished guest, Ms. Ritu Ganguly of ServiceMax Inc.  She will be presenting on the topic of "Testing in the Mobile World?"

Ms. Ritu Ganguly will lend her professional perspective on the emerging challenges of bringing quality to a mobile connected world.  Areas of discussion will include:

• Advantages and Disadvantages for QA engineers
• Basic similarities to the status quo, but note the differences...
• What skills sets are needed by mobile testers?
• How is Automation planning affected?

Bio
Ritu Ganguly is an experienced executive with over 18 years of experience in Quality, Technical Program management, Release management.  Her experience is in varied industries including ERP, CRM, HCM, Service and Healthcare software.  Her key strengths are building effective teams, fixing organizational issues, change management, quality process and software delivery.  Her professional journey includes mentoring and coaching quality engineers and managers for the last 10 years.  Most currently she was a part of Tech women mentorship program sponsored by the U.S State Department.  In addition, she was filmed by Stanford University for She++ videos to promote women in computing.

Ritu Ganguly has a Bachelor’s degree in Computer Science and a Master’s in Medical Informatics.  Born in India, she and has lived in Europe, Middle East and the U.S.  Her professional experience has been working for large enterprises such as PeopleSoft, Oracle, Salesforce and John Deere, as well as small startups such as Health Quality.

Currently she is a Vice President of Quality and Strategic Ops at ServiceMax Inc. ServiceMax is a Leader in Field Service Management software.

Specialties include:

• Software development and quality management.
• Quality of service (QOS) for Cloud Computing and Software as a Service  (SaaS)
• Agile methodology and Scrum
• Talent management, Team building, Career planning and development
• Public Diplomacy, Global mentorship
• Women empowerment

Excellent, thought-provoking presentation and discussion. Given the increasing penetration of mobile digital tech ("mHealth") in the healthcare space, issues pertaining to software (and hardware) QA will be ever more critical. I worry that "QA" in Mobile "apps" is to a distressing degree reactive, i.e., done on the backs of customers in the wake of uploaded bug/crash complaints ("Ignore" / "Send Report" / "Restart"). As a fellow attendee put it, "everything is now always in beta."

I am not at all mollified by the dismissive assertion you often hear from some vendors (particularly those claiming to be "doing Agile"): "We're ALL in QA."

Show me the comprehensive, executed test plans and the upshot documentation. Show me your QMS Manual.
___

More to come...