Requirement: Doctor adds an Appointment

[pA1nD]

We have a use case in which a doctor can add an appointment.

In this case, the UI has fields for Patient Name, Address, ... and can also be created for a Patient that does not exist in the System, yet. It seems like we currently do not have an API that can handle that.

Find the UI here: https://www.figma.com/file/s5QFKXhMS3Lcmpg5ZFb7Xo/CMR?node-id=142%3A2494

[rubenlop88]

We could add a separate field called "patient" that would contain a json object with the attributes of a patient.

[pA1nD]

How would that be stored in FHIR? I am asking because: What will happen if the Patient does not exist? Will we add the patient?

What happens when this patient will sign up later? Will his/her data be available?

[rubenlop88]

What will happen if the Patient does not exist? Will we add the patient?

That's what I was thinking.

What happens when this patient will sign up later? Will his/her data be available?

If a patient or doctor with a given identifier (Cedula de Identidad in this case) exists, it will not be created again.

[rubenlop88]

Will the doctor provide the identification number of the patient?

[cecicasco]

That is the idea.. we can discuss a solution there, maybe @pA1nD can get all the other data (Name, lastname, gender, etc) from a service (also validate if the the identification number exists) and then send to the FHIR server..

[pA1nD]

I have two doubts:

(1) How does it look from a privacy perspective? If we get all data from a service that returns Name, etc. based on the ID, we essentially give doctors an ID lookup tool. This does not sound optimal to me? Or what do you think guys?

(2) If we save the data in the DB and we make it accessible to a patient later, once this patient signs up, we need to be cautious that currently we do not verify patients. Meaning: Everyone can create a new account with a random (existing) ID. In this case, they would get access to the existing Patient Data. This does not sound optimal to me either!?

What we could do about it:

To fix (1): Request to enter the ID and the Birthdate. We look those up for the doctor, and if it matches, we add the patient.

To fix (2): Add a ID verification (we already have a potential partner to do that) in the registration step.

---

It seems to me like without those points we build a problematic feature. How do yo see that? At the same time, building those things are currently beyond the scope of the current milestone

[rubenlop88]

If we get all data from a service that returns Name, etc. based on the ID, we essentially give doctors an ID lookup tool. This does not sound optimal to me? Or what do you think guys? Request to enter the ID and the Birthdate. We look those up for the doctor, and if it matches, we add the patient.

I think the web app calls the NodeJS server, and then the NodeJS server call the healt-core API right? In that case the NodeJS server could do the validation and then call the health-core API to create the Appointment and the Patient.

Or, the health-core could do the validation instead of the NodeJS server. But this would make the core more tightly coupled with the Paraguayan identification system.

Everyone can create a new account with a random (existing) ID. In this case, they would get access to the existing Patient Data. This does not sound optimal to me either!? Add a ID verification (we already have a potential partner to do that) in the registration step.

Yes, they will have access to the existing patient data, that sounds OK to me as long as the same validation used to create the Appointment+Patient is used to create a new Patient account in Keycloak.

[rubenlop88]

How are we going to do this?

[pA1nD]

This issue is out of scope currently.

It is blocked by the implementation of a more secure Patient Verification on Registration.

We agreed on the following:

Doctors can create entries for Patients given their ID(Cedula) and Birthdate.

This will create a new patient if the patient is not in the system yet and an appointment for this patient.

Once patients claim this account, they will be able to see the past appointments.