Healthcare data inevitably varies between systems. You should plan for handling variability before starting your implementation project. Here are some tips to help.
Your system needs to manage several identifier types to exchange data. Identifiers help your system understand where data is coming from or going to, how it's been authenticated, and who the data is about.
Just like a physical package has mailing addresses to direct it, an API request must specify who's sending data and who's receiving it.
In more technical terms, an API request must include a source identifier for the sender, along with the API key identifier to authenticate the request. And of course, the request must include a destination identifier for the intended endpoint. Redox uses all of these to appropriately route data.
During implementation, find out which source identifiers to expect to see from your connection, and which destination identifiers you should use to send data to them. Each identifier must be unique, especially since you and your connection may have multiple sources and destinations. Be prepared to manage all the relevant identifiers for the API keys, sources, and destinations that you plan to use for both sides of the data exchange.
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 of identifying patients within their system.
To accommodate differing patient identifiers, we recommend that you design your system to handle multiple patient identifier types and values per connection. This is especially important when your connection has multiple systems with lots of sources, or your connection is a large network of providers (e.g., the Carequality Interoperability Framework).
During the 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 plan for only one type of patient identifier, you run the risk of mismatching or not locating patient records. Or you may write data back to the wrong patient record.
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 identifiers.
NPI is a nationally unique identifier assigned to providers, whereas an organization-specific identifier is known or used within the context of a 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, most healthcare organizations have likely already implemented many code sets, like ICD-10 and LOINC codes. However, there isn’t always a perfect mapping alignment between code sets.
If you're interested in normalizing coded values, talk to a Redoxer about your specific use case.