Portal Differences If Not Using OP's Practice Management System
For Office Practicum customers that use an external interface for their patient records, some features of the portal are unavailable. For example, if patient registrations are handled by the external interface then patient registrations on the portal would not be authoritative, and could cause discrepancies between OP's records and the interface's records. For this reason, we purposely disable some portal features if the portal detects use of an interface.
Changes for Users of an Interface
- Patient registration on the website is disabled. You will need to continue registering your patients in the office, or via your other practice management software.
- A different version of the Update Contact Information application is shown, with most fields displayed read-only. The preferred contact methods are still enabled because it is unrelated to a patient's medical record or demographic information, and is collected by Office Practicum only.
Q. I run a different piece of software that handles my practice management, billing, etc., outside of Office Practicum. Are there any limitations of the patient portal that I should know about?
A. Yes. There are certain features of the Office Practicum Patient Portal that would not function correctly when you connect with another program via an HL7 interface. Listed below are various features that are either disabled or limited. Please note that as of versions 1.1.5, 1.2.2, and 1.3.0, the Patient Portal will automatically detect the presence of an HL7 interface and disable these features.
Registration of New Families or Patients. Using the Register Family application on the web is not allowed. You should continue using your normal workflow for registering families or patients.
- Updating Demographics Information. Portal users will not be able to change a Patient or Contact's name, email address, address, phone number(s), etc. In order to do this, continue using your current office-oriented workflow. In addition, you will need to maintain information for Contacts manually using your other practice management software.
- Online Payments through Instamed. Parents will not be able to pay bills through the portal. This feature is only available for practices that bill through OP and use Instamed as a clearinghouse.
- Online Appointment Confirmations.
- Flu Clinic Scheduling (or any other future scheduling functionality).
Q. Why am I not able to use these features on my patient portal?
A. The simple answer is that we currently don't support them. The more complicated answer is this: Because both the Patient Portal and practice management programs from other software vendors require exclusive access to the databases (meaning, BOTH programs cannot have editing privileges to the database; one has to be in charge), it would be impossible for both to correctly write data to the same data tables.
Q. But didn't Office Practicum already write an interface program for [[Your other software]] to receive data from it? Why can't you also send the demographic data back to [[Your other software]], since you can send our billing data over?
A. We've had a bit of misunderstanding from our interface customers as to how the interface actually works. Currently, our HL7 interfaces are built to receive output of demographic data from some other specific software vendors. This means that Office Practicum can take IN this data from other programs. What Office Practicum can't do is send it OUT to them.
This operation isn't a limitation of Office Practicum. We have done this purposely to preserve the integrity of data stored within your Office Practicum database. One of programs in question – Office Practicum, or your other software – needs to be exclusively in charge of the data. This means that ONE of them edits and updates data ONLY. The other program simply reads from this database, and displays what it sees. Having more than one program in charge of the data results in a scenario where the two programs are “stepping on each others' toes”; more technically, because they are both authoritative, they are both writing data over top of one another, instead of synching, therefore creating inconsistencies in the data.
To avoid this data corruption, due to the established workflow of many of our clients, we have chosen to put those programs in charge of the patient and contact databases, and in turn, give Office Practicum read-only access to it.
The reason for this has to do with the way each product was intended to be used by its customers. For example, our new-and-improved Patient Portal was built with the intention that a pediatric practice's customers would be able to self-maintain their own demographic information. We put the process of updating e-mail addresses and phone numbers in the hands of the people who know them best – their owners. Other software vendors may have engineered their programs to require updates to demographic information by someone inside the office, instead. By using the patient portal with one of these programs, you are putting two different programs in charge of the same tables of data.
Consider this example: If we did not disallow access to demographic updates on the portal, there would be many database conflicts. If one of your users creates a portal account underneath a particular email address (“firstname.lastname@example.org”) and links it to contact in Office Practicum. The next day, one of your office staff members changes that email address to something else (“email@example.com”) using PCC. What you now have is an inconsistency of data between OP and the Portal, resulting in a portal account that constantly throws errors whenever that user attempts to do anything, because they are no longer linked up by the correct email address.
In earlier versions of our new patient portal, we came across many support cases in interface clients where this conflict of data actually happened. We made a conscious decision to remove any instance of conflict between the Patient Portal and other software vendors' programs because:
- We foresaw too many possible instances of corruption with a two-program setup.
- The integrity of our customers data is too valuable to allow the possibility of corruption via this type of configuration.
- We simply don't have the resources to solve every support case that would come through as a result of misuse.
As of right now, our official stance on this issue is that we do not support the listed features above for customers running an HL7 interface. The only way around this is to upgrade to a fully OP-managed workflow.
Q. For customers who are PCC clients and have demographic information transferred from the PCC system to OP, how does the transfer of data between programs work?
The interface works because each program ( PCC and OP ) is in charge of a specific portion of data. PCC and OP never conflict with each other in the data they maintain. The typical interface set up is:
- Demographics: PCC to OP
- Scheduling: PCC to OP
- Charges: OP to PCC