IP Review

Unattributed Code Systems

http://unstats.un.org/unsd/methods/m49/m49.htm

Copyright Fragment

This fragment is available on index.html

No use of external IP

Copyright and Registered Trademark Uses

IG © 2025+ HL7 International / FHIR Infrastructure. Package hl7.fhir.uv.api-incubator#0.1.0 based on FHIR 6.0.0-ballot3. Generated 2026-06-22 Links: Table of Contents | QA Report | Version History | CC0 | Propose a change ( src )
hl7.fhir.us.hai: Healthcare Associated Infection Implementation Guide ®© HL7 | CC0 ( src )
FHIR R6 API Incubator, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/api-incubator-ig/ and changes regularly. See the Directory of published versions ( src )
The copyright symbol and the '(c)' textual representation SHOULD NOT be included in this string. It will be added by software when rendering the notation. Full details about licensing, restrictions, warrantees, etc. goes in the more general 'copyright' element. ( src )

External References

Type Reference Content

web example.org url : http://example.org/GraphDefinition/example

web github.com FHIR R6 API Incubator, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/api-incubator-ig/ and changes regularly. See the Directory of published versions

web ndjson.org The format for the generated bulk data files. Currently, ndjson must be supported, though servers may choose to also support other output formats. Servers SHALL support the full content type of application/fhir+ndjson as well as abbreviated representations including application/ndjson and ndjson .

web en.wikipedia.org A client SHOULD follow an exponential backoff approach when polling for status. A server SHOULD supply a Retry-After header with a with a delay time in seconds (e.g., 120 to represent two minutes) or a http-date (e.g., Fri, 31 Dec 1999 23:59:59 GMT ). When provided, a client SHOULD use this information to inform the timing of future polling requests. The server SHOULD keep an accounting of status queries received from a given client, and if a client is polling too frequently, the server SHOULD respond with a 429 Too Many Requests status code in addition to a Retry-After header, and optionally a OperationOutcome Resource with further explanation. If excessively frequent status queries persist, the server MAY return a 429 Too Many Requests status code without returning a status answer. It may either return a Retry-after header with the 429 indicating the amount of time that needs to pass before it will again respond to a status check, or it may choose to abandon the asynchronous operation entirely and force a retry. Other standard HTTP 4XX as well as 5XX status codes may be used to identify errors as mentioned.

web developer.mozilla.org A client SHOULD follow an exponential backoff approach when polling for status. A server SHOULD supply a Retry-After header with a with a delay time in seconds (e.g., 120 to represent two minutes) or a http-date (e.g., Fri, 31 Dec 1999 23:59:59 GMT ). When provided, a client SHOULD use this information to inform the timing of future polling requests. The server SHOULD keep an accounting of status queries received from a given client, and if a client is polling too frequently, the server SHOULD respond with a 429 Too Many Requests status code in addition to a Retry-After header, and optionally a OperationOutcome Resource with further explanation. If excessively frequent status queries persist, the server MAY return a 429 Too Many Requests status code without returning a status answer. It may either return a Retry-after header with the 429 indicating the amount of time that needs to pass before it will again respond to a status check, or it may choose to abandon the asynchronous operation entirely and force a retry. Other standard HTTP 4XX as well as 5XX status codes may be used to identify errors as mentioned.

web ndjson.org Body of FHIR resources in newline delimited json - ndjson or other requested format

web en.wikipedia.org Clients poll the URL from the Content-Location header using an HTTP GET to check the job's status. Clients SHOULD implement an exponential backoff strategy.

web developer.mozilla.org Servers SHOULD include a Retry-After header (in seconds or as an HTTP-date) to guide the client's polling frequency. If a client polls too frequently, the server SHOULD return 429 Too Many Requests .

Type	Reference	Content
web	example.org	url : http://example.org/GraphDefinition/example
web	github.com	FHIR R6 API Incubator, published by HL7 International / FHIR Infrastructure. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/api-incubator-ig/ and changes regularly. See the Directory of published versions
web	ndjson.org	The format for the generated bulk data files. Currently, ndjson must be supported, though servers may choose to also support other output formats. Servers SHALL support the full content type of `application/fhir+ndjson` as well as abbreviated representations including `application/ndjson` and `ndjson` .
web	en.wikipedia.org	A client SHOULD follow an exponential backoff approach when polling for status. A server SHOULD supply a `Retry-After` header with a with a delay time in seconds (e.g., `120` to represent two minutes) or a http-date (e.g., `Fri, 31 Dec 1999 23:59:59 GMT` ). When provided, a client SHOULD use this information to inform the timing of future polling requests. The server SHOULD keep an accounting of status queries received from a given client, and if a client is polling too frequently, the server SHOULD respond with a `429 Too Many Requests` status code in addition to a `Retry-After` header, and optionally a OperationOutcome Resource with further explanation. If excessively frequent status queries persist, the server MAY return a `429 Too Many Requests` status code without returning a status answer. It may either return a Retry-after header with the 429 indicating the amount of time that needs to pass before it will again respond to a status check, or it may choose to abandon the asynchronous operation entirely and force a retry. Other standard HTTP `4XX` as well as `5XX` status codes may be used to identify errors as mentioned.
web	developer.mozilla.org	A client SHOULD follow an exponential backoff approach when polling for status. A server SHOULD supply a `Retry-After` header with a with a delay time in seconds (e.g., `120` to represent two minutes) or a http-date (e.g., `Fri, 31 Dec 1999 23:59:59 GMT` ). When provided, a client SHOULD use this information to inform the timing of future polling requests. The server SHOULD keep an accounting of status queries received from a given client, and if a client is polling too frequently, the server SHOULD respond with a `429 Too Many Requests` status code in addition to a `Retry-After` header, and optionally a OperationOutcome Resource with further explanation. If excessively frequent status queries persist, the server MAY return a `429 Too Many Requests` status code without returning a status answer. It may either return a Retry-after header with the 429 indicating the amount of time that needs to pass before it will again respond to a status check, or it may choose to abandon the asynchronous operation entirely and force a retry. Other standard HTTP `4XX` as well as `5XX` status codes may be used to identify errors as mentioned.
web	ndjson.org	Body of FHIR resources in newline delimited json - ndjson or other requested format
web	en.wikipedia.org	Clients poll the URL from the `Content-Location` header using an HTTP `GET` to check the job's status. Clients SHOULD implement an exponential backoff strategy.
web	developer.mozilla.org	Servers SHOULD include a `Retry-After` header (in seconds or as an HTTP-date) to guide the client's polling frequency. If a client polls too frequently, the server SHOULD return `429 Too Many Requests` .

Internal Images

tree-filter.png