De-identified, Anonymized FHIR Profiles Library, published by HL7 International / Cross-Group Projects. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-dapl/ and changes regularly. See the Directory of published versions
| Page standards status: Trial-use |
This section defines the specific requirements for systems wishing to conform to profiles and operations specified in this IG.
This DAPL IG is a library and as such does not define any conformance requirements, but rather defines profiles which can be used by other IGs such as DARTS IG. So implementers of DARTS or any other IG that leverages profiles from DAPL IG will be conformant to this IG.
Before reading this formal specification, implementers should first be familiar with two other key portions of the specification:
The Use Cases page provides the business context and use cases that use the profiles specified by this IG.
The Background page provides information about the underlying specifications and indicates what portions of each should be reviewed in order to have the necessary foundation to understand the constraints and usage guidance described in this detailed specification.
This implementation guide uses terminology and key words from RFC 2119 to indicate conformance requirements.
Actors and systems asserting conformance to this IG will use the profiles defined by this IG to exchange de-identified or anonymized data. This is typically done by implementing the DARTS IG.
The following definition of MUST SUPPORT is to be used in the implementation of the requirements.
Systems SHALL be capable of populating data elements as specified by the profiles and returning the data elements are returned using the specified APIs in the capability statement.
Systems SHALL be capable of processing resource instances containing the MUST SUPPORT data elements without generating an error or causing the application to fail.
Systems SHOULD be capable of displaying the MUST SUPPORT data elements for human use or storing it for other purposes.
In situations where information on a particular data element is not present and the reason for absence is unknown, Systems SHALL NOT include the data elements in the resource instance returned in response to the API requests.
When accessing de-identified or anonymized data, Systems SHALL interpret missing data elements within resource instances returned from API requests as data that has been removed as part of the de-identification and anonymization process.
This specification makes significant use of FHIR profiles and terminology artifacts to describe the content to be shared as data exchange workflows. The implementation guide is based on FHIR R4 and profiles are listed for each interaction.
The full set of profiles defined in this implementation guide can be found by following the links on the FHIR Artifacts page.
This DAPL IG does not specify any capability statements or systems or actors as this is just a library and the implementers of other IGs such as DARTS IG will specify the actors and Capability Statements required.