We are currently updating the OP Help Center content for the release of OP 14.19 or OP 19. OP 19 is a member of the certified OP 14 family of products (official version is 14.19.1), which you may see in your software (such as in Help > About) and in the Help Center tabs labeled 14.19. You may also notice that the version number in content and videos may not match the version of your software, and some procedural content may not match the workflow in your software. We appreciate your patience and understanding as we make these enhancements.

Portal Differences If Not Using OP's Practice Management System

Version 14.19

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.  

FAQ 

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 (“jack@yahoo.com”)  and links it to contact in Office Practicum.  The next day, one of your  office staff members changes that email address to something else (“jill@yahoo.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
Version 14.10

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.  

FAQ 

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 (“jack@yahoo.com”)  and links it to contact in Office Practicum.  The next day, one of your  office staff members changes that email address to something else (“jill@yahoo.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