Procedures App - Architecture Questions

Development
1

I’m working on the Procedures app for O3 (requirements: Procedure History) and would like feedback on the requirements and the data model before implementation.

Planned Fields

The app will handle both historical procedures (patient intake) and current procedures (documented at facility):

Core fields:

  • Procedure name (coded)
  • Custom procedure name (text) - fallback for unlisted procedures
  • Procedure start datetime
  • Procedure end datetime (null for historical procedures)
  • Actual duration (number)
  • Duration unit (coded: minutes/hours)
  • Outcome (coded)
  • Outcome comment (text, 255 chars)

Form Design

Planning to use a single workspace form with a toggle to switch between “Historical” and “Current” modes. This will adjust field requirements and validation:

  • Historical mode: Minimal required fields (procedure name, approximate date)
  • Current mode: Full detail capture (all time fields, outcome, etc.)

Questions

1. Date Precision for “Historical” Procedures

Patients often only remember approximate dates (“I had surgery in 2018” or “sometime in 2020”). How should we handle this?

Options:

  • Store full date with default values (e.g., 2018-01-01) + add datePrecision field (year/month/day/exact)
  • Custom text field
  • Use separate year/month/day fields
  • Not to collect the date at all
  • Something else?

Any pattern we follow for approximate dates? The only I can think of is the approximate age in the registration.

2. Encounter Linkage

Should procedures link to encounters?

Context:

  • Procedures will use dedicated table (not obs)
  • But form component integration (future feature) would capture procedures during encounter forms

Questions:

  • Should we include encounter_id as an optional field?
  • Do we capture conditions via forms? If so how we handle it? (because conditions doesn’t tie to encounters)

Looking forward to your thoughts!

cc: @ibacher @burke @veronica @dkigen @dkayiwa

4 Likes
2

You’re right that we don’t have any pattern for approximate dates. Probably the most straight-forward thing to do is to actually store dates as ISO 8601 text strings. This allows representations like “2018”, “2018-01”, “2018-01-01T134123-0530.” This, of course, makes parsing and handling these fields a bit of an issue.

With birthdates, we store a full datetime and a boolean indicating if it’s estimated or not. This is obviously problematic because it’s unclear if it’s estimated “20 years” or “3 years, 8 months” or “sometime in April 2000”. I’m not sure we how we handle this in Conditions, the other domain where this is quite relevant.

As a general rule, they should be FormRecordable (an interface in core) which implies they are tieable to an encounter (just like Conditions). However, this field should be optional.

2 Likes
3

Thanks for your work on this @jayasanka .

At PIH, we often (especially for surgical procedures) collect pre and post surgery diagnosis related to the procedure. (These diagnoses aren’t recorded as conditions.)

I don’t know if this would be standard for clinicians or data-use, but perhaps this is useful to the discussion.

2 Likes
4

@jayasanka How about these other fields ~ procedure location, Indication/reason it was done, complications, Procedure Performer/Provider

5

I like the idea of making this optional because trying to tie a historical procedure to an encounter might be a tall order. But for the current procedures, it’s more likely happening during an encounter and thus linking makes sense.

6

Good point @ball. KenyaEMR also captures order reason (free text), but I can also see they have a diagnosis field, which I am not quite sure how it’s captured … @dkibet @kmuiruri please chime in

image
image3024×1796 397 KB

7

@jayasanka i am very sure that you must have discussed this. But just for the sake of completeness and documentation, what were the considered reasons to create a new dedicated table for procedures instead of using an obs group?