Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rethinking IP and OP Number #7798

Open
rithviknishad opened this issue May 13, 2024 · 5 comments
Open

Rethinking IP and OP Number #7798

rithviknishad opened this issue May 13, 2024 · 5 comments

Comments

@rithviknishad
Copy link
Member

rithviknishad commented May 13, 2024

// DRAFT; needs to add more depth

  • OP Number for a given patient is always same for a particular facility. (All the validation for OP have being removed)
  • Should be separate fields in DB, since logic for both is different. Could be same UI field for filter.
  • IP number is unique per encounter.
@aparnacoronasafe
Copy link
Member

@rithviknishad the ideal thing to do is to have 3 numbers captured for every patient/encounter.

MRD (Medicine records department) No. /Patient ID: This is 1 unique ID for a patient per facility. Every new facility the patient goes to, a new unique ID within the facility will be issued to the patient.

IP No.: everytime the patient gets admitted, a unique IP number for the facility will be assigned to that encounter of the patient.

OP No.: every time the patient gets an OP consultation at a hospital, a unique OP number for the facility will given to the patient for that encounter. This OP number will be the same for any immediate follow ups recommended, usually within 2 weeks.

You can think of every hospital maintaining 3 separate registers-

  1. patient registry (MRD No.)
  2. IP registry and
  3. OP Registry

Current need:

Since CARE is adopted only by smaller hospitals, they may have a more simplified approach to patient registries. What we gather is that hospitals may not be keeping separate OP registers but only patient registry (MRD No.) and IP registry. Hence currently, we can retain the existing fields in CARE for IP and OP numbers and allow users to type in the MRD No. within the OP field if the hospital does not have a separate OP Numbering system.

@bodhish
Copy link
Member

bodhish commented Sep 6, 2024

@rithviknishad @gigincg @aparnacoronasafe
Instead of us storing these ID, can't the hospital store our ID into their files/system?

I think we should re-think storing these numbers in the system going forward.

  • Going forward OP number will be unique per doctor per day.
  • IP number will be auto incremented per facility where the facility can pick a starting point.

I am leaning towards allowing users to print and store a barcode for each patient file, this will let them easily find out the patient in the system.

@gigincg
Copy link
Member

gigincg commented Sep 6, 2024

@bodhish I think it's a good idea to support using either the auto-generated or hospital reference as IP/OP Number. They can be maintained as Unique though. Same applies to MRD Number.

There is the question of whether we should support MRD Number is also a question. If we want to support Hospital Level Patient IDs (Including Patient ID Card Printing). We should have support for MRD Number.

@bodhish
Copy link
Member

bodhish commented Sep 6, 2024

I am strongly against adding more of these ids, a facility level unique ID has absolutely no value when you have a patient identifier 🤷🏻, these are mostly remanence from a non tech era.

Also this assumes care is used in parallel with another HMIS system, we should work towards a future where its just care and prioritise features for it.

Ideally I will let users print a QR/barcode; at every location we will have a scanner that directly scans these so that user doesn't have to search.

@aparnacoronasafe
Copy link
Member

Currently CARE is being used in conjuntion with other EMRs and paper-based systems.

We must continue to allow them to add at least 1 parameter (the MRD No.) to map patients across records.

All IP, OP numbers may be autogenerated with bar coding enabled. Fully agree that it will be a better more efficient system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants