Profile

https://publicschema.org/Profile

draft abstract

A point-in-time record of data collected about a subject using a defined instrument. Profile is the shared supertype for SocioEconomicProfile and FunctioningProfile within PublicSchema, and for additional profile subtypes published in a sibling schema (see ADR-011). Each profile captures who was observed, when, using which instrument, under which administration mode, and by whom. A profile records the structured responses from a single administration, and may also carry outputs derived from those responses by applying the canonical scoring rule for the instrument. Non-canonical scoring, alternate thresholds, a different rule version, or recomputation after the canonical rule is revised, is captured as a ScoringEvent rather than written back to the profile.

JSON-LD JSON Schema CSV Definition (Excel) Template (Excel)

Supertypes

Event

Properties

Property Type Definition
Identifiers from Event concept:Identifier
Identifiers carried by this entity, such as national ID numbers, program IDs, or identifiers asserted by an identity document.
Subject concept:Party includes Person, Group, Household, Family, Farm
The person or group that the profile or scoring event is about. Ranged at Party (not Agent) because Profiles observe receivers: persons and organised groups of persons (Household, Family, Farm). Institutional actors (Organizations) are described through their own Organization records, not as subjects of a Profile.
Observation date date
The date on which the profile data was collected (when the instrument was administered or the measurement taken).
Performed by concept:Agent includes Person, Organization, SoftwareAgent
The agent (enumerator, field officer, or agency) accountable for administering the instrument or taking the measurement. Typically a Person or an Organization. When a software tool captured or derived the data, record it separately as software_used; performed_by identifies who is responsible, not what ran the capture.
Instrument used concept:Instrument
Reference to the instrument (survey form, questionnaire, screening protocol, measurement procedure) administered in this profile record.
Software used concept:SoftwareAgent
The software that performed this step, recorded so the result can be reproduced or audited. Distinct from the accountable evaluator or performer (the person or organisation responsible), which is recorded separately.
Administration mode string (administration-mode)
How the instrument was administered to the subject: self-report, proxy-report (someone else answering about the subject), assisted (the subject answering with help), or mixed. Washington Group analytical guidance recommends disaggregating prevalence by administration mode because proxy responses systematically underreport difficulty.
Respondent concept:Person
The person who provided the answers to the instrument, when different from the subject. Required whenever the administration mode is proxy or assisted.
Respondent relationship string (relationship-type)
The relationship of the respondent to the subject (parent, spouse, guardian, caregiver, etc.). Uses relationship-type because it describes a person-to-person relationship, not a role within a group. Required whenever the administration mode is proxy or assisted.
Items asked string
The PublicSchema property IDs that were actually asked during this administration. Lets adopters distinguish items that were asked and declined (answer absent) from items that were not asked at all. When omitted, the item set is assumed to be the default item_set of the instrument used. The intended producer is the form compiler or collection server, which populates this list from the form definition at submission time.

Evidence

Not yet found in mapped delivery systems.

Profile is a PublicSchema abstract supertype; no mapped system exposes a profile supertype by that name, so system_count is reported as 0/6 per the convention stated in design-principles.md section 3. FHIR models instrument administration as a first-class record (QuestionnaireResponse, Observation), which is the closest supertype-level analogue; the other five mapped cores (DHIS2, OpenCRVS, OpenSPP, openIMIS, DCI Core) flatten observation data into the subject record. The observation pattern is nonetheless how domain tools model this data outside MIS cores: DHS and MICS store responses as separate survey records, CommCare CMAM keeps nutrition measurements on a visit form, and Washington Group analytics tabulate from raw item responses, not Person flags. DCI's SocioEconomicProfile is the closest peer in social protection and names the pattern explicitly. Convergence evidence for the abstract sits with the concrete Profile subtypes (FunctioningProfile, SocioEconomicProfile, and domain-specific extensions in sibling schemas).

Standard Equivalent Match
FHIR R4 QuestionnaireResponse close
FHIR QuestionnaireResponse is the canonical peer for a single administration of a data-collection instrument. Our Profile is abstract and splits by instrument family; FunctioningProfile and SocioEconomicProfile align most closely because they serialize as a single QuestionnaireResponse.

Referenced by this concept

See full reference catalogue