Is Your EMR Granular?

 Using Matt's textbook definition of granular (below), is your EMR granular?

Lowell,

What is disturbing to me, not to belabor the point, is that it all does seem simple for the majority of physicians. Few physicians really understand the depth of the problem.

Getting computable, granular data from a health record is not simple if the EMR is not designed from the ground up with that in mind.  Any EMR worth its salt is designed with computable vital signs.  Labs will likely be computable.  But sensation of the pad of the left big toe will not be computable for the majority. That's where simplicity ends.  Further, if you want a report that documents that item, it will require much more work for the EMR design team when the EMR was not created for granularity.  Why provide users with a report writer when the design team understands that there will be a lack of computable data to fill the report?  If the EMR did have all the computable data, you would have your report writer already.

The natural thought here is, "Well, I clicked on an item, it went into the encounter, and therefore, it must be granular."  That thought makes sense until an EMR tries to find that granule of information.

Consider two scenarios.  The first EMR provides pick lists, checkboxes and assorted other tools for constructing a record.  You dutifully document on your patient. But in this EMR, your clicks simply string together sentences to construct a note. Nothing is easily searched because there is no uniqueness to each clinical granule. It's now just a string of words.  The second EMR, where its designers considered the problem of granularity, constructs a note from the data, but also stores the picked items in XML (or some other format) that stores identifying characteristics of each granule, unseen by  the user.  It is this unique identifier that allows a computer to quickly gather particular data from the encounter, parse the data, and compile it into a table.  For example, the sensation exam of the pad of the left big toe might have a unique identifier associated with it of {23456789-ABCDEF-456789}.  That identifer is the Holy Grail because it allows all sorts of other activities to take place. The program can look up parsing instructions and formatting instructions on THAT item, whether it's associated with an HMG, whether it should invoke an agent (such as order the labs), whether it goes into a templated letter, whether it should invoke another item (such as automatically document a CPT too) and much more.

The first EMR is easy to write but the second is not.  Lots of EMRs took the easier, more apparent path and few took the more arduous one. As EMR popularity grows, the differences will become more apparent as computable data will be expected by physicians.  And consider this:  There is no going back.  Once a note is constructed without computable data, the uniqueness of each graunle cannot be retrieved.

I've written many times over the last 3 years on the importance of granularity, but other more important stuff has taken precedence like readability, prettiness, CCHIT, and CCR, As these other items become non-isssues (everybody has a pretty note now), granularity will percolate to the top. 

Matt Chase

 Matt - is eCW granular?

DrQuit:

 Matt - is eCW granular?

 

I don't know about the current version of ECW but the version I looked at did not have the degree of granularity that Matt describes.  Same thing with eMDs.  There are parts of the note that are granular and there are parts of the note that are not granular in both ECW and eMDs.  With Medtuity everything you click/do is granular in all parts of the note.  The biggest problem I have in eMDs is that the PMHx section and PSHx section are not granular.  They are just dumb text.   This makes it impossible to do drug/disease interaction checking.  I hope version 7 of eMDs fixes this deficiency.

 There's an old adage in computing "garbage in - garbage out" - This is the problem with granularity. To avoid  "garbage out"  the  in must be perfect - Currently every EMR, except one - and most can guess who I mean  - has a choice to make - granularity or not, open text. If you chose granularity then it is a question of various degrees of aggrevation for the doc - learn a "system," change workflow, training etc The more open text, the less nice less messy granularity. The there is granularity and granularity - SNOMED granularity is different from Medicin granularity, CPT codes only work in the US so granularity based on it is only granular to an US physician and even there there are more and more CASH physicians or ones with special billing that don't care about CPT codes.

But input is king to us - granular means nothing if the doc takes twice as long to record just to make their note granular. Speed is everything.

Medscribbler is granular where it makes sense and even indexes the handwriting, although we are probably a year away from the technology to produce a typed report with lab values and relevant scans automatically from a handwritten note directly.

CEOMike,

Your note reflects your lack of understanding of the problem.

An EMR with true granularity should have no problem (NONE) in inserting plain text anywhere into the note, whether the plain text arrived by voice recognition, by handwriting recognition, by importation from a file, by keyboarding, through some external macro mechanism, or about any other source that you can makeup.

As I've written before, the granular details (nausea, for example) should be independent of any particular ontology.  Instead, the ID of the granule allows ANY number of terms to be associated with the item, whether from MEDCIN, CPT, SNOMED, LOINC, NDC, or other.  Someday, there might be clear winners among ontologies.  When that comes about, all those old notes can still be cross-referenced with that winner.

The presentation of the note (ie, how pretty the note looks) should be independent of the granules.  That is, internally the granule is stored as "positive nausea" in computerese.  The note reflects that as "The patient complains of nausea.", or "Mrs Smith has nausea.", or "Mary notes nause too.", etc, etc.  We actually have docs who like "( + ) nausea, ( - ) vomiting, ( - ) diarrhea.....".  We have others who want the list bulleted. Medtuity notes are in full rich text with all of its advantages(bold, indents, font colors,font changes, bulleting, images, tables, etc).  The note can be dragged and dropped into Word without losing the formatting.  Creating the presentation separate from the data is very important.

We have an urgent care who saw 89 patients yesterday.  There are 8 "NPs-in-a-pharmacy"-type locations in the same city.  So tell me this urgent care is slow with that kind of competition.  If they were limited to handwriting or voice recognition, they would be dead in the water because both are far slower than well designed controls for entering medical information.  Their average patient time-in-the building is 30-some minutes and it is because of the efficiencies of Medtuity and their staff.  By the way, they create their notes contemporaneously.  They close the doors after the last patient, not after filling in notes at the end of the shift.

Anybody who wishes to use voice recognition with Medtuity can.  We've tested our product with Dragon and it works well.  Great product. It's as easy as it is with any other EMR.  Probably less than 10% of our users use that technology because they don't feel the need. We certainly allow it by having an editbox on every screen when doing an HnP.

My intention is to educate physicians on granularity and its advantages.  Programming for granularity is harder, but it does not limit the methods of inputting information. That is where you are wrong. 

 I do understand the problem, ie "the granular details (nausea, for example) should be independent of any particular ontology"  - Ok lets make nausea independent of any ontology -

The  patient has nausea,

She threw up,

she barfed,

It was pizza twice,

Mike was dizzy

Mike was dizie,

She had difficultly keeping it down

Oppsie 

etc. 

True granularity can only be achieved, within the confines of present day computing power and market costs, when an ontological system is chosen or determined.  

 

Back to the question: Is your EMR Granular?

Yes, Medtuity is granular. 

If you want to know about your EMR's granularity, ask during a demo for the demonstrator to put in new clinical information.  Let's get particular about it.  You're an ENT specialist and want sclerosis present as a choice on the TM exam. Ask the demonstrator to add that to your picklist/choices/controls for the exam of each TM.  Now ask the demonstrator to show you that new information in the database. Ask to see the specific identifier on it. Next ask to be shown how that (or any) response to a control can be formatted to your liking in all future notes.   Next, ask the demonstrator to show you how you can find that granule of data in any note among all of your patients.  Finally, ask how you can assign a SNOMED code to your TM sclerosis.

 Pass all of these and the EMR is granular.

 I don't think every piece of data enetered into the EMR needs purposeful granularity.

That is, I want to be able to manipulate the data for meaningful reports and so there are specific elements I am interested in. For example, I would want a report on on drug disease interactions and to Bryan's point, without granularity such a report would not be generated.

mchasemd:

If you want to know about your EMR's granularity, ask during a demo for the demonstrator to put in new clinical information.  Let's get particular about it.  You're an ENT specialist and want sclerosis present as a choice on the TM exam. Ask the demonstrator to add that to your picklist/choices/controls for the exam of each TM.  Now ask the demonstrator to show you that new information in the database. Ask to see the specific identifier on it. Next ask to be shown how that (or any) response to a control can be formatted to your liking in all future notes.   Next, ask the demonstrator to show you how you can find that granule of data in any note among all of your patients.  Finally, ask how you can assign a SNOMED code to your TM sclerosis.

 

This is probably beyond the scope of your average demonstrator...unless they are from Medtuity of course.

Seriously, it appears that granularity is one of the most critical differentiating points in the ,arketplace. Perhaps not so much for the here and now (arguable with P4P) but certainly going forward. It seems to be what separates an EMR that's for documentation vs. one that is for documentation plus population management (registry, P4P, drug/disease interactions, etc.)  

Lowell,

Though you don't believe all data should be granular, who is going to be the arbiter in choosing.  Though you may never note sclerosis of the TM, it is important to another physician.

If we have physicians voting on importance of granular, then only vital signs would receive all votes.  HgbA1c would receive lots.  Monofilament exam of the foot would be gaining popularity.   Specialists would be where they are today- unable to collect useful information on breast masses as a breast surgeon.....name your problem and specialty.

Either an EMR is designed to be agnostic on which data is important, or it's designed to collect certain (limited) items.  Again, who is the arbiter?  Some programmer?

We prefer to do the hard work up front and allow the user to determine relative importance.

Still, another whole area is being ignored that has much to do with granularity-- computable data.  Once data is computable, no matter whether it needs a CPT, ICD, LOINC, or SNOMED, it can ease the burden of many things for a practicing doc.  It can initiate automatic stuff like writing a letter, sending a fax, sending an electronic lab, updating a health maintenance guideline, including pateint education material at checkout, including a CPT for a procedure, etc, etc.  Now who will decide on whether or not that clinical information is important enough to be granular?

Granularity is a whole design paradigm and one that should not be ignored in your EMR selection.

 I understand your points.

I wonder if granularity was a chit requirement?? 

mchasemd:

Though you don't believe all data should be granular who is going to be the arbiter in choosing.  Though you may never note sclerosis of the TM, it is important to another physician.

As a strong advocate and implementer of "granular" data (I call it "discrete" or "structured" data, that is, searchable, queryable, actionable, codified, etc. data), I've also wrestled about how far to take it. As you suggested, it all depends on who is making the decisions. My spiel for making everything granular has always been, "Well, you never know what questions will be asked a year or five years from now, and if the data isn't discrete, you can't look back at the data or report on it or take action based on the data. Just answering questions that we have today is not good enough."

With that being said, creating a very structured and granular operative note for a minor (and maybe useless) procedure like a newborn circumsion, that includes discrete elements like, method, anesthetic, prep material, size of device, complications, etc. may be huge overkill, because how often and in what century will anyone realistically want to know any of these things. Theoretically it is possible, but why even use the processing power or data storage when a note like "Circ with 1.3 Gomco" is good enough?

So, who decides today? I don't know. Maybe some system some day will spit out a patient-specific, method-specific education sheet based on the method of circumcision which would not be possible with a simple note. Without comprehensive and complete granular data there is no chance at all for intelligent medical records, and so I vote for everything to be granular even if it seems pointless and overkill to paper-oriented folks today.

 Granularity seems analogous to the movie Matrix. What you see looks pretty and in the background there is all of this code flyinging around that represents what you are seeing. During the movie there were these moments when time was repeated. With a granular EMR, that can happen. With a non-granular EMR, you c....I have probably gone a bit over here...stopping now. The earthquake last night rattled my brain a bit.

mchasemd:

Lowell,

Though you don't believe all data should be granular, who is going to be the arbiter in choosing.  Though you may never note sclerosis of the TM, it is important to another physician.

If we have physicians voting on importance of granular, then only vital signs would receive all votes.  HgbA1c would receive lots.  Monofilament exam of the foot would be gaining popularity.   Specialists would be where they are today- unable to collect useful information on breast masses as a breast surgeon.....name your problem and specialty.

Either an EMR is designed to be agnostic on which data is important, or it's designed to collect certain (limited) items.  Again, who is the arbiter?  Some programmer?

We prefer to do the hard work up front and allow the user to determine relative importance.

Still, another whole area is being ignored that has much to do with granularity-- computable data.  Once data is computable, no matter whether it needs a CPT, ICD, LOINC, or SNOMED, it can ease the burden of many things for a practicing doc.  It can initiate automatic stuff like writing a letter, sending a fax, sending an electronic lab, updating a health maintenance guideline, including pateint education material at checkout, including a CPT for a procedure, etc, etc.  Now who will decide on whether or not that clinical information is important enough to be granular?

Granularity is a whole design paradigm and one that should not be ignored in your EMR selection.

I think Matt is right on the money and we share common philosophies.