# Medical Record Patient Service

###### tags: `note`

kalo ada bingung ato apa yaudah salah lu yak

## Registration Medical Record Patient Flow# Periksa Id

### The Sequence Diagram For Backend Flow
:::info
:bulb: tags: `note` : Diagram ada 2. yang pertama untuk sisi Penembakan endpoint , yang kedua dari sisi full detail proses Pendaftaran Pasien Baru.

### Pic 1

### Pic 2
:::

:rocket:

### Struktur Atribut

Berikut Adalah model/atribut yang digunakan dalam request body .

| Key | Data Type |
| ----------------- |:-----------------------|
| nama | string |
| namaPanggilan | string |
| identitas | string |
| nipNrp | string |
| noBst | string |
| noIdentitas | string |
| tempatLahir | string |
| tanggalLahir | Date |
| jenisKelamin | string |
| statusKawin | string |
| idReferenceGolonganDarah | int |
| idAgama | int |
| wargaNegara | text |
| telepon1 | string |
| telepon2 | string |
| email | string |
| id_jenis_pasien | int |
| idKaryawan | int |
| idNegara | int |
| alamatIdentitas | string |
| idAlamatIdentitas | int |
| alamatSekarang | string |
| idAlamatSekarang | int |
| idSuku | int |
| idPendidikan | int |
| idReferencePekerjaan | int |
| namaInstansi | string |
| nomorKartu | string |
| bahasa | string |
| hambatanBicara | string |
| kesatuanAngkatan | string |
| keterangan | string |
| foto | string |
| fotoIdentitas | string |
| namaAyah | string |
| pekerjaanAyah | string |
| golongan | string |
| namaPenanggung | string |
| alamatPenanggung | string |
| idAlamatPenanggung | int |
| teleponKeluarga | string |
| teleponKeluarga_2 | string |
| idReferenceHubungan | int |

### Langkah-Langkah / Alur Pendaftaran Pasien Baru

### Step 1: Isi Data Form Sesuai Dengan Format masing-masing input

### Step 2: Service menerima data dari Front End

data diolah di backend , jika data yang diterima sesuai maka akan lanjut untuk

### Step 3: Meng-generate NOMOR RM(Rekam Medis)
Sebelum men-save data ke dalam database, tiap pasien harus memiliki Nomor Rekam medis. generate nomor rekam medis harus dilakukan 1 langkah sebelum men-save data ke database untuk meminimalisir double generate no rm (double NomorRm sering terjadi karena penginputan high traffic secara bersamaan) Berikut Cara mencegah event tersebut

### 1. Get Nomor Rekam Medis Dari idPasien terakhir di database Lalu di increment atau ++1 baru di save `*CURRENT USE`

\\ Example
let attributes = req.body  

//example generate no rm 
const lastRM = SELECT 
    NO_REKAM_MEDIS as no_rm
FROM 
    pasien 
WHERE 
    ID_DATA_KLINIK = ${idDataKlinik} 
    AND VISIBLE = 1 
ORDER BY 
    NO_REKAM_MEDIS DESC
LIMIT 1;

let newRM = lastRM[0].no_rm + 1
attributes = {
...req.body,
newRM,
};

let pasien = await PasienWrite.create(attributes);   
//norm dimasukan kembali ke attribut lalu di save ke table pasien

langkah tersebut adalah langkah yang sekarang dilakukan di service sebelumnya
#### pros:
- Meminimalisir double RM karena aksi dilakukan 1 langkah sebelum Saving Data
- Tidak memenuhi load koneksi di database `(Get pasienByIdPasien as long as the indexing work well, dan pengecekan dari DatabaseMaster bukan read/replika agar tidak ada delay)`

#### cons:
- bisa terjadi double generate no rm jika penginputan dilakukan bersama secara Second&Milisecond `(Ex: 2 Pegawai rekam medis masing-masing meng-submit pasiennya di detik yang sama)`

### 2. Data pasien di save dahulu lalu nomor rekam medis dari idpasien yang sudah di save di update

\\ Example
let attributes = req.body
let pasien = await Pasien.create(attributes);   

    UPDATE pasien
      SET NO_REKAM_MEDIS = IFNULL((
        SELECT NO_REKAM_MEDIS
        FROM pasien ps
        WHERE ID_DATA_KLINIK = ${idDataKlinik}
          AND NO_REKAM_MEDIS IS NOT NULL
        ORDER BY ps.NO_REKAM_MEDIS DESC
        LIMIT 1
      ), 0) + 1
      WHERE ID_PASIEN = ${pasien.idPasien};

#### pros:
- lebih meminimalisir lagi double RM `(Karena Data di save terlebih dahulu (tanpa rekam medis) lalu langsung di update dari query tanpa pengecekan 2x`

#### cons:
- high traffic/connection kemungkinan terjadi karena melakukan write activity di database secara berulang `walau tidak sering`
- ada kemungkinan lock database juga terjadi karena index yang di cek di transaction tersebut (UPDATE) di lakukan secara bersamaan

mungkin ntar kedepannya sekalian dicari step mana yang paling enak untuk mengurangi kemungkinan double rekam medis maaci