General data guidelines
This section outlines general requirement for data ingested into the Smart4Health platform, including existing limitations that cannot be captured directly in the profiles.
Supported FHIR resource types
To ensure the quality of data, the set of resources that can be ingested via Smart4Health ingestion pipelines is currently restricted to the resource types that are profiled or discussed in this implementation guide. The following resource types can be ingested via ingestion pipelines:
- AllergyIntolerance
- Condition
- Device
- DocumentReference
- Encounter
- Medication
- MedicationStatement
- Observation
- Organization
- Patient
- Practitioner
- PractitionerRole
- Provenance
- QuestionnaireResponse
For resources of these types, the ingestion pipeline will check that they conform to the corresponding Smart4Health profiles (if defined); if multiple profiles are available, will check conformity to the relevant sub-set.
Client sending data directly to the Smart4Health platform using the SDK are responsible for verifying that the data conforms to the relevant profiles - as the data is encrypted before upload, no server-side validation is possible. Such clients can also technically upload resources instances for any of the resources types supported by the platform (see below), whether or not they are discussed in here. However, if implementers plan to use resource types not included by this implementation guide, they should bring this up with the relevant groups in Smart4Health to ensure that any needed profiles are created.
The underlying Smart4Health platform technically supports a larger set of FHIR resource types than discussed in this implementation guide. However, as the Smart4Health data exchange also needs to run seamlessly on mobile devices with limited storage and processing power, not all resource types are currently supported. The currently supported resource types are:
- AllergyIntolerance
- CarePlan
- CareTeam
- CodeSystem
- Condition
- Consent
- Device
- DeviceUseStatement
- DiagnosticReport
- DocumentReference
- Encounter
- FamilyMemberHistory
- Goal
- Immunization
- Location
- Medication
- MedicationRequest
- MedicationStatement
- Observation
- Organization
- Patient
- Practitioner
- PractitionerRole
- Procedure
- Provenance
- Questionnaire
- QuestionnaireResponse
- ResearchSubject
- ServiceRequest
- Specimen
- Substance
- ValueSet
The set of supported resources will be extended as required by use cases.
Uploaded data should not contain non-supported resource types. Data containing such resource types may cause errors upon ingestion and contained resources (those embedded directly in other resources) may be lost.
Using the platform user ID to referring to the user
For information about using the platform user ID to refer to the user, please see the documentation of the corresponding code system.
FHIR extensions and modifier extensions
General FHIR extensions on complex data element (e.g. at the top level of a resource) are supported. However, extensions on primitive data elements are currently not supported. Such primitive element extensions should not be used - they will not prevent an upload, but will be lost in the process.
Furthermore, modifier extensions are not allowed anywhere in uploaded resources. Resources containing modifier extensions will be rejected. This is being done because such extensions can completely change the meaning of the data in the resource, posing a significant danger to data consumers that do not know the meaning of the extension in question.