Topic

Level

Presenter(s):Dave Venier

Rosetta Interfaces (Advanced)

300

Safe Harbor Provisions/Legal Disclaimer

This presentation may contain forward-looking statements within the meaning of the federal securities laws, including statementsconcerning future prospects, events, developments, the Company’s future performance, management’s expectations, intentions, estimates, beliefs, projections and plans, business outlook and product availability. These forward-looking statements do not represent a commitment, promise or legal obligation to deliver any material, code or functionality. The development, release and timing of any features or functionality described for our products remains at our sole discretion. Future products developed beyond what is contemplated by existing maintenance agreements, will be priced separately. This roadmap does not constitute an offer to sell any product or technology. We believe that these forward-looking statements are reasonable and are based on reasonable assumptions and forecasts, however, undue reliance should not be placed on such statements that speak only as of the date hereof. Moreover, these forward-looking statements are subject to a number of risks and uncertainties, some of which are outlined below. As a result, actual results may vary materially from those anticipated by the forward-looking statements. Among the important factors that could cause actual results to differ materially from those indicated by such forward-looking statements are: the volume and timing of systems sales and installations; the possibility that products will not achieve or sustain market acceptance; the impact of incentive payments under The American Recovery and Reinvestment Act on sales and the ability of the Company to meet continued certification requirements; the development by competitors of new or superior technologies; the timing, cost and success or failure of new product and service introductions, development and productupgrade releases; undetected errors or bugs in software; changing economic, political or regulatory influences in the health-care industry or applicable to our business; changes in product-pricing policies; availability of third-party products and components; competitive pressures including product offerings, pricing and promotional activities; the Company's ability or inability to attract and retain qualified personnel; uncertainties concerning threatened, pending and new litigation against the Company; general economic conditions; and the risk factors detailed from time to time in the Company’s periodic reports and registration statements filed with the Securities and Exchange Commission.

Agenda

• Immunization Query and Response• Exporting All Orders on One Agent• Image Capture Redesign• Transport Decoupled from Agents• New “Mirth” Transport Type• Integrating Mirth Match with the Rosetta Holding Tank• What’s in the Pipeline?

Immunization Query and Response5.8 UD3

Immunization Query and Response

Currently immunizations can only be exported from NextGen EHR

Immunization Query and Response is supported in 5.8 UD3

The existing agents support the functionality but needs configuration.

This has been tested with the Florida and New York City registries.

• We are willing to test with others if information is provided.

• This is only supported with HL7 2.5.1 and is based on the Implementation Guide for Immunization Messaging, Release 1.5

Immunization Query and Response

Can be done manually or prior to appointment arrival

Items are imported using the Clinical Reconciliation Module

Four different responses to queries exist:

• One Patient Found

• Multiple Patients Found

• Too Many Patients Found

• No Patients Found

Each of these responses is dependent on the logic the registry uses to find patients.

Manual Query Via EHR

The order module has a registry field to select which registry the query will be done against and a “Reconcile…” button which initiates the query.

When clicked the query message is automatically sent.

If one patient is found the immunizations will be presented to the user to import.

If more than one, too many or no patients are found, the user will see an error that more interaction will be needed with the registry.

• The user can modify patient information to query for the patient on the registry.

Automated Query Via BBP

Allows an automatic query for immunization a few days before the patient arrives for their appointment.

This reduces manual processing for querying for immunizations before appointments

Requires appointments created in PM or EAS and the BBP

This is configurable based on the registry and practices.

For example, one practice may want to query 1 day before the appointment but another wants to query 3 days before, etc.

The configuration for this is done in the HIE Gateway Administration page but is run from the BBP

Automated Query Setup in HIE Gateway

Automated Query Via BBP

There is a maximum of 3 queries performed before an appointment is arrived.

Example: The mode is set to query the day before and three days before. An appointment is created today (11/3/2015) for the date 11/30/2015. With this setup, immunizations are attempted to be imported for the following times:

• 1st time set by ‘3’: 11/27/2015, 3 days before the appointment date

• 2nd time set by ‘1’: 11/29/2014, 1 day before the appointment date

We can also create a chart if one does not exist (agent option).

Sample Query Message

MSH|^~\&|NextGen Rosetta|12345^0001|Billing System|BillingSystem|20150709172420242||QBP^Q11|967673029|P|2.5.1|||||||||Z34^CDCPHINVS

QPD|Z34^Request Immunization History^HL70471|QRY967673029|118^^^^MR|Venier^David^XXX||20010201|M|1234 MAInd3333^^PHILADELPHIA^PA^19118|^PRN^PH^^^215^5555555

RCP|I|50|R

Sample Response MessageMSH|^~\&|System|System|NextGen||20150917091812.782-0400||RSP^K11^RSP_K11|272808037|P|2.5.1|||||||||Z34^Request Immunization History^CDCPHINVSMSA|AA|272808037QAK|272808037|OK|Z34^Request Immunization History^HL70471QPD|Z34^Request Immunization History^HL70471|QRY272808037|2174|UGM^Immunization||20120101|F|1234 Main^^Horsham^PA^19044|^PRN^PH^^^641^5551002PID|1||^^^FLSHOTS^SR||UGM^Immunzation^A||20120101|F||2054-5^BLACK/AFRICAN AMERICAN^HL70005|3453 AHEPB AD^^TALLAHASSEE^FL^32356^^H||^PRN^^^^641^5551003NK1|1|UGM^MOM|MTH^Mother^HL70063ORC|RE||6900000625.58.20120502^FLSHOTSRXA|0|1|20120502||120^PENTACEL^CVX|999|||00^New Immunization^NIP001||||||C4485AA||PMC^sanofi pasteur^MVXRXR|IM^INTRAMUSCULAR^HL70162|RA^RIGHT ARM^HL70163OBX|1|CE|59780-7^Series Name^99FLS|1|DTAP^DIPHTHERIA, TETANUS, AND PERTUSSIS ||||||FOBX|2|NM|30973-2^Dose number in series^LN|1|1||||||FOBX|3|ID|59781-5^Dose validity^LN|1|Y||||||FOBX|4|CE|59780-7^Series Name^99FLS|2|HIB^H INFLUENZA TYPE B||||||FOBX|5|NM|30973-2^Dose number in series^LN|2|1||||||FOBX|6|ID|59781-5^Dose validity^LN|2|Y||||||FOBX|7|CE|59780-7^Series Name^99FLS|3|POLIO^POLIO||||||FOBX|8|NM|30973-2^Dose number in series^LN|3|1||||||FOBX|9|ID|59781-5^Dose validity^LN|3|Y||||||FORC|RE||6900000625.55.20141125^FLSHOTSRXA|0|1|20141125||62^HPV4^CVX|999|||00^New Immunization^NIP001||||||J001234||MSD^Merck and Co., Inc.^MVXRXR|IM^INTRAMUSCULAR^HL70162|RA^RIGHT ARM^HL70163OBX|1|CE|59780-7^Series Name^99FLS|1|HPV^HPV||||||FOBX|2|NM|30973-2^Dose number in series^LN|1|||||||FOBX|3|ID|59781-5^Dose validity^LN|1|N||||||FOBX|4|ST|30982-3^Invalid Dose Reason^99FLS|1|MIN AGE FOR HPV4 IN THE HPV SERIES IS 3288 DAYS. THE CLIENT'S AGE IS 1059 DAYS.||||||F

DEMONSTRATION!Manual query from the EHR

Exporting All Orders on One Agent5.8 UD3

Exporting All Orders on One Agent

Currently each lab system requires its own agent

For clients managing all connections to their lab systems they can use interface engines to split their feeds.

A new “Systems To Send” option is available to chose which systems the agent is sending orders for.

Added to standard “Lab Export” agents.

• Not available on Quest or LabCorp agents.

• No customizations from those agents are available when used.

Supported in 5.8 UD3 and KBM 8.3.11

Exporting All Orders on One Agent

The external system name which is seen above (from external_systemtable) is sent in the MSH segment, field 5 (MSH-5) for the interface engine to consume and process.

Image Capture Redesign5.8 UD3

Image Capture Redesign

Current Image Capture requires Videum 1000 VO Plus PCI Card and 32 bit operating systems

We have re designed and rewritten the interface from the ground up with improved functionality and workflow

We no longer require a specific image card. Any card or device which windows recognizes as a video device will be detected and available.

We have tested this with the following video cards:

• Hauppauge USB-Live 2 (our recommended card)

• StarTech.com SVID2USB2NS

Supported in 5.8 UD3 (coming soon to 5.8 UD2)

Image Capture Redesign

Allows capturing multiple images at once and assigning all to a specific category.

All images can be saved at one time or individually.

Individual images can be moved to specific categories.

Users can zoom in and out of the images as necessary.

Before capturing a user can flip images vertically, horizontally and mirrored.

Captures can be done via a button click, F5 key press or external device trigger.

Image Capture Redesign

Transport Decoupled from Agents5.8 UD3

Transport Decoupled from Agents

The current agents are each specific to each transport type.

For example, there are currently 4 immunization export agents due to the support of TCP/IP, File, Web Service and HTTP exports

This creates maintenance problems as new options or fixes could have been added to one agent but not added to others

In 5.8 UD3 we have redesigned the agents and transport to be decoupled from each other and have a better definition of the agents and their options.

Multiple agents have been combined to a single agent (e.g. “Lab File Export” & “Lab TCP/IP Export” are now consolidated to simply be “Lab Export”)

The number of agent selections have reduced from 193 to 85

Transport Decoupled from Agents

A new collapsible panel is added to group all transport related options

The Transport Type of an agent can be changed and the agent renamed if needed.

• Previously this required an agent to be deleted and recreated.

Allows us to add new transports easily if required.

As part of this we also added a “Mirth Connect” transport.

New “Mirth Connect” Transport Type5.8 UD3

Mirth Connect Transport

As part of ongoing integration with Mirth Connect (Connect) we have added a “Mirth Connect” transport type.

This transport type will mainly be used internally between Rosetta and Connect for new NextGen Share services but may also be used by clients if the need arises.

Uses the HTTP Listener on Connect and Rosetta sends a JSON message with the HL7 (or other message) along with additional information.

This allows the passing of additional fields like usernames and passwords for immunizations but also additional fields from the IREM which may not be present in the HL7 message.

Mirth Connect Transport

Connect can use this information to extract the message as well as the additional information and split the messages to many systems and manipulate as needed.

Additional info from the IREM or username/password information is configured using the “Additional JSON Parameters” option.

Username and password information is configured from the “Facility / Username / Password Configuration”

This is all advanced setup and requires in depth knowledge of Rosetta, Connect and JSON in order to be implemented successfully.

JSON Example

{"ngTransportPackageVersion": "1.0","ngRosettaVersion": "5.8.0.53","ngApplicationVersion": "5.8.3.21","messageStructure": "HL7v2","messageContent": “BASE64 MESSAGE CONTENT HERE“

}

{"ngTransportPackageVersion": "1.0","ngRosettaVersion": "5.8.0.53","ngApplicationVersion": "5.8.3.21","messageStructure": "HL7v2","messageContent": “BASE64 MESSAGE CONTENT HERE","orderComment": “Order Comment Here“

}

Facility / Username / Password Configuration5.8 UD3

Facility / Username / Password Configuration

Immunization Registries may a username and password per facility.

Currently this needs a new agent for each username/password.

We’ve added a “Facility / Username / Password Configuration” option which allows one agent to be used for the registry.

When sending the message we look at the value in the facility id field to determine which user name and password to use.

This is only used when sending to a system via HTTP or Web Services.

Facility / Username / Password Configuration

The first option used is the “Facility Id Field”. This dictates where to pull the unique identified information from in the message – for example “MSH\SendingFacility\ID” is MSH-4.2.

The value retrieved from that field then find the corresponding username and password.

The bottom section contains the “Message Value” which is the value from MSH-4.2 and puts the proper “Username” and “Password” in the message.

The default username and password will be under the "ALL OTHER-“ item.

This option can also be used with the Mirth Connect transport type.

Integrating Mirth Match with the Rosetta Holding Tank5.8 UD3

Mirth Match & the Rosetta Holding Tank

Currently any demographic matching issues are sent to the Rosetta Holding Tank (RHT) where the patient must be manually matched.

Rosetta agents use exact matching when looking for patients.

• For example: “Dave” is not the same as “David”

If using advanced matching algorithms, the patients may be matched.

Additionally, all demographic searches in the RHT are manually entered by users which adds time for matching items.

With the combination of Mirth Match and Rosetta, advanced patient matching can be performed to alleviate user matching.

Mirth Match & the Rosetta Holding Tank

A new NextGen Share RHT MPI Service has been created to help with this process.

• Also uses the RLS Services

All demographic records are exported to the RLS service to create your Master Patient Index

When a message is received with patient matching issues, Rosetta automatically queries the RLS Service for the patient.

Any matching patients are stored with the record and made available in the RHT.

Supported in 5.8 UD3

Mirth Match & the Rosetta Holding Tank

Users will see the list of available matches when viewing the items in the RHT.

The user can select the proper patient after comparing the demographics

If no patient match exists in the list, the user can click the “No Matches” button to create a new patient.

• The demographic information will automatically populate in the search window.

This logic is available in the clinical interfaces: Lab Result Import, Documents Import, Direct CCDA Import, etc.

DEMONSTRATION!Mirth Match Query Process

What’s in the Pipeline?

What’s Coming in 5.8 UD3* and Beyond

EHR Inbox – RHT Status InformationAutomatically Import Discrete Data from CCDAFHIR InterfacesIDCO Support (KBM 8.3.11)MU3 Items:

• CCDA R2.1• Implantable Device Support• LRI, LOI and Compendium Updates• Immunization Forecasting

Many More Items!

Discontinuing the Surescripts HISP Interface

• With the advent of NextGen Share, we have decided not to renew our Surescripts HISP connectivity

• This only applies to customers who purchased a Direct interface to the Surescripts HISP

• On July 1, 2016, the Surescripts HISP interface will no longer be available

• Migrate now to NextGen Share to avoid the disruption of your Direct interface

The Surescripts HISP Interface will be discontinued on

July 1, 2016.

Migrate NOW to NextGen Share for Direct connectivity

Do We Still Have Time?(New Features - Small Items)

New Features

Consent based PIX integration (pushed into UD2)

New Mindray Vitals Sign Interface (available in UD1)

HL7 v 3 ADT Import (UD3)

LRI Interface Support More Document Types (UD3)

Support for Agent Level E-Mail Filtering (available in UD2)

Immunization Export Consent, Publicity and Status application fields (UD3)

ZAD Export now uses ZSEGMAP.xml (UD3)

Add the Provider Id to the Queue tab in the RMC (UD3)

Session SurveyPlease take a moment to complete a brief survey regarding this session.

1. Open your ONE UGM Mobile App (please note: you must have already logged

in and accepted the “Terms of Use” to access this feature)

2. Click the Navigation Button at the top left of the screen

3. Select “Sessions”

4. Search for and select this session

5. From the sessions details screen, select “Survey” at the bottom right of the

screen

6. Remember to hit “Save” at the bottom of the survey once you have answered

the questions

Any Questions?