apractis.com Blog

Proposal of systems review team about documentation of critical events during implementation planning for a new EMR system-

Practice at other system facilities:  non-medical staff responders
document in “significant event” system of the EMR and medical staff responders either document in the clinical documentation system template-driven tools or dictate.

Proposal: as above, exclusive of dictation (takes 24 hours for TAT &
upload to EMR).

Attached is screen print of significant event progress note.  If
additional documentation is needed for PI purposes, that would be
extraneous to this process.

Please vote “yes” or “no” to the proposal so that I can put
closure to this item. Thanks.

Nurse Practitioner for stroke program response:

I would need more info because we have a particular process for
documenting particular times and use it for data collection for stroke.
Also, we have to keep a log per what we capture and have to report on for state agency and Joint Commission

Personal COMMENTARY on issue:

Actually this is a more complex workflow question that gets to the core of several similar issues in the field of informatics. unless I am mistakenly making too many assumptions, in the absence of seeing the screens or knowing the details behind this discussion.  Stroke certification processes have been mandated all over the country with guidelines based “reporting” that have created huge resource expenditures by hospitals just to keep up with the data collection and reporting. A big factor has been a global lack of understanding of the “documentation” workflow that ties the real time clinical care process to concurrent case review  to near term data monitoring, to back end data retrieval, reporting to third parties, and analysis.  The closer one gets to seeking the core principle of clinical documentation—document ONCE, document efficiently, effectively, legibly, etc—the more this issue keeps rearing its ugly head. (Again, please forgive me if I am making too much of this, having not seen the initial email).

If a stroke team response is a team-based response, where each team member is playing multiple roles that relate to both clinical care, clinical documentation, clinical data capture, and clinical case tracking workflow, then the separation of documentation solely based on pre-defined “job type” is highly artificial that leads to different locations and methods of capturing information that must inter-relate for both clinical, operational and data analytic purposes.  So lets start with a description of how clinical electronic documentation should function in order to meet the above objectives. Where the current or near term “system or systems” does not meet this need, then the “price to pay” in terms of professional or staff time duplicating information capture or losing continuity due to its separation must be calculated as part of decisions about how to “work around” the inadequacies of what is available.  This is an absolute general rule of medical informatics that is, unfortunately, rarely set in motion due to the lack of its inclusion in design of documentation systems to begin with  (until quite recently in limited scenarios)

This is how this should work:

In emergency room a series of data points begins, starting with time of entry, triage, decision support, pending diagnosis, vital signs, relevant neurologic system findings, radiology results, documentation of nurse observations, then clinician observations, then comments or suggestions of remote specialists, orders and transition to next point of care.  When ANYONE involved in the care of this patient is about to document anything they do, it is immediately assumed to be starting with data captured in previous steps, by people playing roles that overlap clinical and process flow. (for example, a stroke responder might be documenting the actual NIH stroke scale and it is “confirmed or signed off” by the provider, not re-entered in a second clinical documentation process).  The “time” stamps should be automatically captured at each critical point of –triage, decision, result, order, next order, result, event, etc—, associated with that event whether machine or human generated phenomenon, and carry forth thru the documentation without any downstream clinician or data manager having to “recreate” the presumed time based on retrospective chart review or copying over from some parallel “system”. This leads to the primary goal of the system, which is not to generate reports for third parties, but to efficiently lead to safer and more consistent care. The fewer places to re-document a single piece of information that has downstream clinical or analytic relevance, the fewer opportunities for further error and inefficiency.

So without going too far into the abyss of the massive issue in medical informatics of interlocking roles-based fluid non-redundant clinical documentation (the holy grail in many ways, that the whole industry struggles with)—I would very much warn against band-aid solutions that try to vote on one of the lesser of two evils. Because systems of documentation currently tend to not function like this even WITHIN one single workflow domain like the ER (but getting a bit closer) when new programs with external reporting accountabilities are imposed-even if a good thing overall-there is the new creation of added time, inefficiency and duplication of effort on the data entry/capture/reporting realm without concomitant allocation of human time resources to achieve this effectively. Happens all the time, everywhere, over and over.  As both a medical informatics person and accountable for a cross-organizational neuroscience care program, it is difficult to embrace this phenomenon repeatedly, knowing the consequences.

So I would ask that we look as a group at “team based documentation and communication” as it relates to at least a few core clinical processes in the future state, the current state and the intermediate state, with an eye toward confidence in probability of the future state. We map the workflow and roles of each of the participants, being careful to not assume that today’s stroke responder or stat responder assistant/tech/nurse/primary md/captain/intensivist/remote specialist, etc are necessarily the same people doing the same aspects of this process one year from now as they are today. If the documentation needs are tied to the minute-by-minute “dynamic and contextual role” of the individual documentor, rather than the “static job role” then the solutions recommended, even if interim work-arounds, will have far fewer negatives and more positives.

Here is a simpler way to look at this:

At any point in anyone’s documentation process relative to what they are accountable for the common principle applies that before he/she has to enter, dictate, type or create a piece of data –a time stamp, an event capture, a clinical finding, a result, etc—that the documentation “system or application” he/she is using FIRST makes available anywhere else in the “systems” that the data exists, so that it can be viewed and “IMPORTED” into the relevant location.  That is why the current iteration of PN2G documentation templates and discharge depart processes, however limited by still being a “work in progress” at least try to incoporate importation of vitals, diagnoses, demographics, etc that are relevant to non-duplicative continuity of care.  Even these fall way short but are directionally consistent with this principle.

If that simple (but not readily achieved) concept is being adhered to, then it will be far less relevant or critical to any downstream workflow what specific documentation “system” is being used by any one “person or role” at any point in time. The problem is that, in the absence of being even close to that model, we end up with different overlapping roles, where there is not such a black-and-white separation of specialist medical staff/primary care medical staff/midlevel/nurse/support staff roles and accountabilities as it relates to how/when each is “documenting” what is being done at the moment.