Searching by Identifier - MRN

[pemm...@psmiconsulting.com]

Hi there, I've read the other questions on this topic but would like some clarification on searching by the identifier (specifically the MRN)....

Our application's functionality is to retrieve clinical information (e.g. Problems, Medication Orders, etc) using patient contact information provided from another service which uses the Millennium Objects API. 

So we will have to use the patient's MRN identifier to lookup the patient's logical resource id.

https://fhir-open.sandboxcernerpowerchart.com/dstu2/d075cf8b-3261-481d-97e5-ba6c48d3b41f/Patient?identifier=10002700

Using just the identifier results in the "identifier.system: cannot be blank" error message. 

Q1.In dstu2, both the identifier and system (urn:oid) are required to lookup a patient using the MRN identifier e.g. urn:oid:1.1.1.1.1.1|10002700 ?

https://fhir-open.sandboxcernerpowerchart.com/dstu2/d075cf8b-3261-481d-97e5-ba6c48d3b41f/Patient?identifier=urn:oid:1.1.1.1.1.1|10002700

https://fhir-open.sandboxcernerpowerchart.com/dstu2/d075cf8b-3261-481d-97e5-ba6c48d3b41f/Patient?identifier=urn:oid:2.2.2.2.2.2|948357

In the sandbox, the MRN identifier can have system values (urn:oid)  of 1.1.1.1.1.1 and also 2.2.2.2.2.2. 

Q2.If I need the urn:oid value to search using the identifier, how would I know which urn:oid value to use if I only have the MRN value? 

https://fhir-open.sandboxcernerpowerchart.com/dstu2/d075cf8b-3261-481d-97e5-ba6c48d3b41f/Patient/1610007

The above patient has two different MRNs. 

    urn:oid:1.1.1.1.1.1|10000764 with a start period of 2012-08-30T06:38:05.000Z

    urn:oid:2.2.2.2.2.2|10000345 with a start period of 2012-08-30T06:40:19.000Z

Q3. Is it possible for a resource to have more than one MRN and urn:oid?

When searching using the two MRNs and urn:oids:

https://fhir-open.sandboxcernerpowerchart.com/dstu2/d075cf8b-3261-481d-97e5-ba6c48d3b41f/Patient?identifier=urn:oid:1.1.1.1.1.1|10000764 

This returns the same patient (logical id of 1610007) as expected.

https://fhir-open.sandboxcernerpowerchart.com/dstu2/d075cf8b-3261-481d-97e5-ba6c48d3b41f/Patient?identifier=urn:oid:2.2.2.2.2.2|10000345 

This does not returns the patient with logical id of 1610007. Instead, it returns a patient with logical id of 1280007 where the urn:oid:1.1.1.1.1.1|10000345

Q5. Why does the MRN which has the newer start period not work?

Fuzzy or exact:

    may2015 docs says Parameters (other than _id) will currently perform a “fuzzy” search. 

    dstu2 docs says The birthdate, name and telecom search parameters will perform a “fuzzy” search.

Q6. Searching using the identifier in dstu2 returns multiple records. Is it still performing a fuzzy search?

https://fhir-open.sandboxcernerpowerchart.com/dstu2/d075cf8b-3261-481d-97e5-ba6c48d3b41f/Patient?identifier=urn:oid:1.1.1.1.1.1|10002700&_count=1

It seems the first entry of the search result is the patient with the correct MRN. 

Q7. When searching by the MRN identifier, can I expect to get the correct patient by restricting the results to 1 i.e. _count=1?

I very much appreciate any clarification and recommendations on this.

Best Regards,

Peter Emmanuel

[Jenni Syed]

Hi Peter,

Yes, we require the system to search by identifier, so we can limit the search to the proper set of identifiers (ie: MRN, appropriate facility, SSN, etc). In sandbox, they're typically the oids you mentioned above, but at production site, they would be specific to the registered oid for that provider. You would need to work with the system you're integrating with in order to configure or know what OID is appropriate for the MRNs in the facility/system your app is integrated with, assuming the application workflow prevents it from being launched from the Patient's chart.

A Patient can have as many MRNs as they were registered to unique organizations (however a site has decided to break up their unique MRN pools). The OID should be what makes the MRN unique for a patient - it's the identifier of the unique assigning pool for that MRN.

We're working on removing the fuzziness in the patient search (unfortunately, it will be removed for a bit in sandbox while we upgrade this). The identifier search is already fixed, and is no longer a fuzzy search.

As to the weird patient issue where it's pulling back another patient (they have duplicate MRNs in the same pool): this is likely because our sandboxes are development domains, and as such, the data sometimes gets quite messy. However, I can reach out to make sure that this isn't something that would affect production as well. However, you should not restrict the count to 1 - if this happened in production (multiple patients having the same MRN), it would be surprising but technically possible - though there would be many other issues going on. Ignoring the MRN, we have seen SSN duplicates due to fat fingering and other issues in production. You may want to consider what your application should do if it gets duplicate results back.

~ Jenni

[pemm...@psmiconsulting.com]

Hi Jenni,

>> The identifier search is already fixed, and is no longer a fuzzy search.

Q1. Just to make sure I understand you correctly... is this currently only fixed in the production environment but not it the open sandbox where it is still temporarily using fuzzy matching?

I am still getting multiple results returned when searching using the identifier:

https://fhir-open.sandboxcernerpowerchart.com/dstu2/d075cf8b-3261-481d-97e5-ba6c48d3b41f/Patient?identifier=urn:oid:1.1.1.1.1.1|10002700

The above query returns 4 entries:

    system : urn:oid:1.1.1.1.1.1 and value : 10002700

    system : urn:oid:1.1.1.1.1.1 and value : 10001286

    system : urn:oid:1.1.1.1.1.1 and value : 10001715

    system : urn:oid:1.1.1.1.1.1 and value : 10001818

Q2. Will the Millenium Objects API be able to provide a logical idenfier and would it be the same as the logical idenfier of the FHIR Server?

Best Regards,

Peter Emmanuel

[Jenni Syed]

Peter,

I'm going to have someone look at the MRN search - I thought it was supposed to be exact both in sandbox and production, but we'll confirm.

For objects - it depends on what API the app is using in Objects and what workflow it's trying to accomplish. What is the workflow of the app that is requiring it to start with the Objects API? If the primary concern is the MRN search, this is something that should work via FHIR (or, even better, launching from within the patient chart itself via SMART). Since FHIR does provide a way to lookup patients, that is our preferred starting point, assuming FHIR provides the parameters required for your app's workflow.

~ Jenni

[pemm...@psmiconsulting.com]

Hi Jenni,

This is a collaborative project between a few teams (different orgs).

Team A is using Cerner's Millenium Object API because they require certain services not provided by FHIR. They identify patients based on specific criteria and notify the provider.

If the provider requires additional clinical information for a patient identified by Team A, they will request the patient chart using the FHIR services provided by Team B. 

Team A can provide us with either the patient id or the MRN: 

• Is the patient id (using the Millenium Object API) the same as the FHIR resource's logical id? If it is, we will use it. 
• Otherwise, we will use the MRN identifier to get the patient's FHIR resource logical id.

In other words, we're accessing the FHIR server from another resource server (non-FHIR) not from a SMART app on the client. That means we'll already have access to the MRN (no need for launch context to provide it). What we hope is that we can query the FHIR server directly from the other resource server using the logical ID if it is the same.

Thanks,

Peter E.

[Jenni Syed]

The sandbox search hadn't been switched over to the non-fuzzy MRN search. That has been corrected - please test and make sure you seeing the results you would expect now.

As to the patient id - it is *right now* the same as the unique id for FHIR. 

~ Jenni

[pemm...@psmiconsulting.com]

Thank you Jenni and team! The sandbox search using the MRN id now returns a single result as expected!

Best,

Peter