Defining configurable apps when and when not linked to users

[pld]

To deliver a configurable app (for Quest and most custom apps) we need to be able to specify that Questionnaires and potential other FHIR Resources are linked to specific points in the workflow, eg patient registration, patient details view, patient menu expansion, report viewing, etc. Taken as a whole this set of resources will define an "app".

We want to be able to associate an "app" with both:

1. an endpoint or value to be specified in a manually configurable settings field in the smartphone app and
2. a specific Practitioner/user to be loadable on login, maybe directly to the user or to an Organization, Group, CareTeam, or Location linked to that user

Note that for (1) the users needs to be able to enter this when not logged into the app and it should be persisted to the app, not the user. Also note that if there are situations when parts of this configuration are private (which seems reasonable) the user will not only need to specify an endpoint but also some key. This could be defined within the endpoint field or not.

It may be enough to link Questionnaires, if the other resources we need to link are linked to the Questionnaire and through that the point in the workflow. Eg if a registration StructureMap is linked to the registration Questionnaire, and we've linked the registration Questionnaire to the registration point in workflow, we're done, no need to also link the StructureMap to that point directly. However, if there was some reason we wanted to link a StructureMap to a point in the workflow that did not have a Questionnaire or if we cannot link StructureMaps directly to Questionnaires (which seems to be the case at least there nothing explicit in the resource fields of either), we would need to link the StructureMap directly to that point in the workflow.

It's unclear what the best place to store additional metadata that will represents where in a workflow to load the Questionnaire. Identifier certainly seems like a contender, looking at the resource, the below fields seem like reasonable options:

1. identifier (multiple values)
2. publisher (single value)
3. useContext (multiple values)
4. code (multiple values)

In the longer-term I don't think we want to use publisher, since it only stores a single value it won't give us flexibility if we want to define multiple more granular attributes for how to integrate a Questionnaire into the app. More importantly, publishers, like the WHO, etc may want to put their name in the publisher field.

useContext seems like a better fit because we could store an Organization (or Group) as a valueReference and then link users to Questionnaires by putting them in the same Organization (or Group). But I'm not sure how we'd use it to specify where in the workflow to load the Questionnaire, but I guess a stripped down HealthcareService might work? For example, the patient registration for for G6PD might have a useContext value of:

[
  {
    code: 'app'
    value:
      {
        valueReference: [the G6PD organization]
      }
  },
  {
    code: 'workflow`
    value:
      {
        valueReference: [a HealthcareService with only a name field with value "registration"]
      }
  }
]

and in the useContext in each of the forms to be shown on the patient details page:

[
  {
    code: 'app'
    value:
      {
        valueReference: [the G6PD `Organization`]
      }
  },
  {
    code: 'workflow`
    value:
      {
        valueReference: [a `HealthcareService` with only a name field with value "patient-details"]
      }
  }
]

Then in the mobile app, if a user is assigned to the G6PD Organization we'd sync down any forms where the value for the code app matches that Organization.

The mobile would have parts of it's workflow that search through synced Questionnaires to load the correct HealthcareService for that point in the workflow.

Issues to consider:

1. We'd need to handle users that are members of multiple Organizations, we could force the user to select the Organization they are viewing the app for (like Slack does)
2. If you don't have a user account but want to load the app we could let not-logged-in user of the mobile app set an "app" value in a settings view and pull any forms with that app as the Organization

[trevorgowing]

Thanks for sumarizing @pld. I will give it some thought and do some further investigation and follow up with comments.

[pld]

Cool, I'm updating this discussion to clarify the broader issue here is how to configure an app, whether logged in or logged out, which encompasses scope beyond workflow as was made clear by this issue #605

[pld]

These somewhat unstructured notes might be useful background information on what we were thinking to deliver apps through configuration only, https://docs.google.com/document/d/1-8MjzCeo1NJdrVGnhHq1YLInzrs5lHL5QKfrwb0JwMc/edit?disco=AAAANc93v6s

[mberg]

Couple of quick points and questions

• Code doesn't seem like a good option as it's meant to point to a terminology see here

I probably need to jump on a call to understand better on how useContext an work but I agree it feels like the best fit.

Does useContext have to map to a specific resource?

My sense though is doing a pairing of an org and workflow to define a unique app would work well. This would also allow different orgs to publish the same app which I think we could want.

Some other things to consider in all of this.

• Apps currently are only defining which questionnaires and workflows the user has access to. We aren't using the app at this point to determine what data the user has access too. So in effect multiple apps on a shared FHIR instance could access the same data of a patient across apps. Depending on the use case this could be a good or bad thing. We might want to establish if we want to use apps to segment data. One approach is they don't and it's up to you to setup a new FHIR instance if you want to segment data between orgs for example. For health implementations this probably works fine. For more data collection use cases, it may not be possible to fully segment. We might want to consider adding an app id or perhaps the org and workflow (values) above to each questionnaire response and resource generated by the app. We could potentially filter data that way. You may also want to control filters where you can view patients across apps but allow only app based access to the data collected on them. The more I think about it including an app id (which we can ignore / not use) in generated resources could make sense.

[pld]

Cool, thanks for the feedback, I'm aligned with all of this, some thoughts:

• useContext is a field, looks like is a Base metadata field, so it's included in most resources, but some like Binary don't have it. It can only include the info here and can included references to the resources PlanDefinition, ResearchStudy, InsurancePlan, HealthcareService, Group, Location, and Organization.

• on the data point, we definitely need to do some research here. At the QuestionnaireResponse level, we're all set, we can get app segregation through Questionnaire segregation, e.g. if these Questionnaires are in this app and these QuestionnaireResponses are tied to those Questionnaires, they're also in the app.

  • This will (I think?) breakdown when we generate further resources from a QuestionnaireResponse and at the point I agree propagating some kind of app ID makes sense.

Thinking about this as an app ID, makes it sound like useContext isn't necessarily the right place. We could still use that field to define where in the workflow a resource fits, and use the identifier field to store the app IDs. In the original post the Organization is literally the app ID, pros of that are it's easy to link users to and we keep all our info in a single field, cons are is it's not semantic and something feels off about tightly coupling these, like you might want to assign an org TO an app, instead of having an org BE an app.

Walking through how this config architecture would accommodate an extensive use case, like implementing ANC via single-APK/Quest seems like the best next step to make this all more concrete.

[trevorgowing]

I agree, I think the app id approach sounds like a good one and a good way of filtering all resources. In the case of app id I think that identifier would be a better field to use to represent this. I believe the majority if not all resources have an identifier field.

Spot checking a few that assumption seems true.:

• Patient
• Observation
• Encoutner
• StructureDefinition
• RelatedPerson
• Questionnaire
• QuestionnaireResponse
• Binary has securityContext which is reference to another resource. It is not required in the base spec but if we enforce that, we can use the referenced resource to filter the Binaries.

We could implement a standard system whose values are the different applications which we can use as the identifier.

I think that the useContext could work in the context of Quest with the Questionnaires but the app id approach is more universally applicable and would work the extracted resources to.

The question with Quest is, is Quest a single app or would each instance or "deployment" of Quest have it's own id. I think that the latter make more sense.

[trevorgowing]

With respect to Binary resources, we could link them via the securityContext to a Basic resource which has an identifier if no other logical resource existed.

[pld]

Quest is a runner for "apps" so each app, like G6PD, vs ANC, vs G6PD in some specific country, would have a separate app ID.

I want to clarify that if we put IDs in the identifier field this would have to be in addition to useContext (or some other method), not instead of it, because we still need to store the manner in which the resource will be used, e.g. is it a registration form, is it an additional patient details form, is a configuration for the login page, etc.

Also the identifier DataType has a reference to an organization, so if we want we can still use org membership as the way to assign users to apps

[isabelcshaw]

@dubdabasoduba @maimoonak @ndegwamartin chatted with @pld and we'd like to be able to summarize and confirm an approach here on Friday to be able to discuss further with Google Monday.

If you could pls add any additional thoughts and reactions here by your EOD Friday, PLD will plan to synthesize them during afternoon ET. Thanks in advance!

[dubdabasoduba]

UseCase

• Organisation - Ona
• Action
  • Want to get Quest, Load up some Questionnaires in a HAPI server, then use these Questionnaires to collect data about patients.
  • This Data can then be displayed on the patient profile in Quest.
  • They also want to be able to triage a patient and calculate their BMI.
• Workflow
  • Registration.
  • Patient Profile.
  • Patient Triage.

Process

Proposed Use Case Resources (Any Other resources can be added)

• Document Manifest Resource
• Binary Resource
• Questionnaire Resource
• Questionnaire Response Resource
• Patient Resource

How to link the resources

• A Document Manifest is added to be able to track all the other resources that are tied to the organisation. Sample show here.
  • We can reference an Organization from the Documentmanifest. So the different organisations can be represented as actual FHIR organizations

{
  "resourceType": "DocumentManifest",
  "masterIdentifier": "62028e8c-7763-44be-a6a4-b026a010742b",
  "identifier": [
    {
      "use": "official",
      "value": "93bc9c3d-6321-41b0-9b93-1275d7114e22"
    }
  ],
  "status": "current",
  "type": {
    "coding": [
      {
        "system": "<figure-out>",
        "code": "<use-a-code-we-want>",
        "display": "<figure-out>"
      }
    ],
    "text": "WHO App Defination"
  },
  "created": "2021-10-15T12:03:43.181+00:00",
  "author": [
    {
      "reference": "Organization/a741cd5e-5737-4731-908b-957afa91878d",
      "display": "Test Team One"
    }
  ],
  "source": "https://fhir.labs.smartregister.org/",
  "description": "WHO Quest App Defination",
  "content": [
    {
      "reference": "Binary/214",
      "display": "WHO Quest App WorkFlow Points"
    }
  ]
}

• It will contain a masterIdentifier which can be added as an identifier to all the other resources required in the app. The identifier can be added as a temp identifier

{
  "identifier": [
    {
      "use": "temp",
      "value": "93bc9c3d-6321-41b0-9b93-1275d7114e22"
    }
  ]
}

• The content attribute will link to a Binary resource that defines the Resources for each data point. The Binary Resource can hold a JSON with the following structure.
  • resource -- This holds the FHIR resource to be used
  • value -- is the actual id for the a resource or the inferred id (an id that's only know after a selction)
• We can provide a pre-filled JSON template. This will make sure all the workflow points are accounted for.
  • If a workflow point is removed from the JSON then it would mean the workflow is not needed for the app in question.

{
  "title": "WHO Quest App WorkFlow Points",
  "mapping": [
    {
      "registration": {
        "resource": "Questionairre",
        "value": "1eb56ff1-5460-436c-b0f6-2ffa00dbe6ec"
      },
      "bmi":{
        "resource": "Questionairre",
        "value": "c8de0624-5314-45ec-ad83-f894870c9ead"
      },
      "profile":{
        "resource": "Patient",
        "value": "$patient-id"
      }
    }
  ]
}

• The StructureMap resources can hold 3 identifiers
  • official - This is the actual identifier for the Structure Map
  • secondary - This is the identifier for the Questionnaire it is to work with.
  • temp - The masterIdentifer for the DocumentManifest used by the Organization the logged in user belongs to.

{
  "identifier": [
    {
      "use": "official",
      "value": "93bc9c3d-6321-41b0-9b93-1275d7114e22"
    },
    {
      "use": "secondary",
      "value": "300e1eaf-d4c3-4c27-8631-bcc9194903cd"
    },
    {
      "use": "temp",
      "value": "d623023d-cf47-41bc-bef4-6b37252c20aa"
    }
  ]
}

Use Journey

• The System admins (whichever user is allowed to upload the Questionnaires) upload the relevant resources. These are:-

  • The Questionnaires. Should have the masterIdentifier from the DocumentManifest Resource added
  • The Updated JSON, with the correct Questionnaire identifiers. Uploaded via the Binary Resource which should have the masterIdentifier from the DocumentManifest Resource added
  • The DocumentManifest Resource.

• The users then get the apps and either perform the following tasks to select the correct Document Manifest for their organisation.

  • Manually add the DocumentManifest identifier to the app settings.
  • Select the correct DocumentManifest from a screen provided by the app. This means the app will have to load up all document manifests and display them to the users.

• Once the DocumentManifest is selected, the following can happen.

  • The app downloads the Binary linked on the DocumentManifest content attribute.
  • We then fetch all the resources that have the DocumentManifest masteridentifier as a temp Identifier.

• The JSON from the Binary resource will then be used by the apps to know what resources to be loaded at what time.

[dubdabasoduba]

@f-odhiambo Was the idea of having the composition instead do away with the need for custom configs uploaded as binaries?

@maimoonak I think I would like to understand the same about the Library resource usage.

[pld]

Not sure if we'd be able to remove the custom binary configs, it'd definitely be nice, but I don't see it as a requirement, blocker or priority.

If we have an abstraction on the client that converts the custom binary config into JSON, we can replace that loading with reading from a FHIR JSON file in the future if/when we transition to a non-custom format

[maimoonak]

Binary config is just to represent our own custom entity models which android app understands.

Library allows to have Attachment which could be content itself or a reference to Binary (or any other) FHIR Resource so as DocumentManifest. T

he intent was just to highlight that as per FHIR Library is app level and DocumentManifest can be clinical level. For Resources which just define app without any distinction between users or patient Library is a fit but for user/clinical context aware configs Comp/DocM would work. I see that Composition/DocumentManifest can reference any subject from, Patient to Group to Practitioner.

We just need to make a final call on which one to use for our purpose. We can revert later on if we find any glitches but a starting point is important to understand the challenges and further requirements. @pld @dubdabasoduba which one we want to start from? Kindly also consider that we would have a web interface in future which would allow admin to tweak this info (fully or partially)

[dubdabasoduba]

@maimoonak Are you suggesting we convert the files to base64 and use the attachment defination here? The attachment doesn't have a direct reference to Binary resources the only way we can do it is actually building out a URL to a specific Binary resource then add it to the url attribute

Alternatively, we could use the focus attribute of the composition.section. This piece can refer to any resources which mean we can reference Binaries directly. Below is a sample composition with this reference.

{
  "resourceType": "Composition",
  "identifier": {
    "use": "official",
    "value": "93bc9c3d-6321-41b0-9b93-1275d7114e22"
  },
  "status": "final",
  "date": "2021-10-15T12:03:43.181+00:00",
  "author": [
    {
      "reference": "Organization/a741cd5e-5737-4731-908b-957afa91878d",
      "display": "Test Team One"
    }
  ],
  "title": "WHO Quest App Defination",
  "custodian": {
    "reference": "Organization/a741cd5e-5737-4731-908b-957afa91878d",
    "display": "Test Team One"
  },
  "section": [
    {
      "title": "WHO Quest App Defination Workflows",
      "focus": {
        "reference": "Binary/214",
        "display": "WHO Quest App WorkFlow Points"
      },
      "text": "Used to define the app workflows",
      "mode": "working"
    },
    {
      "title": "WHO Quest App Them Definations",
      "focus": {
        "reference": "Binary/215",
        "display": "WHO Quest App Theming"
      },
      "text": "Used to define the app themes",
      "mode": "working"
    }
  ]
}

[maimoonak]

Got it @dubdabasoduba . I see that the focus is a Reference which can only refer to other resources. Its not Attachment (like content in Library) and can not hold data. I think it looks good and is fine to have references as opposed to embedded content which would make the Resource lighter.

[pld]

It's seems like what we do here will be similar (if not equivalent to) an IG or a Profile, https://simplifier.net/guide/profilingacademy/IntroductiontoFHIRandprofiling, it's unclear if we need to consider this now or can adjust for it later. IGs certainly seem like a relevant way to handle the management of apps, i.e. storing the DocumentManifests (or whatever) that define them

[pld]

The work we're discussing for loading apps, especially the nuances of sync that you're pointing out @maimoonak, look like they will overlap with this issue in the Android FHIR SDK, google/android-fhir#253

[maimoonak]

Yes... The rest section of https://www.hl7.org/fhir/capabilitystatement.html refers to that.

[trevorgowing]

Hi Team.

I have been reviewing the G6PD requirements and @f-odhiambo work on mapping the clinical workflow to FHIR.

Although not specifically required by the base spec I think having a ServiceRequest to link all of the resources together makes sense as it provides additional context.

I also agree with @pld comment above that perhaps the G6PD flow should be a profile or an IG. I think it would a great contribution to develop this together with PATH.

There is obviously a bit of a chicken and egg situation here, whether we define the profile/IG first or build the app first. I think there are pros and cons in either direction. I am guessing based on where we are we would have to go with app first though and then potentially follow with the spec.

I think that there is value in extracting the resources from the QuestionnaireResponse so that they can be synced to the server even though we don't necessarily need them to provide the Practitioner feedback in app.

I also think it makes sense for the RIM to use the Patient and extracted Observation resources as inputs rather than using the QuestionnaireResponse directly as I think this decouples it from the Questionnaire.

I know there are many ongoing conversations around Single APK and Quest etc so apologies if anything I have said hasn't considered all of the context. But I thought that I would share my thoughts since I had put in the effort to understand the flow.

[pld]

Yea we don't have time to do the IG first, we can track anything we're doing that would be not in-scope for an eventually IG and see if we can reframe to be in-scope, I don't think there is anything now.

Can't we sync QuestionnaireResponse themselves back to the server?

We'd also want to have StructureMaps (or other method if only a single resource is needed) as part of the DocumentManifest to do some of the resource extraction post g6pd Questionnaire submission.

[trevorgowing]

Cool. I thought that would be the case.

Yes, from the reading I have done around SDC extraction they do recommend storing both the QuestionnaireResponse and the extracted resources. That way if there is anything that is unclear in the resources the original source of the data, the QuestionnaireResponse can be reviewed to provide additional context.

What is the reason for wanting to extract the resources later rather than at QuestionnaireResponse time?

[pld]

Sounds good, I didn't mean to imply that, it can be at the same time and I think that makes sense, just noting all these things are triggered after data is submitted to a Questionnaire 1) we create a QuestionnaireResponse always 2) we look for related extraction definitions and process those, maybe we do (2) before (1), maybe they're the same thing for some reason, I don't know the implementation at that level of detail, only that we want both to happen :)

[pld]

NB this discussion has a nice overview of the different types of extraction, #433

[pld]

For reference this is the g6pd questionnaire, https://turn-fhir.smartregister.org/fhir/Questionnaire/3440

[dubdabasoduba]

Composition Resource Approach

UseCase

• Organisation - Ona
• Action
  • Want to get Quest, Load up some Questionnaires in a HAPI server, then use these Questionnaires to collect data about patients.
  • This Data can then be displayed on the patient profile in Quest.
  • They also want to be able to triage a patient and calculate their BMI.
• Workflow
  • Registration.
  • Patient Profile.
  • Patient Triage.

Process

Proposed Use Case Resources (Any Other resources can be added)

• Composition Resource
• Binary Resource
• Questionnaire Resource
• Questionnaire Response Resource
• Patient Resource

How to link the resources

• A Composition Resource is added to be able to track all the other resources that are tied to the organisation. Sample show here.
  • We can reference an Organization from the Composition Resource. So the different organisations can be represented as actual FHIR organizations
  • NB:- The composition resource only allows one identifier object.

{
  "resourceType": "Composition",
  "identifier": {
    "use": "official",
    "value": "93bc9c3d-6321-41b0-9b93-1275d7114e22"
  },
  "status": "final",
  "date": "2021-10-15T12:03:43.181+00:00",
  "author": [
    {
      "reference": "Organization/a741cd5e-5737-4731-908b-957afa91878d",
      "display": "Test Team One"
    }
  ],
  "title": "WHO Quest App Defination",
  "custodian": {
    "reference": "Organization/a741cd5e-5737-4731-908b-957afa91878d",
    "display": "Test Team One"
  },
  "section": [
    {
      "title": "WHO Quest App Defination Workflows",
      "focus": {
        "reference": "Binary/214",
        "display": "WHO Quest App WorkFlow Points",
        "type": "form_configurations"
      },
      "text": "Used to define the app workflows",
      "mode": "working"
    },
    {
      "title": "WHO Quest App Them Definations",
      "focus": {
        "reference": "Binary/215",
        "display": "WHO Quest App Theming",
        "type": "application_workflow"
      },
      "text": "Used to define the app themes",
      "mode": "working"
    },
     {
      "title": "WHO Quest App Registration Questionairre",
      "focus": {
        "reference": "Questionairre/215",
        "display": "WHO Quest App Registration Questionairre"
      },
      "text": "",
      "mode": "working"
    }
  ]
}

• The section attribute will link to all the resources that the app will need to download for configuration and use. The section will hold a JSON with the following structure.

  • title -- This will hold the human-readable title of the section reference
  • focus -- Will hold the resources that each section object is referencing.
    • This section holds the following attributes
      • reference -- Has the literal reference to a resource
      • display -- Has the human-readable text for reference.
      • type(Optional) -- Will be used to identify the exact workflow that the Binary resource will use. e.g application_workflow This is a BInary resource that will be used to define the workflows that will use the binary resource referenced.
  • text -- Human-readable description of the section usage.
  • mode -- This is to identify whether the section object can be used for references. The status has to be working for the app to download the referenced resources.

• Below are samples of the workflows that the app currently uses.

application_workflow

[
  {
    "appId": "covax",
    "title": "EIR Covax app workflow",
    "mapping": [
      {
        "workflowPoint": "registration",
        "resource": "RegisterViewConfiguration",
        "classification": "patient_register",
        "description": "Configurations for patient register"
      },
      {
        "workflowPoint": "immunization_profile_view",
        "resource": "ImmunizationProfileViewConfiguration",
        "classification": "immunization_profile",
        "description": "Configurations for immunization profile "
      },
      {
        "workflowPoint": "login",
        "resource": "LoginViewConfiguration",
        "classification": "login",
        "description": "Configurations for login"
      }
    ]
  }
]

form_configurations

[
  {
    "appId": "covax",
    "form": "patient-registration",
    "title": "Add Patient",
    "identifier": "207"
  },
  {
    "appId": "covax",
    "form": "record-vaccine",
    "title": "Record Vaccine",
    "identifier": "800"
  },
  {
    "appId": "jnj",
    "form": "patient-registration",
    "title": "Add Patient",
    "identifier": "754"
  },
  {
    "appId": "jnj",
    "form": "record-vaccine",
    "title": "Record Vaccine",
    "identifier": "800"
  },
  {
    "appId": "jnj",
    "form": "adverse-event",
    "title": "Adverse Event",
    "identifier": "1568"
  }
]

Use Journey

• The System admins (whichever user is allowed to upload the Questionnaires) upload the relevant resources. Examples of these resources can be Questionnaires, Binary Resources e.t.c

  • They then write up a Composition and add the references to the uploaded resources to the section attribute of the Composition Resource.
  • They also record the Composition ID for sharing with users later.

• The users then get the apps and either perform the following tasks to select the correct Composition Resource for their organisation.

  • Manually add the Composition Resource id to the app settings.
  • Select the correct Composition Resource from a screen provided by the app. This means the app will have to load up all Composition Resources and display them to the users.

• Once the Composition Resource is selected, the following can happen.

  • The app downloads all the Resources linked on the Composition Resource section attribute.
  • For Binary Resources, the app will use the type attribute to know where each of the binary files will be used in the app workflow.

[dubdabasoduba]

@dubdabasoduba not sure how familiar you are with profiling, but it looks like slicing can give us a useful way to define list items in whichever resource we end up basing the app definition on, https://www.hl7.org/fhir/profiling.html#slicing

@pld Not really let me read on it then revert.

[dubdabasoduba]

Cool, I'm not clear on why we need a reference to a Bundle or DocumentReference. The structure @dubdabasoduba has here looks like it manages what we need using only the Composition, #594 (comment)

@pld @f-odhiambo I think the composition resource works better.

What about using only a Bundle instead of Composition? Would that have enough detail to give us what we need here, i.e. could it replicate what @dubdabasoduba laid out in the Composition above?

@pld the bundle wouldn't provide better attributes for this as compared to the composition.

[pld]

OK I think that's reasonable and we can go ahead with the Composition resource.

The semantic definition for why it's appropriate to use this resource is that the definition of a healthcare mobile app is an instance of

A set of healthcare-related information that is assembled together into a single logical package that provides a single coherent statement of meaning, establishes its own context and that has clinical attestation with regard to who is making the statement.
as stated in the definition of a Composition resource

[pld]

I think we will want to write a Profile for the Composition resource that is a "health app Profile", that says:

• every app must have these sections in this order,
• sections with this content must exist,
• these other fields should not exist.

A Profile is like sub-class or sub-interface of the FHIR resource it is based on. You can also re-profile your an existing profile. This is appropriate if there are specific and deterministic differences in the content for a certain type of app, e.g. a "CHW app Profile" could be a re-profile of the "health app Profile".

We don't need to do this right now, in fact we'd probably be better off doing it after testing some Composition app definitions in the wild a bit, but we should do it soon.

[pld]

Some other bits of profile that seem quite relevant for us:

• Must Support -- for any element or in the IG that includes the profile you can specify how the system using the profile should support the element, like it must be in the UI etc
• Search Critera -- enabling search criteria on elements and extensions, and on combinations of elements

Also, this Task profile from the US DAF (data access framework) research profile is a great example of profiles, you can compare it to the defaut FHIR Task. If you hit "Differential Table" in the first link you can see all the fields that the profile modifies, looks like mainly setting cardinality

[dubdabasoduba]

Composition with Parameter Resources instead of Binary Resource

{
  "resourceType": "Composition",
  "identifier": {
    "use": "official",
    "value": "93bc9c3d-6321-41b0-9b93-1275d7114e22"
  },
  "status": "final",
  "date": "2021-10-15T12:03:43.181+00:00",
  "author": [
    {
      "reference": "Organization/a741cd5e-5737-4731-908b-957afa91878d",
      "display": "Test Team One"
    }
  ],
  "title": "WHO Quest App Defination",
  "custodian": {
    "reference": "Organization/a741cd5e-5737-4731-908b-957afa91878d",
    "display": "Test Team One"
  },
  "section": [
    {
      "title": "WHO Quest App Defination Workflows",
      "focus": {
        "reference": "Parameters/214",
        "display": "WHO Quest App WorkFlow Points",
        "type": "form_configurations"
      },
      "text": "Used to define the app workflows",
      "mode": "working"
    },
    {
      "title": "WHO Quest App Them Definations",
      "focus": {
        "reference": "Parameters/215",
        "display": "WHO Quest App Theming",
        "type": "application_workflow"
      },
      "text": "Used to define the app themes",
      "mode": "working"
    },
     {
      "title": "WHO Quest App Registration Questionairre",
      "focus": {
        "reference": "Questionairre/215",
        "display": "WHO Quest App Registration Questionairre"
      },
      "text": "",
      "mode": "working"
    }
  ]
}

[mberg]

Can we add support for a version.