Yesterday, I attended the NCVHS public hearing about meaningful use. Here's the agenda and my presentation.
I've described the importance of meaningful use in prior blog posts.
Much depends on the definition of meaningful use, including the characteristics of the EHRs which will qualify for stimulus dollars, the kind of interoperability we'll implement regionally/nationally, and the policies that will be required to support health information exchange.
My specific testimony included an overview of the interoperability needed for quality.
I highlighted the work of the NQF Health Information Technology Expert Panel (HITEP) which selected 84 metrics supported by 35 data types as an initial minimum dataset for quality measurement in 13 care processes. HITEP II will meet next week to further refine this work into a core minimum Quality Data Set (QDS).
I also highlighted the work done in Massachusetts on data exchange including the Massachusetts eHealth Collaborative Quality Data Warehouse.
My summary of the day, based on the testimony of 25 folks is
1. The country must rollout EHRs with baseline functionality that at a minimum includes e-prescribing, automated lab workflow, clinical summary exchange, and quality data reporting.
2. Health Information Exchanges will evolve locally based on business cases in communities. The services offered may include e-prescribing, diagnostic test results delivery, quality data warehousing, data normalization into common formats and vocabularies, and "convening services" to create data use agreements for the community.
3. Quality warehouses are needed to provide caregivers with rapid feedback and serve as population health registries. They will often be local based on the political feasibility of co-mingling data.
4. Standards will continue to evolve, but existing standards wrapped in a service oriented architecture using a common data transport approach are good enough. We should use clinical data preferentially over administrative data for quality reporting, population health analysis, and PHRs.
5. Policies in support of this technology will continue to evolve locally. Although there should some common national policies, regional variation must be allowed.
Several of my colleagues will testify today. I'll update this blog entry after their testimony.
Subscribe to:
Post Comments (Atom)
19 comments:
I'm a believer that this technology will improve patient care. Unfortunatley, there are many that feel the financial investment is too high for the potential rewards.
Especially now with the SwineFlu outbreak, the interoperability of these systems would more than justify the benifits of the systems.
You are preaching to the choir at these seminars. You need a more public oriented forum to sell this to the general public and the physicians who are reluctant to purchase these systems due to lack of faith that they may work as sold.
John: I believe your six points are indeed where consensus is shaping up, and they are do-able because they are a) fairly simple to implement, b) rely on existing standards and infrastructure, and c) will cost relatively little, an especially important issue for physicians in small and medium size medical practices. I am very happy to see your statement about the preference for clinical data over billing data for the uses you mention. Now... can we keep it this simple, or will "scope creep" occur?
Kind regards, DCK
What are your thoughts on Virtual Patient Objects? I will post my thoughts after hearing your take on it.
"Health Information Exchanges will evolve locally..."
Yes they will, but without some centralized structure of normalized data it will continue be piecemeal rather than provide a national ability to exchange meaningful quantities of data.
Properly define HIE structures would also provide a tool for migrating data for retiring EMR/EHR systems.
I agree with David. This is both a good summary and a solid direction. It achieves some quick wins and allows for evolution without raising the bar too high. I am stunned by some proposals (not John's posting) since, in my view, the reporting costs will outweigh the gains. Simpler methods are possible and a good start.
Where interoperability and swine flu is concerned,our Memphis exchange (relying on multiple different data types and minimal data tagging) seems to be able to track things in real time. (No alarms, by the way).
One wonders. How will CCD really accommodate the diverse needs? I am agnostic on this but quite committed to understanding how to make what we all have work.
Health Information Exchanges which evolve locally will eventually need to tie into a regional (and someday national) HIE.
There is a lot of work being done on State-Level Health Information Exchanges, so we are waiting to see what develops before pouring resources into a local RLS or HIE.
Brian,
while agreeing with you (I do believe that the sequence you outline will most likely happen) I question why we have to go through these intermediate steps. As a well-wired nation we should have the wherewithal to create an national healthcare exchange structure.
You make a great point Green.
I would love to see a NHIN develop immediately, but unfortunately the reality will probably be a bottom up instead of top down implementation...
Thank you for your summary on the NCVHS testimony. I am glad to see that there is recognition that what we need are results, not so much the specifics of the products. It seems that a first-pass consensus is emerging that baseline functionality of EHRs should include e-prescribing, automated lab workflow, clinical summary data exchange and quality data reporting. The quality data reporting may come out of the EHR itself, or out of regional or even national data repositories (which clinical summary data exchange feeds into), such as being piloted by the Massachusetts eHealth Collaborative.
The question that always comes to mind when asked about “meaningful use” is – meaningful to whom? To physicians, to patients, or to the nation at-large? Of course, the answer is “all of the above,” though different emphasis pertains to each. For physicians, ease-of-use, e-prescribing and lab workflow management are important, as is feedback on quality metrics (not to mention decision support at the point of care). For patients, clinical summary data exchange is important so that PHRs can be filled with clinical, not administrative, data – patients want a “window” into their doctor’s health records in a way that is portable, and builds a patient-centered health record that transcends all loci of care. The nation-at-large wants quality reporting, and overall cost savings (which is assumed by improved efficiencies from EHR use). I believe the consensus criteria will address the interests of each of these audiences, though it is a work-in-evolution.
Robert Rowley MD
Chief Medical Officer
Practice Fusion, Inc.
A word of encouragement: as we start on interoperability (a cause in which I believe deeply), let's be on the lookout for unintended side effects of different semantics between the sending and receiving systems.
I don't know squat about any of the individual HC systems that will interoperate, but from other industries I know plenty about nasty consequences that can result when one system presumes that a certain fact implies other facts, and the other system doesn't, or vice versa.
I know it's tricky and I do believe in the goal. It just requires a lot of vigilance when the systems are first hooked up.
As I say, in my experience the way to deal with it is to start with a small, solvable use case and subset of the vocabulary, and get that working. If something goes wonky with a subsequent expansion, the cause is pretty well isolated.
I think John's assessments are on-target. I would agree with several of the other opinions however, in that I would like to see some focus on nationally-scoped healthbank-like services as an alternative to regional sharing. Many people don't stay in one region, and having one's lifetime of health data spread out all over the country in potentially incompatible regional HIEs is not appealing. This is the age of the Internet -- we don't require web servers to be "regional" -- why should data exchanges have to be? If we have the right standards in place (XDS would do,) a consumer should be able to specify (with a URL?) where he wants his data aggregated.
David McCallie MD
Cerner
This is one of the reasons I like the edge server model that keeps the information local but allows national access with a predefined structure. As David says, we are living in the Internet age.
These are all great comments. To add my personal opinion about health information exchanges, I agree that there are two models easily implementable in the short term - clinician to clinician exchanges that are based on local data use agreements AND patient driven data exchanges such as Google Health, Microsoft HealthVault, and healthbank type services. When the patient controls the data flows, the confidentiality issues are much easier to manage.
RE: 4. Standards will continue to evolve, but existing standards wrapped in a service oriented architecture using a common data transport approach are good enough.
I totally agree. However, from the HITSP Town Hall session (HIMSS09), it appears that your staff might not have heard of PDF Healthcare or decided against using it. For example, you mentioned that because your healthcare organization must send a lot of data daily to the CDC, your staff "self-developed" a wrapper in a service-oriented architecture and uses a common data transport approach (SOAP? WSDL?) to send the data.
PDF Healthcare is a Best Practices Guide (BPG) and Implementation Guide (IG), published in 2008 by two standards development organizations (ASTM and AIIM) and authored by a voluntary committee of healthcare industry consultants, vendors, thought leaders (e.g., Dr. Tom Sullivan, whom you well know), and users. PDF Healthcare is NOT another standard. PDF Healthcare (i.e., its BPG and IG) describes (generally unknown) attributes of the Portable Document Format (PDF -- an international, open, ISO-ratified and published standard, originally created by Adobe Systems, Inc., but since July 1, 2008, developed and maintained by ISO) - freely viewable on almost every netbook/laptop/desktop around the world - to cost-effectively facilitate the capture, exchange, preservation, and protection of health information. Such attributes include the ability for healthcare providers and consumers to develop secure, electronic WRAPPERS (a.k.a. containers) that store and transmit relevant healthcare information, including but not limited to personal, handwritten documents, (structured or unstructured) clinical notes, (structured) laboratory test result reports, (unstructured) word-processed / text summary reports, electronic forms, scanned document images, digital diagnostic images, photographs, and signal tracings (e.g., electrocardiograms [ECGs]). PDF Healthcare maintains any well-formed eXtensible Markup Language (XML), allowing any standardized data set (e.g., the CCR, the CDA, the CCD, etc.) to be embedded in a PDF and then linked to the actual display of that data, retaining the XML. Currently, many providers (e.g., Stasia Kahn, MD in No. IL) use the CCD and PDF Healthcare to send information from their EHR to referring or primary care physicians' EHRs (if they have EHRs; if no, they can view).
Deborah,
can you talk a little more to the structured side of PDF Healthcare. Does it allow a recipient to import the data based on the ASTM/AIIM conventions?
Do you know how widespread the adoption of this format is?
Thanks.
Hello Green:
I am not sure what you mean by:
1) "Does it allow the recipient to import the (structured?) data based on the ASTM/AIIM conventions?"
Are you referring to the ASTM CCR and the ASTM / HL7 harmonized CCD?
2) "Do you know how widespread the adoption of this format is?"
Which format? PDF Healthcare? The CCR, CDA and CCD?
Deborah, I was interest to find out how PDF Healthcare can used for health information exchange if the recipient wishes to capture the incoming PDF information and incorporate the contents in their EHR.
Green - the good news about PDF Healthcare is that PDF Healthcare contains any well-formed XML. This allows any standardized data set (such as ASTM's CCR, HL7's CDA, or ASTM/HL7's "harmonized" CCD) to be embedded in a PDF and then linked to the actual display of that data, retaining the XML. (As you probably know, XML supports what is seen on the screen when the CCR, CDA, or CCD are encoded.) For example, if a consumer, provider, or provider organization must send a patient's (structured) medication list and (unstructured) radiology exam result report, let's say from an office EHR, to multiple physician offices -- some with office EHRs, some without -- the consumer, provider, or provider organization is able to embed those documents in the PDF container and securely send them. If the reports were sent to a provider who does not have an office EHR, the receiving provider can simply (and freely!) view the documents and / or print them to paper. (Also, the receiving provider can print the documents to paper from his/her smartphone without the need of a computer!) However, if the reports were sent to a provider who does have an office EHR, the EHR can consume the XML data in the PDF container and populate the recipient's EHR.
I talk a little about this, above, as well as in another response to Dr. H's blog on Point-to-Point messaging. I hope this helps.
This is one of the reasons I like the edge server model that keeps the information local but allows national access with a predefined structure. As David says, we are living in the Internet age.
Recep Deniz MD
DoktorTR.Net
Post a Comment