Activity Element

The Activity element represents a visit or appointment that the household participated in. Activities are part of the main Household and there are two types with differing required elements. Both types allow an external UUID to be specified, however this is optional.

If the UUID is set and the activity already exists it will not be updated during import.

Types of Activity

Visit Type

A basic, simple visit has the type attribute set to "visit" and requires the following elements:

  • Organization
  • VisitDate
  • Participants
  • type attribute

Appointment Type

An appointment has the type attribute set to "appointment" and requires the following elements:

  • Organization
  • ScheduledVisitDate
  • Participants
  • type attribute
  • status attribute

There are additional rules concerning the VisitDate. This is required if the type is "visit", however if the type is "appointment" then ScheduledVisitDate.

If the appointment status is set to "completed" then the VisitDate becomes required. There is an optional element: CompletedAt that allows a specific date/time to be recorded for when the appointment was collected, otherwise the visit date will be used.

Optional Activity Elements

The following are optional elements for each activity and generally are not needed:

Basic Activity

The most basic activity that can be recorded has the following structure:

Error rendering macro 'code': Invalid value specified for parameter 'firstline'
<Activity type="visit">
    <Organization uuid="..."/>
    <VisitDate>2015-07-23</VisitDate>
    <Participants>
        <Participant uuid="123" primary="true"/>
    </Participants>
</Activity> 

The organization must be one of the UUIDs of the agencies setup in your Network.

The date must include leading zeroes and be separated by hyphens.

The participants identifies which household members took part / received services for this visit. If there is only a single household member, this field must still be completed. The UUID of the person must match one of the Person UUIDs (see UUID Requirements and Format).

Activities can only be used with fully valid UUIDs for each Person. These elements must match and cannot be integer sequences. Invalid UUID strings will fail during import.

Basic Appointment

The most basic appointment type activity has the following structure:

Basic Appointment Activity
<Activity type="appointment" status="pending">
    <Organization uuid="..."/>
    <ScheduledVisitDate>2015-07-23T15:30:00-05:00</ScheduledVisitDate>
    <Participants>
        <Participant uuid="123" primary="true"/>
    </Participants>
</Activity> 

Completed Basic Appointment

In the Link2Feed system, appointments are not part of the visit history until they have been completed. Only once they are completed is a visit record generated and added to the reporting system. If an appointment is marked as completed, then a visit can be created for it during import. This is an optional step and the actual visit can be defined with the appointment if preferred.

The basic structure for a completed appointment is:

Completed Appointment Activity
<Activity type="appointment" status="collected">
    <Organization uuid="..."/>
    <ScheduledVisitDate>2015-07-23T15:30:00-05:00</ScheduledVisitDate>
    <VisitDate>2015-07-23</VisitDate>
    <CompletedAt>2015-07-23T15:37:14-05:00</CompletedAt>
    <Participants>
        <Participant uuid="123" primary="true"/>
    </Participants>
</Activity> 

The status is set to collected and the VisitDate is added. In this example the CompletedAt has also been specified, though this element is not required.

Note: in both examples for the appointment, the scheduled time and collected time are full dates and times with the timezone offset specified. Remember that all date/times in Link2Feed are stored in UTC and converted, so either convert your date/times to UTC or add the appropriate timezone offset.

Participants

Every activity must have at least one Participant defined in the Participants element. Even if there is only a single person, this must still be referenced on each Activity. The Participant person attribute must match a Person UUID attribute. If there is no match, the import will fail.

Multiple participants can be referenced per activity, but only one should be marked as the primary visiting Person.

Participant includes an optional element:

  • Person

This is a complete Person profile (including sub-information) and is intended to represent the Person at the moment in time of the visit.

Participant -> Person is not currently supported during import.

Provision / Provided Items

If the network records items / food provided these can be defined for each activity in the Provisions element. This is a collection of ProvidedItem elements that require the following items:

  • Quantity
  • type attribute

Quantity is number of the type provided.

Type is defined in the XSD and is generally the food, item or service provided. If the Network tracks total quantity provided, there will be a special type the name of which will depend on the Network, but is typically: Quantity or XX of Food Supplied where XX could be Days, Lbs, Kgs, Hampers, Items, Points, Bags or some other unit. The Quantity in this case is the total amount of XX provided so if 20 lbs of food was provided the Quantity would be 20.

Here is an example activity with some ProvidedItems:

Activity with Provisions
 <Activity type="visit">
    <Organization uuid="..."/>
    <VisitDate>2015-07-23</VisitDate>
    <Participants>
        <Participant uuid="123" primary="true"/>
    </Participants>
    <Provisions>
        <ProvidedItem type="Quantity">
            <Quantity>120</Quantity>
        </ProvidedItem>
        <ProvidedItem type="Canned Goods">
            <Quantity>1</Quantity>
        </ProvidedItem>
        <ProvidedItem type="Dried Food">
            <Quantity>1</Quantity>
        </ProvidedItem>
        <ProvidedItem type="Baby Items">
            <Quantity>1</Quantity>
        </ProvidedItem>
    </Provisions>
</Activity>

The type should only be used ONCE per activity - this is especially important for the Total Provided.

If individual quantities are not tracked by your network, the Quantity is still required, simply use 1 (one) to indicate that the item was provided.

Program Element

This element is intended for advanced and Link2Feed usage!

By default, when Activities are imported, they can only be imported to a single program that has been defined for the Organization specified in the Activity. If you need to import multiple visits that belong to different types of program e.g.: food bank, meal program, resume clinic; then you will need to specify the specific program this information belongs to. Without it the import will fail as the datas location cannot be determined.

The program element references a UUID for a program setup within Link2Feed. Programs are specific to Agencies and are assigned to a specific Module (e.g. Appointment, Generic etc). Data can only be imported to programs that have been created for you as part of the Network setup process.

Program UUIDs are not part of the XSD at the time of writing. Please contact Link2Feed for further information if this is a requirement for import.

ReferredTo Element

If referrals are being tracked in your Network, you can specify where the primary person was referred for each activity. The referral types are defined in the XSD. If there are no values in the XSD referrals cannot be tracked and should be left out.

The structure for referrals is:

ReferredTo Element
<ReferredTo>
    <Referral>Some Referral Agency</Referral>
</ReferredTo>

VisitReasons Element

Similar to ReferredTo, VisitReasons allows the reasons for this visit to be recorded. This must be enabled on the Network and again: if not defined in the XSD cannot be used.

The structure is similar to ReferredTo:

VisitReasons Element
<VisitReasons>
    <VisitReason>benefits_social_assistance_delays</VisitReason>
    <VisitReason>family_breakup</VisitReason>
</VisitReasons>Â