Clinical Terminology : What is a History and Physical (H&P)?

Hi fellow CMIOs, CNIOs, Applied Clinical Informaticists, and other #HealthIT friends,

Today, I'm sharing more on the importance of terminology, in untangling and streamlining clinical workflows. 

In day-to-day healthcare, effective communication is the bedrock of success. Ensuring accurate and efficient communication in healthcare settings hinges on the use of standardized clinical terminology and documentation practices.

So to better understand the importance of standardized terminology in untangling and optimizing clinical workflows, we will look at one of the most common anchors of clinical workflow - the History and Physical (H&P). 

The History and Physical (H&P) is one of the first things medical students learn to perform in medical school. (Since around 1968, it's been generally written in the same structure as the SOAP note by Larry Weed, MD.) Asking ChatGPT40 for a summary on 11-10-2024, I got this :

A History and Physical (H&P) is a comprehensive document that records a patient's medical history and a detailed physical examination performed by a healthcare provider. This documentation is typically created at the time of a patient’s hospital admission, outpatient clinic visit, or before a surgical procedure. The purpose of the H&P is to provide a structured, thorough assessment of the patient’s health status, which helps guide diagnosis, treatment, and ongoing care.

The H&P typically includes the following elements:

1. Chief Complaint (CC): A brief statement summarizing why the patient is seeking care, often in the patient’s own words (e.g., “chest pain”).

2. History of Present Illness (HPI): A detailed description of the patient’s current symptoms or concerns, including onset, duration, characteristics, associated symptoms, and any factors that worsen or improve the condition.

3. Past Medical History (PMHx): Information about any prior illnesses, surgeries, hospitalizations, and chronic conditions, as well as any ongoing treatments or therapies.

4. Medication History: A list of current medications, including prescriptions, over-the-counter drugs, supplements, and dosages.

5. Allergies: Details of any known allergies to medications, foods, or other substances, along with reactions.

6. Family History: Information about the health of immediate family members to identify any genetic or hereditary conditions.

7. Social History: Insights into the patient’s lifestyle, including smoking, alcohol use, occupation, living situation, and exercise habits, which may impact their health.

8. Review of Systems (ROS): A systematic check of the patient’s body systems (e.g., cardiovascular, respiratory, gastrointestinal) to identify any other symptoms that may not have been initially reported.

9. Physical Examination: A head-to-toe assessment performed by the healthcare provider, covering major organ systems and noting findings like heart rate, lung sounds, and any abnormalities.

10. Assessment and Plan: Based on the gathered information, the provider lists diagnoses (or differential diagnoses) and outlines a plan for treatment or further evaluation.

The H&P is essential for creating a baseline of the patient’s health status, supporting diagnosis, guiding treatment, and facilitating communication among healthcare providers. In electronic medical records (EMRs), standardized templates often guide providers through completing these sections thoroughly and consistently.

While ChatGPT40 gives us a reasonable starting point that most medical professionals will quickly recognize, I'd like to add that it did not explicitly call out Surgical history (SurgHx), Psych history (PsychHx), or OBGYN History (OBGYNHx), which are often separately called out in certain H&Ps.

So in addition to the PMHx, PSurgHx, SocHx, PsychHx, and OBGYNHx, the foundations of Larry Weed's SOAP note can be found in most H&Ps : 

• SUBJECTIVE (S) = What is the patient telling you? (e.g. CC, HPI, ROS, etc.)
• OBJECTIVE (O) = What do you see? (e.g. Physical Exam, Vitals, Labs, Radiology, etc.)
• ASSESSMENT (A) = How do you interpret this, and what do you think the patient needs?
• PLAN (P) = What is your plan to address these issues?

While this gives us a helpful framework to start from - it doesn't really clarify the eleven (11) different types of H&Ps that are commonly used in healthcare. Let's start off our journey by looking at the first four : 

I want to call out these first four (4) H&Ps because they are sometimes confused in elective pre-operative (and pre-procedural) workflow discussions : 

1. Primary (General) Pre-Operative (or pre-procedure) H&P and Risk Evaluation - That general pre-operative or pre-procedure H&P that is commonly done by a Surgeon, Proceduralist, or Primary Care Provider (e.g. Internal medicine, Family medicine, Geriatrics, Pediatrics, or OBGYN), which includes a pre-operative (or pre-procedure) risk evaluation and optimization plan.
2. Secondary (Focused) Specialist Pre-Operative (or pre-procedure) H&P and Risk Evaluation - That secondary, focused pre-op or pre-procedure risk evaluation that might be needed for patients with complex histories, typically done by one or more specialist(s) at the request of the Surgeon, Proceduralist, or Primary Care Provider doing the Primary (General) Pre-Operative (or pre-procedure) H&P and Risk Evaluation.
3. Interval H&P - That H&P where the Surgeon or Proceduralist briefly reviews, within 24h of surgery/procedure, the pre-operative H&P(s) - including the data elements PMHx, PSurgHx, FamHx, SocHx, Med List, Allergies, ROS, PE, and relevant labs and radiology -  and acknowledges that the information is all correct and accurate and that no changes or updates are needed prior to surgery/procedure, usually with a simple attestation : "I have read and reviewed the patient's pre-operative H&P and no changes or updates are required."  
4. Admission H&P - That H&P done by the Admitting Attending (or their clinical delegate) at the time of admission, usually to describe the patient's condition, reason(s) for admission, admission status, admitting team, admission active problem list and management plans, and contingency plans.  

While these contain many of the same data elements, they also contain different elements, and are authored by different provider(s) at different times. Mislabeling all of them as just "H&P" leaves potential room for confusion - For example, if post-operatively Inpatient Nurses seeking post-operative orders were to try to contact the PCP instead of the Surgeon, because the Pre-Op H&P and the Admission H&P are both labeled "H&P".

Similarly, distinguishing the Primary (General) Pre-Op H&P and Risk Evaluation from the Secondary (Specialist, focused) Pre-Operative H&P(s) is necessary to clarify who has the primary responsibility and what other specialist(s) might need to be involved in assessing a patient with a complex history (e.g. pulmonary, cardiac, renal, endocrine, or other complex medication, allergy, or anesthesia needs). Labeling both of these as an "H&P" just leaves room for confusing the two (e.g. a Surgeon sending the patient to a cardiac specialist for a primary risk evaluation.) 

If you have ever tried to create structured documentation, to encourage users to complete the data field(s) that are necessary and unique to each of these note types - You will quickly see why it's important to label each of these notes correctly. 

In short : Trying to 'keep it simple' by labeling them all as "H&P" only confuses users and makes it a challenge to structure your workflows. My advice : Call it what it is.

Just to be complete, I thought I'd share some of the other common types of H&Ps used across healthcare : 

These include : 

• 5. The Emergency Department (ED) H&P - That focused H&P that is commonly done by Emergency Medicine doctors, usually as part of their routine visits. (In some organizations, this is labeled an 'ED Progress Note.)
• 6. The Discharge Summary H&P - That H&P that is usually done by the Attending Provider (or their clinical delegate) at the time of discharge, to provide a synopsis of the patient’s hospital stay, covering the course of illness, treatments provided, and recommendations for follow-up. These also often include the admission reason, key findings, procedures done, discharge medications, patient's condition on discharge and instructions for aftercare, and they help enable a smooth handoff to outpatient providers to help ensure continuity of care and provide clear guidance for post-discharge recovery.
• 7. The Consultation H&P - That H&P that is often done by a specialist, either as part of an inpatient consult or an ambulatory referral, at the request of another provider seeking specialty evaluation.
• 8. The Annual Physical H&P - That H&P commonly done by a Primary Care Provider as part of an annual evaluation of a patient's overall health status and needs. These are often preventative in nature (rather than problem-focused) and usually cover the entire spectrum of a patient's health, including lifestyle factors, preventive screenings, immunizations, and a physical exam.
• 9. The Employee Physical H&P - That H&P commonly done by an Employee Health Provider as part of a pre-employment evaluation, fitness-for-duty evaluation, or workplace injury.
• 10. The Sports Physical H&P - That H&P commonly done by a Primary Care Provider, Cardiologist, or other Sports Medicine provider, to evaluate an athlete prior to playing competitive sports or engaging in other demanding physical exercise regimen.
• 11. The Insurance H&P - That H&P typically done by a Primary Care Provider or Insurance Provider to help evaluate a patient prior to completing agreements for an insurance policy.

... each of which also has unique authors and unique data elements for unique purposes - So if you want to structure these notes, they will also require unique (descriptive) names. 

IN CONCLUSION : 

Terminology is important. The accurate capture of H&Ps relies heavily on standardized clinical terminology. From admission to discharge, the use of consistent terms and codes across each H&P type ensures that information is unambiguous and interoperable within the healthcare system. Applied Clinical Informatics professionals play a crucial role here, by:

1. Creating Templates and Standardized Workflows: Clinical informatics teams often design templates that incorporate standardized terminologies, improving the quality and consistency of documentation across providers and specialties.

2. Supporting Clinical Decision Support (CDS): By ensuring that H&P documentation aligns with clinical terminology standards, CDS tools can better identify risk factors, suggest interventions, and flag potential issues based on coded data from H&Ps.

3. Optimizing for Billing and Compliance: The use of terminologies like ICD-10 and CPT in H&P documentation is vital for billing accuracy. Standardized language not only supports coding but also ensures compliance with regulations.

So my four key take-home messages for this post include : 

• There are at least eleven (11) H&Ps commonly used in healthcare - If you are a clinical provider, a medical records professional, a billing/coding person, or a clinical informaticist, it is helpful to familiarize yourself with all of them.  
• Many federal and state regulations only refer to them as an "H&P" - This, and the common saying "An H&P is an H&P..." potentially only causes confusion and workflow challenges.
• The right naming conventions / labeling can help you structure your documentation, and clarify and optimize your clinical workflows. 
• Remembering the mantra, "Call it what it is" will help you reduce confusion and untangle even your most complicated workflows.

For Clinical Informatics professionals, understanding these elements is critical to optimizing workflows, enhancing patient care, and contributing to the data-driven future of healthcare. By promoting accurate and standardized documentation, we can facilitate the development of a healthcare system that is not only more efficient but also more responsive to the needs of patients and providers alike.

I hope this helps you plan your document index and naming conventions, to help streamline your clinical processes. If you have any feedback or other comments, please leave them in the comments section below!

Have any experience with naming conventions for your clinical documentation? Feel free to share and leave other feedback in the comments section below. 

Remember, this blog is [ DRAFT ] guidance for discussion and educational purposes only - Your mileage may vary. Always check with your Clinical Leadership and your own Legal, Compliance, Regulatory, and Informatics leaders before adopting any definitions or new clinical standards.

Developing and Approving an Order Set

Hi fellow CMIOs, CNIOs, and other Clinical #Informatics and #HealthIT friends,

Today I thought I'd share some helpful slides from a discussion that very few people write about - Developing and approving order sets.

This is a topic where far too little has been shared openly, so many organizations struggle unnecessarily until they learn through repeated trial-and-error how to do this in a much more smooth, efficient way.

Unfortunately, it also brings up the question about maintenance of order sets : 

• Yes, order sets can help save time, reduce clicks, and reduce unexpected pages from staff, but...
• They can also take a lot of work to develop, approve, monitor, and maintain.

So our agenda for today includes : 

First, what exactly do we mean by 'Order Sets'?

Order sets are sometimes referred to as 'Ordering Tools', since different vendors use different terminology to describe these collections of orders that are used to standardize and expedite the ordering process for a common, well-described clinical scenario.

Because they look so similar (and even share some of their definitions!), Order sets are sometimes confused for order panels, pick-lists, and clinical pathways:

1. Order Set (n.) - A collection of orders used to standardize the ordering process for a common, well-described clinical scenario (e.g. workup, treatment, admission, discharge, prep, postop, protocols, etc for pediatric and adult/geriatric patients.)
2. Order Panel (n.) - A collection of common orders of a specific type, typically designed for inclusion in order sets (e.g. common pain meds, common GI meds, common labs, common nursing orders)
3. Pick-List (aka 'Quick Preference List' or 'Convenience Panels') (n.) - A collection of common orders of a specific type, typically designed for convenience only, that is not related to a specific, well-described clinical scenario (e.g. common pain meds, common IV fluids, common anti-emetics, common lab orders, common radiology orders, etc.)
4. Clinical Pathway (n.) - A collection of order sets used to standardize and expedite the daily ordering process (typically throughout the course of a planned hospitalization) for a defined clinical condition, procedure, or surgery.

Order sets also typically come in two types : 

• Oncology Order Sets - Typically broken out in a separate category, because of the unique, complex ordering needs for chemotherapy and biologic infusions (e.g. monoclonal antibodies)
• All other Order Sets (General order sets) - Typically related to working up common chief complaints, treating common conditions/diseases, admitting/transferring/discharging to/from an inpatient area, preparing for a surgery/procedure, recovering from a surgery/procedure, and special protocols (to automate common, high-risk clinical scenarios where the benefits of standardization and timely delivery of care outweigh any known risks).

For this purposes of this post, we will mostly be discussing the second category above - General order sets. (We could write a whole separate post about the unique needs of Oncology and biologic infusion ordering workflows.)

So before we get to our development discussion, let's first start with our approval discussion - In a typical healthcare organization, who is best-suited to approve an order set?

Many organizations struggle with this question, because there's usually no one person who has all of the time, expertise, and authority needed to approve an order set. I sometimes describe this as the 'Captain Kirk and Scotty' paradox : 

• Captain Kirk = Has all the authority, but little expertise
• Scotty and engineers = Have all the expertise, but little authority

So ultimately, the lesson here is : Captain Kirk, Scotty, and the other engineers have to work together to make the ship run.

Some organizations chose to focus on expediency, by assigning one person or one team - sometimes a clinical officer (CMO, CNO, or both?) or an appointed committee (chaired by a CMO, CNO, CMIO, and/or CNIO?) - But is that enough? Are there any helpful regulations or published best practices, and if so, what do they say?

Unfortunately, there's not much. As of 2024, order sets are still a bit of a mystery to most regulatory agencies. Not only does CMS use the terms "Standing Orders", "Order Sets", and "Protocols" interchangeably, but there are very few published best practices openly available on the Internet. The OHSU ClinfoWiki has some helpful information about oversight and governance in these published pieces :

• "Creating Order Sets"
• "Making Sense of Clinical Practice: Order Set Design Strategies in CPOE"
• "Enhancing Physician Adoption of CPOE: The Search for a Perfect Order Set"

... but while there's some helpful information about oversight committees and mentions of templates, these articles don't contain much concrete detail about the exact development or approval processes, or samples of templates.

So the most concrete regulatory guidance seems to come from the Centers for Medicaid Services (CMS) 42 CFR § 482.24, under section (3) which states : 

So if CMS expects the Medical Staff and the hospital's Nursing and Pharmacy leadership to be 'reviewing' order sets - Does that mean three committees need to be involved in the review/approval process? (E.g. Medical Board/Medical Executive Committee, Nursing Council, and Pharmacy and Therapeutics?) Or should those committees delegate a separate team to just focus on order sets? 

Or should the clinical leadership of those areas (e.g. CMO, CNO, and VP of Pharmacy) approve the order sets? Even if they have the time and expertise to approve order sets, do they have the time to develop them? And if they don't have the time and bandwidth to 'get into the weeds' to develop them, how can they feel confident about approving them?

And what about the other supporting departments in a clinical enterprise - Laboratory, Radiology, and other ancillary services? When the OHSU ClinfoWiki article on "Creating Order Sets" says, "They have their needs thoroughly examined by their practice management oversight group, nursing, support staff and anyone who might be affected by the order set," who exactly might be affected by the order set? After all, don't doctors just write orders, and other people in the organization have to execute/follow-through with them?

Well, it's not that simple. Clinical staff affected by the order set include both : 

• The staff writing/creating orders (typically Ordering Providers, including Attendings, Residents/Fellows, Advanced Practice Providers/APRNs/PAs/CRNAs etc.)
• The staff following/executing orders (commonly everyone else in a clinical enterprise, including Nursing, Pharmacy, Lab, Radiology, Bed Management, Case Management, Dietary/Nutrition, and other ancillary support services)

Some doctors initially bristle when they learn that other specialties are involved in reviewing and approving their order sets. But if we take a step back - Order sets create patterns of clinical care and utilization that have an impact across the whole organization, so it shouldn't be a surprise that other people are involved in reviewing the best practices, and planning utilization and resource needs to execute and follow-through with those orders.

So how do we make sense of this? It helps to imagine a 'pyramid' of delegation and oversight, one that helps to connect Captain Kirk (all authority, little expertise) with Scotty and his engineers (all expertise, little authority) :

... which is a very basic operational unit that can be employed in developing a process for reviewing and approving order sets. So in a typical clinical enterprise, there are similar pyramids for the major clinical disciplines involved in the delivery of care (Nursing, Pharmacy, and Physicians):

Note there are also similar pyramids for Lab, Radiology, and other Ancillary Services (such as Physical Therapy, Occupational Therapy, Dietary/Nutrition, Case Management, Social Work, etc.) :

So now, let's see if we can answer the question : Who exactly is affected by an order set? Well it depends largely on the complexity of your order set. Small, short order sets typically have fewer stakeholders, and larger, complex order sets typically have more. 

Exactly who needs to participate in the discussion will depend on the type(s) of orders in your order set. You can create a very helpful order set development template by identifying and aggregating your most common order types. Most healthcare organizations can divide up all patient care orders into one of sixteen (16) groups : 

Since each order type has a unique function, usually executed/performed by a unique stakeholder - You can then take these sixteen (16) order types, import them into a spreadsheet, and next identify the common stakeholders for each order type : 

Once you've identified the common stakeholders for each order type, you can then create a standardized order set template, that not only helps define expected standards for each order type (e.g. medication orders with medication doses, routes, frequencies, etc.), but also the stakeholders necessary to participate in the review and approval of the order set :

Once you have this template, you can first try it out with a simple order set, say, with just a Procedure order, some Activity and Nursing orders, some Diet orders, and some IV fluid orders :

Or, you can try it with a more complex order set, one that includes : ADT orders, Code Status orders, Procedure orders, Activity orders, Blood Bank orders, Nursing orders, Diet orders, IV Fluid orders, Medication orders, Laboratory orders, Diagnostic Radiology orders, Consult/Referral orders, and Discharge Education orders -

This is helpful when trying to plan new order sets, so you can identify who to invite to your build discussions.

Now, since I'm discussing order sets, I thought it would be helpful to mention the surprising importance of solid, well-planned naming conventions. 

Early in my Informatics career, I would have never have guessed the importance of naming conventions. A few people warned me, but at first I was skeptical. I actually once said something like this : "What does it matter, what you call it? As long as they can find it!"

What I didn't know at the time (and learned with experience) is that naming conventions : 

• Determine the size of your order set library - More coarse/vague naming conventions result in fewer order sets, and more specific/granular naming conventions result in more order sets.
• Determine how easy it will be for your users to find (and bookmark) the order set.
• Help determine whether you are clearly building a time-saving order set - Or if you are confusing it for a Pick-List, Order Panel, or Clinical Pathway. 
• Strongly influence the number of clicks and unexpected pages your users will experience - The more clear and specific the naming convention is, the more you can pre-configure and pre-click default settings (so your users don't have to!)

Knowing that well-described, scenario-specific order sets help reduce clicks and unexpected pages more than general Pick-Lists (aka 'quick preference lists' or 'convenience panels'), I thought I'd share one way to index your order set catalog, based on your most common patient types, common chief complaints, common treatments, common surgeries and procedures, and common protocols :

So with that - First, some helpful take-home reminders : 

... and a few more to consider as you create and develop your governance and order set development, review, and approval processes with your Clinical, Legal, Compliance/Regulatory, Finance, and other leadership :

I hope this quick review has been helpful and provides some helpful food for thought for your own team discussions! Since there is not much written about this subject, please feel free to share feedback in the comments section below.

Remember, this blog is for educational and discussion purposes only - Your mileage may vary!

Have any experiences building order sets, leading order set teams, or creating or an order set development and approval process? Feel free to share any helpful feedback or experiences in the comments section below! 

Why Healthcare needs Clinical Architects

Hi fellow CMIOs, CNIOs, and other Clinical Informatics friends,

Some of you might already be familiar with #BlueprintsBeforeBuild, the hashtag I started several years ago (on X/Twitter, LinkedIn, and elsewhere) to help create awareness of the need for good workflow design in healthcare technology. 

You might also be aware of the value of having an Applied Clinical Informatics ('Clinical Architecture') team in Healthcare, to assist with things like : 

1. Project Intake or Procurements that require additional support or workflow evaluations, to help ensure the technology does not already exist, and to help ensure proper scoping, budgeting, stakeholder identification, resource allocation, necessary safety, compliance, and regulatory reviews, and expected outcomes.
2. Special Event Workflow Planning (e.g. Planned upgrades and maintenance, unplanned downtimes, project go-lives, etc.)
3. Complex IT Tickets that require workflow updates or modifications (which often span multiple areas with multiple stakeholders)
4. Complex Projects that require clinical translation, terminology work, stakeholder alignment, or other workflow updates/modifications
5. Ongoing Maintenance of existing configuration / workflows to meet CMS/TJC regulations, that require continuous staff engagement with multiple stakeholders across different areas and specialties. 
6. Helping to ensure clinical workflows are aligned with the Clinical, Administrative, HIM, Regulatory/Compliance, coding/billing, and revenue capture needs of the organization. 

So while my last post helped to ask and answer the question, "Where is the Clinical Informaticist?", this month's post is related to my support of an easy way to make Applied Clinical Informatics more familiar and tangible for newcomers - Instead of "Clinical Informatics", consider using the synonyms "Clinical Architect" and "Clinical Architecture" :

 

While some organizations have clinical staff (MDs, RNs, APRNs, PAs, Pharmacists, Lab/Radiology staff, and others) who are trained to configure computers, other healthcare administrators might question the reasons for paying a clinical team member to do this sort of configuration (building) : 

Q : "Why should we pay a doctor (or RN, APP, or other clinical role) to do this?"

In addition to the six deliverables mentioned above, there are other good reasons to pay clinical staff to be involved in your EMR go-live, configuration, and ongoing maintenance, including :

• Improved user satisfaction and workflow design (See this recent AMA article for a success story from TSPMG on the benefits of improved user engagement!)
• Improved upkeep of technology (to reflect continuously-changing medical literature and other clinical, regulatory, and billing standards)
• Improved utilization (ROI) and stewardship of your technology
• Improved quality metrics and revenue capture
• Improved patient care
• Improved patient satisfaction

... where clinical staff play an essential role in experiencing and understanding their workflows, translating their workflows, and maintaining their workflows. The questions then become : 

• Q : "Do we need clinical staff to build configurations?" ('Clinical Builder')
• Q : "Or do we need them to architect clinical workflows?" ('Clinical Architect')

While many clinical staff begin their HealthIT journeys focused on build - I would argue that there is a value in focusing their efforts on clinical architecture, rather than construction. Here's why.

Effective, predictable change management generally begins with a ten step process :

Generally speaking, these ten steps include : 

1. Documenting and understanding the change.
2. Analyzing, evaluating, designing, and scoping the change.
3. Prioritizing and approving the change project.
4. Building the project team (including stakeholders, deliverables, and timelines).
5. Designing blueprints for all EMR/Non-EMR deliverables (for discussions, tabletop exercises, edits, and to secure necessary buy-in and approvals)
6. Building the change (Analyst)
7. Testing and approving the change (future-state workflow)
8. Communicating and educating (training) the change
9. Implementing the change
10. Monitoring and supporting the change

After reviewing these steps, the questions then become : 

• Who supports each of these steps?
• Do your IT Analysts typically support step #6?
• If so, are your clinical staff then more useful in step #6, or in steps #2 and #5?
• Could any analyst time be saved in #6 with more informatics time spent in #2 and #5?

This may seem somewhat paradoxical at first, since many clinical staff initially gravitate towards building when they first get involved in healthcare technology. After all, it seems like a good way to get involved, learn about data structures, and get some control over the systems they use to deliver care to patients. 

But on closer inspection, I believe there's real value in focusing your clinical staff on architecture, rather than construction (build) : 

From Wikipedia : Architecture is the art and technique of designing and building, as distinguished from the skills associated with construction. And what connects architecture to construction is blueprints. (Note : For more about architecture, please also see this helpful Brittanica article.)

So for most clinical staff first getting involved in HealthIT, having some experiences with construction is very helpful. Unless they have some kind of a background in computer science, it's still very helpful (foundational) to learn about data structures, relational databases, indexing, and coding. 

But once they have this foundational understanding, I personally think their bigger value comes from using their clinical expertise to architect workflows using blueprints, rather than building (configuring) workflows. Here's why : The value of blueprints in construction is typically underestimated :

• Blueprints allow you to quickly mock up deliverables (e.g. the EMR and non-EMR deliverables that work together to support your desired workflow)
• They let you share your mockups with other clinical staff, to discuss, review, create tabletop exercises, make edits, and secure necessary buy-in and formal approvals.
• They let you then share your approved blueprints with your IT analysts (who can then quickly create the electronic deliverables in your EMR, e.g. orders, order sets, clinical documentation, alerts, charges, etc.)
• They let you share your approved mockups with other Clinical Leaders (who can then help create the non-EMR deliverables, such as policies, guidelines, protocols, schedules, training, budgets, etc.)
• Finally, blueprints can also help save analyst time while synchronizing your electronic (EMR) deliverables with your paper deliverables (downtime forms).

How can blueprints help save analyst time, while synchronizing your electronic and paper deliverables (for planned EMR maintenance / unplanned EMR downtimes)? They can do this because blueprints help to create clear understanding and discussions, and allow clear edits and revisions, that are necessary before you can secure the necessary buy-in and final approvals - Not just from your clinical staff, but also from your Legal/Compliance/Regulatory staff, Pharmacy staff, Nursing staff, Radiology staff, Laboratory staff, HIM staff, Billing/Coding staff, Clinical Leadership, IT leadership, etc. 

Having that level of clarity, understanding, and buy-in is very difficult to achieve after something has been built. (This is a common reason for IT Analyst complaints of having to build and re-build something before it's right.) So why not put your Clinical Architects (Clinical Informaticists) to work on blueprints, rather than build?

And so once your IT analysts are working on the electronic (EMR) deliverables, blueprints are then also very easy to convert to paper downtime forms :

So that process for creating synchronized EMR deliverables (from an IT Analyst) and paper downtime forms (from a Clinical Architect / Clinical Informaticist) can then look like this : 

How to use blueprints to create matching paper and electronic tools : 

1. Clinical Architect (Clinical Informaticist) will study and design the desired (future-state) workflow. 
2. Clinical Architect (Clinical Informaticist) will use templates to quickly mock-up blueprints for all deliverables. 
3. Clinical Architect (Clinical Informaticist) will use blueprints to review and share with staff and other stakeholders, conduct tabletop exercises, lead clear discussions, make necessary edits/changes based on feedback, and secure the necessary buy-in and approvals.
4. Clinical Architect (Clinical Informaticist) will share and discuss approved blueprints with IT Analyst, for building and testing of electronic deliverables.
5. Clinical Architect (Clinical Informaticist) will convert blueprints to paper downtime forms.

So to summarize, some key take-home points from today's discussion :

• There is real value in having (some) clinical staff engaged in the development and ongoing maintenance of your EMR and downtime processes (e.g. improved outcomes, improved user and patient satisfaction, improved quality metrics, improved revenue capture, etc.) 
• Clinical architecture (Clinical Informatics) is the art and technique of designing and building clinical workflows, a specialty distinct from (but intrinsically related to) IT Analysts (who commonly focus their primary efforts on construction).
• Clinical staff commonly begin their HealthIT career journey focused on building in an EMR, but their value can increase when they focus their efforts on clinical architecture (Clinical Informatics) and blueprint development.
• Blueprints can help save project and IT analyst time by creating the necessary discussions, understanding, buy-in, and approvals before beginning construction.
• Blueprints can also help synchronize your electronic deliverables with your paper downtime forms (by making it easy to create downtime forms with the same appearance, format, and cadence as your electronic deliverables).
• An easy way to improve clinical workflow design, improve outcomes and user satisfaction, save time, create clarity and understanding, and develop smooth downtime processes is to develop a Clinical Informatics (Clinical Architecture) team, and remember the hashtag #BlueprintsBeforeBuild!

For many of you, this discussion is probably just a refresher. For others, I hope this was a helpful discussion, for you and/or your clinical informatics teams. Please let me know your experiences, and feel free to leave comments and feedback in the comments section below!

Disclaimer : Remember, this blog is for educational, discussion, and information-sharing purposes only - As always, your mileage may vary! Remember to always have your clinical leadership, IT, and legal/compliance teams review any changes to processes before you initiate them. Have any related experiences, or other suggestions for improving clinical workflow design? Leave your comments and feedback below!

Where's the Clinical Informaticist?

Hello fellow CMIOs, CNIOs, and other Applied Clinical Informatics friends,

This month I'd share some cool discoveries I've made with some friends recently, in a helpful blog post about finding the Clinical Informaticist(s) in your organization, and/or identifying the need for them.

One of the common challenges of Applied Clinical Informatics is that Informaticists can sometimes be hard to find. Typically due to a number Human Resources (HR) and other industry issues, they can sometimes be hidden behind : 

• FALSE NEGATIVES - E.g. People who actually do Clinical Informatics work, but aren't necessarily titled "Clinical Informaticist" in their job title, or aren't recognized as doing Clinical Informatics work at all.
• FALSE POSITIVES - E.g. People who are called "Clinical Informaticist", when they don't necessary do the work that might commonly fall under the domain of the Clinical Informaticist (or they only do a specialty branch on the larger 'tree' of Applied Clinical Informatics - See below.)

While some have tried to tackle these HR challenges, concrete job descriptions are hard to find since there is such a wide variation of practice, in the general 'tree of Informatics' - which spans a number of disciplines related to both data storage ('data in') and data retrieval ('data out') functions : 

If your search for a Clinical Informaticist turns up negative, you will probably need to establish the need to hire one (or more) to help with your clinical workflow analysis and development. Historically, there have been two common approaches to doing this in #Healthcare - the 'Clinical Choir' approach, and the 'Executive/Financial' Approach: 

Each of these historic approaches come with some pros and cons : 

1. The 'Clinical Choir' Approach - Where the Clinical Staff recognizes the need for workflow updates and redesign, and collectively asks for Applied Clinical Informatics resources. PROS : Support from clinical end-users can be very helpful to support the allocation of FTE(s) for Clinical Informatics. CONS : Difficult to execute. Most clinical end-users aren't familiar with the potential role of Applied Clinical Informatics in their day-to-day workflows, so it's not easy to get them to ask for it by name. 
2. The Executive / Financial Approach - Where the Executive / Finance teams recognize the need for improved Return on Investment (ROI) and overall improved stewardship of technology investments, and so they collectively ask for Applied Clinical Informatics resources. PROS : Support from Executives and Finance officers can also be helpful to support the allocation of FTE(s) for Clinical informatics. CONS : Most ROI from workflow design and improvement falls under the category of 'soft ROI' which could easily be attributed to other departments, or it falls into the category of cost reduction rather than revenue improvements. (Both will help your organization, but one is easier-to-identify.) So putting a hard number to ROI or cost reduction that stands up to scrutiny will require some real pre-planning before you execute your improvement projects.

So for today, I'd like to share a new approach that I recently discovered, when I worked with some of my trusted Project management and Compliance colleagues (Jim McGennis and Elle Box) to combine my 10-step change management recipe with a Responsibility Assignment (RACI) Matrix :

First, a brief reminder that my recommended ten steps for clinical change management (originally published back in 2018) helps to create consistent outcomes through the thoughtful analysis, scoping, development, and planning of workflow changes (both big and small) :

After combining these ten change steps (above) with a Responsibility Assignment (RACI) Matrix (typically used by experienced Project Managers for assigning responsibility for various tasks), new discoveries were made and additional clarity was achieved. (Note : If you're new to Responsibility Assignment / RACI matrices, please see this Wikipedia article for a helpful introduction. And special thanks to PM guru Jim McGennis, for introducing me to this powerful tool.)

The basic premise of a RACI matrix is that you create a grid (spreadsheet) of roles versus steps, and then assign these four categories in each step : 

• (R)ESPONSIBLE (also recommender) - The one (or more) person(s) who are responsible to complete the task.
• (A)CCOUNTABLE (also approver or final approving authority) - Who is ultimately answerable for the correct and thorough completion of the deliverable or task, who also ensures the prerequisites of the task are met, and delegates the work to those responsible.
• (C)ONSULTED (sometimes consultant or counsel) - Those whose opinions are sought, typically subject matter experts (SMEs), and with whom there is two-way communication
• (I)NFORMED (sometimes informee) - Those who are kept up-to-date on progress, often only on completion of the task or deliverable, and with whom there is just one-way communication.

Putting my 2018 clinical change management recipe together with the RACI matrix has been remarkably helpful and enlightening. And with some help from Compliance colleages (thanks to Compliance guru Elle Box for her help reviewing and refining the descriptions), the first thing I began to notice was the number of roles that participate in one or more steps of change management : 

Roles that participate in one or more steps of clinical change management

 

Roles that participate in one or more steps of clinical change management

... as well as the details of exactly who is (R)esponsible, (A)ccountable, (C)onsulted, and (I)nformed at each step. (*Note : In the slide above, you'll notice that the Applied Clinical Informaticist already has a different set of roles and responsibilities than the Clinical IT Analysts. More to come on this shortly...)

When we look at the first phase of the change recipe (documentation of request and expectations, or intake) it's easy to see who has primary and secondary (R)esponsibility - Both the clinical end-user and the official requestor - their supervisor, director, chair, or chief - who needs to help support the request : 

First phase of change : Documentation of Request and Expectations ('Intake')

First phase of change : Documentation of Request and Expectations ('Intake')

As we move to the second phase of the change management recipe (Analysis, scoping, prioritization, resource allocation, and project approval), we can see that suddenly the Chief Information Officer picks up (A)ccountability, while the Applied Clinical Informaticist has primary (R)esponsibility for the literature search, sponsor identification, workflow gap analysis, workflow development, scoping of deliverables, and identification of stakeholders. Together with a number of (C)onsultants including Clinical IT Analysts, Medical Librarians, Compliance, Regulatory, and Finance, they will also help review regulations and estimate a Total Cost of Ownership (TCO) and Return-on-Investment (ROI), providing much more helpful information for Senior Executives who will need to prioritize and approve this project before it can be assigned. (*Note : By serving this important workflow analysis role, the Applied Clinical Informaticist will also become a subject matter expert (SME) for other experts who will be (R)esponsible for later steps in the change recipe.)

Second phase of change : Analysis, scoping, prioritization, resource allocation, and project approval

Second phase of change : Analysis, scoping, prioritization, resource allocation, and project approval

When we arrive in the third (Project Planning) phase, now the Executive Sponsor has picked up (A)ccountability, while the Project Manager has primary (R)esponsibility for working with the Applied Clinical Informaticist, Clinical IT Analyst, and others to plan the necessary parts of the project, including Gantt charts, RACI Matrices, and/or other formal project plans :

Third phase of change : Project Planning and RACI Matrix / Gantt Chart Development

 

Third phase of change : Project Planning and RACI Matrix / Gantt Chart Development

Assuming all of the above phases have been completed, this now brings us to the fourth phase of change - The drafting of workflows, for which the Applied Clinical Informaticist has primary (R)esponsibility, typically in conjunction with the Clinical IT Analyst, Compliance, and the End-users. 

Fourth phase of change : Drafting of Workflows

Fourth phase of change : Drafting of Workflows

While some organizations may not yet have implemented blueprints in their development process, this step can be very helpful because :

• Blueprints help to create understanding, align clinical stakeholders, let you conduct tabletop workflow discussions and reviews, and obtain preliminary approvals before the Clinical IT Analysts begin their build (in the next step).
• Once approved, and with a few small changes, blueprints can also become your downtime forms, in case your electronic system is ever down for planned maintenance or other unplanned reasons.

This now brings us to the fifth and sixth phases of change, the building of deliverables and testing of workflows, where the Clinical IT Analyst now has primary (R)esponsibility to build and test the deliverables, typically in conjunction with the Applied Clinical Informaticist and the End User (for end-user acceptance testing).

Fifth and sixth phases of change : Building of deliverables and testing of workflows

 

Fifth and sixth phases of change : Building of deliverables and testing of workflows

For the seventh phase of change (Final workflow approval), the Applied Clinical Informaticist now assumes primary (R)esponsibility and works to secure the necessary final approvals in conjunction with Senior Leadership and a number of other stakeholders. (*Note that the Executive Sponsor still has (A)ccountability for this step.)

Seventh phase of change : Final Workflow Approvals

 

Seventh phase of change : Final Workflow Approvals

 

Finally, for the eighth phase (Communication and Education/Training), ninth phase (Implementation/Publication), and tenth phase (monitoring and support) of change, the Clinical IT trainers, Clinical Education / Training team, Communications Team, and End-Users now all share (R)esponsibility, and typically do their steps in conjunction with the Applied Clinical Informaticist and the Clinical IT Analysts.

Eighth, ninth, and tenth phases of change : Communication, Education, Implementation, Monitoring, and Support

 

Eighth, ninth, and tenth phases of change : Communication, Education, Implementation, Monitoring, and Support

IN CONCLUSION : 

What does this exercise (combining change management recipe with a RACI responsibility assignment matrix) teach us? Five helpful take-home points : 

1. Clinical change management is a team sport that requires the participation of a large number of stakeholders to work together in a clear, highly-detailed, highly-coordinated fashion, where different roles will be (A)ccountable for some steps, have primary (R)esponsibility in some steps, serve as a (C)onsultant in other steps, and need to be (I)nformed of other steps.
2. The roles of the Applied Clinical Informaticist and Clinical IT Analyst are separate and distinct roles that often work together, but serve in distinct and unique capacities, and thus should have separate and distinct job titles and descriptions.
3. Before projects are approved, the Applied Clinical Informaticist has primary (R)esponsibility for the analysis, scoping, prioritization, and resource allocation, typically in conjunction with (C)onsulting expertise from the Clinical IT Analyst, End-users, Compliance, Regulatory, Finance, Executive Sponsor(s), and Senior Leadership.
4. The Applied Clinical Informaticist also has primary (R)esponsibility for the drafting of workflows (blueprints of deliverables), typically in conjunction with (C)onsulting expertise from the Clinical IT Analysts, Compliance, and End-Users. These blueprints will help to create understanding and alignment, and later serve as downtime forms in the event of a planned or unplanned downtime. 
5. The Clinical IT Analyst often provides (C)onsulting expertise during earlier analysis and scoping phases of the change, but then assumes primary (R)esponsibility for the building and testing of electronic deliverables, before providing additional (C)onsulting expertise during the implementation phase of the change. 

I know there's a lot to unpack here, but I hope this review helps to demystify the process, and helps you look at your own change recipe and the roles that are (A)ccountable for,  (R)esponsible for, (C)onsulting on, and (I)nformed of each step. I also hope it helps to dispel the misunderstandings and confusion about the roles of the Applied Clinical Informaticist and the Clinical IT Analyst, two important roles that often work together but each of which require their own skill sets, job titles, job descriptions, and support.

Remember, the above is all a [ DRAFT ] and this blog is for educational and discussion purposes only - Your mileage may vary! Have any feedback or experiences you would like to share? Please feel free to leave comments in the comment section below!