This comment is not in response to the specific questions posed by ONC, which seem to presume a certain validity of the PCAST report. This comment is respectfully raising several basic questions, which in my opinion, the PCAST reports either did not address or circumvented. With this in mind, you may choose to continue reading, or not.
I would like to start by clarifying that I am now, and always have been, a strong proponent and supporter of appropriate computerization of medical records, HIT in general and the resulting opportunities for expanded clinical research. For the purpose of full disclosure, I have no financial or any other, interests in any HIT vendor.
1. Where does clinical data reside today?
- Providers – As we all know, there are massive amounts of paper based medical records residing within the walls of providers of all shapes and types. In addition to paper based records, there is a significant (and growing) amount of medical records maintained in electronic format by mostly large providers, but smaller ones as well. The vast majority of these records are created and stored in document format (scanned, dictated, typed, annotated, handwritten, transcribed, etc.). A small portion of this data is stored in structured format, mostly if not all, in relational databases. The most common discrete data elements are demographics, insurance details, diagnoses (ICD-9), procedures (CPT), vitals, and here and there lab results, immunizations, medications, some histories and relatively rarely, findings.
2. How should clinical data be collected for clinical research?
- I don’t think anybody will disagree that it is much easier to extract data from a few centralized databases than it is to extract it from tens of thousands of smaller and diverse ones. The set of data elements contained in the union of payers, laboratories, radiology and imaging centers databases is lacking very little that can be provided from mining provider generated clinical data. As an aside, I would like to clarify that, contrary to common mythology, there should be no distinction between payers “billing codes” and provider maintained codified “problem lists”. If there is a discrepancy, it is either due to incompetency or plain fraud. Provider databases may contain longitudinal vital signs and perhaps more up to date allergies, smoking and drinking status. So why is the research effort concentrated on providers EHRs which, under best circumstances, are practically mirrors of already aggregated and analytics ready repositories?
- With very few exceptions, population level research data need not be available in real time and need not be extracted in milliseconds. While web crawling enabled technologies and infrastructures are very appealing, the cost of retrofitting every data repository with the means to bypass a Service Oriented Architecture (SOA) seems a bit unjustified and the benefits seem unclear to me in view of the multitude of algorithms continuously executing in payer databases with obvious benefits to that industry. As an additional note, I believe the report severely underestimates the costs to the industry to migrate to a web-based, data-element centric architecture, which will involve major changes to all payer, laboratory, pharmacy, clearinghouse, intermediaries, HIE, CDS, drug database providers, etc., in addition to the obvious impact on providers and their EHRs.
3. Does a browser based, research oriented infrastructure benefit health and health care?
- There is no question in my mind that a “universal language” for health care information exchange is necessary. Languages are composed of syntax and semantics.
- Syntax – There has been increasing agreement in the U.S. and other countries as well, that HL 7 v3, which is XML based, is capable of providing a universal syntax for data exchange either through messaging or through exchange of “documents”. Both messages and documents are based on extensible structures, with the added benefit that CDA is compatible with the needs of those who do not own and cannot process individual data elements. Those needs will be around for a very long time. Additionally, the CDA automatically provides context for all data elements it contains. One may argue that metadata tags can contain all contextual information required to recreate the CDA, in which case the question is why disaggregate the document in the first place? For illustration purposes, let’s assume that an MRI order is represented by a metadata tagged element. For a given physician, treating a given patient, seeing that an MRI was ordered sometime in the past is rather meaningless without the context of a progress note containing diagnoses, subjective and objective findings and perhaps other diagnostic tests. However, I can easily see a “measurement” being created from the proposed atomic data elements, to calculate all the MRIs ordered by Dr. X in a certain period of time. Dr. X would probably be rewarded or wrist-slapped if he ordered less-than/more-than the “norm”. Without the proper context this measurement would, of course, be meaningless. Obtaining the proper context would pretty much require the assembly of the CDA and application of appropriate logic to the query. This is a bit more complex than what a web-crawler is required to do.
- Semantics – Here too I believe the report underestimates the complexities involved in using multiple vocabularies, translated at the edges by some type of “middleware”. If you ever clicked on the “Translate this page” link in Google, or used an online translator to obtain a nice Latin quote, you should know that using arguments like “my middleware speaks more vocabularies than yours”[2 slide 6] cannot be taken seriously by anybody with any exposure to UMLS and SNOMED-CT.
- I have no doubt that creating a health care ecosystem based on atomic data elements is conducive to a plethora of research activities. Perhaps even clinical research. I am not certain though, that such activities will either improve health or reduce cost of health care. If you happened to read Dr. Gawande’s latest article, you should realize that health care is best AND most cost effectively delivered one patient at a time with very high-touch methodologies. Patient-centric was never meant to be interpreted as data-centric. Yes, computerized records can help tremendously, but I could not identify a single use case in the report that requires atomic data elements, or even benefits incrementally from such strategy.
- Both physicians and patients need to exchange meaningful information. I cannot identify with certainty one optimal way for such exchange. The Direct Project looks to me as very promising. However, if I may be allowed one more illustration, medical records are very similar to books, mostly collections of short stories. Patients and their primary care providers may want to have a copy of the entire book. Other providers may want a chapter or two, or even just an abstract, but nobody has any use for just words or sentences being moved across the wire. Most books do have an index, but that index serves as a pointer to contextual information. There can be no understanding without the context. If I say that my book contains an index to “death panels” which appears 50 times in the book, you still have no idea if this is a liberal book, a Tea Party manifesto, a history book about ancient tribunals, a critique of the NHS, or Mr. Boehner’s latest interview. Yes, we do know how to efficiently crawl around the web and aggregate billions of indexed locations with no particular context in mind, but just because we have a hammer…..
4. What is Government’s proper role in technology?
This is not about Meaningful Use, incentives, vision for a better future, or any lofty goals. This is about capriciously and arbitrarily influencing industries and markets.
- I do understand how technology serves manufacturing, retail and financial industries exceedingly well, but there is a reason why health care did not take the same path. As I wrote elsewhere, medicine is very different than other “industries” in that it lacks 100% repeatable processes. For example, the entire process of manufacturing, packaging, ordering, delivering, stocking and selling a box of Fruit Loops is exactly the same for every single Fruit Loops box. Automation of such process is easy. Unfortunately, people are not very similar to Fruit Loops boxes, and paradoxically, the lack of appeal and utility of current EHRs is in large part due to EHR designers thinking about Fruit Loops instead of the many ways in which people express pain and suffering. The legal industry is even less computerized than health care for the same exact reason. I do understand the frustration of technical folks and research oriented scholars with the slow adoption of HIT by physicians, but the answer is not to decree exactly how medicine should be practiced, and how it should be paid for, just so that it accommodates existing technologies, no matter how cutting edge their inventors seem to think those are.
- I am familiar with the various theories of innovation, disruptive innovation, fostering innovation, stifling innovation and all other derivatives of what has become a meaningless term. I don’t see how Government’s role extends to arbitrarily deciding that some products are “legacy” and others, yet to be invented are not, and to creating a “vibrant market of innovators”. “Vibrant market” should suffice. Is Government engaged in similar efforts in other “industries”, whether those are technically advanced or not? Yes, there is a host of incumbent technology vendors in HIT, and yes, they are well entrenched and getting more so as adoption rates are increasing, and yes, their products are well positioned for improvement. Has the Government decided that these vendors are unable to be “innovative”? Has anybody done a bit of “longitudinal” research on how products have changed in the last few years? I do understand there is significant private capital on the sidelines, waiting impatiently to enter the “market” [2 slide 3], but is it proper for the U.S. Government to “pave the way” by imposing new regulations on the industry, which may or may not be appropriate, just so that room is made for those who could not enter, or gain enough share of the market on merit alone? Is this what we now consider innovation?
- We will probably be better served if Government, or CMS, just defined what the outputs and inputs should be, what the rewards and penalties are, and let physicians, hospitals, HIT and the rest of the industry figure out how best to deliver. You would probably see some serious and true innovation right there.
Thank you for reading what has ballooned to 5 times what I intended it to be.
Margalit Gur-Arie was COO at GenesysMD (Purkinje), an HIT company focusing on web based EHR/PMS and billing services for physicians. Prior to GenesysMD, Margalit was Director of Product Management at Essence/Purkinje and HIT Consultant for SSM Healthcare, a large non-profit hospital organization. She shares her thoughts about HIT topics and issues at her blog, On Healthcare Technology.
You mentioned the privacy aspect being tagged to every data element and I did leave that out mainly because I realized that I already had 4 pages written, and because I was satisfied that the new PCAST Workgroup at ONC grasped the issues immediately upon being presented to them last week. Particularly the portion asserting that the data received from another provider should be stored in the original encrypted format, with the key maintained elsewhere. This pretty much says that you cannot incorporate anything received from another source into your own chart. You can look at it and store it somewhere on a separate “shelf” for looking at it again later, but you cannot integrate it into your own database.
I have no idea how this approach can be put into useful practice.
My feeling is that they were trying to fit the needs of information sharing for health care purposes, into the web search-engine paradigm. I don’t think it fits “as is”.
If you are interested in breast cancer treatments and preventions, please take a look at this link: http://breastcancerbydrruddy.com/. There are great articles you’d love to read! It goes over the Breast Health and Healing Foundation as well as the breast cancer virus and vaccine. The vaccine may be a great help to breast cancer patients as well as the healthy. Prevention includes the food you eat, the amount of exercise you get, and the destructive things you must avoid such as HRT, birth control pills, alcohol, and cigarettes. Thanks for reading!
I appreciated this thoughtful post. Amen about the importance of Context! The “atomic level” aspect of PCAST concerned me from the get go, not just because of the complexity of tethering granular privacy policies to atomic data elements, but because of the very examples you used (short stories, books) which were both clever and relevant. Maybe more explanation from the PCAST report’s authors would be helpful, because there were times they referred to “data elements” in a way that seemed less “atomic” — e.g., they referred to a “mammogram” as an example, and there are many attributes of a mammogram (e.g., the image itself, observations, date performed, interpreting radiologist) so they may not have intended data to be as chopped up as it appeared from the report. Hopefully, ONC will see the necessity of “atomic data elements” within their context e.g., in clinical documents or “short stories” — a Both/And proposition, not an Either/Or.
The whole issue of COST (e.g., development, adoption, support) vs BENEFIT (e.g., safety, efficiency, outcomes), to do whatever, is not always apparent in recommendations. There are a myriad of “good things” but to avoid the equivalent of “pork” in HIT, we need such a balance, as you talk about in your paragraphs about research and population health.
In that regard, you raised a very interesting point about where the clinical data resides today, and the difference in retrieving it from payers/labs/imaging centers, vs. providers. (Suggestion: you could also have mentioned the e-prescribing networks, which I’d characterize as more than payer/PBM since it includes retail Pharmacies). I hadn’t really thought about that much (admittedly, HITECH shines the spotlight so heavily on EHRs that it’s easy to overlook what else is out there).