Category: Questions and Answers

Understanding the Redox Provider Data Model

When do I need to use the Provider data model?

The Redox Provider data model should be used if your application is looking to maintain a synced provider database with an EHR. Health systems that support this model generate messages when provider records are created, updated or inactivated, allowing applications receiving them to update their own application’s provider database accordingly.

Which EHRs support the Provider data model?

Right now this model would leverage either a vendor API or an MFN HL7v2 feed on the EHR side. MFN interfaces aren’t incredibly common, but the setup is site specific and not based on the EHR vendor, so it is always worth asking if this is something a specific health system has live.

What are the future plans for the Provider data model?

We do have a future project planned to build support for leveraging ADT or SIU HL7v2 interfaces to maintain a synced provider database, which would allow applications to use the Provider model at sites that don’t have available APIs or MFN interfaces. After pulling provider objects from the ADT or SIU messages, Redox would maintain them in our Data Chateau infrastructure and applications would call a queryable endpoint to receive up-to-date provider details.

Understanding the Redox Results Data Model

When do I need to use the Results data model?

The Redox Results data model is used to transmit discrete clinical data to or from an EHR. Typically this model is applicable in situations where a one-off value, many times the result of some kind of order that was placed for a patient, is being sent to the patient’s chart. This data will show up wherever lab results are in the EHR. Additionally, PDF result reports can be embedded in Results message, either discretely associated with an order or unsolicited. For more information on that check out our Sending Files through Redox post.

How is the Results data model different from the Flowsheets data model?

The main difference between these models is where the data will end up within an EHR destination. The Flowsheets model is more appropriate for workflows where the same type of discrete data is being measured and reported regularly. A number of EHRs support some kind of flowsheet activity where this data will show up and viewed together, which makes identifying trends easier. The Results model is usually better suited to situations where a one-off value, many times the result of some kind of order that was placed for a patient, is being sent to the patient’s chart. This data will show up wherever lab results are in the EHR.

Understanding the Redox Device Data Model

When do I need to use the Device data model?

The Redox Device data model is used to transmit discrete device data to an EHR. The device data model is useful for workflows where an EHR is distributing the device to the patient and so can already match the device ID to the patient record; the application sending the device data back to the chart only needs to include the device identifier.

How is the Redox Device data model different from the Flowsheets model?

The Redox Flowsheets and Device models are almost identical save for one key difference: the Device model requires a device identifier to match the results with the patient’s chart while the Flowsheets model (and almost every other Redox data model) requires a patient identifier.

 

 

Understanding the Redox Flowsheets Data Model

When do I need to use the Flowsheets data model?

The Redox Flowsheets data model is used to transmit discrete clinical data to or from an EHR, which can include: inpatient and outpatient assessment information, vitals, patient reported outcomes, device data, and other discrete clinical documentation.

How is the Flowsheets data model different from the Results data model?

The main difference between these models is where the data will end up within an EHR destination. The Flowsheets model is more appropriate for workflows where the same type of discrete data is being measured and reported regularly. A number of EHRs support some kind of flowsheet activity where this data will show up and viewed together, which makes identifying trends easier. The Results model is usually better suited to situations where a one-off value, many times the result of some kind of order that was placed for a patient, is being sent to the patient’s chart. This data will show up wherever lab results are in the EHR.

How is the Flowsheets data model different from the Device data model?

The Redox Flowsheets and Device models are almost identical save for one key difference: the Device model requires a device identifier to match the results with the patient’s chart while the Flowsheets model (and almost every other Redox data model) requires a patient identifier. The device data model is useful for workflows where an EHR is distributing the device to the patient and so can already match the device ID to the patient record; the application sending the device data back to the chart only needs to include the device identifier.

Understanding the Redox Financial Data Model

Does this mean Redox can integrate with Practice Management Systems as well as EHRs?

We can support integrations with practice management systems as well as other revenue cycle specific products. If we have not already integrated with a specific system that you’re interested in, we’re happy to speak with the vendor and identify their integration capabilities and how we could support a connection with them via Redox.

Can I use the Financial data model to post a charge without an encounter?

Most (if not all) EHRs and Practice Management systems will require that you have a specific encounter or visit that you’re posting the charge to. However, some EHRs do support a concept of “billing only encounters”. One common use case for billing only encounters is when a provider performs rounds at a nursing home that doesn’t have an EHR or PM system, so providers are instead forced to bill out of their primary EHR at their typical practice location. In these scenarios, the charges associated with the physician’s rounding are often entered into an EHR at a later date and applied a billing only encounter.

Can I post patient payments with the financial data model?

Yes, you can post patient payments with our financial data model! However, it’s important to consider how the payment will be received and applied to past balances when scoping out a potential workflow. EHRs will typically have minimal (if any) support for applying a payment to a specific portion of an outstanding balance. Instead, a healthcare organization will typically decide during their initial setup process how they’d like patient payments to apply to past balances. This could mean that all new payments are automatically applied to the oldest balance first (FIFO) regardless of whether or not that balance had any association with your application or they could use a more custom method where a percentage is applied to professional fees before any payments are applied to hospital fees. There are quite a few different methods that an organization could use when applying payments, so it’s important to discuss this with your partners if you’re looking to include patient payments in your workflow.

What information do we need to post a charge?

We list several items in our data model documentation as required, but it’s important to recognize that EHRs and Practice Management systems will often utilize their own unique terminology and could require additional data to successfully post charges and payments (we do update our documentation whenever we identify new requirements from EHRs). At a bare minimum, any workflows that will leverage our financial data model to post charges should be prepared to identify a patient ID and Charge Code. It’s important to note that EHRs do not necessarily use the same charge codes and you may need to import and maintain a list of charge codes on your end. In some scenarios, you may also be required to include a visit ID and provider ID associated with the charge. In cases where charges are not generated by a provider during an encounter (ex. Home care, or patient tracking scenarios), EHRs may support using a generic provider and a billing only encounter to allow you to post charges without a provider and visit ID.

Understanding the Redox ClinicalDecisions Data Model

When do I use the ClinicalDecisions data model?

If your application is looking to deliver real-time, immediate clinical decision support (CDS) to providers then the Redox ClinicalDecisions data model may be a good solution to leverage. There are a myriad of potential use cases that could use the ClinicalDecisions model, such as recommending alternative medications and procedures or identifying drug-drug interactions at the point of ordering.

What triggers the initial ClinicalDecisions Request message?

This will vary depending on the use case and will be configured within the EHR alert setup – e.g. an alternative medications alert would be configured to fire when a provider attempts to sign an order, or an alert regarding a possible chronic condition might fire based on a patient’s vitals history when a new set is documented.

Will the alert always display to the provider?

It doesn’t have to! The application responding to the request from the EHR can set Advisories[].ShowAlert to False.

What actually appears to the provider if Advisories[].ShowAlert is set to True?

The application responding to the request from the EHR can specify the alert text by setting Advisories[].Description field.

What if more information is needed?

The responding application can include an external link for the provider to access and provide the necessary data. This link can be sent in the field Advisories[].AdditionalInfo.Link.

What are those question and answer fields?

The question and answer fields correspond to any custom Ask at Order Entry (AOE) questions the provider may have filled out when placing an order. This applies to CDS workflows triggered by the placing of medication or procedure orders, where the healthcare organization can configure AOE questions to appear for certain orders to ensure the application responding to the CDS request has all of the data it needs.

What EHRs support the ClinicalDecisions model?

The connecting EHR in a ClinicalDecisions flow needs to have a corresponding CDS API that can map to the Redox ClinicalDecisions model. The ClinicalDecisions model was built based on the FHIR specification, which has the potential to be supported agnostically across different EHR vendors although currently we have only seen Epic EHRs have such a web service available.

We’re happy to talk through the above in more detail as we scope your integration project!

Understanding the Redox PatientSearch Data Model

When do I need to use the PatientSearch data model?

The PatientSearch data model is a model applications can leverage when they have key patient inputs, such as demographic data or the patient’s Medical Record Number (MRN), and are looking to confirm and receive all of the patient’s identifiers and full demographic profile.

What is supported via Data Chateau?

For PatientSearch queries via Data Chateau where Redox is responding to the application’s query based on ADT HL7v2 or similar data that’s pushed from the healthcare organization, identifier-based searching is supported.

What is supported outside of Data Chateau?

If the connecting EHR supports a Patient Demographic Query (PDQ), a Cross Gateway Patient Discovery (XCPD), or an API that Redox can map the PatientSearch model to then demographic-based searching is supported and patient identifiers are not required.

If I’m querying with demographic data points as inputs, what is required to identify a patient at a given EHR?

Every EHR will have its own threshold of required demographic inputs in order to correctly identify a given patient. Some smaller systems may just need first name, last name and DOB. Other larger, enterprise systems will need additional data points like zip code, phone number, email, etc. If demographic-based searching is a required part of your workflow, it will be good to discuss this early with your healthcare organization partners to determine what they need in order to respond to the queries.

What if I have a patient’s SSN? Shouldn’t that be sufficient to identify a patient’s record?

Many health systems won’t accept a patient’s SSN as part of a PDQ or XCPD; this is something that will be variable by site that we can talk through with each HCO.

Is a patient’s insurance information always included in the response?

No. Patient insurance information will be returned for PatientSearch queries leveraging Data Chateau where Redox has previously received insurance information for a patient via an ADT HL7v2 or similar feed from the connecting healthcare organization.

Are potential matches always included in the response?

No, not always. Generally cloud-based EHRs that have a corresponding API, like Athena, will return potential matches. If we are mapping our PatientSearch model to a PDQ or an XCPD then potential matches will not be returned.

Keep in mind that we’re happy to talk through the above in more detail as we scope your integration project!

General Data Model FAQs

What is the difference between a visit/case number and an encounter number?

You may hear these two terms used during conversations with the health system. The importance of each really will depend on your workflow and your goals for tracking data. A visit/case number represents a single, specific appointment or surgical case. An encounter number can represent a single appointment but is more often used to bundle together a set of appointments related to a single event. In the case of a surgery, a patient’s pre-op evaluation, surgical case, and post-op visit could all have the same encounter number but different visit numbers. For some EHRs, the encounter number is preferred for them to be able to file information in a specific place in the patient charts.

Cool – the visit/case number sounds like what I need.  Will the appointment always have the same visit/case number if it’s been rescheduled?

This depends on the EHR workflow for handling appointment rescheduling. If the EHR uses a true reschedule workflow, the visit or case number is usually retained. If the EHR uses a cancel/new workflow where the old appointment is cancelled and then a new one is made, the visit number may change.

Understanding the Redox Media Data Model

When do I need to use the Media data model?

The Media data model is most often used to send media files, such as a PDFs, images, and audio files, to a patient’s chart.

What data is required in order to file media documents to the patient’s chart?

This will depend on how the users want to access the information within their EHR and the information needed by the EHR to file it as expected.  To file a document to the patient’s chart for general information purposes, most EHRs will require the patient identifier in addition to other basic patient demographics such as name and DOB. Additional required items include relevant provider information (i.e. who generated the document), the file type, the file name, a unique document ID, and whether or not the document has been authenticated and is authorized to be shared in the patient’s chart.  To file a document to a specific visit or to show up associated with specific areas or actions in the EHR, a visit number is often required to provide more specificity.

How do I send the files over the Redox Media data model?

Media files under 200KB can be sent directly to the API as base64 encoded strings over the Redox Media data model. Files over 200kb will first need to be uploaded to the Redox blob endpoint, which will synchronously return the file URI that can then be specified in a Media message. You can read more about that here.

 

Understanding the Redox SurgicalScheduling Data Model

When do I need to use the SurgicalScheduling data model?

The SurgicalScheduling data model is used to receive surgical case information, such as staff assigned to the surgery, case and procedure details, location, etc.  This may come from an OR specific system or from the same scheduling system as non-surgical appointments.  This data model is typically used for just the actual OR case that’s been scheduled – if you want to receive pre and post-op office appointments, see the Scheduling data model.

What is the difference between a visit/case number and an encounter number?

You may hear these two terms used during conversations with the health system. The importance of each really will depend on your workflow and your goals for tracking data. A visit/case number represents a single, specific appointment or surgical case. An encounter number can represent a single appointment but is more often used to bundle together a set of appointments related to a single event. In the case of a surgery, a patient’s pre-op evaluation, surgical case, and post-op visit could all have the same encounter number but different visit numbers. For some EHRs, the encounter number is preferred for them to be able to file information in a specific place in the patient charts.

Cool – case numbers sound like what I need.  Will the procedure always have the same case number if it’s been rescheduled?

This depends on the EHR workflow for handling appointment rescheduling. If the EHR uses a true reschedule workflow, the visit number is usually retained. If the EHR uses a cancel/new workflow where the old surgical appointment is cancelled and then a new one is made, the case number may change.

Will I always be able to receive a coded diagnosis for the surgery?

It depends on the EHR and the end user workflows at scheduling.  Some EHRs require that a coded diagnosis is used to schedule the procedure, while others may not.

Can I get insurance information through the Scheduling data model?

Insurance details are most reliably available through a PatientAdmin feed or PatientSearch query.