Healthcare data inevitably varies between systems. You should plan for this variability prior to implementing with Redox. Here are some general things to think through to manage data variability.
First, your system needs to manage several identifier types to effectively exchange data. Identifiers help your system understand where data is coming from and whom it concerns.
Just like a physical package has two addresses, any request you initiate must include an identifier for who's sending the data and who's receiving or processing the data. In more technical terms, a request must include an identifier for the API key you're using to authenticate your system and another identifier for the intended endpoint.
Redox uses these identifiers to appropriately route the data to the correct location. Your system must also know which API keys to expect to see (from your integrated systems) and endpoint identifiers (to send to your integrated systems).
But remember that you–or your connection–may use multiple API keys and endpoints for your system. Each API key must have a unique identifier and each endpoint must also have a unique identifier. You must manage all the relevant identifiers for the API keys and endpoints that you plan to use. Learn about API keys and endpoints.
Each patient should have a unique identifier. However, there are several types of patient identifiers. A popular "master" patient identifier is the Medical Record Number (MRN), but not all healthcare organizations use the MRN in the same way. Essentially, every healthcare organization has a unique way to identify the patients within their system.
To accommodate differing patient identifiers, we recommend that your system be designed to handle multiple patient identifier types and values per connection. This is especially important when your connection has multiple systems that all use different identifiers, or your connection is a large network of providers (e.g., the Carequality Interoperability Framework).
During your implementation process, we recommend establishing which specific identifier types your system needs to support for each connection. This way, you can easily work with whichever identifier types you receive from your connection.
If you only plan to accommodate one type of patient identifier, you run the risk of mismatching patients or not being able to appropriately locate or write back data for the correct patient in your connection's system.
To refer to a specific patient visit or case, you must also manage visit identifiers or case identifiers. Unlike patient identifiers, visit identifiers won’t be sent with an associated ID type. Instead, you have to know which field should contain the visit or case identifier.
In data models, the visit identifier is located in the Visit.VisitNumber field. Or in the SurgicalScheduling model, the case identifier is located in the SurgicalCase.Number field.
Just like a patient should have a unique identifier, so should an individual provider or clinician. The two main types of provider identifiers you can expect to encounter are the National Prescriber ID (NPI) and organization-specific IDs.
NPI is a nationally unique identifier assigned to providers whereas an organization-specific ID specifies a provider within that given organization. If your system needs to track provider identity, we recommend establishing which provider identifier type to expect from your connection during your implementation process. This way, you can easily work with whichever identifier types you receive from your connection.
Due to government regulations, it’s likely that most healthcare organizations have already implemented a number of codesets, such as ICD-10 and LOINC codes. However, there isn’t always a perfect mapping alignment between codesets.
If you're interested in normalizing coded values, talk to a Redoxer about your specific use case.