HL7 FHIR provides different means to assign persistent identifiers to FHIR resources. See FHIR identifiers and FAIR principles on IDs for more details. 

The page Metadata and data describes some of the challenges in implementing distinct data and metadata by using HL7 FHIR.

Depending on the usage context and on the kind of metadata to deal with, implementers may choose different means , including a partial fulfillment of the requirement or the adoption of hybrid solutions (FHIR and non-FHIR).

Given that FHIR provides means to uniquely identify resources, the key point of this requirement is a clear identification of what a metadata is (see also the page Metadata and data ).

If there are no doubts that metadata are the “data about data”, more complex is to turn this definition in the reality, with a clear distinction between data and metadata. In fact, what is “data” and what is “metadata” is a matter of perspective: based on the context, the same information can be in fact considered as part of the data or of the metadata. 

In consideration of this, the expectation of having a single persistent and unique ID that identifies the metadata FAIR data object, distinct from that describing the data one, cannot be always satisfied in the FHIR space, except for specific contexts.

A pragmatic approach is therefore suggested in the evaluation of this requirement, determining case by case, and in dependence of the type of data (study level or subject level data), what are the actual information to label as metadata, that should and can be distinguished by the associated data.

Other information, that could be considered as well as metadata might be recorded in the same object containing the data and used to search them.

See RDA-F1-01M for the general considerations on the identification of the FHIR resources.

If the organization assures the persistency of the FHIR identifiers, this indicator is automatically fulfilled when data is represented by a single FHIR resource.

This doesn't exclude more complex situations that need to be analyzed case by case.

See RDA-F1-01M.

In consideration of this, the way a single persistent and unique ID is used to identify the data FAIR data object may depend on the data design.

This requirement is fulfilled when data is represented by FHIR resources.

HL7 FHIR provides means to record metadata information and to enable the search of data based on them. Moreover through FHIR profiling can enforce their adoption by implementers.

Communities should define what is meant with "rich" metadata for the use cases they need to cover and possibly formalize them by using FHIR profiles and implementation guides.

The rationale behind this principle is that someone should be able to find data based on the information provided by their metadata, even without the data’s identifier (adapted from GO-FAIR F2 principle). 

Whether metadata is 'rich' enough would therefore really depend on what users would need to search on in terms of metadata fields to find the resources. This 'richness' criterium is then use case dependent. 

Please refer to Metadata and data  about a more general discussion about issues in implementing metadata in FHIR.

The adoption of FHIR can enable the documentation of metadata but claiming the conformance with FHIR is not a sufficient condition for fulfilling this requirement.

Communities should define what is meant with "rich" metadata for the use cases they need to cover; indicating what are the information that have to be recorded, possibly formalized as FHIR profiles; and the kind of searches that servers should support, possibly formalized as FHIR Capability Statement.

The way this is satisfied depends on how FAIR metadata and data objects are represented in HL7 FHIR.

In order to adhere to this requirement, the FHIR search framework can be used. The extent of data and metadata that have to be registered or indexed would however depend on what users would need to search to find the resources.

Each community should define what are the relevant metadata and data that have to be registered or indexed by a FHIR server for each supported resource to fulfil this principle; formalizing them with FHIR conformance resources and implementation guides.

Identifiers and rich metadata descriptions alone will not ensure ‘findability’ on the internet. Perfectly good data resources may go unused simply because no one knows they exist. If the availability of a digital resource such as a dataset, service or repository is not known, then nobody (and no machine) can discover it (adapted from GO-FAIR F4 principle).

FHIR provides FHIR metadata datatypes and resource interfaces. FHIR resources allow the documentation of the data context. The architectures adopted should ensure that the FHIR server hosting the data set has strong searching capabilities.

Implementers should look for specific FHIR Conformance resources and/or Implementation Guides that describe the metadata and data elements that shall or should be provided to a FHIR server for the use case in question and registered or indexed by that server. HL7 FHIR CapabilityStatement, SearchParameter, StructureDefiniton , possibly documented within a Implementation Guide should be used to document this. 

See also RDA-F2-01M and RDA-F3-01M

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects.

In the FHIR REST paradigm _"the location of a resource instance is an absolute URI constructed from the server base address at which the instance is found, the resource type and the Logical ID, such as

http://example.org/fhir/Patient/123 (where 123 is the Logical Id of a Patient resource). When the location is an HTTP address, this address can generally be used to retrieve or manipulate the resource."_

Depending on the FAIR data design, different FHIR mechanisms can be used to refer the FAIR data, e.g. by using direct or reverse references to other FHIR resources, or referring data business identifiers. FHIR also provides mechanisms to enable the access to non-FHIR data.

The solution architecture should ensure that the metadata FHIR resource includes a reference to the actual data or information on how to access it directly or indirectly.

This is not related to the FHIR standard, but on the capabilities offered by the system/platform implementing the services.

The metadata FHIR resources should provide information on how to access the data, if a manual access is foreseen.

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects

This requirement is typically fulfilled if the metadata object is expressed in HL7 FHIR and available in a FHIR server.

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects

This requirement is typically fulfilled if the data object is expressed in HL7 FHIR and available in a FHIR server.

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects

This is fulfilled by the existence of the data in a FHIR server.

FHIR provides mean to fulfils this requirements, excepting for the metadata information that are recorded in the same FHIR resource documenting the data.

The fulfillment of this requirement is not however determined by the technical capabilities of FHIR, but it depends also on architectural and organizational choices.

Community can enforce the adoption of suitable FAIR data object design choices to enforce this requirement, by specifying community FHIR profiles and implementation guides.

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects

This principle is important because there can be many reasons why data are no longer available whereas the associated metadata should be a permanent record to describe the data. Future reuse of available data requires separately identified metadata and it also crucial to enable future reproducibility of new data for more science. The practical application of this A2 FAIR principle to data and metadata from the clinical sciences and specifically, supported by the HL7 FHIR standards should consider the following recommendations.

• Some clinical data elements may serve as metadata for other data elements. If all data elements have identifiers are compliant with FAIR principle, A1 being global, unique, persistent and resolvable by machine (GUPRI) it should be possible to comply with this FAIR principle, A2.

• Clinical data and associated metadata can be stored on multiple FHIR servers. This will present no issues if compliant with the FAIR principles of F1 and A2.

• To maintain FAIR compliance it is critical to manage and maintain the persistency aspect of GUPRIs (independently on FHIR) for all data and metadata elements.

FHIR provides support for standardized knowledge representation

The RDA-I1 (01M, O1D,  O2M, O2D) indicators are in general covered by virtue of using HL7 FHIR, however, to strive to semantic computable interoperability, communities should agreed on common vocabularies, profiles and other conformance resources that applies for their context of use.  

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects

There are different ways to interpret 'knowledge representation expressed in standardised format', for example the capability to:

• have a machine readable physical representation, e.g. JSON

• represent and formalize healthcare models and data;

• share clinical knowledge artifacts;

• provide an expression logic

• strive for semantic computable interoperability (i.e. semantic interoperability between machines)

HL7 FHIR supports XML, JSON and RDF machine readable physical representations. It provides in general a formal (FHIR Infrastructure, the core framework on which FHIR depend, is a Normative part of FHIR); accessible and shared (the HL7 FHIR standard is public, accessible and usable by everyone) and broadly applicable language: HL7 FHIR is widely used in the Healthcare for covering a wide range of domains and use cases (from genetic to administrative data for representing healthcare related models and data). The FHIR Clinical Reasoning module provides "resources and operations to enable the representation, distribution, and evaluation of clinical knowledge artifacts such as clinical decision support rules, quality measures, public health indicators, order sets, clinical protocols, and evidence summaries.". It enables finally the representation of logic using languages such as FHIRPath and Clinical Quality Language (CQL).

FHIR resources can be used together with other knowledge representation approaches, including SNOMED CT Compositional Grammar 

Thus, if we are looking to the first four aspects this principle is covered by virtue of using HL7 FHIR resources to represent metadata and data.

Concerning instead the last point, the compliance with FHIR, even if it is a strong enabler, may not be sufficient for the semantic computable interoperability. For example a vocabulary used by the sender or an extension defined in a specific context might not be understood by the receiver. To strive for semantic computable interoperability communities are invited to agree on context specific FHIR Implementation Guides, relying as possible on existing ones. 

HL7 FHIR provides a formal way to bind codeable elements with vocabularies (intended as terminologies), but with very few exceptions, it doesn't impose the usage of any of them.

Communities should select FAIR-compliant vocabularies, preferably managed through FHIR  terminology services.

This choice should be formalized  through  community specified FHIR Implementation Guide, including appropriate conformance and terminology resources.

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects HL7

HL7 FHIR provides a formal way to bind codeable elements with vocabularies (intended as terminologies), but with very few exceptions, it doesn't impose the usage of any of them.

HL7 FHIR includes terminology resources and API that may facilitate the fulfillment of some 'technical' FAIR principles as the unique, global persistent identification of vocabulary metadata and data (e.g. by using the canonical URL).

To satisfy this principle FHIR implementers should make an assessment of the FAIRness of the terminologies to be used and  enforce the adoption of the FAIR-compliant vocabularies.

FHIR supports different kinds of (qualified) references among FHIR resources and also to non-FHIR objects.

Communities should determine what are the (qualified) references to other resources that are needed to provide a sufficient contextual knowledge for the scope of their community. This should be formalized  through a community FHIR Implementation Guide.

A qualified reference is intended as a cross-reference that explains its intent. 

HL7 FHIR technically supports different kinds of (qualified) references among FHIR resources and also to non-FHIR objects.

This capability of HL7 FHIR doesn't guarantee however "per se" that as many meaningful links between metadata and data resources are used to enrich the contextual knowledge about the data (that is the goal).

Thus, if on one hand this principle is technically satisfied by HL7 FHIR, FHIR implementers should determine what are the links among resources that are needed to provide a sufficient contextual knowledge for the scope of their community.

The realization of this requirement may depend on the data and metadata design approach (e.g. hybrid approaches with some metadata represented using non-FHIR technologies) .

Each HL7 FHIR resource includes a rich set of attributes describing most relevant data and metadata.

A formal extension mechanism is also specified by that standard to cover additional requirements.

Communities should define which rich metadata are sufficient to describe data to make them useful in their context. This should be formalized with appropriate FHIR conformance resources in FHIR implementation guides.

This requirement is related to the F2, but while F2 focuses on metadata that allows its discovery, R1 focuses on the context under which the data were generated as well as they should been used.

General considerations made for F2 about FHIR apply also for R1, FHIR is therefore an enabling factor, but the conformance with FHIR is not necessarily a sufficient condition for fulfilling this requirement.

The fact data and metadata are 'richly described' depends on the context of use; therefore, depending on the use case, implementers should identify what are the minimal, recommended and suggested intrinsic and contextual information that should be returned to describe the data and make them actually USEFUL in a particular context.

FHIR implementers should look for specific FHIR Implementation Guides (IG) that cover the Resource types and the use case of interest; and/or define FHIR IGs that apply in their usage context.

The realization of this requirement may depend however on the data and metadata design approach (e.g. hybrid approaches with some metadata represented using non-FHIR technologies).

FHIR provides different means to specify the license and the conditions under which data can be reused.
The adoption of FHIR is not however a sufficient condition for fulfilling this requirement.

Published FHIR resources have to include clear references to the usage license.

Communities should specify in appropriate FHIR implementation guides  - for each kind of data - how this is realized in their context.

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects HL7

HL7 FHIR provides different means to specify the license and the conditions under which data can be used. For example, a resource may convey specific security metadata by using the security labels, enabling policy fragments to accompany the resource data; the Citation resource offers a copyright element to covey human readable copyright information at different level of granularity (Citation , abstract, cited artefacts); the Consent resource can be used to record choices which permits or denies identified recipient(s) or recipient role(s) to perform one or more actions within a given policy context, for specific purposes and periods of time.

The solution to be adopted may change depending on the type of data and the context of use.

The adoption of FHIR is not however a sufficient condition for fulfilling this requirement, implementers should therefore define how this requirement is supposed to be met.

The fulfillment of this requirement depends moreover on the capability of the organization to capture and record this kind of information.

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects HL7.

This principle focuses on specific type of contextual data as where the data came from, how they have been processed; if it has been published before; who need to be cited and/or acknowledged....

Most of this information may be captured in HL7 FHIR by using the Provence resource enabling the recording of data sources and of the actions applied on them at different level of granularity.

Other kinds of resources, e.g. the Citation, could be used for capturing instead publication related infos.

As for some other principles, HL7 FHIR can technically support the data FAIRness, but it is not a sufficient condition for fulfilling this requirement; that depends also on the capability of the organization to capture and record this information.

FHIR is a standard that can be used to represent human and machine-readable metadata and data information.
It defines formal profiling mechanisms to specify community agreed rules.

Even though HL7 FHIR can be considered it self a 'domain-relevant community standard' , implementers are strongly suggested to identify, and if needed specify, appropriate  FHIR Implementation Guides covering the community expectations in terms of models, vocabularies and other objects for their context of use.

Please refer to RDA-F1-01M and RDA-F1-01D for the discussion on distinct and identifiable metadata and data FAIR objects HL7.

HL7 FHIR is a globally recognized standard in the health domain, that can be used to represent human and machine-readable metadata and data information.
It defines also formal profiling mechanisms to specify community agreed rules.

There are several published FHIR Implementation Guides describing how FHIR should be used for specific scopes.

Beyond this, there might be implementation independent standards (e.g. clinical guidelines) a community wish to refer to.

Implementers are therefore suggested to look for existing FHIR implementation guides or define new ones to cover appropriately the community expectations.