Category: Questions and Answers

Questions and answers for different Redox Data Models

Understanding the Redox SSO Data Model

When do I use the SSO Data Model?

​​​​​​​ The SSO Data Model allows organizations to securely share the login context for a user. The most common use case is a provider in an EHR launching an integrated application, and being automatically logged in, as well as passing context such as which patient and visit are open.

Current support of this data model requires that the EHR is capable of making an outbound SAML request. Additional browser-based SSO schemes may be used with an EHR uses as long as it meets the bar for security. As with all Redox Data Models, we provide abstraction, standardization, and normalization services to deliver a consistent experience for developers.

What is an example SSO workflow?

The goal is to launch an application from within an EHR without requiring the user to sign in repeatedly.

  • User (physician, nurse, scheduler, etc) is logged into an EHR
  • User clicks a button to launch a Redox network app in their EHR
    • SAML (or another base message) is sent to Redox and transformed into the Redox SSO Data Model
  • Application receives message, processes contents, and returns a URL to the EHR to show the user inside of the EHR window.

What contextual information is included in the SSO request?

Basic information about the user who launches the application as well as the particular patient is included in the SSO Data Model. In the event that this basic information does not meet your needs, some EHRs may have support for extending this information to include additional data.

Does our SSO model work for patient context, such as launching apps from an EHR’s patient portal?

The SSO support we’ve currently implemented has only been via SAML, which is launched from an EHR context for providers or other organizational users. However, patient SSO could be set up with a URL based launch or SMART on FHIR. If you are interested in pursuing such functionality, please reach out to us.

How does the SSO Data Model differ from the ClinicalDecisions Data Model?

Both the ClinicalDecisions and SSO Data Models involved workflow embedded bi-directional exchange. However, they differ in several capacities:

  1. Trigger Point
    1. ClinicalDecisions is typically triggered from the EHR via a normal workflow step such as ordering or adding of a problem.
    2. SSO is typically triggered from the EHR via a specially configured button made available within the right EHR module.
  2. Returned Content
    1. ClinicalDecisions returns discrete data that the EHR can utilize as part of an alert to advise on the user’s behavior.
    2. SSO returns a URL that the EHR can launch for the user.

Understanding the Redox Notes Data Model

When do I need to use the Notes Data Model?

The Notes Data Model is used to convey free text or RTF content to or from an EHR. Typically this is non-structured documentation about the clinical care of a patient. Applications typically use Notes to summarize actions taken by users in their system and file it back into a hospital’s EHR. Alternatively, notes created in the EHR may be sent outbound to applications for reference or analysis.

Notes is a good choice for customers that want to send plain text or rich text to an EHR, especially if they want to show it in the EHR context with advanced text parsing capabilities (NLP, searching of the chart, etc).

When and where can the Notes Data Model be supported?

While there is widespread support across EHR vendors for the related Media Data Model, not all EHR vendors have a separate concept or capability to use the Notes Data Model. EHR vendors with robust interfacing capabilities will typically offer this capability through an MDM HL7v2 interface or an API.

How is the Notes Data Model different from the Media data model?

The Notes data model is similar to the Media data model, in that it is often used for sending a summary back to an EHR, but differs in that:

  • Layout:
    • Media, when sent as a PDF, has a guaranteed layout that is consistent across EHRs.
    • Notes sent as plain text or rich text are subject to the rendering capabilities of the EHR.
  • Direct Display:
    • Media is generally represented as a link (a user clicks a link to launch a separate program to show the PDF, play the WAV, display the JPEG, etc).
    • Notes are shown within the EHR context.
  • Searchability and Analytics:
    • Notes may offer superior searchability (if the EHR has that capability) and usability for things like Natural Language Processing (where software analyzes the note content for things like diagnoses, problems, and medications and offers them to the user to be added discretely)

What data is required in order to file Notes 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 Notes 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 note type, a unique note ID, and whether or not the note has been authenticated by a physician and is authorized to be shared in the patient’s chart.  To file a note 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.

 

Understanding the Redox Vaccination Data Model

When do I need to use the Vaccination Data Model?

The Vaccination Data Model relates to biological preparations that provides active acquired immunity to a particular disease. A vaccine typically contains an agent that resembles a disease-causing microorganism and is often made from weakened or killed forms of the microbe, its toxins, or one of its surface proteins. Another name for a vaccination is an immunization.

The Vaccination Data Model is usually triggered at administration, not ordering. Therefore, it is most useful for applications that want to know when a patient has been administered a vaccination.

When and where can the Vaccination Data Model be supported?

Vaccinations are most commonly administered in outpatient settings. Additionally, supporting transactions between the EHR and immunization registries was one of the three possible public health components in Meaningful Use 2. As a result, EHRs with an ambulatory focus oftentimes have developed support for vaccination interfaces to meet the MU criteria, generally through HL7v2 VXU messages.

What other Data Models is Vaccination similar to?

Vaccination is similar to the Medications Data Model:

  • Both follow a similar workflow where they are ordered by a physician and administered to a patient.
  • Vaccinations are proactive, in that they are given prior to an infection occurring. Medications may be given proactively or retroactively (after illness symptoms have occurred)
  • Vaccinations are dead versions of a micro-organism. Medications are generally compounds that hurt or fight micro-organisms or disease symptoms.

Understanding the Redox Referral Data Model

When do I need to use the Referral Data Model?

The Referral Data Model deals with information when a referring provider turns the management of the patient over for a specific problem to another provider. It typically differs from a consultation, where a provider may review a patient without assuming authority over his or her care. Referrals can be internal to an organization (from one department to another, for instance) or between organizations.

It is most common with EHRs to maintain the administrative status of a referral order. Once an order has been received referring a patient from one hospital to another (or from one specialty to another), the referral data model is used to track the progress of that referral as back office users get authorization from insurance, schedule the referral, etc.

When and where can the Referral Data Model be supported?

EHRs with advanced referral management capabilities and robust interfacing libraries typically offer the Referral Data Model through an HL7v2 REF interface or vendor-specific API.

What if an EHR doesn’t have a referral interface?

Many EHRs create referrals on the fly when an order is sent in via the Order Data Model. When using the Orders Data Model the application may not be able to update any referral specific items after creation. Redox will help you determine the best path forward as you move through your implementations.

How is the Referral Data Model different from the Order Data Model?

Referral can be though of a specific type of Order when it pertains to transfer of patient responsibility across specialty care. When a healthcare organization receives an order for a referral, it creates a referral record. The appropriate administrative staff then work these records in terms of getting approval from insurance, scheduling, etc. These concepts can vary per EHR. Redox will help you determine the best path forward as you move through your implementations.

 

Understanding the Redox Research Data Model

When do I need to use the Research Data Model?

The Research Data Model is primarily concerned with connecting EHRs with Clinical Trial Management Systems (CTMS). Clinical trials are defined in the CTMS, and then synced to EHR, via a push from the CTMS. Additionally, either system may enroll patients in the trial and share that information with the other system.

This data model could be useful to other vendors that are interested in patient study status, possibly for prioritization of work, such as labs, imaging vendors, etc. It would also be useful for applications that want to maintain the list of active studies at an organization.

When and where can the Research Data Model be supported?

You’ll find the Research model is used most commonly when connecting to academic healthcare organizations or other HCOs with robust interfacing capabilities and strong research programs.  Typically EHRs and CTMSes will make Research data available via HL7v3-based messages defined in IHE’s Protocol for Execution profile  and Research Process content.

What other data models is the Research similar to?

Research.Study is a master data notification message, in that it keeps a list of static data synchronized across systems. In this way, it is similar in function to other master data notification events, like Provider events or Inventory.Update.

Understanding the Redox Inventory Data Model

When do I need to use the Inventory Data Model?

The Inventory Data Model is used to track surgical supplies (scalpels, bandages, etc) between systems. The Inventory.Update transaction is an administrative message that is used to synchronize the lists between systems. Generally this data comes from the Enterprise Resource Planner into the EHR, including the types of items stocked and the specific locations in the hospital they might be found. The Inventory.Deplete event is a workflow-oriented message that sends information from the EHR to the ERP when a supply is used in a surgical procedure.

When and where can the Inventory Data Model be found?

You’ll find the Inventory Data Model most commonly when connecting to inpatient EHRs with robust interfacing capabilities and surgical specialty modules.  Supplies are also often used in areas that function similarly to surgery, such as invasive cardiology or angiography. Typically ERPs will make Inventory.Update data available via an HL7v2 MFN format or a vendor-specific API. Inventory.Deplete is most commonly made available via an HL7v2 OMS or DFT format or a vendor-specific API.

How is the Inventory Data Model different from the Financial Data Model?

Financial is administrative information about what’s happened to a patient in regards to financial impact. Inventory.Deplete is also administrative information about what’s happened to a patient, mainly for the purposes of tracking when certain items might need to be re-ordered or restocked.

Can I receive preference card information via the Inventory Data Model?

Once the full list of supplies is created in the EHR via Inventory.Update, surgeons can create their preference cards, a list of supplies they commonly use and document in surgery. Preference cards are master data themselves, in that they are lists of surgical supply preferences, but they are not exchanged via a known standard.

When a surgeon uses a supply in surgery, they choose the supply from the preference card list and mark it as used or wasted. This sends the usage to the outside systems via Inventory.Deplete. Depending on use case, this usage information, as well as other relevant Data Models like SurgicalScheduling, are typically sufficient in supporting the needs of Redox applications that focus on surgical areas.

Understanding the Redox Order Data Model

When do I need to use the Order Data Model?

Applications use the Redox Order data model to transmit a request for services or from an EHR.  ​​​​​​​The Order Data Model is the message conveying the electronic entry of medical practitioner instructions for the treatment of patients. EHRs generally send an order when the a physician places the order. They may also send the order when a user releases it (after ordering, a user takes action on a worklist of pending orders to say “it’s time to do this”).

Lab orders are a common workflow involving the Order Data Model. In this case, when a physician places an order for a glucose test, for instance, the EHR sends a message with an expected date and time. When a nurse doing lab rounds (inpatient) or at a collection center (outpatient) collects the specimen, the EHR might send Order.Update with additional information about the collection, such as collection user or collection date/time.

When and where can the Order Data Model be found?

Almost anywhere! Physicians place all sorts of orders, ranging from specialty diagnostic tests like EEGs, cardiac echos, or X-Rays, to more administrative functions, such as discharge orders or referral orders. It is a fairly standard feed for EHRs to have set up and that we would expect it to be available to license if not already active at the healthcare organizations you are considering as partners. Typically EHRs will make this data available via an HL7v2 ORM interface or a vendor-specific API.

What are Order-specific questions?

Order specific or Ask at Order Entry (AOE) questions are information that a provider must provide to give additional clinical context. For instance, certain lab tests require race and whether the patient has eaten recently to know the appropriate reference range for results (i.e. an Asian who ate this morning might have a different reference range than an African American who did not eat).

How is the Order Data Model different from the Medications data model?

The Medications data model is in some ways a sort of order, in that physicians place orders for medications (prescriptions). However, Redox offers the Medications Data Model separately because a prescription has standard data elements that aren’t found in other types of orders, such as medication frequency, dose, and route.

The main event as an outcome of most orders that Redox customers are looking for is diagnostic test completion and physician interpretation (using the Results Data Model). For Medications, outpatient dispense/usage or inpatient dispense/administration are the relevant outcomes (also using the Medications Data Model).

How is the Order Data Model different from the Referral Data Model?

An Order can be thought of as a request for Referral when it pertains to specialty care. When a healthcare organization receives an order for a referral, it creates a referral record. The appropriate administrative staff then work these records in terms of getting approval from insurance, scheduling, etc. These concepts can vary per EHR. Redox will help you determine the best path forward as you move through your implementations.

Understanding the Redox Medications Data Model

When do I need to use the Medications Data Model?

Applications use the Medications Data model to receive prescription notifications and fill requests in realtime. This includes new medication orders as well as updates and cancellations.

What if I want to receive all the medications the patient is currently taking?

If you’re not looking for prescription order updates but rather the patient’s list of current medications, then ClinicalSummary Data Model is the best model to use. See our FAQ on the ClinicalSummary model for more information.

Does the medications model allow my application to e-prescribe medication orders?

Nope, applications primarily use this model to transmit prescription notifications in realtime as medications are ordered between an EHR and a connecting application. If your application wants to update a patient’s medication list with a medication that has already been ordered and prescribed or that has been reported by the patient, then we recommend leveraging the ClinicalSummary model to send the patient’s updated medication list inbound to the EHR where it will be reconciled by a clinician.

What if I need to receive medication administrations?

If you need data on medications that are administered within a healthcare setting, then the visit ClinicalSummary is the best model and event type to use. See our FAQ on the ClinicalSummary model for more information on visit summaries and medication administrations. Eventually we are planning on adding an administration event to the medications model as well.

What other use cases will the medications model support in the future?

In addition to administration, we also plan on adding dispense and statement event types in the future. Dispense events fire as users dispense or fill prescription orders. Systems transmit statement events as users add patient-reported medications to the patient’s chart.

What are the EHR requirements to support the medications model?

The current supported events require one of the following:

  • Active OMP or RDE HL7v2 interface
  • MedicationOrder FHIR resource
  • Medication orders API

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 synchronized 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.

What’s the difference between the Provider Data Model and other Data Models that use providers?

Almost all patient centric data models have data elements that are providers. For example, PatientAdmin may have a referring provider, Scheduling may have a scheduled provider, and Order may have ordering provider. The Provider Data Model is different in that it is not patient-centric. It tells who the provider is, not what role the provider plays in regards to a certain patient.

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. In general, MFN interfaces aren’t incredibly common; however, the setup is site specific and not based on the EHR vendor. 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 synchronized 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. Applications could then 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 an application is sending a one-off value, many times the result of some kind of physician-entered order, to the patient’s chart. This data will show up wherever results are in the EHR.  Some examples that commonly involve the Results Data Model:

  • Labs
    • General lab (discrete lab values)
    • Microbiology (discrete, structured lab data pertaining to antibiotic sensitivities)
    • Pathology (result reports after reviewing pathologic images)
  • Diagnostic imaging/image-like areas
    • Radiology (result reports after reviewing radiologic images)
    • Cardiology (result reports and/or discrete data after reviewing cardiology images)
    • Urology (urination tests)
    • Pulmonology (lung function test)
    • Neurology (EEGs and result reports)
    • Obstetrics (fetal echos and result reports)

What form of data do applications send or receive using the Results Data Model?

Results data can be filed back in various formats depending on EHR capability:

  • Discrete information, such as specific lab and cardiology values
  • Textual information, such as a pathology report
  • A PDF or other complex data formats (JPEG, Word, etc) for the test (such as a document that shows a graph of lung function)
    • Applications can embed the document in the message using an encoding scheme called base64. The EHR can then pull this embedded document out of the message and store it in their database. For more information on that check out our Sending Files through Redox post.
    • Applications may store the PDF or file on their own server and send a reference pointer (a URL or file destination). The EHR then would render the link to view the document.

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 Flowsheet Data 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 diagnostic test order that was placed for a patient, is being sent to the patient’s chart. This data will show up wherever results are in the EHR.