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!

How I Became a 'Document Whisperer'

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

I'm writing today to share some stories from my career path in Applied Clinical Informatics, and how I became a 'document whisperer' with regard to clinical workflow design. This post stems from a common question I get asked: 

'If you care so much about clinical workflows - Then why do you seem to care so much about bylaws, policies, procedures, guidelines, protocols, bylaws, charters, order sets, and other documents? Why don't you just worry about the things inside the EMR?' 

The reason is because all of these documents (whether they are inside or outside an EMR) work together to shape clinical workflow. 

To explain, I need to first offer some context. 

Back in 2007 when I first started my formal clinical informatics career, like most newcomers, I didn't yet have enough experience to fully understand my role. I figured my job was to 'help with the electronic medical record', so naturally, I focused mainly on the things that doctors interacted with inside the EMR. 

After a while, however, I started to see challenges we had with some of our projects. There were order sets that, after we built them, didn't get used. There were order sets that created turbulence with other workflows when we rolled them out. I received complaints from doctors who felt the computer was 'too clunky' and that 'it takes too long to get things done'. 

Initially, I wondered if this was simply a matter of an EMR just being more difficult to use. There were some people who told me, 'Oh, some doctors are just resistant to change' (which is partly true), and others who told me, 'Computers are just complicated and finicky' (which can also sometimes be true).

But I kept looking for a better answer - There must be some sort of symmetry here that I was missing. 

And then, over the next 2-3 years, I experienced two important things : 

1. I once worked on a complex titration protocol, which required an extensive analysis to fully build out the protocol, and...
2. One day, a Registered Nurse complained to me about a policy that would need to be updated, in conjunction with a project we were actively working on.

So it was while confronting the question of 'How exactly do you write a protocol?' that I started to really confront the question : "What exactly is a protocol?" This led to even more questions, like : 

Trying to find more concrete answers, I looked to various potential sources, including various regulations, the International Standards Organization (ISO), the National Institute of Standards and Technology (NIST), the CMS web site, various HealthIT/Informatics societies, ITIL, and even Black's Law Dictionary, without much help. 

So around 2010, I decided to look at this from a more analytical, design-thinking standpoint : 

"If we gathered every document in healthcare, both those sitting on desks and on hard-drives - what would they be, and what would they look like?"

This led me to scribbling down some commonly-used words people use in healthcare, putting them into a spreadsheet, and in 2010 I came up with my first CMIO's Checklist : 

[ FIRST DRAFT ] Note : My workflow definitions have evolved since this 2010 version.

[ FIRST DRAFT ] Note : My workflow definitions have evolved since this 2010 version.

... which turned out to be my first real foray into clearly-defined terms, tools, and functions. Yes, a sample size of one - based only on my own clinical and administrative experiences - but a fairly comprehensive function-based analysis, nonetheless, that helps to clarify concepts and increase shared understanding.

(What good, functional, policy-grade definitions do to clarify concepts

and increase shared understanding - Hit PLAY to see animation)

Now with this new function-based analysis in hand, I stumbled into two interesting [DRAFT] functional definitions : 

Template (n.) - A tool used to standardize and expedite the creation of a document. 

... and ...

Document (n.) - A tool used to record and transmit information.

... both of which shed light on an important concept - For many of you, this may be common-sense or trivial, but for me it was a 'eureka' moment : 

• Definitions can be used to create templates.
• Templates can be used to create documents.
• Documents can be used to store and transmit the information needed to support workflows.

So around 2015, this led me to the realization that these concepts all depend on each other. And so, realizing that workflow inconsistencies sometimes arise from misalignment of these concepts, I wrote this blog post about workflow management and the Clinical Informatics domain : 

[ SCREENSHOT ] From Informatics Domain and Workflow Management, 2015

 

This also led me to the realization that all of the documents and tools contained in drawer #4 above :

• needed to be aligned with the workflows, goals, and mission above it, and... 
• were shaped by the concepts contained in #5, #6, #7, and #8 below it. 

It also revealed to me that some of the documents and tools that support workflows are typically contained inside the EMR, and others were contained outside the EMR : 

So now being able to mentally visualize this conceptual structure (above), I also realized that : 

• Workflow depends on all of these tools (above) for support. 
• Changing workflow means changing all of the tools (both inside and outside the EMR) that are used to support the workflow.

... and so effective workflow change management means : 

1. Clearly understanding each deliverable (tool) above.
2. Identifying the deliverables (both inside and outside the EMR) that are needed (or need to change) to support the desired workflow. 
3. Quickly drafting those deliverables, to demonstrate to users and HealthIT professionals how the deliverables need to fit together,
4. Reviewing those draft deliverables with clinical stakeholders, to confirm their needs/expectations before committing them to a formal build, and to help get their input and align expectations.

So to help quickly draft the deliverables in step #3 above, I had to quickly make templates for these roughly 24 documents that we commonly use in healthcare. And this brought me back to my pursuit for high-quality, high-grade definitions so that my workflow templates were quick, easy-to-use, and maybe most important - functionally sound. 

And this is essentially how I became a document whisperer for good clinical workflow design and EMR support. Using this deeper understanding of how these common concepts are related has helped me to quickly draft the 'workflow blueprints' that help to outline workflows, identify deliverables, identify stakeholders, create clarity, develop understanding, and align expectations before beginning a project. (This understanding has proven especially useful when scoping/analyzing clinical project requests prior to approval.)

 

I hope sharing this journey helps give you a roadmap for your own journey, and helps you develop your own definitions, templates, and tools for rapid workflow analysis and scoping before undertaking any significant projects. 

Remember this blog is for educational purposes only - Your mileage may vary. Have any anecdotes or stories to share about workflow analysis or development? Feel free to leave them in the comments section below!

Difference between Specialty, Service, Level-of-Care, and Location?

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

In today's post, I thought I'd help answer a common clinical terminology question I sometimes get asked, about information management during inpatient hospitalizations : 

I thought I'd write this post, largely because these very important terms : 

1. Specialty / Subspecialty
2. Service
3. (Nursing) Level-of-Care
4. Geographic Location

... can often look alike and sound alike, and so they are sometimes easily confused (or used interchangeably) by both clinical and administrative staff.

Unfortunately, getting this terminology right is essential to good communication, good patient flow, good bed management, and good data reporting - So for clinical educational purposes, I figured I'd write this helpful primer on these terms, what they do, and how to use them. 

A. WHAT IS SPECIALTY (and SUBSPECIALTY)

Specialty (and subspecialty) is what a Provider is trained to do. While the Association of American Medical Colleges (AAMC) recognized the need to stratify medical training back in 1876, this specialty (and subspecialty) training has since continued to evolve. 

Today, we recognize a number of :

• RESIDENCIES (SPECIALTY TRAINING)
• FELLOWSHIPS (SUBSPECIALTY TRAINING)

...which together, gives us some of the physician specialties (and subspecialties) that most people will recognize today : 

• Select ONE :
• (  ) INTERNAL MEDICINE (General Internal Medicine)
• (  ) INTERNAL MEDICINE > CARDIOLOGY
• (  ) INTERNAL MEDICINE > ENDOCRINOLOGY
• (  ) INTERNAL MEDICINE > GASTROENTEROLOGY
• (  ) INTERNAL MEDICINE > RHEUMATOLOGY
• (  ) INTERNAL MEDICINE > GERONTOLOGY (Geriatrics)
• (  ) INTERNAL MEDICINE > PULMONARY/CRITICAL CARE
• (  ) INTERNAL MEDICINE > HEMATOLOGY / ONCOLOGY
• (  ) PEDIATRICS (General Pediatrics)
• (  ) PEDIATRICS > EMERGENCY MEDICINE
• (  ) PEDIATRICS > NEONATOLOGY
• (  ) EMERGENCY MEDICINE (General emergency medicine)
• (  ) EMERGENCY MEDICINE > TRAUMATOLOGY
• (  ) EMERGENCY MEDICINE > TOXICOLOGY
• (  ) RADIOLOGY (General Radiology)
• (  ) RADIOLOGY > INTERVENTIONAL
• (  ) SURGERY (General Surgery)
• (  ) SURGERY > ORTHOPEDICS
• (  ) SURGERY > PLASTIC SURGERY
• (  ) SURGERY > NEUROSURGERY
• (  ) SURGERY > TRANSPLANT
• (  ) SURGERY > GYNECOLOGIC
• (  ) SURGERY > VASCULAR
• (  ) NEUROLOGY (General Neurology)
• (  ) NEUROLOGY > MOVEMENT DISORDERS
• (  ) NEUROLOGY > MULTIPLE SCLEROSIS
• (  ) OBGYN (General OBGYN)
• (  ) OBGYN > MATERNAL FETAL MEDICINE
• (  ) OBGYN > FERTILITY MEDICINE
• (  ) PSYCHIATRY (General Psychiatry)
• (  ) PSYCHIATRY > CHILD AND ADOLESCENT

... and over 135 other specialties/subspecialties currently recognized by the AAMC.

Note : While there may be some occasional variation about how one ended up in a particular subspecialty (e.g. Pediatrics>Emergency Medicine, or Emergency Medicine>Pediatrics), historically - this system of categorization has generally worked fairly well, and gives people a good sense of what training the provider has had. 

The key take-home point : Specialty/Subspecialty training is what the provider has been clinically trained and licensed to do.

B. WHAT IS A SERVICE?

Service is what the provider actually does. It'stypically one-or-more clinical function(s) that they have been assigned to deliver.

Services are commonly categorized as either INPATIENT, ED, or OUTPATIENT services, and again, a provider may function in one or more services : 

• Select ALL THAT APPLY : 
• [  ] OUTPATIENT Internal Medicine (Ambulatory Internal Medicine Clinic)
• [  ] INPATIENT Hospitalist
• [  ] INPATIENT Intensivist
• [  ] INPATIENT Labor and Delivery
• [  ] OUTPATIENT Psychiatry
• [  ] INPATIENT Psychiatry
• [  ] EMERGENCY MEDICINE (Emergency Services)
• [  ] INPATIENT Neurology
• [  ] OUTPATIENT Neurology (Ambulatory Neurology Clinic)
• [  ] INPATIENT Surgery 
• [  ] OUTPATIENT Surgery (Ambulatory Surgery Clinic)

... and many other clinical services (functions) that have been designed to provide patient care services in various settings. 

This is where confusion can sometimes arise, especially for scenarios where a provider might have one specialty but two services, e.g. : 

• SPECIALTY/SUBSPECIALTY = INTERNAL MEDICINE (General Internal Medicine)
• SERVICE1 (Primary Service) = OUTPATIENT INTERNAL MEDICINE (General Internal Medicine)
• SERVICE2 (Secondary Service) = INPATIENT HOSPITALIST

Confusing specialty and service can lead to incorrect scheduling of meetings - E.g. Let's say you want to introduce a new outpatient televideo service to your OUTPATIENT INTERNAL MEDICINE docs, then : 

• [ WRONG WAY ] Mail to SPECIALTY = Internal Medicine ('Please mail this to all Internal Medicine Docs!')
• [ RIGHT WAY ] Mail to SERVICE = Outpatient Internal Medicine ('Please mail this to all docs who work in the Outpatient Internal Medicine Clinic/Service!')

If you accidentally did mail your announcement to SPECIALTY = Internal Medicine, then half of the recipients might wonder why you contacted them about this new outpatient tool : 

• SPECIALTY = INTERNAL MEDICINE - Includes both : 
• [ INTENDED AUDIENCE ] SERVICE = Outpatient Internal Medicine
• [ UNINTENDED AUDIENCE ] SERVICE = Inpatient Hospitalist

As you can see, it's very easy to get tripped up on this terminology, when it looks so similar. 

One final note about SERVICE - This is often used during inpatient admissions to describe the "Admitting/Covering Service", as in, who should Nursing call when they identify something that needs a Physician's attention?

C. WHAT IS A (Nursing) LEVEL-OF-CARE

The (Nursing) Level-of-Care is an important concept that basically answers the question, "What are the nursing standards that are required for a patient admitted in this hospital bed?" Typically, this is based on patient type and acuity, and is developed in conjunction with both Nursing Leadership and Physician Leadership. From a practical standpoint, this usually needs to include some agreements about : 

• Patient Acuity - How active are the patient's medical problems, and how much care will they need? (Low/Medium/High?)
• Standard Frequency of Vitals - How often does a Nurse need to monitor the patient?
• Standard Nursing Skill Set - What are the Nurses trained/certified to do? Is it general care, or specialty care? On what patient population? Adults? Pediatric? Neonates?
• Standard Nurse Staffing Ratios - How many patients are Nurses routinely expected to manage concurrently for this Level-of-Care?

Because these are all important to establish a level-of-care, they are commonly laid out in a table that might look something like this : 

So to help standardize care along the needs of the patient (and patient acuity), most admission order sets are aligned along these Nursing Levels-of-Care, with vitals that default to the institutional standards - E.g. :

• ADMIT TO ADULT MED/SURG : 
• [   ] Vital Signs every 8 hours
• [   ] Vital Signs every 6 hours

... and ...

• ADMIT TO ADULT ICU
• [   ] Vital Signs every 1 hour
• [   ] Vital Signs continuously

... and so on. 

D. WHAT IS A GEOGRAPHIC LOCATION?

Geographic location technically should be the easiest concept to manage - It's just the floor/room (and sometimes bed slot, E.g. Bed A or Bed B) that the patient's bed is geographically located in. Sometimes it also includes a temporary location, such as when a patient is being temporarily located in Radiology for an X-ray :

• Geographic Location = Room 401 
• Temporary Location = Radiology
• Sometimes displayed as "Room 401 (Radiology)"

However, location can occasionally be confused with a (Nursing) Level of Care, especially when naming conventions sometimes combine these concepts, usually intended for convenience purposes. (E.g. "5th Floor Telemetry")

Note that there are two challenges that can sometimes occur when combining these concepts in the naming convention for your geographic locations/floors : 

1. FIRST CHALLENGE : The first of these challenges is boarding - which is when a patient bed needs to be created in a non-standard location, usually for patient flow and/or surge purposes. For example - 

• If you usually have ten (10) beds on your FOURTH floor, where you commonly care for up to ten (10) Med/Surg patients...
• One day, you have a patient surge, and need to be able to care for twelve (12) Med/Surg patients...
• ... then you will need to create two (2) extra Med/Surg beds, maybe on the FIFTH floor. 

Assuming you are approved to 'surge' your bed capacity like this, and have the Med/Surg nurses available to support those two (2) extra Med/Surg beds on the FIFTH floor, then you can hypothetically create a bed with a defined (Nursing) level-of-care in any geographic location that can support the delivery of the necessary (Nursing) level-of-care. 

For example, in an disaster scenario, you could hypothetically make a med/surg bed available in your cafeteria (assuming you had the available resources) : 

• ADMIT TO = Med/Surg Level-of-care
• GEOGRAPHIC LOCATION = CAFETERIA Bed 2
• SERVICE = Inpatient Hospitalist

Or, if you are admitting a Med/Surg Patient from the Emergency Room to your FOURTH floor (where you commonly care for Med/Surg patients) - If there is no bed available on the FOURTH floor, you you could hypothetically admit and 'board' the Med/Surg patient (temporarily) in an Emergency Department location : 

• ADMIT TO = Med/Surg Level-of-Care
• GEOGRAPHIC LOCATION = ED Bed 2
• SERVICE = Inpatient Hospitalist

... and then once the bed becomes available on the FOURTH floor, you could update the status: 

• ADMIT TO = Med/Surg Level-of-Care
• GEOGRAPHIC LOCATION = Fourth Floor Bed 401
• SERVICE = Inpatient Hospitalist

As you can see, keeping this terminology clear and concise is important for the delivery of services. 

2. SECOND CHALLENGE : The second challenge that comes from naming conventions that combine concepts (e.g. "FOURTH Floor Med/Surg") is data-reporting. Suppose that when beds are needed - you 

• sometimes have to board MED/SURG patients on your FIFTH floor, or 
• sometimes you have to board TELEMETRY patients on your FOURTH floor.

And then one day, you need to know, "How many Med/Surg patients did we see last month?"

• If you generate a report of 'How many patients were geographically admitted to the FOURTH floor', you may miss any Med/Surg patients who were boarded in other locations, or over-count other telemetry patients who might have been temporarily boarded on the FOURTH floor.
• If, instead, you generate a report of 'How many patients were admitted with a Level-of-Care=Med/Surg", your report will be accurate and will account for any patients who were temporarily boarded in non-standard locations.

If this all seems confusing, you're not alone. Even seasoned professionals can sometimes confuse/interchange these terms. It's helpful to have an experienced Clinical Leader, Bed Manager, HIM/Billing/Coding person, or Applied Clinical Informatics person to help translate/validate, help design your bed management and patient flow strategy, and then help turn that into build/configuration that meets the needs of your patients, Nurses, Physicians, Bed Managers, Billers/Coders, and Data Reporting teams. 

In conclusion - These terms are all very important, and are the reason most hospital admissions contain the following information : 

• [ REQUIRED ] ADMIT TO = ________ (Nursing) Level-of-care
• [ REQUIRED ] SERVICE = ___________
• [ OPTIONAL ] GEOGRAPHIC LOCATION=(Use only if a particular location is necessary, otherwise Nursing may not have any flexibility about where to geographically locate the patient in a surge/boarding scenario.)

... and why it's also helpful to track doctors by both their specialty/subspecialty and also their service(s) : 

• SPECIALTY/SUBSPECIALTY = Internal Medicine (General Internal Medicine)
• SERVICE1 (Primary Service) = Inpatient Hospitalist
• SERVICE2 (Secondary Service) = Outpatient General Internal Medicine

While this may have been somewhat lengthy, I hope this helps you review and discuss this terminology with your own teams. 

Remember, this blog is for academic/discussion purposes only - Your mileage may vary! Have any patient flow or bed management tips you'd like to share? Have any experiences managing this terminology with your teams, or any other feedback you'd like to share? Leave it in the comments section below!