Patient2
Patient import into PI Web
What makes up a Patient?
A patient in FOTO is a person that is evaluated via the Patient Inquiry web application. The evaluation is traditionally done via surveys that result in a risk adjusted predicted outcome reported to the clinician. The evaluation and the risk adjustment drive the data we need to have for patient. Here are the properties that make up patient including field sizes and types used for storage. Notice that ExternalID is required as this will identify that person and be used for controlling of future API interactions
Patient2 is an extension of Patient. It adds the ExternalSiteId, MiddleInital and Alias data elements that will be used when creating new episodes in the FOTO system. ExternalSiteId is to assign a patient to a defualt clinic in FOTO and Alias is the suggested Patient ID in FOTO.
Patient Workflow
Patients are created by the clinics with the Patient Inquiry web application highlighting patients that have recently been active. All patients that are imported via the API are held in a separate location from the active patients. When clinic staff starts to enter new patients they are presented with patients that have been imported so they do not have to enter all information. This workflow keeps the patients list in the Patient Inquiry web application clean but also presents the imported information at entry time to save data entry time and assure agreement in data between systems. These advantages are why patients are the initial focus of the API. Since these are stored separately we refer to them as incoming patients.
Importing Patients
The API presents multiple ways for importing patients, managing your imported patients and, for debugging use, the ability to query recently imported patients.
All the patient import methods will check the existing incoming patients' ExternalIDs and update those that match and create new entries for those that don't yet exist.
Do you support HL7?
There is a method available that HL7 messages can be passed to. We currently accept HL7 version 2.2, 2.3 and 2.3.1 messages and take action on the following trigger events.
2.2, 2.3 and 2.3.1
- ADT_A01 = Create
- ADT_A04 = Create
- ADT_A05 = Create
- ADT_A08 = Update
- ADT_A23 = Delete
- ADT_A28 = Create
- ADT_A31 = Update
2.3 and 2.3.1
- SIU_S12 = Update
- ADT_A39 = Merge
- ADT_A40 = Merge
What is used from message
2.2
- ExternalId = PID-3 first instance
- ExternalSiteId = PV1-3.7
- LastName = PID-5.1
- FirstName = PID-5.2
- MiddleInitial = PID-5.3
- Alias = PID-4
- DateOfBirth = PID-7
- Gender = PID-8
- Language = PID-15
2.3 and 2.3.1
- ExternalId = if available PID-2 if not then PID-3 first instance
- ExternalSiteId = if available PV1-3.1 if not then PV1-3.9
- LastName = PID-5.1
- FirstName = PID-5.2
- MiddleInitial = PID-5.3
- Alias = PID-4.1 first instance
- Email = PID-13.4 first email found used
- DateOfBirth = PID-7
- Gender = PID-8
- Language = PID-15
- Payer Source = PV1(0)-20 (Organization cross reference needs to be available for organization)
- Physician Referral = PV1(0)-8 (ID PV1(0)-8.1, FirstName PV1(0)-8.3, LastName PV1(0)-8.2, Description PV1(0)-7)
- Insurance Referral = IN1(0)-2 (ID ID1(0)-2.1, Description ID1(0)-2.2)