This page is part of the MII Implementation Guide PRO (v2027.0.0-ballot.1: 2027 Ballot 5) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Profiles

Abstract Profiles

The MII PRO module defines abstract profiles that serve as the basis for all PRO implementations. These profiles are marked abstract = true and are not intended to be instantiated directly. They establish the common structures and behaviours that instrument-specific profiles must extend. The two profiles for Questionnaire and QuestionnaireResponse inherit from the SDC specification, while the two score profiles for Observation and ObservationDefinition inherit directly from the FHIR specification.

Why Abstract Profiles?

Abstract profiles ensure that common structures are used consistently across all implementations while preventing the creation of incomplete or generic instances. Every PRO instrument must define a concrete profile that inherits from these abstract profiles and adds the instrument-specific detail.

Overview

Profile	Resource type	Base	Description
MII_PR_PRO_Questionnaire	Questionnaire	SDC Questionnaire	Basis for all PRO questionnaires
MII_PR_PRO_QuestionnaireResponse	QuestionnaireResponse	SDC QuestionnaireResponse	Structure of completed questionnaires
MII_PR_PRO_Score_Blueprint	ObservationDefinition	FHIR R4	Templates for PRO score definitions
MII_PR_PRO_Score_Instance	Observation	FHIR R4	Concrete score observations

Inheritance Hierarchy

The abstract profiles form the basis of a clear inheritance hierarchy:

Implementation Rules

Because these profiles are marked abstract, the following rules apply:

1. No direct instantiation: FHIR servers should reject the creation of resources that reference an abstract profile directly
2. Inheritance required: every PRO instrument must define concrete profiles that inherit from the abstract ones
3. Complete specification: concrete profiles must give every abstract element a concrete value or constraint
4. Validation: validators check that instances reference only concrete profiles

Benefits

Using abstract profiles offers several benefits for the MII PRO module:

• Consistency: all PRO implementations follow the same base structure
• Type safety: prevents the creation of incomplete generic instances
• Maintainability: changes to shared structures happen centrally in the abstract profiles
• Clarity: a clear separation between base infrastructure and concrete implementations
• Interoperability: generic processing is possible thanks to the shared abstract base

Migrating Existing Implementations

Existing implementations already using these profiles need adjusting:

1. The abstract profiles themselves are marked abstract = true
2. Concrete instrument profiles remain unchanged (they already inherit from the abstract profiles)
3. Instances must reference concrete profiles, not the abstract ones
4. Validation should be updated to check the abstract constraint