Those that have spent any time in the ambulatory EMR area are likely aware of NextGen. The vendor owns two EMRs – it’s flagship “NextGen” product and NextGen Clinic a cloud-hosted product for smaller organizations. The former – which will simply be referred to as NextGen – product is often used in larger specialty practices, multispecialty practices, or FQHCs. The latter is often commonly seen due to the product’s tight integration with a dental module; thereby allowing for an FQHC to have a full-spectrum EMR rather than having to patch together multiple products. The former, NextGen clinic, is seen in a variety of specialty and primary care practices; however, the focus is on organizations with fewer total providers.
NextGen’s power lies in its customizability. While many EMRs allow users to create templates, in reality, such templates are really just a series of structured fields that can be used to more quickly chart a specific type of visit (e.g., UTI, Strep, etc…). NextGen, on the other hand, allows for very high-levels of customization including the creation of what they term as templates but, in actuality, are entire charting workflows. For example, if a practice onboards integrated behavioral health, and it is targeting patients that are having behavioral roadblocks to managing diabetes, a template specialist. – either a superuser in the practice or a contracted third-party – can create a highly specialized document that targets the desired data capture requirements. This can be a double-edged sword as these templates need to be tested with each upgrade to ensure continued functionality. NextGen clinic, however, lacks this feature and instead allows customizability consistent with other EMRs.
Integrating with each EMR is a fairly straightforward process. NextGen has an API, however, it has not been available that long, so it is difficult to know if it is straightforward to use; the company, however, appears to be dedicated to making it’s API as open as possible to encourage development. NextGen clinic lacks an API at this point, but it is likely to follow the same model in the near future. This leaves the traditional interface model along with template customization as the means to integrate with NextGen; for NextGen clinic, traditional interfaces are the primary option.
With template development, in addition to creating workflows, triggers can be created that initiate other processes. For example, if one needs to call a web browser with an encrypted string – for example as part of a single sign-on project – that can be done entirely on the template side. This makes it fairly easy to integrate third-party web applications that user standard single sign-on tools with NextGen (an example of this would be a registry that stores gaps in care data). Traditional interfaces would involve working with inside sales for either EMR product to obtain the costs and licensing for the interfaces – be it HL7 2.x or a CCD – and then work with their implementation teams to install the necessary components. One could also combine the two with NextGen – i.e., use templates for some functionality, and then send the needed data via a traditional interface.
More options will likely become available as NextGen’s API is used more (and one is released for NextGen clinic). That said, there are currently options available to create highly customized user experiences that also include enhanced integrations using traditional interfaces and templates. The latter – almost entirely unique to NextGen – offer a compelling option for many third parties as they essentially create a development environment within the EMR itself that allows technically savvy users to not only create unique workflows to enhance productivity but to also perform certain integration tasks including creating processes in place to capture data necessary for powerful and effective data integrations.