Method or helper function to return objects from EntityFramework with Linq
Besides the naming that should more C# friendly (PascalCase), the application should have a clear separation between data models and view models. 

Data models are usually generated automatically in database first scenarios or POCOs classes defined by the programmer (code-first approach) and should be separated from view models or data returned by the service layer which usually consists in aggregated information.

Ok, for your particular case, data model is Patient:

public partial class Patient
{
    public DateTime BirthDate { get; set; }
    public String City { get; set; }
    public String Cpatient { get; set; }

    // rest of properties come here
}


and your view model can be called PatientViewModel:

public partial class PatientViewModel
{
    public DateTime BirthDate { get; set; }
    public DateTime BirthDateStr 
    { 
        get { return BirthDate .ToShortDateString(); }
    }

    public String ChartNumber { get; set; }
    public ChartRecid { get; set; }
    public String City { get; set; }
    public String Cpatient { get; set; }
}


So, as you can see, the view model hold the properties required by the view, which are aggregated from multiple data models.

Getting data model extra data

One method I found convenient (although not exactly orthodox, since it pollutes data models) is to extend the data model with properties that provide extra needed data, like this:

// this is another part of the partial class
public partial class Patient
{
    public String ChartNumber 
    { 
       get { return Chart.chart_number; }
       set { Chart.chart_number = value; }
    }

    public ChartRecid 
    { 
       get { return Chart.ChartRecid; }
       set { Chart.ChartRecid = value; }
    }

    // other "computed" properties come here
}


An alternative to this approach is to have custom map these properties when transferring data model -> view model and vice-versa (so, this also supports data persistence, not just data fetch).

Actual mapping

As already suggested, AutoMapper was specially designed for this kind of chores. Its usage is simple as:

setup the mapping:

(this is deprecated in the last version, as described here (and also mentioned by the compiler, if last NuGet package is referenced))

Mapper.CreateMap&lt;Patient, PatientViewModel&gt;();
Mapper.CreateMap&lt;PatientViewModel&gt;();


using it:

var patientDataModels = ctx.patients.
   .Include(p =&gt; p.Chart)               // eager load chart data
   .Where(p =&gt; cpatient == cpatient)
   .ToList();                           

var patientVms = new List&lt;PatientViewModel&gt;();
// Mapper should also handle collection mapping automatically, if type mapping is set up
Mapper.Map(patientDataModels, patientVms);

// if data model is not extended, you have to manually map Chart type properties


Eager load is recommended to avoid separate queries generated when Chart object properties are required (less SQL verbosity, significantly faster for large collections).

AutoMapper will automatically map properties having the same (and type, if type is different and no implicit conversion can be done, it will throw an exception) and not ignored (IgnoreMap attribute).