Best Practice For Custom Field in Program Link
Posted: Mon Jul 25, 2022 8:53 am
Hi there,
I'm evaluating OD from the perspective of a third-party API provider. One feature I was looking at was the "program links" and using a custom URL to navigate to our doctor portal. The existing internal patient number won't match up to anything we have on our end, so I was looking at using a custom field.
Example:
Path of file to open: https://testurl.com/patient?patientId=[someCustomField]
There are a handful of out-of-the-box fields (fields like PatNum, FName, LName, etc) that will properly swap in the patient value; I found them in the Patients.cs ReplacePatient function. They are all similar like:
Firstly, am I in the right place? If so, what's the recommended way to handle this problem? I could add a line like this:
And then also extend the Patient class itself. But there are shortfalls: the function would have to be extended for each custom field versus a generic way to match fields.
Another idea would be creating a handful of these generic fields and letting third parties describe how to use them versus vendor-specific implementations in their documentation.
Any thoughts or feedback would be useful.
Derek
I'm evaluating OD from the perspective of a third-party API provider. One feature I was looking at was the "program links" and using a custom URL to navigate to our doctor portal. The existing internal patient number won't match up to anything we have on our end, so I was looking at using a custom field.
Example:
Path of file to open: https://testurl.com/patient?patientId=[someCustomField]
There are a handful of out-of-the-box fields (fields like PatNum, FName, LName, etc) that will properly swap in the patient value; I found them in the Patients.cs ReplacePatient function. They are all similar like:
Code: Select all
ReplaceTags.ReplaceOneTag(template,"[NameF]",pat.FName,isHtmlEmail);Code: Select all
ReplaceTags.ReplaceOneTag(template,"[SomeCustomField]", pat.SomeCustomField.ToString(), isHtmlEmail);Another idea would be creating a handful of these generic fields and letting third parties describe how to use them versus vendor-specific implementations in their documentation.
Any thoughts or feedback would be useful.
Derek