Lo primero que en realidad deberías hacer, por lo que a mi me parece, es estudiar mejor el modelo Entidad-Relación, y sus fundamentos, porque tienes que comprender que la existencia de las PK y FK no tienen un motivo tan liviano. Son críticos en el modelo, y muy importantes para las consultas en SQL.
Una PK es un campo o conjunto de campos que identifica unívocamente un registro en una tabla, por eso es único, irrepetible y no puede ser nulo. Y entre otras cosas, no se eligen por que si, ni se crean a partir de cualquier cosa al azar.
Una PK, según el paradigma, debería ser un atributo propio de la entidad representada. En el caso de un paciente tienes más de una opción: Su documento, su numero de historia clínica, u otro dato que sólo le pertenezca a esa única persona en todo el universo.
Pero lo que seguro NO PUEDE SER es la suma de los dos. SI lo hicieras podrías poner el mismo numero de documento para otro paciente, simplemente porque su historia clínica sería otra...
No se deben combinar datos únicos de una persona entre si. Se pierde la unicidad de su dominio.
¿Se entiende?
En el modelo ER, las relaciones se determinan y restringen en la implementación por medio de claves foráneas (FK), y son
fundamentales para proteger la integridad de los datos, en especial cuando las tablas no tienen claves propias (entidades débiles), normalizadas y con cardinalidades 1: y N:M.
Las FK son obligatoriamente idénticas a la PK a la que apuntan,por consecuencia si la PK es compuesta, la FK también.
Cita: La tabla paciente es la tabla principal pero esta tiene una relación de uno a varios en otras tablas, en la cuales cada una de ella posee el campo Id_pacienbte, tales como cambios, factores_riesgo, etc.
Un "factor de riesgo", o "cambios" no se puede definir como perteneciente directamente a ese único paciente. No a menos que un determinado "factor de riesgo" sólo pueda pertenecer a un único paciente... cosa que veo poco probable.
A mi entender hay al menos una tabla "FactoresDeRiesgo" que se relaciona en cardinalidad N:M con los pacientes (más de un paciente puede presentar los mismos factores), y es en esa tabla donde se presentan las FK de lso factores y los pacientes... como PK de esa misma tabla.
¿Se va entendiendo cómo lo veo yo?
Cita: La relación de todas estas tablas las manejo desde PHP, pero quisiera realizar una relación mediante una FK para actualiza o eliminar en cascada, ya que si elimino un paciente el mismo sql mediante la FK va a hacer lo demás sino tendría que generar varias consultas para limpiar los datos del paciente que se eliminó.
Manejar las relaciones desde la aplicación es una mala idea a ciertos niveles. Es fácil que se produzcan errores de integridad referencial por defectos de programación indetectables (por ejemplo poner un espacio vacío en lugar de un NULL). Es la única forma si usas tablas MyISAM, pero con las InnoDB tienes las FK... y transacciones.
Resumiendo, habría que revisar el modelado de los datos para limpiar las cosas que no estén bien definidas, creando las FK en el orden y necesidad correctos.