PracticeSuite Release Note For Interfaces

Product Release Version: 23.0.0

Product Release Date: February 2024

Disclaimer: All rights are reserved. No part of this work may be reproduced in any form or by any means through graphic, electronic, or mechanical, including photocopy, recording, or information storage and retrieval systems – without written permission of the publisher.

The products that are referred to in this document may be either trademarks and/or registered trademarks of the respective owners. The publisher and the author make no claim to these trademarks.

While every precaution has been taken in the preparation of this document, the publisher and the author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained in this document or from the use of programs and source code that may accompany it. In no event shall the publisher and the author be liable for any loss of profit, or any other commercial damage caused or alleged to have been caused directly or indirectly by this document.

Printed February 2024 at PracticeSuite, Inc., 3206 Cove Bend Dr. Suite A, Tampa, FL 33613

Part – 1 Enhancements

1.1 Inbound Patient Insurance Update

Moving forward, to preserve the integrity of the patient’s insurance data, when an update to the patient’s insurance (where claims have already been submitted for that insurance) is received over the API from Elation, instead of overwriting the existing insurance a new insurance entry is added for the patient. Previously, the existing patient insurance used to get overwritten regardless of the claim submission status.

The following are the changes made to PracticeSuite based on different scenarios of patient insurance updates received through the interface:

Scenario 1: If there is a change in the insurance company ID in the demographics message received.

Impact: PracticeSuite will keep the current insurance entry unchanged. It will instead create another patient insurance entry with the updated details.

Scenario 2: If there is a change in the subscriber # of the patient but the insurance remains the same,

Impact: Again, PracticeSuite will keep the current insurance entry unchanged. It will create another entry in the patient insurance for the same insurance with the new subscriber #.

Scenario 3: If there is a change in insurance level.

Impact: PracticeSuite will keep the current entry untouched. It will rather create a new entry for the insurance with the new level sent over the API.

1.2 Elation

1.2.1 Bidirectional Sync for Guarantor Information

A new API has been introduced for the guarantor info exchange between Elation and PracticeSuite. From now on, guarantor information will be synced bidirectionally between PracticeSuite and Elation. The following are the key points regarding this sync:

Multiple guarantors can exist in the PracticeSuite system, whereas Elation has only the provision for one guarantor per patient. Therefore always only a single guarantor info is exchanged at a time between the systems.
A guarantor can be added to either system. When a guarantor is added in Elation, a unique guarantor ID is triggered and sent through the interface and this ID gets stored in PracticeSuite. If a guarantor is added in PracticeSuite, this info is sent to Elation, and from there the unique ID for the new guarantor is returned to PracticeSuite.
Guarantors when added or updated in either system, the info is sent in the demographics message to the other system.
As the guarantor info resides on a separate screen in PracticeSuite, after the guarantor info is added/updated, the user will need to hit the save on the patient demographics to have it synced with Elation.
Since there can be multiple guarantors in PracticeSuite, only the latest primary guarantor gets sent to Elation. The secondary guarantor is only sent in the absence of a primary.
Elation has the following guarantor types: SPOUSE, CHILD, and OTHER; PracticeSuite permits all of these types and also has additional types that can be used. Guarantor types other than the three in Elation will be mapped to ‘OTHER’ in Elation and for any sync that happens thereafter, the guarantor type gets updated as ‘Other’ in PracticeSuite.
Please also note that Elation does not send a notification to PracticeSuite when a guarantor is removed. Due to this reason, when a guarantor is deleted in Elation, the same guarantor entry will remain unaffected in PracticeSuite. However, the info will sync when it is the other way around, that is when the guarantor is rendered inactive in PracticeSuite, it is removed from Elation.

1.2.2 Bidirectional Mapping of Patient Status through API

Bidirectional patient status mapping between PracticeSuite and Elation has been enabled. The table below lists the patient statuses in Elation and the corresponding statuses in PracticeSuite.

Patient status In Elation	Patient status In PracticeSuite
Active	Active
Inactive	Inactive
Deceased	The patient is considered deceased if the deceased date is provided on the ‘Other Attributes’ page
Prospect	There is no related status in PracticeSuite; the patient will be made inactive.

The following are the impacts of the status update in both systems:

Active: When a patient is made active in Elation, the same is made active in PracticeSuite, and vice versa.
Inactive: When a patient is made inactive in Elation, the same patient is made inactive in PracticeSuite, and vice versa.
Deceased: When a patient is marked as deceased in Elation with the deceased date, the deceased date will be saved in PracticeSuite. However, when a patient is marked as deceased in Elation without a deceased date, the patient’s record will remain unaffected in PracticeSuite, as the date of death is a mandatory field to flag the patient as deceased.
Prospect: When the patient status is changed to Prospect in Elation, it changes the patient status in PracticeSuite to inactive. Thereafter, saving the patient record keeping the inactive status will replace the status in Elation and change it to inactive.
Reason & Notes: Elation has the option to enter Reason and Notes when changing the status, however, this field does not exist in PracticeSuite and is disregarded when the message is received. Alternatively, when the status is updated in PracticeSuite, any existing text in the Reason and Note fields in Elation will be erased.

Note: Once the changes are deployed, PracticeSuite will not send the “INACTIVE” or “DECEASED” status as patient tags to Elation.

1.2.3 Supervising Provider Mapping for Inbound Charges

Supervising provider info if present in the charge message sent from Elation will hereafter map to the corresponding field in PracticeSuite.

Note: The supervising provider will be present in the inbound charge message only if Elation has enabled the supervising provider field in the system.

1.3 Quest Lab- Multiple Account Mapping

If the primary Quest Lab account has several secondary accounts linked to it, PracticeSuite can accommodate these as distinct lab accounts. Each legal entity can be mapped to a lab account and orders can be placed for the selected LE.