This page provides an overview of the available API endpoints within FYDO, along with a summary of the data shared through each endpoint.

For clarity, the following terms are used throughout this document:

• PII (Personally Identifiable Information): Any data that can be used to identify an individual, such as name, date of birth, contact details, or identifiers like MRNs.
• PHI (Protected Health Information): Health-related information that is linked to an individual, including clinical data, diagnoses, procedures, and appointment details.

This information is intended to support your internal governance, privacy compliance, and decision-making when enabling access for third-party systems to your FYDO database via APIs.

Endpoint	Description	Details of Data shared
/api/Anaesthetictype/getAnaesthetictypeSyncList	Anaesthetic Type	Anatype code and description (no PII or PHI)
/api/AppointmentTypes/getAppointmentTypesSyncList	Appointment Type	Appointment type name, length, color, status (no PII or PHI)
/api/BookingCodes/getBookingCodesSyncList	Booking Code 1 and 2	Booking code 1 and 2 description and status (no PII or PHI)
/api/Doctor/CheckPractitioner	Cgov Integration
/api/Doctor/UpdatePractitioner	Cgov Integration
/api/Clinic/getClinicApptsList	Clinic Appointments	Contains PHI for clinical appointments
/api/Codingdiag/getCodingdiagSyncList	Episode Diagnosis Codes	ICD diagnosis code (de-identified PHI)
/api/CodingProc/getCodingprocSyncList	Episode Procedure Codes	ICD procedure code (de-identified PHI)
/api/Countries/getCountriesSyncList	Country List	Country of birth code and description (no PII or PHI)
/api/Diag/getDiagSyncList	Diagnosis Codes List	Latest version of ICD diagnosis code, description and effective date (no PII or PHI)
/api/Doctors/getDoctorsSyncList	Doctor List	Doctor ID, specialty, name, contact details, APHRA, provider number, specialty and insurance details
/api/Drg/getDrgSyncList	DRG List	DRG codes and description (no PII or PHI)
/api/DrSpeciality/getDrSpecialitySyncList	Doctor Specialty List	Specialty code, type, description and status (no PII or PHI)
/api/Episode/getEpisodeList	Episode Details	Contains PHI and PII for each episode within the selected period e.g.: Adm/discharge date/time and Doctor ID etc.
/api/Episode/getEpisodeListAnon	Episode Details	De-identified episodic details
/api/Episode/EpisodeDetailReportList	Episode Details	Aligns with the Episode Stats Report output (Contains PII and PHI)
/api/Episode/EpisodeSurvey	Cemplicity Integration	Contains PHI
/api/Episodeitems/getEpisodeitemsSyncList	Episode MBS Items	Episode identifier and MBS item (no PHI)
/api/Episodeitems/getEpisodeOSSyncList	Episode Other Service Items	Episode identifier and other service item codes e.g.: prosthesis, misc. items etc. (no PHI)
/api/Episodevisits/getEpisodevisitsSyncList	Theatre Time Values	Episode identifier, theatre time, proc time, other theatre personnel e.g.: nurse, surgical assistant etc. (no PHI)
/api/Healthfunds/getHealthfundsSyncList	Health Fund List	Fund code, name, status and other relevant settings (no PHI)
/api/InProcSch/getInProcSchSyncList	Inpatient Procedure Information	Episode ID, theatre, proc date and booking code (no PHI)
/api/Languages/getLanguagesSyncList	Language List	Language code, description, state code and threshold date (no PHI)
/api/Locations/getLocationsSyncList	Location List	Hospital location, address, contact, BSB and account details (no PHI)
/api/LoginDetails/getLoginDetails	FYDO User Login Details	UserID, user Type, username and created date (no PHI)
/api/Mbsitem/getMbsitemSyncList	MBS List	MBS code, description, theatre band, day band, other relevant settings and status (no PHI)
/api/Misccode/getMisccodeSyncList	Misc code list	Code (Prosthesis rebate code and misc/other service code) and description (no PHI)
/api/Morp/getMorpSyncList	Morphology List	ICD morphology code, description and ICD date (no PHI)
/api/Patient/getPatientList	Patient List	Patient demographics (Contains PII)
/api/Patient/Cemplicity	Cemplicity Integration
/api/Patrefs/getPatrefsSyncList	Patient Referral Details	Patient ID, referral no, referral period and referral first visit date (no PHI)
/api/Practice/getPracticeSyncList	Practice List	Practice name, address, contract and status (no PHI)
/api/Proc/getProcSyncList	ICD Procedure List	ICD procedure code, description, sex code and ICD date (no PHI)
/api/Prostheses/getProsthesesSyncList	Prothesis List	Billing code, prod name, company and status
/api/Recdata/getRecdataSyncList	Patient Recall Details	MRN, next recall date, reason, action and recall date
/api/Ref/getRefList	Referring Doctors List	Referral #, name, provider number and contact
/api/Report/GetUnbilledRevenueData	Unbilled Revenue Report	Derived from the same data source and business logic as Unbilled Revenue Report (contains PII and PHI)
/api/Report/ArrearsReportHospital	Arrears Report	Derived from the same data source and business logic as Arrears Report (contains PII and PHI)
/api/Service/getServiceSyncList	Financials Revenue	De-identified episodic ID, service code, date of service, date of transaction, date of audit, charges, GST charges and service code type
/api/Service/getserviceListDoc	De-Identified Financials	Same output as getServiceSyncList, however, no doctors’ names and drawer
/api/Theatres/getTheatresSyncList	Theatre List	Theatre name, type, location ID, color and theatre no (no PHI)
/api/TheatreSchedule/getTheatreScheduleSyncList	Theatre Roster	Date, time, length, theatre, Doctor ID, anaesthetist ID, other nursing staff, reason for delay and cancel status (no PHI)

The process of billing NIB Type C procedures, to accommodate the SDEX item, has been simplified in FYDO.

To accommodate the easier workflow, development work has been completed to restructure how FYDO processes these claims, ensuring they can continue to be transmitted electronically and paid successfully via ECLIPSE.

As part of this update:
– It will no longer be necessary to manually add SDEX as an item number to each claim
– FYDO will automatically populate and transmit the required information in the correct segments in line with NIB’s updated requirements

Please see the updated requirements below for billing NIB procedures with a Type C Certificate:

1. Settings > Health Fund Fees > Fund: NIB > Other Settings tab.
   Review the two options below to ensure the setting aligns with your NIB contract stipulations:
   – When Type C – Charge Theatre fees is to be selected if your contract allows theatre fees for the Type C item number.
   – When Type C – ignore Type C accom fee is to be selected if the contract allows for the regular accommodation band (1 to 4) to be billed, instead of the specific Type C Accommodate Fee.

2. The Type C Accommodation Fee must be configured, as it will be used and reported within the Single Value Benefit (Casebase Fee) segment. This can be found in the Same Day Fees tab.

3. NIB Type C procedures are now required to be billed on a per diem basis. When using the Create Invoice screen, please ensure that the billing type is set to Default or Per Diem. FYDO will convert the per diem Type C bed fee into the required Single Value Benefit (Casebase Fee) segment, applying the appropriate mapping code.

If you require any further clarification, please don’t hesitate to reach out.

This page outlines the standard Fydo workflow for:

• Admitting maternity patients
• Registering newborns
• Entering Hospital in the Home (HITH) details where applicable

This ensures patient records, episodes, and downstream integrations (billing, reporting, data extracts) are accurate.

Maternity Patient Admission

1. Navigate to Appointment → Right-Click Menu → Make an Appointment
2. Select the appropriate Patient Category & Accom Type

3. Once the mother needs to be Admitted, this can be done in the usual matter:

• Care type = Acute
• Other details same as overnight Acute
• 💡HITH Start Date – if patient is going to receive Hospital In The Home care during the episode, HITH start date can be entered after patient is admitted.

4. Allocate a Bed to the mother – Appointment → Right-Click Menu → Inpatient → Bed History

Registering Newborns

Newborns must be registered as separate patient records and linked to the mother.

Step 1: Create Newborn Patient Record and admission

1. From the mother’s appointment, Right Click > add Newborn (or create a new patient manually)

2. Enter newborn details:

• Temporary name (e.g. Baby of Jane Smith which can be updated later once the legal name is confirmed)
• Date and time of birth
• Gender
• Most of the details will be inherited from Mother, for example address, GP, Fund etc.
• NOK/Emergency Contact relationship must be reviewed and updated as FYDO blank fills the relationship after copying Mother’s details

3. After the newborn patient details are saved, FYDO will prompt the newborn admission screen. Enter all newborn admission details.

📝Currently only QLD facilities will have below highlighted fields pre-populated for newborn admissions; other state will need to manually assign the relevant values.

Step 2: Link Newborn to Mother

1. This will be linked automatically if baby is registered using the Add Newborn option

From Baby’s record, Mother name is listed and hyperlink to mother’s patient details page:

From Mother’s record, child/ren’s details are also listed:

Discharge Mother and Newborns

Always Discharge from the Mothers Episode

1. Appointments Screen → select Mothers episode →Right-Click Menu → Discharge

📝 If HITH start date is entered on admission screen, HITH end date will auto default to Discharge date, can be updated if needed

2. FYDO will prompt a screen to also discharge the baby

FYDO now supports a digital workflow for sending Informed Financial Consents (IFCs) and National Private Patient Hospital Claim Forms (HC21 forms for insured patients) directly to patients via the Preadmit Portal.

This feature allows patients to receive, review, and sign their IFC before arriving at the facility, with the signed document automatically returned to FYDO for staff to view — reducing paperwork, manual handling, and administration time.

---

What This Feature Does

Once enabled, this feature allows facilities to:

• Send IFCs and HC21 forms digitally via the patient’s Preadmit Portal
• Allow patients to read and sign forms in their own time
• Automatically return the signed IFC to FYDO
• Automatically update Checklist items as the IFC progresses
• Give patients ongoing access to their signed IFC via the Preadmit Portal
• Reduce reliance on paper forms while still meeting informed financial consent obligations

Key Benefits at a Glance

• ✅ Faster, more efficient IFC processing
• ✅ Reduced manual administration
• ✅ Clear visibility of signed vs unsigned IFCs
• ✅ Improved patient experience
• ✅ Reduced paper usage
• ✅ Continued compliance with informed financial consent requirements

---

How the Digital IFC Process Works

At a high level, the workflow is as follows:

1. The facility creates the IFC in FYDO (using the existing IFC screen).
2. The IFC is sent digitally to the patient via their Preadmit Portal.
3. The patient reviews and signs the IFC online.
4. The signed IFC is automatically returned to FYDO.
5. Facility staff can view the signed form directly in FYDO Documents.

No scanning, uploading, or manual checklist updates are required.

---

Automated Checklist Updates

As part of this workflow, FYDO’s Checklist feature is fully automated:

• “IFC Created” is automatically ticked when the IFC is generated
• “IFC Signed” is automatically ticked once the patient signs the form

This provides staff with real-time visibility, right on the Appointments Screen, of which patients have completed their IFCs and which are still outstanding — without any manual intervention.

---

Patient Access to Signed IFCs

Once signed, the IFC remains available to the patient via their Preadmit Portal at any time.

This means:

• Patients can easily access their copy when needed
• Facilities can reduce or eliminate the need for printed copies
• Hospitals continue to meet their obligation to provide informed financial consent documentation

---

Important Requirements

Preadmit Account Required

This digital IFC feature only works for patients who have a Preadmit Account.

If a patient does not have a Preadmit Account, the IFC will need to be handled using existing non-digital processes.

Patients with a Preadmit Account can be identified by the Preadmit Logo displaying on their Patient Screen.

Patients are linked to their Preadmit Portal via the Email Address that they use to log in. FYDO can check existing patients utilising the Get Preadmit ID feature on the Patient Screen for patients with a valid email address entered.

---

Enabling This Feature

This feature must be enabled by the FYDO Support team before it can be used.

If you’d like to implement digital IFCs for your facility, please reach out to our wonderful Support team, who will assist with setup and configuration at support@alturahealth.com.au

Once enabled, the feature will be available directly from the standard IFC screen — no new workflows or screens to learn.

---

Information can be synchronised from CGOV to FYDO using an API. This feature is helpful for hospitals that utilise CGOV for doctor credentialling, as it can reduce the need for double data entry. The following fields are able to be imported:

You can now send invoices directly from FYDO using your Microsoft 365 email account. This feature uses a secure integration via a Microsoft Enterprise Application called FYDO_EmailSender.

For this functionality to work, your Microsoft 365 tenant must allow the required permissions, which may need assistance from your IT department. To find out how to set up your email, see our Setting up to Email from FYDO user guide.

Once successfully set up, you can email an Invoice Copy from the Episodes screen.

1. Under the Invoice Options Drop down in the Episodes screen, select ‘Invoice Copy’

2. Select the Invoice options as usual and click on the ‘Email Invoice’ button

3. Select who you’d like to email, whether it be the Patient or Fund, modify the Email Subject and Body of the email if necessary and click on the ‘Send Email’ button

4. If the email is successful, you should see a message at the top of the FYDO screen like below

⚠️ Important: The email will appear to the recipient as being sent from the shared mailbox (e.g. reception@hospital.org.au), but will still be sent using your personal Microsoft 365 account. The message will be saved in your Sent Items, not the shared mailbox’s.

You can now send invoices directly from FYDO using your Microsoft 365 email account. This feature uses a secure integration via a Microsoft Enterprise Application called FYDO_EmailSender.

For this functionality to work, your Microsoft 365 tenant must allow the required permissions, which may need assistance from your IT department.

Email Verification Step – Before being able to email an invoice from FYDO, you firstly need to verify your email account (either your user account or a shared email account, such as a department email address).

To verify your email, follow these steps:

1. Go to your user account initials in the bottom left corner and select ‘Edit Profile’

2. Select the tab Email Verification and if you want to email from a Shared email account, enter the email address, otherwise leave blank to send from your account you used to log into FYDO.
3. Click on the Microsoft button, which will prompt you with the following screen.
4. Click on the Accept button and if your Microsoft already has the appropriate permissions set, you should get a “Email has been successfully verified” message at the top of FYDO, as shown below.

Note: If you do not see the success message, your Microsoft 365 tenant may not have granted the required permissions. Please contact your IT department and advise them that the FYDO_EmailSender application needs to be granted the following permissions for your user account:

• offline_access
• Mail.Send
• User.Read

You may also not have the appropriate permissions to email from a Shared email account.

IT Support Teams can contact Altura Health Support for assistance if required.

To find out how to email an invoice from FYDO, please see our additional instructional wiki pages below:

Emailing an Invoice from FYDO user guide.
Emailing Documents from FYDO user guide.

In order for patient’s Discharge Summaries to be uploaded into My Health Record (MHR) their Individual Healthcare Identifier (IHI) needs to be successfully verified.
These instructions will explain how this can be done in FYDO.

When creating a new patient, the MHR Consent tick box will be ticked by default. This ensures all episodes created for this patient will automatically have the MHR Consent box ticked at an episodic level.
It will need to be unticked if the patient withdraws consent for information to be uploaded to MHR, and in turn, any bookings created after the patients MHR Consent tick box is unticked will not have the tick selected in the episode.

FYDO will automatically verify the IHI Number when the patient is added to the database for the first time.

If manual verification is necessary, click “IHI Check” after adding the patient.

If you are aware of what the patient’s IHI Number is, and have typed it into FYDO, the check will verify that it is correct.

If you do not have the patient’s IHI Number, the check will retrieve their number and populate the field, provided that the patient can be identified.

The Status, Record Status and Last Verified information will be displayed.

A message will display if the patient cannot be identified.

IHI verifications work according to the same data matching principals’ as the Medicare OPV. To address an unsuccessful verification, users can check certain patient identifiers i.e. the spelling of the first and last name, accuracy of their Date of Birth and Medicare card.

MHR Consent

MHR Consent is available in FYDO on both the Patient Level and the Episodic Level to allow patients the flexibility to withdraw MHR consent for specific episodes.

For facilities that utilise Preadmit, MHR Consent can be obtained when the patient submits their admission form, and the information can be transferred into FYDO. The answer that the patient gives will be reflected on the Patient Screen. If you are interested in setting this up, please reach out to our Preadmit team.

Consent on a Patient Level:

• For patients created in FYDO, MHR Consent is ticked on the Patient Screen by default when a patient is created.

• If a patient withdraw consent completely, this box needs to be manually unticked.

• MHR Consent updates made in Preadmit will update the patient’s MHR Consent status in the Patient Screen. 

Consent on an Episodic Level:

• MHR Consent is defaulted at the point of booking based on the patient’s current consent status in the Patient Screen.

• If the patient has consented, new episodes will be automatically ticked as consented. 

• If the patient has not consented, new episodes will remain unticked.

• After booking, the Edit Appointment Screen consent operates independently from the Patient Screen. This allows consent to be added or removed for an individual admission. 

• If the MHR Consent is not ticked in the Edit Appointment Screen, FYDO recognises that the patient has not consented, and the facility will be unable to upload the discharge summary to MHR.  

For more helpful information related to My Health Record visit our associated wiki pages to:

Add your organisations HPI-O to FYDO here.
Add your doctors HPI-I to FYDO here.
Upload a discharge summary in FYDO here.

In order to upload Discharge Summaries to My Health Record Clinical Staff (Doctors/Surgeons) will need to supply the facility with their Healthcare Provider Identifier – Individual (HPI-I). Doctors can find out what they HPI-I is by calling Healthcare Identifiers on 1300 361 457 or they can get it from AHPRA.
This number needs to be entered into FYDO by following the instructions below.

Navigate to Settings
Select Doctors

Double click on the required Doctor & select Edit

Type in the Doctors HPI-I, under the section Health Identifier, and click Save

FYDO will automatically run an internal check, to ensure the HPI-I follows the required format, when you click save. If the number doesn’t meet the requirements, you will be given an alert.

You will then need to either correct the HPI-I or remove it to be able to save the rest of the information.

If the number was able to be saved, you can utilise the HPI-I Check button to verify the number. A successful verification will be identified with a GREEN boarder, and the Status and Last Verified date and time also be displayed.

For more helpful information related to My Health Record visit our associated wiki pages to:

Add your organisations HPI-O to FYDO here.
Check a patients IHI in FYDO here.
Upload a discharge summary in FYDO here.

In order to upload Discharge Summaries to My Health Record organisations will need to have completed the registration process & received a Healthcare Provider Identifier – Organisation (HPI-O). 
This number needs to be entered into FYDO by following the instructions below.

Navigate to Settings
Select Locations

Double click on the required Location & Click Edit

Enter in the organisations HPI-O and click Save

You will then be able to click HPI-O Check and see the Status and Last Verified date and time.

A successful verification will be indicated with a GREEN boarder around the number as per above.

For more helpful information related to My Health Record visit our associated wiki pages to:

Add your doctors HPI-I to FYDO here.
Check a patients IHI in FYDO here.
Upload a discharge summary in FYDO here.