Tuesday, October 27, 2009

"Project" and "Product" Certification

Last Friday night I testified to the President's Council on Science and Technology (PCAST). Many issues were discussed, but one of the most interesting was the idea of "project" verses "product" certification.

Here's the significance.

In Massachusetts, Partners Healthcare and Beth Israel Deaconess use home built EHR solutions based on Intersystems Cache. We both use Sun's eGate (now Oracle) and Intersystems Ensemble as middleware. We both use datamarts/data warehouses based on extracts from our clinical systems to support quality reporting, performance measurement and research. We both use NEHEN as our healthcare information exchange.

We'll achieve meaningful use via this combination of applications with many moving parts. Its totality provides the tools our stakeholders need. We need to certify the sum of the "project" and not the individual "products".

"Project" certification can be empowering in other ways.

Imagine that innovative products such as Microsoft Healthvault/Amalga or Google Health offer services to aggregate data from multiple data sources as part of quality reporting. They can become accelerators of meaningful use.

Imagine that a Modular EHR (such as Quest's Care360) plus a Healthcare Information Exchange can store the lab and medication data needed to coordinate care. Quest and iPhone app innovators can accelerate meaningful use.

My experience is that federated authorship - harnessing the talents of many companies and individuals - leads to the most rapid innovation.

Of course, some of the most advanced aspects of meaningful use, such as comprehensive decision support, may require larger, fully integrated EHRs. But other aspects such as the data exchanges required for 2011 - eRx, Lab, Quality reporting, and administrative transactions - can be empowered by assembling multiple products and services.

Since the theme of the work of the HIT Standards Committee for the next few months will be accelerating standards adoption and implementation (more on this in my blog tomorrow), encouraging all stakeholders to innovate by creating reusable components in support of meaningful use seems timely.

As the Notice of Proposed Rulemaking (NPRM) is written to define the certification process, I encourage policymakers to certify "projects" in addition to "products", encouraging innovation. I have no direct influence on this work, but I am hopeful that industry and clinician stakeholders will provide this input to those writing the policies.


Bernz said...

Federated Authorship (or what I've always referred to as "autonomous teams") enables a divide and conquer strategy.

Modern software toolkits enable one to build a product in relative isolation and then connect to other products securely and cleanly without coordinating between the two products that much. As long as both products can spit-out/accept some sort of structured language with some sort of authentication/authorization, then the two can conceivably communicate. Most modern toolkits and languages have ways to deal with many established input/output methods.

And when the technology you work with doesn't actually have the connectivity built-in, you can use a middle-piece, like an Enterprise Service Bus, to provide that connectivity.

Building modules with experts in those modules is a great idea. My personal feeling is that as long as each module has a way to connect, a network will naturally emerge. And by naturally, I mean that various people (in this case aggregators like MS) will seize the day and build it.

gred43 said...

This is an interesting meeting and echoes a significant consideration that comes with sharing confidential data. Hospitals and their related practices already have an in-house connection to their labs. However private physicians, particularly in small practices, do not have any attachment in the sense of creating lab data. It then becomes troublesome to be responsible for it. Corroboration at a patient interaction is an important activity but once the patient wishes a copy or an involved provider is involved it seems more appropriate to retrieve that data from its source. It should be a general understanding that only the creators of the data should have responsibility for its accuracy. Patients have access to records of their providers that were specifically created by them. If it came from elsewhere they should obtain it from there. If any lab data was given out in my office it was a copy of the report I received.

The major obstacle in this endeavor to have an exchange is formalizing responsibility and the approach to access. This should be finalized first before putting in systems that have too broad a reach. In downloading lab from the hospital into our EMR it was eyeopening how many nuances, double numbering, and errors existed. To enter data into the EMR proper matching was done with some manual but not cumbersome oversight. It took about 10 minutes to do this each day but it was well worth it and quite frankly embellished my education on this subject.

Mike Kovner said...

I suggest "process" certification rather than "project". By definition, a project has a defined beginning and end, whereas a "process" is ongoing.

Adrian Gropper said...

Thank you for raising the relationship between federated clinical apps and innovation.

Real world deployment of federated components like the ones you mention typically requires user authentication and patient identification. These core functions must be federation-enabled themselves in order for the innovation barrier to be low enough to allow physicians and patients to try new services as they become available.

Federated user authentication in an enterprise setting can be as easy as supporting OpenID single sign-on for clinicians.

Federated patient identification can be achieved by allowing patients to specify a secure and trusted intermediary as their voluntary identity provider. People are already familiar with credit card numbers and checking account numbers as voluntary identifiers in online commerce and banking. Telephone providers are also in the business of managing the trust and identity of individuals and families.

The emergence of federated clinical applications will encourage these non-healthcare service providers to provide federated patient and family identity services using OpenID and secure identity card technology.

Finally, the National Health Information Network (NHIN) gives our federal government an opportunity to adopt federated voluntary identity standards including OpenID and OAuth as a way of delivering to patients their complete digital health records as mandated by HITECH / ARRA 2009.

Dan said...

I agree with Bernz. Meaningful use should be measured by the ablity to send and receive data based on the HITSP selected standards. Note both sending and receiving are required. For example, a testing group could send mulitple CCD's with different sets of content. A combined CCd, or one targeted for referrals, etc. could be sent back and automiatically verified. It should not matter how many systems it is stored in if it can be combined in the receiving or sending.

Rob Campbell said...

Take a look at Sarasota Memorial Hospital where iPhones are delivering a unified communication system to point-of-care workers.