/
Procedure History

Procedure History

4 Must-Do’s

1. Problem Description: Have you clearly defined the user problem(s) you intend to solve, and what value this creates? Write down a story, user insight, or quote about this problem (this is important because (1) this will motivate your team, and (2) without this your problem might not actually be a big problem for the users themselves).
2. User Stories: Have you clearly written at least 3 user stories and use cases? 
3. Market Analysis: Have you surveyed what the market is doing here (e.g. comparison to other EMRs, or paper approaches; and don’t forget about learning from historic/existing OMRS instances)? Have you written down any possible gaps in your understanding of your users or their workflows? Have you reviewed the topic in FHIR to see what requirements or fields the global community references? (Eg if working on insurance, should look here)
4. Technical Considerations & Dependencies: Have you outlined what you need from cross-functional areas for success of the feature? E.g. do you need the platform to support a new API call? Have you explained how you’ve addressed dev concerns, such as designs that may not be feasible, or will be extra time-intensive to implement? 

Optional/Encouraged

Sketches: Have you added a drawing or description of how the feature could work to solve the problem at hand? (Pictures of sketches are ok!) 
Project Management: Have you created the Epic and JIRA tasks so you can share work clearly? Roll-out plan: Do you have an idea whether this will be an experiment, gradual roll out, and when? Have you added this to the timeline view? Have you planned how you will promote and/or work with communications folks in order to help this feature reach the widest audience and have the biggest impact it can?

Later but should do

QA Plan: Have you mentioned the plan for QA, such as how you will discover and address edge cases? Does your team/squad have a plan for automated tests to be added to new components (unit tests) or workflows (e2e tests)?
Safety & Tech Risks: Is there any reason you could regret rolling out this feature? (e.g. possible patient harm, heavy tech debt like introducing an unsupported library) Have you thought through the risks for this particular solution? And, how to reduce/address those? 

This checklist was inspired by this article. Additional Business Analyst Resources here.

Summary:

  • Surgeries and some procedures are a really important part of a person’s medical history.

  • We need a portion of the Patient Chart where things like surgeries can be recorded!

In this page:

 

image-20250915-053738.png
image-20250915-055927.png

Problem & User Stories

  • Context: Surgeries and some procedures are a really important part of a person’s medical history.

    • Procedures can be clues! Seeing that someone has had a heart or lung procedure, or multiple biopsies, gives you some clues about what kinds of serious medical conditions they may have. (E.g. multiple biopsies suggests previous providers were worried about cancer; multiple abcesses may suggest an immune condition or that the patient is using IV drugs, etc.)

    • Example: Previous C-Section: Patients who have had a C-Section may need special management in a future pregnancy, which can change their care.

    • Example: Previous Heart Surgery: Patients who have had certain heart procedures in the past are extremely vulnerable to some complications - not only with their hearts, but in other areas like their lungs. This can drastically change what decisions a physician might make.

    • Example: Blood transfusion: Seeing that a patient had a blood transfusion - or especially multiple transfusions - will prompt the provider to ask more health-history questions. E.g. did the patient have a large accident, that could still be affecting them today? Do they have a condition causing serious consequences, such as blood cancer?

    • Example: Previous Colonoscopy or Mammogram: This is important information for Primary Health Care, since when people reach a certain age, they are often supposed to be referred for Colonoscopies and/or Mammograms. Since healthcare staff don’t want to have to ask at every check up “Remind me, um, did you already have a colonoscopy recently?”, it is helpful to have such information easy to look-up in the chart.

  • Gap: We need a portion of the Patient Chart where things like surgeries can be recorded!

    • Problems for you to solve:

      • Recording History of Procedures: This is the focus of this hackathon/v1 feature. As a healthcare staff member taking the patient’s history, I need to be able to record important past surgeries/interventions the patient has had, so that we don’t have to force the patient to repeat themselves on each visit, and so that I can be sure to tailor the patient’s care appropriately.

      • Form Component: (Bonus/Optional for v1 of this feature): Be able to record procedure history within a form workflow. Many forms ask providers to enter past surgical history. We do not want providers to have to enter data twice (both in a custom O3 Form built by an implementation, and in the Procedures app). Instead, it would be ideal to have a form engine component similar to the one we have for Drugs and Conditions. This way everything that’s captured within a physical encounter with the provider gets correctly organized in the chart, without need for duplication of work.

        • Examples of the Drugs, Conditions, and Lab order components embeddable within forms:

image-20250915-064313.png
image-20250915-064359.png

  • Prevent Important Procedures from Getting Hidden: (Bonus/Optional for v1 of this feature): We need a way to make sure major procedures (e.g. heart surgery) don’t get hidden in the noise of small procedures like repeated wound care. For example, a patient who is hospitalized with a wound may have many, many, many orders/instances of “wound care” procedures ordered by a doctor and done by nurses - however, we don’t want something really clinically important like “major heart surgery” to be hidden/hard for clinicians to find behind pages of these minor procedures.

    • One possible approach is to add a piece of metadata / question to the Procedure history list that says “Major or Minor?” Then the list could be filtered to show “Major” surgeries first. However, this is not a universally agreed upon way of categorizing important vs less important procedures.

  • Ordering Procedures: (Note: This is out of scope for v1 of this feature.) In the Order Basket, we’ll want to enable clinicians to Order some procedures (e.g. a doctor might order a blood transfusion). See the screenshots from KenyaEMR below. Note: It is very important it that Ordered Procedures be connected to billing, since this is a big cost/revenue source for clinics.

Designs

Overall, should have:

  • Page in Patient Chart called “Procedures”

  • Left Navigation menu option called “Procedures”. Use the “scalpel” icon from Carbon Design’s Icon Library: <Scalpel /> Search the icon library for “scalpel”, or use this svg file: scalpel.svg

  • Table Widget (app) for showing the history of procedures at-a-glance.

  • Form that opens when you click “Add +” to allow you to “Record a Procedure” (record what important procedures / surgeries the patient had done in the past).

Simple Design showing all the above:

image-20250915-055927.png

Concepts Needed

Typically in the US these are CPT4 codes. However for our community reference content, it is very reasonable to use CIEL codes.

You need 2 categories of concepts for a working v1:

  1. Actual Procedure Concepts: Concepts to collect the name of the procedure done. Grace has started a “Sample Procedures” collection you can use: https://app.openconceptlab.org/#/orgs/openmrs/collections/sampleprocedures/

    1. Subscription URL: https://api.openconceptlab.org/orgs/openmrs/collections/sampleprocedures/1/

    2. JSON file:

  2. Form Concepts: Concepts to collect information for the Procedure History form

    1. See for example: CIEL concept for Procedure history: https://app.openconceptlab.org/#/orgs/CIEL/sources/CIEL/concepts/160714/ (this is added to the “Sample Procedures” collection already)

Technical Guidance & Considerations

Market Analysis

Example

Visuals and Notes

Example

Visuals and Notes

KenyaEMR’s own use in 3.x

In KenyaEMR’s 3.x dev environment, you can actually order a procedure for a patient. However, there is no UI to see the patient’s Procedure history. But, we can still use this work in KenyaEMR as great inspiration for what kinds of procedures should be encoded.

image-20250915-060907.png
image-20250915-060928.png

Note: See how important it is that Ordered Procedures be connected to billing.

image-20250915-061003.png

 

 

image-20250915-061009.png

 

PIH’s use case in O2 in Haiti

For Procedure History: Currently capture history as obs group in a form. It looks like this:
https://github.com/PIH/openmrs-module-pihcore/blob/90fb376935ee071649b2a2c2a8ac4fff869c2ec1/omod/src/main/webapp/pages/visit/templates/encounters/clinicConsultLong.gsp#L71

image-20250911-142135.png

Procedure Notes: For detailed record of a procedure

image-20250911-141941.png
image-20250911-142016.png