Work on the monograph is coming along well, and, as the title of this post implies, the end is finally in sight! After having changed many times, the outline and content are stable at eight chapters plus any required appendices. Five chapters have been written, two are in progress and the remaining chapter consists only of examples. When this project began, I somehow had the ridiculous idea it would take only four months to complete. Since March 2017, there have been four major changes to the monograph’s content, and each change added a significant delay. The most recent delay was six months long…
As anyone who has experienced our healthcare system up close can attest, there is no actual system, just assorted parts that interact. I have learned this the hard way, which is by helping family members navigate the maze of modern health care. Two serious patient safety issues involving medications occurred, one that caused serious morbidity, and another that was caught before any real harm was done. Addressing both issues required numerous calls to pharmacists and doctors, yet I have the impression that nothing has changed. One should not have to have a doctor in the family to avoid medical errors.
While I wish that neither incident had occurred, they altered my thinking in terms of the monograph in a positive way. My initial interest in processes grew out of software development challenges. Accordingly, much of my blog output has been directed at software design issues. However, looking at care delivery itself, absent software systems, became a focus after these incidents. There was a six-month delay between chapters four, which was finished in September, and chapters five and six, which were started in April, because I realized there was a need to describe clinical processes in much greater detail purely for the sake of understanding and analyzing the many aspects of care delivery. This six-month long forced introspection enriched and helped to evolve my view of clinical processes.
Clinical processes have many moving parts, and many of those parts are ad-hoc adaptations (workarounds) invented by process participants. Frequently, there is a significant difference between what should happen (formal process, as written in policy and procedure documentation) and what actually happens—even when no EHR is present. Process variations may be introduced by a number of factors. Variations created by those performing the process may or may not be a good idea. (After all, workarounds are not necessarily bad if the formal process is poorly designed.) Likewise, patients may introduce process variations, and those variations are actually good if they help to ensure each patient gets the care that is best for his/her situation.
The unavoidable reality is that clinical environments are inherently dynamic and messy, and when safety or quality issues arise, the underlying causes are likely to be multi-factorial. No two ICUs work the same, and primary care practices, even those under the auspices of the same organization, may vary. So what does all of this mean? It means we need a more scientific way of describing, decomposing, and modeling clinical processes so that for any given process we understand what it actually accomplishes, how it affects patients and those who perform it, and what goes wrong. The first stab at meeting all of these requirements is found in the two chapters currently in progress.
Matters of software usability and safety have also taken on a new light with this evolution in thinking on clinical processes. Software implementation adds new ways of performing tasks, disrupting existing clinical processes. The resulting disruptions are only partially understood because the original processes were probably incompletely understood and documented. Thus, addressing usability and safety issues requires both looking deeply into existing processes and their variations in addition to looking at software-specific issues. Stated another way, workarounds and disruptions that arise after EHR implementation are not likely arising in an otherwise orthodox process environment. The more probable case is that heterodoxy is already present and the EHR simply adds some of its own. Further, the mistaken belief that orthodoxy ever prevailed likely results in many futile attempts to correct the problems that arise after implementation.
Usability testing, as now performed, does not have a well-defined method for capturing the nuances of clinical processes in a standard way. Further, usability research is itself not standardized across researchers and institutions. Since each care setting is different, usability findings in one setting may not apply well in another, even though they are ostensibly the same.
The complex interplay between the shortcomings of current clinical process analysis methods and how those methodological deficiencies affect research on workarounds, usability, safety and quality improvement will be a major blog theme going forward.
Databases for everyone!
As a techie, the proliferation of database tools is one of the most welcome developments of the last decade. I remember writing TurboPascal code just to get basic file management capability for my programs, while today getting sophisticated database tools is only a matter of downloading. NoSQL tools allow one to break out of the relational model, and in some cases, that adds significant capability. I find graph and document databases most compelling. Document data stores seem to be a convenient choice for some use cases where relational feels like more trouble than its worth. Graph databases, on the other hand, make some things that are genuinely difficult with relational systems much easier. Processes are directed graphs, so capturing the natural structure of a process is much simpler in a graph database. Complex networks of relationships are also easier to code and visualize using graph databases. The spread of an infectious disease is a graph, as are ontologies and family trees.
NoSQL databases have been around officially since around 2009 (though some would classify the MUMPS database as NoSQL). For health care, with its many and complex data types and relationships, NoSQL, and graph databases in particular, offer a world of possibilities. All types of NoSQL data stores have matured significantly over the last three years and are worth a serious look.
Resource pages and posts
Resource page updates took a hit along with the posts. Happily, I managed to update the resource pages on EHR Science and Clinical Workflow Center in May, and expect regular updates to continue.
I have really missed blogging, and I hope this to be a return to a regular posting schedule. Posts may be only once or twice per month for the summer, but should be weekly by autumn. There are so many things I want to discuss, and I really miss hearing from all of you and debating the arcane aspects of processes, software, and systems. It’s good to be back.
{ 0 comments }
