Thanks for your insight. This early in design I just hate to build in such a fundamental flaw that has to be dealt with later. The virtual column seemed like the way to go and I've tested it with my forms for single-row maintenance and there are no issues at all as far as performance (which I expected). I just wasn't sure if there were unexpected consequences waiting for me down the road. Your insight is a confidence boost. Thanks again!

Warning: you are converting numbers and dates to strings without explicitly including NLS parameters. If your session-level NLS parameters change, the hash value will change. You do not want this!

Suggestion: use STANDARD_HASH instead of DBMS_CRYPTO.

Second suggestion: don't convert to strings in the first place. Hash each column directly with STANDARD_HASH, then concatenate the hashes using UTL_RAW.CONCAT, then hash the hashes.

Best regards,
Stew

Following up my original question... if my table contains a BLOB or CLOB column how would you revise handling the hash and would that change my choice of hash function to use (STANDARD_HASH, DBMS_CRYPTO, etc.)? I am tangled up in the choice of when and where to convert data and what to convert it to in order to include a BLOB/CLOB.

SQL> create table t ( x clob );

Table created.

SQL> select standard_hash(x) from t;
select standard_hash(x) from t
                     *
ERROR at line 1:
ORA-00902: invalid datatype

I'm sorry, my last follow up question was too brief. I should have provided more details into my issues.
In my example, I based my approach on converting the row data to VARCHAR2 as a basis:

ALTER TABLE my_emp
ADD hashkey      VARCHAR2(4000)
GENERATED ALWAYS AS(
   CAST(MY_SECURITY_PKG.hash_value(TO_CHAR(empno) || '|' || ename || '|' || job || '|' || TO_CHAR(mgr) || '|' || TO_CHAR(hiredate, 'mm/dd/yyyy') || '|' || TO_CHAR(sal) || '|' || TO_CHAR(comm) || '|' || TO_CHAR(deptno))
   AS VARCHAR2(512))
   );
/

and my function receives and return VARCHAR2:

CREATE OR REPLACE PACKAGE BODY my_security_pkg
AS
   FUNCTION hash_value(
      p_input_string_in IN VARCHAR2
      )
   RETURN VARCHAR2 DETERMINISTIC
   IS
   BEGIN
      RETURN DBMS_CRYPTO.HASH(UTL_I18N.string_to_raw(p_input_string_in),DBMS_CRYPTO.hash_sh512);
   END hash_value;
END my_security_pkg;
/

So now I introduce a column that is either a CLOB or a BLOB. What is the best approach to hashing my record? Should I hash the CLOB/BLOB by itself and simply include the hash in my concatenation and then hash the entire record? Also, looking at my choice of VARCHAR2 for the parameter into my hash_value FUNCTION I'm thinking I should switch to CLOB or maybe at least overload it to handle if my concatenation ever gets beyond 4000 characters.
Finally, one last question... DBMS_CRYPTO.HASH returns RAW. After writing the original code in the question I noticed that I did not convert raw to varchar2 in my function but it had been working. I assume Oracle has been implicitly converting for me. I added in an explicit conversion to avoid problems:

RETURN UTL_I18N.raw_to_char(DBMS_CRYPTO.hash(UTL_I18N.string_to_raw(p_input_string_in),DBMS_CRYPTO.hash_sh512));

Before I would get readable alphanumeric characters returned, but afterwards would get unreadable characters. Can you explain what is happening? Here is basically that change written as a SELECT:

SELECT
UTL_I18N.raw_to_char(DBMS_CRYPTO.hash(UTL_I18N.string_to_raw('Some string'||'Another string just to add some length'||TO_CHAR(SYSDATE, 'mm/dd/yyyy hh24:mi:ss')||TO_CHAR(53)),6))
FROM dual

Thanks for taking the time to review and answer my follow up. I get so much valuable insight from your site and I cannot imagine doing my job without having it as a resource.