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!