I have been asked to send data to the EPIC SER connector by enabling attribute sync. IL has a new requirement for data that we need to pass over to Epic SER. The ask is that we send a value that is made up from full date of birth and full Social Security Number. They have asked us to store this data in ISC and then take that data and pass it on create and enable this in attribute sync.
I was wondering if any one else has run into this issue and how did you solve for it. My leadership team said I can not give the answer that Best Practice is to not store these values in ISC.
While I do agree that we don’t normally want to store these values, I understand that some circumstances require sensitive data. My one question I would ask is does this data need to be synchronized. Birthdate and social security number should be fixed. If you could do this as part of create only, you may be able to encrypt the values coming in from your authoritative source and then use a before provisioning rule to decrypt the values going to Epic but that won’t work for attribute sync as it needs to directly compare the two values.
For a technical solution, as far as synchronizing a combined attribute such as what you describe, you can create the new value as an identity attribute by using a concat transform then you would map that new identity attribute to synchronize.
I agree with Alicia that these two attributes are typically fixed, so providing them during the CREATE process should be sufficient. I’m not sure why they would need to be included in the attribute sync. From solution perspective, encrypting the values using Identity Attribute Rule and then decrypting in the Create Account Profile using the same key that was used for encryption. FYI, org admins will have access to the rules and can easily decrypt the values if they wish to.
Due to what this value is it could be months before that value becomes in scope for needing to be populated. I want to try and avoid adding the values to the Cube if possible to help ensure fewer users have access to this information and better hide it from Search. I do like the idea of being able to encrypt the values on the record then maybe using an before/after provisioning rule to decrypt the values before being passed.
We also do have instances where the two value are not entered into the HR source accurately and are at a later time updated correctly.
Org Admins - Is a very limited scope of users. So that is fine if only Org Admins have access.
Here is a little more context as to how this value is being used.
home health users visits have to be reported to each state via electronic submission. The EVV ID is what we submit to the states with the user data to track their visits.
It’s the ID the state issues to them when they apply for their home health licensing/credential.
Would you happen to have example code how you would encrypt the values? Writing rules is still very new to me and would love to learn how best to accomplish this. Up to this point I have been able to be creative in how I solution for issues. But this one I would want to make sure it is encrypted correctly.
I would actually you set those values in MPI fields. They are sort of designed for just this task. There are many formats supported, but ask your SER experts if there are any appropriate syntaxes for these data. (Some of the fields due lookups to make sure they are valid which might make sense here).
For example, they can require uniqueness in an MPI. So no two users can have the same value.
This would be 9300 and 9301, where 9300 would have the MPI number and 9301 would have the value.
Do you happen to have an example of this? I have been working on the non sensitive ones and have not been able to get them mapped on the SER account in ISC. I have tried to set the value to 9301 and 9300 and I am still not seeing the value on records I know have a value in the extract file.
The way the ImportData records its data is in a series of key value pairs, sort of.
In SOAP, it it 35,1. In Rest, the jSON has something like: {"Data":["1,*","2,Provider, Import","45,Provider"]}
So you would have to have: {"Data":["1,123456","9300,240","9300,7","9300,60","9301,ABCD1234","9301,ValueFor7","9301,ValueFor60"]}
You can do this in a BPR I expect. The connector does not seem to support this out of the box. Or at least I can’t figure out how they expect you to do it.