Home » Readers Write » Currently Reading:

Readers Write 11/14/11

November 14, 2011 Readers Write 11 Comments

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.

View/Print Text Only View/Print Text Only

HIStalk Featured Sponsors


Currently there are "11 comments" on this Article:

  1. So if you have such a vivid complaint of the people you worked with did you voice the concerns and request improvement through your own team or their implementation PMs? Since their business is customer service regarding implementation I have a hard time believing they would stand for that through an install if there were enough reasonable escalations from the customer side

  2. I’m working with Epic on an implementation now and I don’t know who “Informaticist RN’s” AC/AM are but mine are totally not like that. Infact they are the opposite. They are constantly demanding agendas before sit visits have meeting minutes to us before we get back to our desks and the first I hear of “Epigoogle” was on HISTalk.

    Granted they don’t know the answer to ever questions I have off the top of their heads but generally I think they do a pretty good job. Sure I have to remind them to get back to me on a few of the more vexing questions I’ve posed, but I see keeping any vendor honest and poking them with a cattle prod periodically part of my job.

    Its unfortunate that “Informaticist RN” is having a hard time. In my experience, 12 years in healthcare IT, you as the customer have to set the agenda, be demanding of vendors, and hold them accountable. Epic isn’t perfect by any means but they are heads and tails above some others I have worked with.

  3. “Epic isn’t perfect by any means but they are heads and tails above some others I have worked with.”

    Some would even call them the “cream of the crap,” which is the problem.

  4. RE: Epic Customer Service. Just like many things in life, it all depends on who you get. I have worked for about 5 different Epic clients and have had a number of different support people from Epic for different applications. I have seen a huge variance in how good they are… but in every case if I couldn’t get good customer service there was always someone at Epic that I (or someone at my organization) could escalate things to. In some cases Epic people who couldn’t handle things were just gone one day, and later I learned they had been let go. From my experience, as long as you escalate up through the channels Epic is extremely responsive and will assign more resources as needed.

  5. I have had a similar experience as Informaticist RN, getting two kids assigned to an OR install, which was a very complex area for my organization at that time. But after expressing my concern to Epic, we worked out a staffing change that solved the problem. Done deal.

    No vendor is perfect, but I agree with Timmy that Epic is definitely responsive.

  6. Re: Problem Lists. A major “problem” with the Problem Lists is that Problems need Metadata associated with them (is it active? Resolved? Chronic? Acute? etc). The problem list as it is conceived of today is much too simplistic.

    Is it on the ddx list and waiting to be ruled out? (I believe the Google Health PHR had a little problem with that particular question).

    Does the inpatient’s problem list need different properties than the outpatient’s?

    Thanks to Meaningful Use, we’re getting problem lists for inpatients and ambulatory patients. But we need two more things to make this useful for the clinician:

    (1) A complete and effective model for the lifecycle of a problem that can be represented in a computer and be effectively used for managing the patient’s condition(s);

    (2) A Problems standard terminology that supports the lifecycle of a problem (in particular when things first start out as a complaint or symptom).

    Like Dr Jim, I too am excited about the collaborative problem list approach, Clinical Decision Support around the problem list, and the use of standards-based problem lists to tell the patient’s story (well beyond the “table of contents” to the patient’s record).

  7. If you’re going to spend 500 words trashing two unnamed “kids,” I wouldn’t recommend ending your article on the note that you found yourself to be great, but everyone else at your hospital was impressed by the same people you found terrible. While I’m sure you’re a genius and horribly under-recognized in your time, it makes it seem like all you have to vent is a case of sour grapes, and not any sort of truly substantial complaint.

  8. Seems to me the way to avoid that Epic problem RN talks about (and with any vendor) is to get a contract clause that says you must interview /approve any install/training person before they get rolled in. If that had been done at RN’s place by the internal project lead the issues could have been avoided. I know from my own experiences as a IT consultant that most vendors do not like to commit to that…would /does Epic? Others?
    How many ERM buyers insist on that clause today? My guess – way to few.

  9. I also agree with Timmy D. I’ve been implementing/consulting Epic for several years and have seen some really great Epic AC/AM’s and some really poor ones. This is true of any vendor, not just Epic and it doesn’t matter if they are clinical or not, young or old. You get good, you get bad. If you get bad, you work with the vendor and iron out the issues.

    And how does this RN know they were a good IC? all subjective

  10. Deborah – thanks for raising an important and oft overlooked issue in a very creative way. With the huge increase in the prevalence of structured data as the adoption of EHR technology accelerates, the need to convert unstructured data into usable digital assets is increasingly important. Electronic Content Management Systems (ECMS) facilitate the “dating” between structured and unstructured data. Such systems help hospitals convert unstructured data into digital assets that can be recognized and incorporated into systems which “think” only in terms of structured data. Using scanning technologies, metadata and character recognition to make this previously static data more dynamic, advanced ECMS products can play a key role in getting structured and unstructured data to interact. As an example, many users ECMS solutions can now “marry” structured and unstructured data to help them meet the Meaningful Use criteria related to release of information.

Subscribe to Updates



Text Ads

Report News and Rumors

No title

Anonymous online form
Rumor line: 801.HIT.NEWS



Founding Sponsors


Platinum Sponsors






























































Gold Sponsors
















Reader Comments

  • MA/MBA Grad: I have both an MBA and an MBA in Hospital & Health Administration. These were done together through a dual-dual prog...
  • richie: I don't think it's legal to whip a horse these days without mentioning blockchain. And I'd add "innovative", "interopera...
  • Publius: Your Bingo board is missing "Machine Learning"...
  • Ex-Epic: Re: MHA v. MBA I think if you are 100% down the health systems path, you could probably consider MHA or MBA (but woul...
  • The trip: I agree with you. I have an MHA but think an MBA with a concentration in healthcare is the way to go. My RN IT boss in t...
  • David Butler: I absolutely love this article! I'm fairly new to following HIStalk and Dr. Jayne (and the various portions of the site...
  • MiroslavB: Great insights - Thanks Ed !...
  • SteveS: I’d like to hear more from Ed about his perspective on the current state of “Professional Organizations” – in te...
  • Brian Too: Nice to hear from a small hospital for a change. We hear lots from the large players and consolidation has meant that b...
  • Sam Lawrence: Except in this case, coding = medical billing, not development. Though the same warning may be true...

Sponsor Quick Links