Passing custom identifier to Patch endpoint

[Rui Wang]

Hi Team,

We are looking for a way to pass in a custom patient identifier that is generated by our system to Cerner using the Patch endpoint. In some other thread, you mentioned we need to register an OID for the identifier generated by our system and client will need to configure it into their domain (See this thread: https://groups.google.com/d/msg/cerner-fhir-developers/3fqTj6d-5MM/-UMAkHqRAAAJ). I have some follow up questions on that 

(1) Can we register a single OID and use it for all production systems/customers?

(2) We are trying to register the OID from https://www.hl7.org/oid/ and one of the questions that was required to fill in during the registration process is the HL7 OID type. Do you know what type we need to select for our custom patient identifier? 
https://wiki.hl7.org/index.php?title=HL7_OID_Registry_Frequently_Asked_Questions#I_have_no_idea_what_Type_I_should_select_for_my_OID

Thanks!
Rui

[Sydne Anschutz (Cerner)]

Hi Rui,

1) At a high level, if you register an OID for some organization/entity that is assigning unique MRNs across all production customers, yes, you can use the single OID for all production customers.

2) I don't think we (Cerner) know enough about your particular use case to answer your questions about registering an OID and what type it is.

Thanks,

Sydne (Cerner)

[Rui Wang]

Hi Sydne,

We did some research and we decided to register a type 3 OID and assign unique oid for each production customer for our identifier. This is the request we are currently using to add our identifier to the sandbox.
Just to be sure,  will the type field(in yellow) still be the same for the add identifier operation if we use Type 3 oids in the system field(in green)?

[{

  "path": "/identifier/-",

  "op": "add",

  "value": {

    "type": {

      "coding": [

        {

          "code": "MR",

          "system": "http://hl7.org/fhir/v2/0203"

        }

      ]

    },

    "system": "urn:oid:2.2.2.2.2.2",

    "value": "Our_Identifier_Value",

    "period": {

      "start": "2020-03-24T00:00:00-05:00",

      "end": "2024-03-24T00:00:00-05:00"

    }

  }

}]

Thanks,
Rui

[Benjamin Eichhorn (Cerner)]

Hi Rui,

Unfortunately without more context we likely won't know. The type field is a mapped field and the point/use of your identifier will impact what the "type" field will be. I would recommend you scan through the http://hl7.org/fhir/v2/0203/ system and identify what code value makes the most sense for your use case. When we collect the fields you need mapped, we will likely be able to map your specific OID to the specific type code you have chosen.

Thanks,

Ben (Cerner)

[Rui Wang]

Hi Ben,

Just trying to understand this more,
We can register any type of OID and it will not affect the value in the type code field (the yellow) we need put in. It's the use case of this identifier that will affect what we need to put in to the type code field. You will need to map our new OID and the type code that fits in our use case so we can add identifier to patient using our own OID in the sandbox.  Is that correct? 

Is it also correct that when it comes to production, the customer will need to do the mapping again so that they can get our identifier stored?

Thanks,
Rui

[Benjamin Eichhorn (Cerner)]

Hi Rui,

I'll try to explain roughly the process that you'd go through if you were integrating an app with a specific OID unique to that app (like your use case) into a production domain.

1. You'd register/get your OID from the HL7 registry (which you seem to have done).

2. When going to production the client would need to register your OID in their system so that the specific identifier (or alias) can be returned VIA FHIR and stored in the clients domain.

3. After the OID has been configured in the given clients domain, they will begin to be returned via FHIR, however the "type" field will not contain any code.

4. To get the type field to be returned concept mappings need to be completed by us (Cerner) for that given domain so that the "type" field is populated with a specific standard code.

This is true for every domain that your app would be onboarded for. We don't necessarily recommend that apps go down this route as it does make onboarding an app potentially harder, however, this does not mean you can't do this. There are perfectly valid use cases which I'm sure you evaluated.

Thanks,

Ben (Cerner)

[Rui Wang]

Ben,

Thanks for the information! That's really helpful. 
We actually haven't completed the new OID registration yet. We are in the middle of registering it but we found it's required to select an OID type so we are trying to figure out what type we need to select. (https://wiki.hl7.org/index.php?title=HL7_OID_Registry_Frequently_Asked_Questions#I_have_no_idea_what_Type_I_should_select_for_my_OID). 
After done some research,  we think Type 3 is most appropriate for our use case where we will be able to assign new oids under it for each customer.  And I just wanted to make sure I can still use the patch endpoint to add our identifier with a type 3 OID in the "system" field. 

Based on the example the documentation shows, the request for adding an identifier will need the "type" field(yellow) and the identifier oid (green) populated. That's why I asked if we should send in the same value we use in sandbox for the type field when it comes to production. I think it makes sense now that I will need to figure out the type from http://hl7.org/fhir/v2/0203/  and then you can help map it with the new oid we get. 

I will post the new OID and appropriate standard code here once we have it. With a Type 3 OID purchased, we will have the ability to assign oids under it. Is it possible that you can map a new oid in the sandbox as well? Or we should keep use urn:oid:2.2.2.2.2.2 to test the patch endpoint even we have new oids available?

Thanks,
Rui

[Benjamin Eichhorn (Cerner)]

Hi Rui,

For our sandbox environment at least you will need to use the OID you mentioned above. (along with it's assigned type). When you move into a clients domain, you'll have to have them configure the OID assigned to your organization and you will then be able to use it within that domain. 

Thanks,

Ben (Cerner)

[Rui Wang]

Hi Ben,

In case you missed my private message, we have another follow up question on the "type" field of the adding identifier request.

We are scanning through http://hl7.org/fhir/v2/0203/ to figure out the right type. We are wondering if you have additional info you can provide regarding which type we should select.

Our identifier is an unique patient identifier that will associate with the patient biometric stored in our system. With this unique identifier added to Cerner patient record, we will be able to identify a patient biometricly to help improve the patient look up workflows for hospitals.

We've been told in some other projects with Cerner that: A Snomed code in Cerner namespace has been created to map our custom identifier and it will be proposed for inclusion with the Snomed standard : 26091000175105 : Biometric identifier (observable entity).

Do you know how the type we are going to select for the FHIR request will map back to the Snomed spec -- specifically the 26091000175105 : Biometric identifier (observable entity) type in Snomed?

Thanks,

Rui