Questions and Answers

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.

Understanding the Redox Scheduling Data Model

When do I need to use the Scheduling data model?

If you want to know when a patient has a scheduled office or non-surgical appointment, you’ll use the Scheduling data model to either receive updates pushed updates or request a schedule via query. To receive OR case information, see the SurgicalScheduling data model.

When are the queries supported? When is a webhook supported?

Scheduling information is in most cases made available by EHRs through a standard SIU HL7v2 feed or through APIs and other web services. SIU messages will naturally follow a push model while APIs and web services will typically be queries. For applications that prefer or require queries, Redox can use the Redox Data Chateau to consume pushed scheduling data and enable the Scheduling.Booked query for any HL7 or other push-based integrations. For applications that prefer push notifications of scheduling data, Redox can use polling for API-based integrations to push data to an application’s endpoint.

Can I get insurance information on the scheduling HL7 feed?

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

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 – visit numbers sound like what I need.  Will the appointment always have the same visit 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 appointment is cancelled and then a new one is made, the visit number may change.

Will I always see a New message the first time an appointment is sent to my application?

For an SIU HL7-based scheduling integration, the New message occurs at the time the appointment is scheduled. If the appointment is scheduled prior to your go-live date or prior to the start date of the backfill you received, the first time you learn of it may be when a Modification (such as a reschedule or check-in event) occurs. Applications typically address this by adjusting their code to evaluate based on whether or not the Visit.VisitNumber value is new to your product in addition to the event received.

Understanding the Redox PatientAdmin Data Model

When do I need to use the PatientAdmin data model?

PatientAdmin is the most common feed used across Redox customers and is something we would recommend you require if you persist patient data in your application. Over 90% of our installs use PatientAdmin in some form. This is the primary method for you to stay in sync with the health care organization regarding the patient’s documented demographics, insurance information, and the health system’s patient identifier (usually called a medical record number or MRN). PatientAdmin is the only webhook-based feed that communicates changes to this type of patient information, usually through a push notification generated from health system’s ADT HL7v2 interface.

What is a PatientMerge event?

A PatientMerge event occurs when the health system identifies duplicate patients in their EHR system and merges their charts together.  This usually is an uncommon event that occurs a few times per month at a health system, but it’s critical for you to know the correct patient identifier and to help you identify if you have duplicate patients from the health system in your application.  If you persist patient information in your application, we strongly recommend that you plan to receive PatientMerge events from the health system.  Most Redox application partners develop to accept the PatientMerge event and leverage a notification process such as an email or page to either someone on their team or someone at the health system with access to the application to manually review duplicate patients identified for merge.  If duplicates exist that need to be merged, the process of merging the records is also usually handled manually on the backend in the application.

If I can get VisitUpdate information from PatientAdmin, why do I need a Scheduling feed?

The biggest piece of scheduling related content that you can’t get on a PatientAdmin feed is the appointment status.  

Will the IDType for the patient identifier always be MR?

Redox sample messages use MR as the value for Patient.Identifiers.IDType, but this is a value that is defined by the health system.  Some EHRs and health systems have different names for their IDTypes and require those same IDType values be sent back for any updates that you need to push into the EHR.

But, I only have to worry about the main identifier, right?

Not always – some health systems will have multiple identifiers that are used for different reasons so you should plan to be able to handle multiple identifiers in the Patient.Identifiers array.

Understanding the Redox ClinicalSummary Data Model

When do I need to use the ClinicalSummary data model?

If your application is looking to receive a patient’s clinical information, either historical or in real time, then our ClinicalSummary data model is for you. This model is based on documents that are formatted using Clinical Document Architecture, or CDA documents. We can map any CDA document type to our ClinicalSummary data model but the most common is the Continuity of Care Document, or CCD. Ultimately these documents and the standards behind them are pretty complex so there are some things that you should know if our ClinicalSummary is something you will need to consume or generate.

Patient vs. Visit summary endpoints: What’s the difference?

Some CDA documents are visit-level and have data specific to one visit included in their headers; we map these documents to our visit summary event types. CCDs specifically can be either visit-level or patient-level. It is also important to note that a document we map to our visit event type will still contain patient-level information like the patient’s problem list, allergies and medications list. Conversely, documents we map to our patient-level events will still contain encounter-level information, like recent Encounters, Procedures, Results, and Vital Signs. This brings us to our next question…

How much encounter information is included in patient-level documents?

This varies per health system and we won’t know their configurations until we start speaking with them regarding the integration project. In a lot of cases, these sections contain data spanning the most recent 1-3 months.

Push vs. Query events: Which do I build against?

CDA documents can either be queried at any time or pushed, which typically happens at the end of a visit. Some EHRs can support both methods while others may just support one or the other. If you know your first integration site’s EHR vendor let us know and we can talk through what we’ve seen that EHR support. Ultimately, however, if you’re unsure what your connections will be able to support then you should build against the event type that best suits your workflow, understanding that changes may need to be made down the road to accommodate what your partners can support.

What if I query for a visit summary during the visit?

In the integrations we’ve implemented with EHRs that support visit summary queries, querying for the visit summary during the admission before the patient has been discharged returns most documented data in a “final” state, like a signed note. Not all documented data may be returned; in our experience the MedicationsAdministered section in particular may only return the last three medications administered to the patient.

What’s the difference between the Medications section and the MedicationsAdministered section in the visit summary?

The Medications section, available in both the patient and visit summaries, is the list of medications the patient is currently marked as taking, which includes any prescribed medications as well as any patient-reported medications. The MedicationsAdministered section, available in visit summaries, details any medications administered to a patient during an inpatient stay.

Can I push a ClinicalSummary back into an EHR?

The short answer is absolutely! The longer answer is that when you post a ClinicalSummary message to Redox, each EHR will receive and consume the corresponding CCD document that we send differently. Some systems will be able to integrate elements of a pushed CCD discretely while others will simply attach the summary document as a whole to the patient’s chart so it’s important to keep in mind this might vary across your integrations.

What are these Text nodes?

CDA documents contain two types of information: human-readable text called a narrative and machine-processable discrete data. Most of our data model (like codes and timestamps) is oriented around the discrete fields, but it is possible for a CDA to contain additional information in the narrative. Some sections such as Reason For Visit or Chief Complaint may be only textual. Redox presents this information to you in the Text nodes as they were originally present in the CDA. The format is HTML-esque XML, but we can easily convert this into pure HTML or even plain text for you. Similarly, when you push a ClinicalSummary into an EHR, you can provide these textual summaries for your data. It’s worth noting you don’t have to, though, as our engine will automatically generate a narrative based on the fields you provide.

Can I get ICD-10 for problems?

Meaningful Use requires SNOMED, so most EHRs use this as the default codeset for CCDs.  However, many EHRs support sending ICD-10 in addition to SNOMED, so it’s usually possible but may require an update on the EHR side.

What communication methods will EHRs use to send CDA documents to Redox?

There are several different ways in which a CDA documents can be transmitted and the method used for a given implementation will be dependent on what the EHR in question supports.

 

Anything else I should be aware of?

Some Epic organizations may require documented patient consent before making their CCD and other clinical documents available. If you initiate a ClinicalSummary query for a patient who does not have documented consent at these sites the query will return an error.

Keep in mind that we’re happy to talk through the above in more detail as we scope your integration project but this should at least give you an understanding of the nuance and variability we might come across during integration projects involving CDA documents and our ClinicalSummary model.

CCD, CDA, C-CDA… What’s the Deal?

The healthcare industry is infamous for its aggressive use of acronyms that often confuse people more than they help. Chief among these is the term CCD… and CDA, C-CDA. Though similar in both name and function, these terms don’t always mean the same thing.

Luckily, our resident HL7 Whisperer, Nick Hatt, is here to help you decipher what these terms mean, what they don’t, and how they relate to each other when it comes to sharing patient data with EHRs.

Is every CCD a CDA?

  • No, CCD stands for Continuity of Care Document, and it has origins as a paper document.

If I say “CCD” to someone at Redox, what will they think I mean?

  • We would think you are referring to a CDA document.

What’s a CDA?

  • A CDA is an electronic document written in the Clinical Document Architecture.

Is every C-CDA a CDA?

  • Yes. C-CDA is set of rules for CDAs to follow so that they are easy to exchange.

Is every CDA a C-CDA?

  • No. C-CDA is an implementation guide. It sets very specific rules about how to use CDA. C-CDA originated around 2010/Meaningful Use timeframe, and CDA is about 10 years older than that.

Is every C-CDA a CCD?

  • No. C-CDA spells out many different documents including CCD, but also Progress NoteDiagnostic Imaging Report, and Discharge Summary. Each of those has different rules for what it should include.

Are there CCDs that aren’t C-CDAs?

  • Yes. There have been many iterations of the CCD concept, most notably C32which was the de-facto standard before C-CDA was published.

What’s in CCD, why do they keep changing it?

  • Medications, Problems, Allergies, and Results are the required sections in C-CDA version 1.1, but there are many more optional pieces. They keep changing it to meet government regulations and to fix mistakes in the specification itself.

Wait, there are versions?

  • Yes, but most people only care about C-CDA v1.1 because the government mandated using that for the Meaningful Use program.

Does FHIR replace CDA?

  • Yes, hopefully.

Does FHIR replace CCD?

  • It can, but there need to be rules put in place, just like with C-CDA. Think C-FHIR. So far, no one has really taken that leap because FHIR is still unstable.

Can I delete a user in my organization?

Contact Redox if you need help deleting a user from your organization. To chat with us directly, you can click the button in the bottom right-hand corner of your screen!

Do I need a new source or destination record for each of my implementations?

Short answer – nope!

Long answer – still nope! You will have 4 records – 2 in Staging (1 Source record, 1 Destination record) and 2 in Production (1 Source record, 1 Destination record).

Each of these 4 records has its own respective ID. Every node on our network maintains this format. What this means is that when you send a message to an integration partner, that message should contain their Destination ID as well as your Source ID as a means of tracking where the data was generated and where it was sent to. Similarly, the messages you receive will contain your Destination ID and a Source ID indicating which of your connections that data came from.

Source and Destination IDs are auto-generated for each Source and Destination record. To find them, go to the Subscriptions page for your destination or source, there should be an ID link next to the name of your organization that you can click to display the ID.

If you need help creating a source record, check out our documentation.

Are There Limitations on API Calls or Callouts in 24hrs/a Week/a Month?

No!

We intentionally don’t place limits or structure pricing around a specific number of API calls because we want our pricing to be transparent and predictable for our partners. This way, they will know exactly how much integration costs, whether it is with Site #1 or Site #100.