NVD FHIR API integrācijas apraksts

Identifies the purpose for this name.

Allows the appropriate name for a particular context of use to be selected from among a set of names.

Applications can assume that a name is current unless it explicitly says that it is temporary or old.

Specifies the entire name as it should be displayed e.g. on an application UI. This may be provided instead of or as well as the specific parts.

A renderable, unencoded form.

Can provide both a text representation and parts. Applications updating a name SHALL ensure that when both text and parts are present, no content is included in the text that isn't found in a part.

Part of the name that is acquired as a title due to academic, legal, employment or nobility status, etc. and that appears at the start of the name.

Part of the name that is acquired as a title due to academic, legal, employment or nobility status, etc. and that appears at the end of the name.

Indicates the period of time when this name was valid for the named person.

Allows names to be placed in historical context.

Administrative Gender - the gender that the patient is considered to have for administration and record keeping purposes.

Needed for identification of the individual, in combination with (at least) name and birth date.

The gender might not match the biological sex as determined by genetics or the individual's preferred identification. Note that for both humans and particularly animals, there are other legitimate possibilities than male and female, though the vast majority of systems and contexts only support male and female. Systems providing decision support or enforcing business rules should ideally do this on the basis of Observations dealing with the specific sex or gender aspect of interest (anatomical, chromosomal, social, etc.) However, because these observations are infrequently recorded, defaulting to the administrative gender is common practice. Where such defaulting occurs, rule enforcement should allow for the variation between administrative and biological, chromosomal and other gender aspects. For example, an alert about a hysterectomy on a male should be handled as a warning or overridable error, not a "hard" error. See the Patient Gender and Sex section for additional information about communicating patient gender and sex.

The gender of a person used for administrative purposes.

This field contains a patient's most recent marital (civil) status.

Most, if not all systems capture it.

The domestic partnership status of a person.

Image of the patient.

Many EHR systems have the capability to capture an image of the patient. Fits with newer social media usage too.

Guidelines:

• Use id photos, not clinical photos.
• Limit dimensions to thumbnail.
• Keep byte count low to ease resource updates.

The version of the code system which was used when choosing this code. Note that a well-maintained code system does not need the version reported, because the meaning of codes is consistent across versions. However this cannot consistently be assured, and when the meaning is not guaranteed to be consistent, the version SHOULD be exchanged.

Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.

Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays).

This has been identified as a clinical safety criterium - that this exact system/code pair was chosen explicitly, rather than inferred by the system based on some rules or language processing.

Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.

A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

Very often the text is the same as a displayName of one of the codings.

Identifies the purpose for this name.

Allows the appropriate name for a particular context of use to be selected from among a set of names.

Applications can assume that a name is current unless it explicitly says that it is temporary or old.

Specifies the entire name as it should be displayed e.g. on an application UI. This may be provided instead of or as well as the specific parts.

A renderable, unencoded form.

Can provide both a text representation and parts. Applications updating a name SHALL ensure that when both text and parts are present, no content is included in the text that isn't found in a part.

Part of the name that is acquired as a title due to academic, legal, employment or nobility status, etc. and that appears at the start of the name.

Part of the name that is acquired as a title due to academic, legal, employment or nobility status, etc. and that appears at the end of the name.

Indicates the period of time when this name was valid for the named person.

Allows names to be placed in historical context.

Address for the contact person.

Need to keep track where the contact person can be contacted per postal mail or visited.

Administrative Gender - the gender that the contact person is considered to have for administration and record keeping purposes.

Needed to address the person correctly.

The gender of a person used for administrative purposes.

Organization on behalf of which the contact is acting or for which the contact is working.

For guardians or business related contacts, the organization is relevant.

The period during which this contact person or organization is valid to be contacted relating to this patient.

A reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources.

Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server.

The expected type of the target of the reference. If both Reference.type and Reference.reference are populated and Reference.reference is a FHIR URL, both SHALL be consistent.

The type is the Canonical URL of Resource Definition that is the type this reference refers to. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition/ e.g. "Patient" is a reference to http://hl7.org/fhir/StructureDefinition/Patient. Absolute URLs are only allowed for logical models (and can only be used in references in logical models, not resources).

This element is used to indicate the type of the target of the reference. This may be used which ever of the other elements are populated (or not). In some cases, the type of the target may be determined by inspection of the reference (e.g. a RESTful URL) or by resolving the target of the reference; if both the type and a reference is provided, the reference SHALL resolve to a resource of the same type as that specified.

The purpose of this identifier.

Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers.

Applications can assume that an identifier is permanent unless it explicitly says that it is temporary.

A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.

Allows users to make use of identifiers when the identifier system is not known.

This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.

Time period during which identifier is/was valid for use.

Organization that issued/manages the identifier.

The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization.

Organization that is the custodian of the patient record.

Need to know who recognizes this patient record, manages and updates it.

There is only one managing organization for a specific patient record. Other organizations will have their own Patient record, and may use the Link property to join the records together (or a Person resource which can include confidence ratings for the association).

An identifier for the target resource. This is used when there is no way to reference the other resource directly, either because the entity it represents is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference.

When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier) but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it - see CapabilityStatement.rest.resource.referencePolicy.

When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference

Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it.

Reference is intended to point to a structure that can potentially be expressed as a FHIR resource, though there is no need for it to exist as an actual FHIR resource instance - except in as much as an application wishes to actual find the target of the reference. The content referred to be the identifier must meet the logical constraints implied by any limitations on what resource types are permitted for the reference. For example, it would not be legitimate to send the identifier for a drug prescription if the type were Reference(Observation|DiagnosticReport). One of the use-cases for Reference.identifier is the situation where no FHIR representation exists (where the type is Reference (Any).

Plain text narrative that identifies the resource in addition to the resource reference.

This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.