It looks like you are confusing your underlying model objects with your API resources, they are not necessarily mutually exclusive. If you are simply serializing your classes as JSON, you going to duplicate content (and get the profile appearing several times) which is not needed and a smell.

You could:

Create specific resource models that represent your resources better (kind of like View Models in a MVC Framework). So you could create model objects such as PatientResource, XRayResource and a AllergyResource (you don’t have to suffix the name Resource here, they could just sit somewhere separately to your other models). that better represent what your clients need to consume instead of every property of the domain model.

c# here:

public class PatientResource
{
    public int Id { get; set; }
    public IEnumerable<AllergyResource> Allergies { get; set; }
    public IEnumerable<XrayResource> XRays { get; set; }
}

public class AllergyResource
{ 
    public int Id { get; set; }
    public string Name { get; set; }
    public int ProfileId { get; set; }
}

public class XrayResource
{ 
    public int Id { get; set; }
    public string Name { get; set; }
    public int ProfileId { get; set; }
}

All very basic, the allergy and xray resource do not hold profile objects, they hold a reference id for a profile, even that would look slightly out of place, so you may need to restrict some properties depending on where your data is consumed, for example, do you really need to show an profileId if you are representing an AllergyResource in the AllergyResource collection of a PatientResource, probably not, so for that serialization you would omit that property. However, if you were in a standalone AllergyResource you would probably like to show the reference.

I like to use links in my API’s

I don’t really know what flavour of API you are creating (RESTFul, RPC, HATEOS etc) so this may not apply. I mainly deal with REST style (some may not be REST in the truest sense of the word) but when i am building an API i like to be a succinct as possible with my response objects but give the clients the ability to discover linked resources via links. This can be as complicated or simple as you like, you can use JSON or a more specific media type like HAL+JSON but the point is, you send your resources down the wire, and you enable the discover-ability of related resources via standard HTTP links.

BasecampX as an example: where they have a person, but the todo list is available at another resource endpoint which is specified in response. The objects are simplified but it does make calling the API more verbose in that multiple requests are required. It really depends on how your clients will consume the data and work with it.