Grand Rounds : Turning Policy into Practice

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

I'm writing today to share some slides that I recently presented at a grand rounds for a very talented group of Northwell Health Clinical Informatics (CI) Fellows, courtesy of CI leaders Anncy Thomas, DO FAMIA and Keriann Latten, DNP.

The topic : Turning Policy into Practice. While I've discussed task grammar (the 'cupcake test') in the past, I wanted to first convey how Applied Clinical Informatics is constantly building on the work of the past - not replacing it - and so it's helpful to start our discussion by framing a big-picture look at exactly where we are in #Healthcare history :

While #Healthcare has been on a roughly 2000+ year journey, what we think of as modern Western medicine mostly started about 250 years ago, gradually evolving and bringing us to the inflection point we have reached in the last 20 years : Technology, payment reform, pandemics, and now Artificial Intelligence (AI). The key points to highlight during this recent part of the journey : 

• Change is happening faster than ever.
• Managing that constant, ongoing, accelerating change requires dedication, time, people, and resources.

Along with the global adoption of Electronic Health Records also came a need for a higher degree of architecture and engineering for our clinical workflows - Hence, our Applied Clinical Informatics professionals, helping #Healthcare to adopt a culture of well-orchestrated, well-organized, and well-developed design and implementation : 

This brings us to our discussion about turning policy into practice : It's not about rewriting policies - it's about adding a task grammar to help them become more executable. :

... which helps to better understand the workflow details, and connect them to real EHR build.

So now, for teaching purposes, let's imagine a very simple example of something that one might want to achieve - A well-baked and safe cupcake. 

While serving well-baked, safely-prepared cupcakes is always an admirable goal (who doesn't like cupcakes?), the goal itself is not operational. It leaves many questions unanswered, such as : 

• WHO is making the cupcakes?
• WHAT kind of cupcakes are they making?
• WHEN are they expected to make these cupcakes
• HOW are the cupcakes supposed to be prepared, to be safe (for the baker and the consumer)?
• WHY are we needing to establish this standard?

While these admirable (and usually necessary) standards exist all across #Healthcare, the modern question then becomes : Could you configure this in your EHR?

Before we go on, a word of respect (and thanks) to all of the #Healthcare leaders (globally) that got us to here in 2026. We are all standing on their shoulders, and so we owe them a great deal of gratitude and respect. The policies they developed helped to protect patients, align clinicians, and meet regulatory expectations : 

... which worked well before Electronic Health Records (EHRs), but did not always contain the task grammar (who, what, when, where, why, how) necessary for configuring them today.

Usually, this discussion raises the question : Why does Clinical Informatics (CI) get stuck in the middle here? It's not uncommon for CI professionals to get funny looks the first time they begin to discuss policies and compliance, but this translation is a necessary part of the job : 

So now, let's look at how to operationalize a policy by applying task grammar (who, what, when, where, why, how) to a sample 'aspirational' (not operational) policy : 

We can use this task grammar to define a task, the most granular unit of work : 

TASK = [ WHO ] will/may [ WHAT ] { how } { when } { where } { why } 

where :

• WHO = Who will perform the task
• will/may = Use WILL for required tasks, MAY for optional tasks
• WHAT = Brief description of the task
• { how } = Optional, use only to clarify how the task will/may be performed
• { when } = Optional, use only to clarify when the task will/may be performed
• { where } = Optional, use only to clarify where the task will/may be performed
• { why } = Optional, use only to clarify why the task will/may be performed 

... and use it to augment the procedure for improved EHR configuration purposes (a more 'operational policy')  : 

This augmentation using the above task grammar can significantly elevate the clarity and granularity of your policy and procedure, making it much easier to configure in an Electronic Health Record (EHR) : 

It's important to note that this culture change should never occur in a silo - and comes with potential risks and benefits - that you should always review with your own Clinical Leadership, and other Legal, Regulatory, and Compliance professionals.

In general, this culture shift can shift organizational risk patterns, and so you will want to talk to your own Clinical Leadership and Legal, Regulatory, and Compliance teams before implementing this new task grammar.

This new task grammar can also help you to update and refine your organizational definition of a Procedure : 

Procedure (aka process, workflow, recipe, algorithm) (n.) = A series of ordered TASKS that uses people, time, and resources to achieve a desired outcome.

... which, again, should only be undertaken in collaboration with your Clinical Leadership and Legal, Regulatory, and Compliance teams :

With this new task grammar at hand, you can then 'strengthen' your workflows (procedures) by better supporting them in your EHR configuration. You can also help ensure that their costs are better estimated, and that they are fully vetted (understood, reviewed, and secondarily approved) by the necessary stakeholders (usually Directors, VPs, Chairs, and Chiefs) before they receive final approvals (usually from your Clinical and/or Operational Leadership) : 

Since this task grammar also helps you define each task in a more granular manner, you can also provide a pretty decent estimate of the cost of each task, as well as the total (annual) cost of the policy : 

• TASK COST = TASK LABOR + TASK MATERIALS
• TASK COST = TASK (Time * Hourly salary) + TASK MATERIALS

... which can also help you to design workflows that help reduce costs by keeping everyone operating at the top of their license/certification. A simple way to demonstrate this effect is to now put the task grammar to work in a spreadsheet, allowing you to estimate the cost of making simple macaroni and cheese if a Doctor, a Nurse, or an MA prepares it (*Note: These salaries are very inaccurate guesses, but used for discussion purposes only!): 

... which all brings us back to the key data elements that this new task grammar can build onto a policy, to help make it more operational and configurable in an EHR : 

... and coordinating this policy with all of the other tools that shape workflow helps to make your workflows more clear, smooth, and predictable :

This brings us to some helpful take-home messages : 

• Policy writers help to create inspiration and aspiration.
• Clinical Informatics helps to create operation.
• Academic Medical Centers are often required to manage additional layers of complexity (usually created by trainees, supervision models, systems/multiple hospitals, research workflow, and extensive subspecialty variations)

As well as some final thoughts : 

• Modern #Healthcare is going through exponential levels of change.
• Continuously managing and supporting this change is key to EHR success.
• Understanding how to critically read and write policies can help reduce costs, reduce risks, and update/streamline your workflows. 

Remember, Applied Clinical Informatics is not about policy enforcement - It is about workflow translation, advocacy, and alignment.

You will also want to respect the work that got us here (and avoid policy debates) by choosing your terminology carefully when discussing this with your Clinical, Legal, Regulatory, and Compliance Leadership : 

Finally, I suggest that new Applied Clinical Informatics professionals should start with something small - Pick one aspirational policy, try adding the task grammar, work to convert it to a more operational policy, and then test your build feasibility. 


Remember : 

• Policies help define belief;
• Task grammar helps define behavior;
• Blueprints describe what we build;
• Your EHR configuration helps to enforce reality.

I hope this is helpful to you and your own Clinical Informatics teams, and always remember to explore this with your own Clinical, Legal, Regulatory, and Compliance leadership before adopting at your own organization.

Remember - This blog is for educational and discussion purposes only - Your mileage may vary! Have any similar experiences with writing task grammar, or operationalizing pre-existing policies? Feel free to share in the comments section below!

Tips and Tricks for Clinical Workflow Redesign

 Hi fellow CMIOs, CNIOs, and other Informatics friends,

Today I thought I'd share some materials I delivered in a talk back in 2023 for Dr. Judi Binderman, a really seasoned Clinical Informaticist and good friend of mine. I recently discovered these when going through some old slides. At the time, Dr. Binderman had asked me to speak briefly to her team at Community Medical Centers in Fresno, CA about some helpful tips and tricks of clinical workflow redesign : 

My talk was mostly related to workflow analysis, change management, documenting workflows, and workflow design. So I opened up first with a brief discussion about workflow analysis and change management : 

The first point that I usually emphasize for any new Clinical Informatics leaders is that work can be measured and estimated through a workflow gap analysis. The distance from the current state to the future state gives you a good estimate of the stakeholder(s) you will need to involve in a project, what they will need to learn and do (to achieve your future state), and so this gives you a good estimate of your project deliverables and project scope (for planning purposes) :

Once you have completed your gap analysis to get a sense of the current-state and future-state workflows, you can then review a list of common deliverables, to select what you will need to get your users from current to future state : 

Note that some of these deliverables (above) are inside of the Electronic Health Record (EHR), and other deliverables are outside of the EHR. You will want to identify all of the deliverables you anticipate needing/using, and then identify who you will need on your project team to help develop each deliverable.

Remember that workflow change management is a team sport - A common mistake is to think that you can make a change with 'only Doctors' or 'only Nurses'. Almost all clinical workflows depend on many stakeholders, from different enterprises, with a number of different roles. Understanding the different enterprises of your organization, and the different roles you may engage with, is helpful to make sure you've thought through all of the stakeholders you will need to make your project successful : 

Once you have a sense of the estimated stakeholders and deliverables, it's helpful to think through the steps you will need to develop your workflow. For teaching purposes, I usually shrink this down into ten (10) easy steps, that you can talk through with your development team : 

This discussion almost always brings up the debate (question?) about change / project management methodologies. Two common methodologies include : 

• Waterfall Methodology - Linear, step-by-step, good for plan-first approach, takes longer but especially well-suited for Healthcare or new high-risk scenarios where one build is all you can plan for.
• Agile (Software Development) Methodology - Iterative, emphasizes rapid feedback and adaptation, sometimes useful when clinical workflows are evolving or need user-centered design - but not ideal for Healthcare scenarios. Better built for speed and iterations.

Some people will argue that Waterfall can take too long, and they prefer the speed and flexibility of Agile. Personally, I'm not sure how well Agile fits into the many high-risk clinical workflows of Healthcare (since there is usually little room for error), and so I've condensed those ten (10) helpful steps in the slide above into this 'general-purpose change recipe' below :

Once you've gone through the exercise of writing out those ten steps, and developing your own change recipe - You can then import it into a spreadsheet, and add your common roles across the top to build out your own Responsibility Assignment (RACI) Matrix : 

This Responsibilty Assigment (RACI) Matrix can then walk you through the first step of your change management - Documentation of Request and Expectations ('Intake') - And help you to develop key questions that your requestor and their supervisor (e.g. Chief, Chair, or Director) can answer before you do further analysis.

Once you have their preliminary input and feedback, you (Clinical Informaticist) can then pursue the next steps of your journey - Analysis, scoping, prioritization, resource allocation, and project approvals - To help evaluate and develop the request, and make sure your Clinical and Administrative Leadership have the information they need to prioritize and approve the project : 

After your Administrative and Clinical Leadership understands :

• the project priority, estimated scope, estimated stakeholders, estimated deliverables, and necessary resources, 
• the estimated Total Cost of Ownership (TCO) and Return on Investment (ROI)

... they can effectively prioritize and approve the project, leading you to formal project initiation, project development, and the drafting, building, testing, approval, education, implementation, and support of your future-state workflows : 

So - What tips can I offer a new Clinical Informaticist for documenting workflows and workflow design?

My first tip is to closely examine the similarities between a 'Swimlane diagram' (Visio) and a Procedure : 

If we break down a a 'Swimlane diagram' (Visio), it basically answers the questions : 

Q : Who is doing what, and in what sequence (order)?

So with a small adaptation, we can revisit the traditional swimlane diagram as :

... which leads me to share a helpful discussion of what exactly a procedure is (adapted from Charles Webster, MD aka @wareflo, another brilliant Clinical Informatics mind I have had the fortune of learning from)

Procedure (n.) (synonym : workflow, recipe, process, algorithm) - An ordered series of tasks that uses people, time, and resources to achieve a desired goal or outcome.

Now, if you accept the definition above as true, then you can create a simple template for writing a task, the most basic building block of a procedure (synonym : workflow, recipe, process, algorithm) : 

Task = [ WHO ] will/may [ WHAT ] { how } { when } { where } { why } 

where : 

• [ WHO ] = Role of the person that will perform the task
• will/may = Use "WILL" for required tasks, "MAY" for optional tasks
• [ WHAT ] = Brief description of the task
• { how } = Optional modifier, use only when needed to clarify how the task is performed
• { when } = Optional modifier, use only when needed to clarify when the task is performed (for timing/duration)
• { where } = Optional modifier, use only when needed to clarify where the task is performed
• { why } = Optional modifier, use only when needed to clarify why the task is formed

You can then include this in your own 'workflow glossary', where you define and organize your favorite high-grade (policy-grade) terminology related to workflow design : 

... but you can also use it to start writing out procedures for all sorts of things. My favorite teaching example is to take a poorly-written process (in this case, a poorly-developed process for baking and delivering cupcakes) :  

... and turn this into a well-developed process that identifies not only the necessary steps and deliverables of the workflow, but also the necessary stakeholders and their Directors/Chiefs : 

So that's a very helpful skill for the new Clinical Informaticist - Learning how to write an effective procedure. Procedures create clarity and helps you develop solutions. And this also means that your policy manual will be an excellent source of common clinical workflows, their stakeholders, and their deliverables : 

Plus, once you understand how to write a task and a procedure, you can then easily estimate the cost of the procedure by assigning either : 

• Cost = Labor + Materials
• Cost = (Salary * Time) + Materials

... to each step : 

Just for fun, you can use this trick to estimate the cost of a box of macaroni and cheese, if different clinical roles made it : 

... and so, by writing out a procedure and assigning an estimated cost to each step -  you can see the different estimated costs for an MD, an RN, a LPN, and a MA making mac and cheese :

Understanding this (and the regulatory scope-of-practice questions that naturally arise from this level of analysis) can not only help you estimate costs, but also save money, and help your clinicians to work at the top of their license - See the estimated cost of this workflow below, with an RN giving a cupcake to the patient : 

... versus the estimated cost of the workflow if an LPN gives the cupcake to the patient : 

And so, to summarize : 

And some helpful final thoughts : 

And one more final thought (wisdom once passed to me by another experienced Clinical Informaticist, early in my career) : If you're ever lost, start to untangle your workflows by writing a good procedure. 

I hope this has been a helpful journey into how to document, analyze, and develop your own clinical workflows. If you have any questions, please feel free to leave them in the feedback/comment section below! (And special thank you to both Dr. Judi Binderman and Dr. Charles Webster for their contributions to this post!)

REMEMBER : This blog is for education and discussion purposes only - Your mileage may vary. Have any other helpful tricks for quickly untangling or developing clinical workflows? Feel free to leave them in the comments section below! 

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.