As mentioned supra, the Belgian federal profiling effort considers all published rules or constraints defined by HL7 on the FHIR resources strictly as an integral part of the standard and as such, they SHALL be followed unless otherwise defined.

Any guidance presented in this guide is not meant as an exhaustive description of the FHIR standard. Rather, the guidelines presented here list some specific points of attention.

Unless stated otherwise, we consider the mapping between KMEHR elements and the corresponding elements in FHIR resources to be overall self-evident. Any mapping initiative SHOULD consider the fact the approach of information in a KMEHR element as part of an XML document is fundamentally different from a modular FHIR resource.

Some particularities in this context are described in the definitions or comments within the artefacts published in this guide when deemed necessary. Note the direction in this is how to functionally express that what is in KMEHR in FHIR, not the other way around. Attention points that could not directly be incorporated in the seperate artefacts follow here.

As the FHIR specification is very developer friendly, there will be no public delivery of FHIR validation or visualisation tools by the eHealth Platform. Developers are encouraged to enjoy the speed and abundance of the existing FHIR eco system, which existence is indeed one of the rationales behind the choice for FHIR.

As a general principle for implementers, please note Postel's Law is quoted on the HL7 FHIR pages.

More specific infos: