como ago esta consulta

[gnzsoloyo]

Por lo que parece, el problema básico es que tienes poca preparación en fundamentos de las bases de datos, perdona que lo diga, porque tu problema tiene que ver en este caso bastante con ello.

Las cosa vendrá a ser:
Un paciente o "cliente" de un servicio médico, como cualquier otro cliente comercial, sólo puede estar identificado por un único atributo, que es en ese sentido su PRIMARY KEY. Una primary key puede estar compuesta por uno o más atributos simultáneamente, pero en tu caso dices que la "ficha" del paciente es en Nro 148100, que debería ser la identificación del paciente. Entonces debo suponer que el "0" es un código de uso interno de algún tipo que se refiere a alguna característica o del paciente o de la atención recibida.
Si es una condición de paciente, se trata de algo que no pertenece a la PK y por tanto no debe estar "combinado" en la tabla con el numero de ficha. Si es algo relacionado con la atención, no puede pertenecer a la tabla sino a otra, porque es lógico pensar que un paciente puede recibir N atenciones por razones diferentes.
En cualquier caso, y esto lo debes tener en cuenta, el que tu hagas que el numero de la ficha aparezca como dos campos separados ("148100" y "0"), o uno solo ("148100-0") es absolutamente irrelevante para el almacenamiento de los datos, porque se trata de un problema de visualización, de representación en pantalla, y los problemas de visualización no son dominio de la base, sino de las aplicaciones. La base simplemente lo puede devolver formateado, pero datos de distintos dominios no deben combinarse en un mismo campo.
La razón de esto es simple: Si tu almacenas los datos combinados (como dices hacerlo), las consultas se complican y las actualizaciones de datos también porque tienen una enorme inconsistencia de datos, ya que en unas tablas el número de ID de la ficha paciente aparecerá como "148100-0" y en otros como "148100". Eso se denomina "inconsistencia", y es un defecto grave.

Como puedes apreciar, hay algunas cuantas cosas y análisis que afectan tanto al diseño de las tablas como a la resolución de las consultas. Son importantes de resolver a tiempo porque eventualmente te traerán problemas (de perfomance, de consistencia, etc.). No digo que pueden traerte problemas, te van a traer problemas porque cuando la base esté en trabajo estará acarreando problemas que se incrementarán a medida que los datos vayan creciendo.
Es mejor resolverlos ahora, que todavía estás a tiempo, y no luego, cuando el problema se vuelva mucho más grande.

Resumiendo:
Para que las consultas se puedan optimizar y devuelvan datos seguros sin el uso de funciones innecesarias, es conveniente que ajustes la estructura de tus tablas de modo que esos dos datos (148100 y 0) se encuentren en campos separados, tales que se pueda hacer el JOIN sin problemas y realmente devuelva los datos esperados.
También sería bueno revisar la estructura completa de las tablas implicadas para ver si están cumpliendo al menos la tercera forma normal (3FN) de modo de poder asegurar que la perfomance de las consultas sea mínimamente optima.

El resto es generar las consultas que necesites.

¿Podrías postear la estructura de las dos tablas implicadas y describir un poco qué representa ese valor "0" exactamente, cómo identificas al paciente y qué es lo que representa la ficha (atención o registración del paciente)?