Full description with examples at https://github.com/chrisgrenz/FHIR-Primer/wiki/Profiled-FHIR.

Profiled FHIR has been hinted at since early in the FHIR publication process. We propose the following:

1. Implement distinct MIME types for profiled FHIR to differentiate this representation from unprofiled FHIR documents:

• application/xml+fhir+profiled

• application/json+fhir+profiled

2. The standard XML/JSON conversion rules apply to profiled FHIR

3. Profiled FHIR will match un-profiled FHIR except:

• Named slices will be promoted to first class elements using the element name.

• Extensions will be "collapsed" into a single element rather than the current extension+value[x] pair

This format is intended to compliment the standard application/xml+fhir and application/xml+json formats and will provide a standard and predictable wire format for those needed this functionality. It is not a breaking change.

Use Cases:

Apps - applications can operate on extensions and named slices (business defined distinctions) as first class elements in reads and writes.

Analytics - Currently there is no way for a client to have the server apply a profile and communicate what element definition from the profile applies to each element of the resource instance. Profiled FHIR allows downstream information systems to use a business profile, applied by the FHIR infrastructure, to describe its data. For instance, a profile may slice Patient.identifier by system into SSN and MRN. The downstream system, using Profiled FHIR, would not have to re-apply the discrimination logic as these identifiers would be provided with those element names.