Readers Write 11/14/11

Submit your article of up to 500 words in length, subject to editing for clarity and brevity (please note: I run only original articles that have not appeared on any Web site or in any publication and I can’t use anything that looks like a commercial pitch). I’ll use a phony name for you unless you tell me otherwise. Thanks for sharing!

Structured and Unstructured Data, I Adore You Both
By Deborah Kohn

Calling all electronic patient record systems (EPRS) structured data! Yes, all you electronic health / medical, administrative, and financial systems’ data elements that are binary, discrete, computer-readable, and, typically, are stored in relational databases with predefined fields … you tidy, typically core, transactional and mined elements. Hello? I’m talking about all you digital, patient demographic, financial, and clinical health data that are sitting in master patient indices, insurance claims, clinical histories, problem lists, orders, test results, care plans, and business intelligence reports — to mention just a few.

Meet unstructured data! Yes, all you EPRS data that are non-binary, non-discrete, sometimes only human-readable, and sometimes not stored in relational databases. This means all you digital, bit-mapped images, text, videos, audios, and vector graphics that are harnessed in word-processed summary reports, electronic forms, diagnostic radiology images, scanned document images, electrocardiograms, medical devices, and web pages – again, to mention just a few.

I know this might be an awkward introduction. However, I’m really happy to finally get you two data formats together. And, while this might be jumping the gun a bit, I really hope one day you two will get married! I know, I know. That is, after you’ve carefully sorted out all your differences and learned how to live together in peace and harmony for the betterment of patient care.

After all, I’m certain you heard the rumor that the “adoption” and “Meaningful Use” of “certified” diagnostic image-generation and management systems, such as a PACS for one or more of the “ologies”, might be included in Stage 2. In addition, heaven help if, given the revised Federal Rules of Civil Procedure Governing Electronic Discovery that became effective December 1, 2006, a patient’s electronic health/medical, administrative and financial episode-of-care records (I mean x-rays, bills, ECGs, orders, progress notes – the works!) are subpoenaed for that Weird News Andy case we recently read on Mr.HIStalk! So, don’t you think it’s time at least to begin acknowledging one another in public?

Who am I, you ask, to be so bold to introduce you to the other? I’m just one, frustrated HIT professional who specializes in most of the EPRS unstructured data and who observes that these data are rarely considered in EPRS strategies and purchases … until after the fact. Once considered, they divide provider organization departments right down the middle; those working with you, structured data, vs. those working with you, unstructured data. Don’t even get me started about integration and usability issues!

Come close, structured data, so I can tell you that I do adore you – especially when I search a database for one or more of you, and, quickly and easily, the search engine finds, retrieves, and even manipulates parts or all of you. On the other hand, what often makes me want to delete you is when you insist on snubbing unstructured data. I’ve even watched you try to convert some unstructured data, such as rich-text or video data, to your popular religion, using pretty-good-but-not-perfect artificial intelligence and recognition tools … just so that you can brag about how you were able to generate the complete health story with your qualities.

Unstructured data? After so many years working with you, you know that I love being able to retrieve your gorgeous, bit-mapped, raster images generated by that digital chest x-ray or computed tomography (CT) scan stored in a diagnostic image management system; or, listen over and over to your brilliant sound bytes generated by that digital stethoscope; or, fast forward your streaming videos / frames generated by that important cardiac catheterization study; or, admire the perfect lines connecting the series of points plotted by that fetal trace recording. On the other hand, what I can’t tolerate is when I am required to search, for example, a valuable narrative text for one or more of you, and after hours I still can’t find you!

Today there is no complete electronic patient health / medical, administrative or financial record system without both of you. Let me see a hand shake.

Deborah Kohn is a principal with Dak Systems Consulting  of San Mateo, CA.

Problem Lists:  Avoiding the Tragedy of the (Coded) Commons
By Dr. Jim

If we want to take better care of patients, we have to know what we did. To know what we did across a whole group, we need computers to crunch concepts that computers understand.  

But here lies a paradox. While we need structured data entry to enable useful analysis, too much structure complicates both data entry and analysis. The splitters (and payors) among us can create use cases that force the lumpers to accede to ever finer divisions until, for instance, a single ICD-10-PCS procedure code represents nearly an entire chart summary: “ICD-10-PCS 027334Z Dilation of Coronary Artery, Four or More Sites with Drug-eluting Intraluminal Device, Percutaneous Approach” e.g. There are upwards of 1,000 more angioplasty codes within ICD-10-PCS, all with a General Equivalence Mapping to a lesser number of ICD-9-CM Volume 3 codes.

Are my fellow clinicians napping off yet? If so, put on a hazmat suit before you do. What is hitting the fan now will be splattering you shortly if it is not doing so already. In the interest of being able to use our electronic records meaningfully, the movement is toward collaborative problem lists with structured entries documented by clinicians. This would be a good thing—an excellent thing—were it not for the concomitant explosion of  “structure” detail, the de facto  requirement that clinicians do the structured entry as part of their workflow, and the variety of workflow places and coded sources that potentially populate the “Problem List.” 

These sources include the SNOMED-CT and ICD-9/10-CM libraries for diagnoses. I won’t be surprised if a typical Problem List ends up including Procedural Codes as well from the  ICD-10-PCS and CPT/HCPCS libraries. While these procedural codes are not technically “problems,” and not currently Meaningfully Used (the current standard is for “ICD-9 and SNOMED-CT” pending the swap to ICD-10), it does not take a Workflow Scientist to predict that a clinician who documents a percutaneous angioplasty as a CPT code will have an expectation that the Problem List is automatically populated with that (coded) “diagnosis.” 

We are about to see electronic record-generated collaborative Problem Lists that are essentially a repository for the “workflow” output of every clinician who touched the patient. Diagnoses attached to ordered tests; diagnoses entered during a Hospital stay; ED diagnoses; prescription diagnoses; ambulatory diagnoses; imported diagnoses carried by CCDs … perhaps even diagnoses entered by billing services after discharge. It will be the plethora, and not the dearth, of finely-split coded data, which renders the Problem List less functional and the analytics related to it problematic. 

The challenge is to find ways to get to Meaningful Use without letting it prevent the record from being used meaningfully. It’s a great idea to have a collaborative Problem List from which every workflow can read and to which every workflow can write. But we must also focus on finding ways to preserve a Problem List which readily communicates a plain-English problems summary for all caregivers so that Meaningful Use does not morph it into an unnecessarily long and noisy collection of all the code-speak entered on a patient.

There is a need in the electronic record for good, coded, structured data. This does not mean it should replace clear communication.

Real-World Epic from the Ground-Level View
By Informaticist RN

I have worked as a nurse with Siemens Invision, Cerner, and Meditech and an implementation consultant for a leading HIS vendor (not Epic). I’ve also worked as an IT analyst at a major medical center implementing Epic ambulatory.

We had two Epic employees assigned to the ambulatory application, an application coordinator (AC) and an application manager (AM). Both were fresh out of college and obviously green to healthcare.

Our AC/AM would come out for a week at a time, with no agenda given in advance. When they were here, it was disorganized. Whether this was the hospital’s fault or Epic’s, I’m not sure.

Usually, the two Epic people would be typing away on their laptops and not meeting with anyone from the hospital. When I did have one-to-one meetings with them regarding the build we were working on, they were constantly on "Epigoogle" (Epic’s search engine) because they did not know answers to what seemed to me like basic questions.

After their visits, we received no follow-up on outstanding issues or status reports of things they were working on for us. Reaching them was always a challenge. Either by voice mail or e-mail, it could take days or weeks to get questions answered. Generally, it took escalating issues through our project manager just to get a response. We didn’t even get, "Saw your e-mail, working on issue, will get back to you." Nothing! Very poor customer service from them.

During what Epic calls validation sessions, we ran into many problems where scripts weren’t sent ahead of time for our review. Some sessions ended up with last-minute cancellations because Epic wasn’t prepared or hadn’t shared the necessary info with us. Very frustrating.

When build questions arose, the Epic AM preferred to fix the problem in our system herself rather than explain the answer to us so we could learn the system. Frustrating again!

These same AC/AM were also responsible for grading projects for certification. When clarification was needed for me to understand what I got wrong, they were unable to. That was actually a final answer I received from our AC — "I don’t know," and no offer to find who might know more or send on my project to someone more senior for grading.

It was really very disappointing because I was a better IC at the vendor I worked for than either of these two, but everyone at the hospital acted like they were so great because they come from Epic.