FHIR Chat · which profiles go into CapabilityStatement.profile? · implementers

Stream: implementers

Topic: which profiles go into CapabilityStatement.profile?

Sebastiaan Raap (Jul 24 2019 at 11:47):

hello! I have a server which only job is to receive four different fhir documents, nothing else. I've declared the Composition profiles in CapabilityStatement.document.profile .

In these fhir documents there could be many Observations, conditions, deviceUseStatements etc. Do we declare all the possible Observation- and Condition profiles in CapabilityStatement.profile?

Or do we declare the Compositionprofiles double: In CapabilityStatement.document.profile and in CapabilityStatement.profile?

Or should we leave CapabilityStatement.profile empty?

Thanks in advance

Lloyd McKenzie (Jul 24 2019 at 13:02):

document.profile should only point to your Composition profile (which should ideally point to other profiles for the things allowed as entries, etc.

Lloyd McKenzie (Jul 24 2019 at 13:02):

Composition.profile identifies the profiles you'll recognize in instances and will allow searches on. If you don't require/look for/allow search on your Observation profiles, no need to list them.

Sebastiaan Raap (Jul 24 2019 at 13:04):

OK thanks!

What to do with CapabilityStatement.document.profile in my usecase?

Lloyd McKenzie (Jul 24 2019 at 13:27):

Ideally you should have a profile for your Composition that defines the sections and entries allowed in your document, identifies the Composition.code, etc.

Sebastiaan Raap (Jul 24 2019 at 13:57):

Yes, we have a Composition profile which points to the resources that have to/can go into the fhir document. But if I understand you correctly, I should point twice to the same profile in the CapabilityStatement? So if I just want my server to receive and handle one kind of FHIR document, my capabilitystatement should look like this(?):

    "resourceType":"CapabilityStatement",
    "url":"http://nictiz.nl/fhir/CapabilityStatement/eoverdracht-servercapabilities-phase-one",
    "version":"1.0.0",
    "name":"eOverdrachtServer-phase-one",
    "kind":"requirements",
    "fhirVersion":"3.0.1",
    "acceptUnknown":"both",
    "format": [
        "application/fhir+xml",
        "application/fhir+json"
    ],
    "profile": [
        {
            "reference":"http://nictiz.nl/fhir/StructureDefinition/eOverdrachtAanmeldbericht-phase-one",
            "display":"Composition-eOverdrachtAanmeldbericht-phase-one"
        },
    ],
    "document": [
        {
            "mode":"consumer",
            "profile":{
                "reference":"http://nictiz.nl/fhir/StructureDefinition/eOverdrachtAanmeldbericht-phase-one",
                "display":"Composition-eOverdrachtAanmeldbericht-phase-one"
            }
        }
    ]
}

thank you for your help

Lloyd McKenzie (Jul 24 2019 at 17:38):

The capability statement would only need to declare document.profile. It could declare the CapabilityStatement.profile only if there was an expectation to be able to search the REST endpoint by that profile or will be checking declarations of that profile that are present in instances.

Sebastiaan Raap (Jul 25 2019 at 07:10):

thank you

Last updated: Apr 12 2022 at 19:14 UTC