Showing posts with label Clinical Analyst. Show all posts
Showing posts with label Clinical Analyst. Show all posts

Sunday, December 2, 2018

The Offerings of (Applied) Clinical Informatics

Hi fellow readers,

If you are involved in electronic medical record (EMR) implementations, or healthcare technology in general - Someone has probably forwarded to you the recent November 12th New Yorker article by surgeon and innovative healthcare thinker Dr. Atul Gawande :


In the style of Dr. Gawande's excellent narrative and analysis, this is a well-written, thoughtful piece about the common challenges of EMR implementation, as told from the front lines of medicine: The surgeon who feels the EMR is controlling him, instead of vice-versa. The Internal Medicine Primary Care Physician (PCP) who spends hours after her shift documenting her notes and managing problem lists. The rigidity of EMRs, compared with the fluidity of paper. The use of physician scribes, with questionable improvement in outcomes. And the patients who lose when their provider no longer focuses solely on them during a clinic visit. These are all real - but there is more to the story.


In his piece, Dr. Gawande very eloquently describes these real and common scenarios, why they happen, and their impacts on providers and patient care, both for good and for bad. I appreciate his storytelling, and how it educates people about some very real usability issues, which impact users all across the clinical spectrum - and the patients they serve.

So this is not a rebuttal, but more of a commentary on his piece in the New Yorker. As a clinical informatics professional, I was somewhat disappointed that nowhere in his essay did he share the term "clinical informatics" - The discipline that works to implement emerging technology in the safest, most sensible, and cost-effective manner possible.

Given the wide audience for this piece, it could have been a great opportunity to educate the general public about this underrated, poorly-understood, but very important clinical discipline. 

What is Clinical Informatics?

For those of us who work hard to implement these technologies, we often to struggle to explain this (still!) emerging discipline of information engineering, and how/why it impacts clinical workflows, safety, efficiency, and provider satisfaction.

To begin : Informatics is a branch of the academic field of information engineering. Taken from the current Wikipedia page on Informatics :
"It involves the practice of information processing and the engineering of information systems, and as an academic field it is an applied form of information science. The field considers the interaction between humans and information alongside the construction of interfaces, organisations, technologies and systems. As such, the field of informatics has great breadth and encompasses many subspecialties, including disciplines of computer scienceinformation systemsinformation technology and statistics. Since the advent of computers, individuals and organizations increasingly process information digitally. This has led to the study of informatics with computational, mathematical, biological, cognitive and social aspects, including study of the social impact of information technologies."
Informatics is a branch of information sciencenot information technology, that sits right in the intersection between healthcare (clinical medicine), our health system (clinical operations), and information technology and communication : 

If IT professionals need to focus on supporting the technology that will store and route all of this clinical information, then Informatics professionals are more focused on what information will be stored, and how it will be organized and used for clinical purposes. 

To do this, Clinical informatics professionals ('Informaticians') need to focus on what care is being delivered, and how exactly clinical staff is using (or planning to use) the information and new technology to improve outcomes :
  • How will the technology impact the delivery of patient care?
  • In which workflow(s) will clinical staff use the technology?
  • Is the technology safe, efficient, and well-configured?
  • Are any technical, process, or terminology standards needed to support the technology in a harmonious way?
  • Does the technology make it easier to deliver good patient care within the planned workflow(s)?
  • What kind of training will clinical users need to correctly use the technology?
  • What other things might be needed to achieve a successful implementation of the technology?
  • What research opportunities will the technology make possible?
So to accomplish their mission, clinical informaticists have to care about organizing both data in and data out : 
... and the breadth of workflows that clinical staff will use to deliver quality care. This means studying a wide variety of disciplines :
  • Clinical medicine, terminology, roles, and operations
  • Cognitive and behavioral science
  • Evidence-based design principles
  • Interface design, usability and interoperability
  • Data structure design (e.g. data indexing, archetypes, hierarchies, and logical functioning)
  • Heuristics
  • Process analysis and engineering
  • Linguistics and terminology management
  • Project management
  • Legal/compliance environmental analysis
... and more. It's this kind of detailed analysis and workflow ownership that is necessary to convert turbulent workflows into laminar workflows : 

I know this because I am one of the many physicians who is now board-certified in Clinical Informatics by the American Board of Preventive Medicine (ABPM), a program supported by the American Medical Informatics Association (AMIA). With over twelve years of practical, applied clinical informatics experience, I have seen the problems created by turbulent clinical workflows, and worked hard to make them laminar again - And seen the improved outcomes and provider satisfaction that informatics can offer.

Why Clinical Informatics?

Clinical Informatics professionals are especially helpful when implementing electronic medical records because, as Dr. Gawande points out - EMRs enforce a certain sense of operational rigidity and role accountability that is difficult to identify (or enforce) in a paper-based clinical environment. If operational standards are not strictly enforced prior to EMR go-live, then these roles will be re-aligned after go-live : 

Given this realignment of roles and responsibilities, a significant amount of workflow analysis and engineering must occur for EMR configurations to align with user needs and expectations. Clinical informaticists ('Informaticians') are particularly adept at this sort of workflow analysis and design, translating the needs between the clinical and IT realms, and providing design and project management support.

Where are the Clinical Informaticists?

It can be difficult to identify the clinical informatics professionals on many EMR implementations, because there are often challenges in separating them out from other common HealthIT roles - few of which require clinical backgrounds. While these roles commonly overlap, and many people fill more than one role, here are some gross generalizations - As a caveat, your mileage may vary : 
  1. Clinical analysts - These are generally the professionals who work with end-users to analyze, build, test, and implement clinical content in an EMR. While analysts are the backbone and workhorses of configuration for most EMRs - they generally focus mainly on the tools inside the EMR, which occupies most of their time - and often do not have time or expertise to manage additional workflow tools that may be necessary outside the EMR. 
  2. Application Support Professionals - These are often the 'second-tier help desk' or 'second-tier support' professionals who work together with the help desk, to respond to more detailed user questions, troubleshoot issues, and provide elbow-to-elbow support to end-users who might need additional assistance.
  3. Clinical/credentialed trainers - These are the professionals who are experts at  studying clinical workflows, studying application features, developing training materials and curricula, and delivering that training in classroom and online settings. They also sometimes assist application support professionals in direct elbow-to-elbow settings.
  4. Project Managers - These are the professionals (many with PMP certificates), who are experienced at planning, budgeting, scoping, and leading projects. Their tasks include meeting frequently with stakeholders, developing detailed project plans, timelines, and deliverables, and keeping the work team on schedule and on budget.
  5. Analytics professionals / report writers - These are professionals who are focused on getting data out of the system, validating it, interpreting it, and displaying it in a meaningful way, to help advance clinical care and research needs.
  6. Process Improvement Specialists (E.g. Lean or Six Sigma- These are trained professionals who typically report to quality to study clinical processes, study outcomes, and improve upon them. They may or may not have clinical experience.

While clinical informaticists ('Informaticians') may work with all of the above, or fill some of all of these roles, the informatics role is unique in their ownership of implementing clinical workflows, change management, standards, clinical terminology and translation, information design, indexing, archetype analysis, usability, and clinical outcomes. Clinical informaticists are skilled at critically evaluating details of workflows and configuration, and adjusting them, when necessary. While it is not always necessary, most clinical informaticists come from clinical backgrounds, which is very helpful when trying to interface with clinical staff and navigate clinical terminology, roles, or processes : 



Despite their important role, there are other things that may make it more difficult to identify a clinical informatics professional:
  • For many years, clinical informatics was a poorly-understood, poorly-controlled term. Since clinical analystsapplication support professionalsclinical/credentialed trainers, project managers, analytics professionals/report writers, and process improvement specialists are all involved in information design and EMR support - some of them might refer to themselves as 'Informaticists' or 'Informatics professionals' - Unfortunately this loose association clouded the role for the new generation of clinical informaticists who come prepared with formal informatics training and certification
  • Clinical informatics often reports to IT departments, where there can be a competition for resources. (It can be challenging to budget for informatics when there are also valid and competing IT needs.) 
  • Some people seeking to lower the cost barriers-to-entry for their projects, may sometimes minimize the importance of having clinical informatics professionals available on projects to help support the clinical analystsclinical trainersreport writersapplication support professionals and process improvement specialists who help develop content and support end-users. 
  • Some organizations believe that 'sample content' can help save significant time by replacing clinical workflow evaluations and operational discussions with sample content that has already been developed by another organization. Unfortunately, these workflow evaluations and clinical discussions are still necessary for gap analysis and proper scoping, and to validate and align configuration with end-user needs, expectations, and training - and so there generally not much time saved from using sample content.
  • Many workers fulfill the role of clinical informatics, but with other vague job titles like 'solutions engineer' or 'clinical workflow analyst' or 'EMR implementation specialist'.
This somewhat-ironic 'Informatics terminology issue' was recently highlighted in this humorous (!) segment from the November 2018 AMIA conference in San Francisco, featuring AMIA President and CEO Douglas B. Fridsma : 

Given these terminology, budget, and support challenges, many HealthIT projects and EMR implementations occur with little or no significant informatics support. 

The Cost of No Informatics

The easiest way to demonstrate the importance of clinical informatics comes from an examination of a best-practice model for implementing clinical workflow changes : 
The change management procedure outlined above is a sort of 'best-practice' series of steps which, only if performed in order, will help ensure that a new workflow is safe, best-practice, compliant, and efficient before it is built, tested, and expertly delivered with a minimum of disruptions. It will also help engage users, ensure that testing is complete, align expectations, and ensure that users are properly trained and supported during go-live. 

Making great clinical configuration, workflows, and outcomes is a great deal of work. Many organizations struggle to have the time or resources to fully complete all steps, so to meet project deadlines, they often have to make compromises - while still trying to fulfill as many of the steps as possible. 

Without well-trained, well-defined clinical informaticists there to support the project team, a few things become clear :
  1. It is usually difficult to manage all of the steps of a 'best-practice' change control and project management process. This can result in user dissatisfaction, lack of engagement, and unplanned outcomes.
  2. Terminology and naming conventions may be difficult to manage. This can result in reporting challenges, and difficult validation of data.
  3. Other roles (clinical analystsapplication support professionalsclinical/credentialed trainers, project managers, analytics professionals / report writers, and Performance Improvement specialists) may have translational challenges when trying to engage with clinical staff.
  4. Prioritization of projects may be difficult, without an accurate assessment of needs, and proper scoping and prioritization.
  5. Without adequate analysis, scoping, prioritization, and design pre-work - analysts may spend time re-building workflows that require frequent adjustments.
In my experience, organizations that support the role of clinical informatics to augment their project team generally see better use of their technology, improved user satisfaction, better staff engagement, and improved outcomes.

To help improve physician satisfaction...

To help clinical staff in Dr. Gawande's organization better utilize their technology, it's important to critically assess the configuration and workflows that the providers and their teams are working in every day :  

... and ask some of these questions : 
  1. Have all of the steps of this workflow been properly organized, designed, and budgeted? 
  2. What is the clinical governance like? Is it shared or siloed? And how does it interact with administrative governance?
  3. Healthcare is a team sport - Do the physician, nursing, and pharmacy leaders need to meet to critically assess and re-evaluate their shared clinical goals and needs?
  4. Have the current-state and future-state workflows in all service lines been well-documented?
  5. Are there templates for common operational tools and documents found both inside and outside the EMR?
  6. Do directors and clinical chiefs have adequate support for their participation in EMR discussions (analysis, design, and testing)?
  7. What is the request intake, prioritization, and project management process like?
  8. How many ways can users find solutions? Is end-user education easily available on the organizational intranet?
  9. How is clinical terminology managed and harmonized?
  10. How many clinical staff have been trained in workflow development, project management, or document writing (e.g. policies, orders, order sets, protocols, guidelines, clinical documentation, clinical decision support, etc.)?
And : Are there trained clinical informatics professionals available to help educate, evaluate, and oversee all of the above?



FINALLY - A big thank you to Dr. Gawande for writing such a great, real, and thought-provoking piece. Provider burnout is a real issue, and we need to work together to combat it. I hope my discussion helps shed light on how clinical informatics can help change the environment for both providers and patients. 

Remember, the above discussion is for education purposes only. Your mileage may vary. What are your thoughts? Are there other ways to improve clinical workflow and provider satisfaction? If you have any comments or feedback, leave them in the comments box below!

Wednesday, January 12, 2011

Order Set Development and Preparing for the Downtimes

So as if order set development wasn't challenging enough, some people will ask :

"Dirk... So once you go electronic, you don't need paper anymore, right...?"

Well, here's the bad news. You will probably still need paper order sets.

"Huh...?"

Yep. It's true.

You will probably still need paper versions of all of your order sets, just in case your EMR / CPOE goes down.

I know it seems like a lot of work, but think about this :
  1. After you develop electronic order sets, your doctors will come to rely on them.
  2. The time they save using good order sets will increase their efficiency.
  3. The good order sets you've built will help them standardize care.
  4. This improved efficiency and improved standardization will, over time, allow you to make staffing changes.
The problem, however, will be : What happens when your EMR goes down?
  1. Will your docs have order sets that accomplish the same goals as your electronic order sets?
  2. Will your docs suddenly lose efficiency that they accomplished with those electronic order sets?
  3. Will your docs be able to handle as many patients as they did with the electronic order sets?
  4. If your docs rely on those order sets, and your computer is down... What paper order sets will they use?
So here's the message : It's good practice if you simultaneously develop matching paper and electronic order sets.

"But Dirk... it takes so much time to make an electronic order set... how do I make a matching paper order set?"

Some people, when confronted with this demand, will try this approach :
  1. Have one team make the electronic order sets
  2. Have some person, after the electronic order set is built, type out a matching paper order set.
This approach works, but I think a smoother approach is to develop an order set process that allows your informaticists to develop both paper and electronic order sets as part of the same process.

This gets us into a discussion about order set development.

After a hospital goes electronic, they generally try to use the same process they used before to make paper order sets. Unfortunately, because of the new demands an EMR brings :
  1. Now - Will need both paper and electronic order sets developed at the same time
  2. Now - Will need better engineering (e.g. order sets separated from protocols, etc.)
  3. So... Will need informaticists to help engineer those changes
  4. And... Will need Clinical IT Analysts to help build the work that the informaticists do
... Eventually, you start to realize : The old process doesn't meet the demands of an EMR.

So I generally recommend developing an order set change process.

The Order Set Change Process

Order sets are like any other clinical tool your hospital uses : You will need to define :
  1. Who is the owner?
  2. Who are the builders / project managers? (Generally, an Informaticist + Clinical IT Analyst)
  3. What importance/priority does the order set/change have?
  4. Who will assign this importance / triage changes?
  5. Who will build the first draft? 
  6. Who will test the new order set / changes?
  7. Who will review the testing results?
  8. What education plan (if any) will you need?
  9. What companion documentation (if any) will you need?
  10. What implementation plan (if any) will you need?
  11. What accompanying clinical policy (if any) will you need?
  12. What committee will "approve" your order set, after testing?
  13. Who will implement the order set and the implementation plan?
So if you need to build both a paper and electronic order set, at the end of this process, here are my recommendations :

A. Develop an order set "Change Request Form". You will need this to help understand the expectations and understanding of your owner. Typical questions you might ask include :
  1. Date of order set request?
  2. Owner of order set? (I generally recommend this be a department director)
  3. Builder/Informaticist assigned to order set?
  4. Request :  (   ) new order set    (   ) delete order set     (   ) change order set
  5. If requesting a change, what is the previous order set you wish to change? __________
  6. What change are you requesting? (Please be specific) : ________________________
  7. What companion documentation will you need? : _________________________
  8. Will you need an education plan/curriculum for this change? : ____________________
  9. Will you need an accompanying clinical policy to support this? : ___________________
  10. Will you need a protocol to help support this order set? : __________________________
  11. Will you need an implementation plan for this change? : _________________________
  12. Priority of change : (1-5, 1=low, 5=high) : ___________
  13. Expected date of completion : __________________
(Generally, at the bottom of this form, it's helpful to have signature lines that match the key, important parts of the process below, so you can help keep track of the process...)


B. Develop a process. You will then need a process where that change request form helps lead your process. A typical process might look like this : (I've highlighted the various characters, so you see how many people might be involved and the roles they play...)
  1. Change Request Form is published throughout hospital (explain to docs/directors that all order set building/changes/deletions will be done according to this form)
  2. Change Request Form is completed by owner, and brought to CMIO for triage.
  3. CMIO and Clinical Analyst Project Manager review form and assign a priority and assign an informaticist and clinical analyst to work on the project.
  4. Informaticist works with owner to define workflows.
  5. Informaticist creates first paper draft of order set, using orders found in your electronic order library/EMR. (This helps make sure your paper version matches with your electronic order sets.)
  6. Informaticist defines testing plan : What front-line clinical staff will be needed for testing?
  7. Informaticist gives first paper draft to clinical analyst to build first electronic draft.
  8. Informaticist helps prepare companion documentation (if needed)
  9. Informaticist helps prepare clinical policy (if needed)
  10. Informaticist helps prepare protocol (if needed)
  11. Informaticist helps prepare education plan/curriculum (if needed)
  12. Informaticist helps prepare monitoring plan (if needed)
  13. Informaticist helps prepare implementation plan (if needed)
  14. Informaticist and Owner execute testing plan - Using front-line staffmembers the owner makes sure show up for testing
  15. CMIO and Informaticist review results of testing together, and review current versions of paper/electronic order sets, protocols, policies, companion documentation, education plan
  16. If CMIO and Informaticist approve - Then proceed
  17. CMIO puts paper/electronic order sets on agenda for Order Set Committee - Sends notification/drafts/links to committee members
  18. Informaticist and Owner - Pass clinical policy through committee for approval
  19. Informaticist and Owner - Pass documentation through committee for approval
  20. Informaticist and Owner - Pass protocol through committee for approval
  21. Order Set Committee meets to review both paper and electronic order sets
  22. If Order Set Committee approves - Then proceed
  23. CMIO sends notification of approval of final paper draft to printshop : Paper order set is coded and published (usually to a "red file cabinet" where you keep "order sets needed for electronic downtimes)
  24. CMIO sends notification of approval of electronic version to clinical analyst  : Electronic order set is coded and published (by your analyst moving from test-->live, usually via your EMR)
  25. Informaticist and Owner conduct implementation plan
  26. Informaticist and Owner conduct monitoring plan (if needed)
  27. Owner : Continuously monitors order set after use
  28. (Restart at step 1 if needed) 
Yes, it's a lot of work. Seems monotonous and boring, but you will need to define a process for order set change management, or else you will end up with order sets that lack support, order sets nobody uses, order sets with no monitoring/involvement, and poor project management.

You'll notice that the Informaticist title up above appears in many steps in the process. This is why you'll want an informatics platform after you "go EMR". Clinical IT Analysts (sometimes mistakenly referred to as "programmers") actually play a much smaller role in implementation than most people think - They're mainly there during development, to make the technical changes and advise the informaticist on technical limitations. You'll also notice that order set owners, once you define this process, will become much more involved in the development, testing, implementation, and monitoring of their order sets.

Finally, you'll want a CMIO to help manage your informaticists, and help corral your doctors/directors into this new process.

And, if you engage in this sort of process, your informaticists will be building/approving simultaneous paper and electronic order sets :
  1. ... so you can have an electronic order set that helps expedite the electronic ordering process (CPOE) for a common clinical scenario...
  2. ... and at the same time, you'll have a matching paper order set that can be filed in an emergency file cabinet to be used during electronic downtimes.
Phew! As I said : With order sets, there are no shortcuts

This is part of the culture that EMRs bring. My advice : Prepare for change. :)

Would love to hear other people's stories - of how you developed a streamlined change management process for your order sets - I look forward to feedback! :)