We have observed a fairly severe issue after Bare Metal ODA patching from the bundle 184.108.40.206.0 to the bundle 220.127.116.11.0 (the latest available among the 12.1 bundles at the time of this writing)
Namely - none of the 18.104.22.168 databases would start as soon as Infrastructure & GI components of the ODA were patched via the "oakcli update -patch 22.214.171.124.0 -server" command.
Error messages were indicating that DB control file could not be identified.
We were still able to see each 126.96.36.199 DB's control file via the asmcmd>lsdg exactly where it was expected to be.
At the same time either on CRS restart or after the "srvctl start instance" command the DB instance would show up in the "ps -ef | grep pmon" output for a few moments and then it would disappear.
After looking into the DB alert files the following error messages were spotted for the times when the attempts to start 188.8.131.52 databases were made.
ORA-600 [kfdJoin3]   
Also. luckily enough, this MOS DocID has been posted in mid-February 2018 and it describes the same exact issue ... and the solution !
Database Instance Will Not Start ORA-600 [kfdJoin3]    After Patch 184.108.40.206.0 Including the ODA (Doc ID 2341707.1)
The solution came down to completing ODA patching up to and including the RDBMS homes and then downloading the one-off patch p18948177_112040_Linux-x86-64.zip that simply needed to be applied per its README.
It is important to note that this one-off patch should NOT be applied to the GI homes on the ODA since those homes would be already at 12.1 and this one-off patch is specific to 220.127.116.11 homes.
Once we applied the patch, via opatch apply, all 18.104.22.168 databases had started as expected.
Hope this article could help if you end up being in the situation that we had found ourselves after applying ODA bundle patch 22.214.171.124.0 to the appliance where databases 126.96.36.199 are still running.