HL7 Terminology (THO)
5.5.0 - Publication International flag

This page is part of the HL7 Terminology (v5.5.0: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Structures: Extension Definitions

These define constraints on FHIR data types for systems conforming to this implementation guide.

MIF Associated concept property

Concept Properties that are associated with this Code System or Value Set Version

MIF concept relationship inverse name

Identifies the name of the relationship that references the inverse of the current relationship. Allows linking a relationship and its derived inverse.

MIF concept relationship is navigable

Indicates whether the relationship is intended to be navigated when selecting a code

MIF concept relationship is reflexivity

Indicates if the association always holds for a concept with itself (refexive), never holds for a concept with itself (irreflexive)

MIF concept relationship kind

Identifies a type of relationship between codes that is supported by this code system version

MIF concept relationship symmetry

Indicates if the relationship always holds in the reverse direction as well (symetric), never holds in the reverse direction as well (antisymetric)

MIF concept relationship transitivity

Indicates whether the relationship always (transitive) or never (antitransitive) propagates such that if the association exists from A to B and from B to C that the relationship can be inferred to exist from A to C

NamingSystem title

The human-readable descriptive name for the code or identifier system

NamingSystem version

The business version associated with the Naming System

Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide.

AMA CPT All Codes

All codes in CPT (including metadata, modifiers, etc).

AMA CPT Base Codes

All codes in CPT that represent procedure codes (no modifiers allowed - e.g. for Claim.item.productOrService).

AMA CPT Modifier Codes

CPT modifiers (e.g. for Claim.item.modifier)

AMA CPT Usable Codes

All CPT codes (no modifiers) that represent procedure codes (e.g. for Procedure.code).

Abenakian

No description

AccessMedicalDevice

A device used to allow access to a part of a body

AcknowledgementCondition

Acknowledgement Condition codes describe the conditions under which accept or application level acknowledgements are required to be returned in response to the message send operation.

AcknowledgementDetailCode

A site specific problem code

AcknowledgementDetailNotSupportedCode

Refelects rejections because elements of the communication are not supported in the current context.

AcknowledgementDetailSyntaxErrorCode

Reflects errors in the syntax or structure of the communication.

AcknowledgementDetailType

A code identifying the specific message to be provided. A textual value may be specified as the print name, or for non-coded messages, as the original text.Discussion: ‘Required attribute xxx is missing’, ‘System will be unavailable March 19 from 0100 to 0300’Examples:

AcknowledgementType

Acknowledgement code as described in HL7 message processing rules.

Act Procedure Code CCI

** MISSING DESCRIPTION **

ActAccommodationReason

Identifies the reason the patient is assigned to this accommodation type

ActAccountCode

An account represents a grouping of financial transactions that are tracked and reported together with a single balance. Examples of account codes (types) are Patient billing accounts (collection of charges), Cost centers; Cash.

ActAdjudicationCode

Includes coded responses that will occur as a result of the adjudication of an electronic invoice at a summary level and provides guidance on interpretation of the referenced adjudication results.

ActAdjudicationGroupCode

Catagorization of grouping criteria for the associated transactions and/or summary (totals, subtotals).

ActAdjudicationResultActionCode

Actions to be carried out by the recipient of the Adjudication Result information.

ActAdministrativeAuthorizationDetectedIssueCode

No description

ActAdministrativeDetectedIssueCode

Identifies types of detectyed issues for Act class “ALRT” for the administrative and patient administrative acts domains.

ActAdministrativeDetectedIssueManagementCode

Codes dealing with the management of Detected Issue observations for the administrative and patient administrative acts domains.

ActAdministrativeRuleDetectedIssueCode

No description

ActAmbulatoryEncounterCode

Definition:A comprehensive term for health care provided in a healthcare facility (e.g. a practitioneraTMs office, clinic setting, or hospital) on a nonresident basis. The term ambulatory usually implies that the patient has come to the location and is not assigned to a bed. Sometimes referred to as an outpatient encounter.

ActAntigenInvalidReason

Description: Coded reasons why an antigen is considered invalid.

ActBillableModifierCode

Definition:An identifying modifier code for healthcare interventions or procedures.

ActBillingArrangementCode

The type of provision(s) made for reimbursing for the deliver of healthcare services and/or goods provided by a Provider, over a specified period.

ActBoundedROICode

Type of bounded ROI.

ActCareProvisionCode

Description:The type and scope of responsibility taken-on by the performer of the Act for a specific subject of care.

ActClaimAttachmentCategoryCode

No description

ActClass

A code specifying the major type of Act that this Act-instance represents. Constraints: The classCode domain is a tightly controlled vocabulary, not an external or user-defined vocabulary. Every Act-instance must have a classCode. If the act class is not further specified, the most general Act.classCode (ACT) is used. The Act.classCode must be a generalization of the specific Act concept (e.g., as expressed in Act.code), in other words, the Act concepts conveyed in an Act must be specializations of the Act.classCode. Especially, Act.code is not a “modifier” that can alter the meaning of a class code. (See Act.code for contrast.)

ActClassAccession

A unit of work, a grouper of work items as defined by the system performing that work. Typically some laboratory order fulfillers communicate references to accessions in their communications regarding laboratory orders. Often one or more specimens are related to an accession such that in some environments the accession number is taken as an identifier for a specimen (group).

ActClassAccommodation

An accommodation is a service provided for a Person or other LivingSubject in which a place is provided for the subject to reside for a period of time. Commonly used to track the provision of ward, private and semi-private accommodations for a patient.

ActClassAccount

A financial account established to track the net result of financial acts.

ActClassAcquisitionExposure

Description: An acquisition exposure act describes the proximity (location and time) through which the participating entity was potentially exposed to a physical (including energy), chemical or biological agent from another entity. The acquisition exposure act is used in conjunction with transmission exposure acts as part of an analysis technique for contact tracing. Although an exposure can be decomposed into transmission and acquisition exposures, there is no requirement that all exposures be treated in this fashion. Constraints: The Acquisition Exposure inherits the participation constraints that apply to Exposure with the following exception. The EXPSRC (exposure source) participation must never be associated with the Transmission Exposure either directly or via context conduction.

ActClassAction

Sender asks addressee to do something depending on the focal Act of the payload. An example is “fulfill this order”. Addressee has responsibilities to either reject the message or to act on it in an appropriate way (specified by the specific receiver responsibilities for the interaction).

ActClassBattery

Description:A battery specifies a set of observations. These observations typically have a logical or practical grouping for generally accepted clinical or functional purposes, such as observations that are run together because of automation. A battery can define required and optional components and, in some cases, will define complex rules that determine whether or not a particular observation is made. Examples: “Blood pressure”, “Full blood count”, “Chemistry panel”.

ActClassBioSequence

Description:A sequence of biomolecule like the DNA, RNA, protein and the like.

ActClassBioSequenceVariation

Description:A variation in a sequence as described by BioSequence.

ActClassBoundedRoi

A Region of Interest (ROI) specified for a multidimensional observation, such as an Observation Series (OBSSER). The ROI is specified using a set of observation criteria, each delineating the boundary of the region in one of the dimensions in the multidimensional observation. The relationship between a ROI and its referenced Act is specified through an ActRelationship of type subject (SUBJ), which must always be present. Each of the boundary criteria observations is connected with the ROI using ActRelationships of type “has component” (COMP). In each boundary criterion, the Act.code names the dimension and the Observation.value specifies the range of values inside the region. Typically the bounded dimension is continuous, and so the Observation.value will be an interval (IVL) data type. The Observation.value need not be specified if the respective dimension is only named but not constrained. For example, an ROI for the QT interval of a certain beat in ECG Lead II would contain 2 boundary criteria, one naming the interval in time (constrained), and the other naming the interval in ECG Lead II (only named, but not constrained).

ActClassCareProvision

An Act that of taking on whole or partial responsibility for, or attention to, safety and well-being of a subject of care. Discussion: A care provision event may exist without any other care actions taking place. For example, when a patient is assigned to the care of a particular health professional. In request (RQO) mood care provision communicates a referral, which is a request:

  • from one party (linked as a participant of type author (AUT)),
  • to another party (linked as a participant of type performer (PRF),
  • to take responsibility for a scope specified by the code attribute,
  • for an entity (linked as a participant of type subject (SBJ)). The scope of the care for which responsibility is taken is identified by code attribute. In event (EVN) mood care provision indicates the effective time interval of a specified scope of responsibility by a performer (PRF) or set of performers (PRF) for a subject (SBJ). Examples:
    1. Referral from GP to a specialist.
    2. Assignment of a patient or group of patients to the case list of a health professional.
    3. Assignment of inpatients to the care of particular nurses for a working shift.
ActClassCategory

A group of entries within a composition or topic that have a common characteristic - for example, Examination, Diagnosis, Management OR Subjective, Objective, Analysis, Plan. The distinction from Topic relates to value sets. For Category there is a bounded list of things like “Examination”, “Diagnosis” or SOAP categories. For Topic the list is wide open to any clinical condition or reason for a part of an encounter. A CATEGORY MAY CONTAIN ENTRIES.

ActClassCdaLevelOneClinicalDocument

A clinical document that conforms to Level One of the HL7 Clinical Document Architecture (CDA)

ActClassClinicalDocument

A clinical document is a documentation of clinical observations and services, with the following characteristics: (1) Persistence - A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements; (2) Stewardship - A clinical document is maintained by a person or organization entrusted with its care; (3) Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated; (4) Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document; (5) Human readability - A clinical document is human readable.”

ActClassClinicalTrial

The set of actions that define an experiment to assess the effectiveness and/or safety of a biopharmaceutical product (food, drug, device, etc.). In definition mood, this set of actions is often embodied in a clinical trial protocol; in event mood, this designates the aggregate act of applying the actions to one or more subjects.

ActClassClinicalTrialTimepointEvent

An identified point during a clinical trial at which one or more actions are scheduled to be performed (definition mood), or are actually performed (event mood). The actions may or may not involve an encounter between the subject and a healthcare professional.

ActClassCluster

A group of entries within a composition, topic or category that have a logical association with one another. The representation of a single observation or action might itself be multi-part. The data might need to be represented as a nested set of values, as a table, list, or as a time series. The Cluster class permits such aggregation within an entry for such compound data. Examples include “Haematology investigations” which might include two or more distinct batteries. A cluster may contain batteries and/or individual entries

ActClassCompositeOrder

No description

ActClassComposition

A context representing a grouped commitment of information to the EHR. It is considered the unit of modification of the record, the unit of transmission in record extracts, and the unit of attestation by authorizing clinicians. A composition represents part of a patient record originating from a single interaction between an authenticator and the record. Unless otherwise stated all statements within a composition have the same authenticator, apply to the same patient and were recorded in a single session of use of a single application. A composition contains organizers and entries.

ActClassConcern

No description

ActClassCondition

An observable finding or state that persists over time and tends to require intervention or management, and, therefore, distinguished from an Observation made at a point in time; may exist before an Observation of the Condition is made or after interventions to manage the Condition are undertaken. Examples: equipment repair status, device recall status, a health risk, a financial risk, public health risk, pregnancy, health maintenance, chronic illness

ActClassConditionNode

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassConsent

The Consent class represents informed consents and all similar medico-legal transactions between the patient (or his legal guardian) and the provider. Examples are informed consent for surgical procedures, informed consent for clinical trials, advanced beneficiary notice, against medical advice decline from service, release of information agreement, etc. The details of consents vary. Often an institution has a number of different consent forms for various purposes, including reminding the physician about the topics to mention. Such forms also include patient education material. In electronic medical record communication, consents thus are information-generating acts on their own and need to be managed similar to medical activities. Thus, Consent is modeled as a special class of Act. The “signatures” to the consent document are represented electronically through Participation instances to the consent object. Typically an informed consent has Participation.typeCode of “performer”, the healthcare provider informing the patient, and “consenter”, the patient or legal guardian. Some consent may associate a witness or a notary public (e.g., living wills, advanced directives). In consents where a healthcare provider is not required (e.g. living will), the performer may be the patient himself or a notary public. Some consent has a minimum required delay between the consent and the service, so as to allow the patient to rethink his decisions. This minimum delay can be expressed in the act definition by the ActRelationship.pauseQuantity attribute that delays the service until the pause time has elapsed after the consent has been completed.

ActClassContainer

Used to group a set of acts sharing a common context. Container structures can nest within other context structures - such as where a document is contained within a folder, or a folder is contained within an EHR extract. Open issue: There is a clear conflict between this act and the use of the more general “component” ActRelationship. The question that must be resolved is what should be the class code of the parent (or containing) Act.

ActClassContainerRegistration

An Act where a container is registered either via an automated sensor, such as a barcode reader, or by manual receipt

ActClassContract

An agreement of obligation between two or more parties that is subject to contractual law and enforcement.

ActClassControlAct

An act representing a system action such as the change of state of another act or the initiation of a query. All control acts represent trigger events in the HL7 context. ControlActs may occur in different moods.

ActClassCorrelatedObservationSequences

Container for Observation Sequences (Observations whose values are contained in LIST<>’s) having values correlated with each other. Each contained Observation Sequence LIST<> must be the same length. Values in the LIST<>’s are correlated based on index. E.g. the values in position 2 in all the LIST<>’s are correlated. This is analogous to a table where each column is an Observation Sequence with a LIST<> of values, and each row in the table is a correlation between the columns. For example, a 12-lead ECG would contain 13 sequences: one sequence for time, and a sequence for each of the 12 leads.

ActClassCoverage

When used in the EVN mood, this concept means with respect to a covered party:

  1. A health care insurance policy or plan that is contractually binding between two or more parties; or
  2. A health care program, usually administered by government entities, that provides coverage to persons determined eligible under the terms of the program.
    • When used in the definition (DEF) mood, COV means potential coverage for a patient who may or may not be a covered party.
    • The concept’s meaning is fully specified by the choice of ActCoverageTypeCode (abstract) ActProgramCode or ActInsurancePolicyCode.
ActClassDetectedIssue

An observation identifying a potential adverse outcome as a result of an Act or combination of Acts. Examples: Detection of a drug-drug interaction; Identification of a late-submission for an invoice; Requesting discharge for a patient who does not meet hospital-defined discharge criteria. Discussion: This class is commonly used for identifying ‘business rule’ or ‘process’ problems that may result in a refusal to carry out a particular request. In some circumstances it may be possible to ‘bypass’ a problem by modifying the request to acknowledge the issue and/or by providing some form of mitigation. Constraints: the Act or Acts that may cause the the adverse outcome are the target of a subject ActRelationship. The subbtypes of this concept indicate the type of problem being detected (e.g. drug-drug interaction) while the Observation.value is used to repesent a specific problem code (e.g. specific drug-drug interaction id).

ActClassDeterminantPeptide

Description:A determinant peptide in a polypeptide as described by polypeptide.

ActClassDiagnosticImage

Class for holding attributes unique to diagnostic images.

ActClassDiet

No description

ActClassDisciplinaryAction

An action taken with respect to a subject Entity by a regulatory or authoritative body with supervisory capacity over that entity. The action is taken in response to behavior by the subject Entity that body finds to be undesirable. Suspension, license restrictions, monetary fine, letter of reprimand, mandated training, mandated supervision, etc.Examples:

ActClassDocument

Specialization of Act to add the characteristics unique to document management services.

ActClassDocumentBody

A context that distinguishes the body of a document from the document header. This is seen, for instance, in HTML documents, which have discrete <head> and <body> elements.

ActClassDocumentSection

A context that subdivides the body of a document. Document sections are typically used for human navigation, to give a reader a clue as to the expected content. Document sections are used to organize and provide consistency to the contents of a document body. Document sections can contain document sections and can contain entries.

ActClassElectronicHealthRecord

A context that comprises all compositions. The EHR is an extract that includes the entire chart. NOTE: In an exchange scenario, an EHR is a specialization of an extract.

ActClassEncounter

An interaction between a patient and healthcare participant(s) for the purpose of providing patient service(s) or assessing the health status of a patient. For example, outpatient visit to multiple departments, home health support (including physical therapy), inpatient hospital stay, emergency room visit, field visit (e.g., traffic accident), office visit, occupational therapy, telephone call.

ActClassExposure

The action of coming into sufficient physical proximity to allow physical or chemical interaction. Examples include: exposure to radiation, inhalation of peanut aerosol or viral particles. This includes intended exposure (e.g. administering a drug product) as well as accidental or environmental exposure. Actual vs. potential exposure can be differentiated using Act.uncertaintyCode. The agent to which the subject was exposed is conveyed as a Direct participation or specialization there-of. Constraints: The following Participations should be used with the following Roles and Entities to distinguish the specific entities:

  • The exposed entity is the entity of interest that is the recipient of the exposure and potentially affected. This is conveyed through the subject (SBJ) Participation.
  • An entity that has carried the agent transmitted in the exposure is the “exposure source” (EXSRC). For example:
    • a person or animal who carried an infectious disease and interacts (EXSRC) with another person or animal (SBJ) transmitting the disease agent; or
    • a place or other environment (EXSRC) and a person or animal (SBJ) who is exposed in the presence of this environment.
  • When it is unknown whether a participating entity is the source of the agent (EXSRC) or the target of the transmission (SBJ), also known as “exposure contact”, the “participant” (PART) is used.
  • The substance to which the subject is exposed that carries the exposure agent or the chemical substance of interest itself, participates as a “consumable” (CSM). There are at least two configurations: (a) the player of the Role that participates as CSM is the chemical or biological substance mixed or carried by the scoper-entity of the Role (e.g., ingredient role); or (b) the player of the Role that participates as CSM is a mixture known to contain the chemical, radiological or biological substance of interest.
  • The device specifically used to administer the substance is associated using the device (DEV) Participation. This may be a device intentionally used (such as applicator device) or it may be a thing that accidentally carried this substance; for instance, an infected needle or knife. The same entity may be related in the act as both EXSRC and DEV.
ActClassExpressionLevel

Description:An expression level of genes/proteins or other expressed genomic entities.

ActClassExtract

This context represents the part of a patient record conveyed in a single communication. It is drawn from a providing system for the purposes of communication to a requesting process (which might be another repository, a client application or a middleware service such as an electronic guideline engine), and supporting the faithful inclusion of the communicated data in the receiving system. An extract may be the entirety of the patient record as held by the sender or it may be a part of that record (e.g. changes since a specified date). An extract contains folders or compositions. An extract cannot contain another extract.

ActClassFinancialAdjudication

A transformation process where a requested invoice is transformed into an agreed invoice. Represents the adjudication processing of an invoice (claim). Adjudication results can be adjudicated as submitted, with adjustments or refused. Adjudication results comprise 2 components: the adjudication processing results and a restated (or adjudicated) invoice or claim

ActClassFinancialContract

A contract whose value is measured in monetary terms.

ActClassFinancialTransaction

A sub-class of Act representing any transaction between two accounts whose value is measured in monetary terms. In the “intent” mood, communicates a request for a transaction to be initiated, or communicates a transfer of value between two accounts. In the “event” mood, communicates the posting of a transaction to an account.

ActClassFolder

No description

ActClassGenomicObservation

Description:An observation of genomic phenomena.

ActClassGrouper

No description

ActClassIncident

An event that occurred outside of the control of one or more of the parties involved. Includes the concept of an accident.

ActClassInform

The act of transmitting information and understanding about a topic to a subject where the participation association must be SBJ. Discussion: This act may be used to request that a patient or provider be informed about an Act, or to indicate that a person was informed about a particular act.

ActClassInformation

Sender sends payload to addressee as information. Addressee does not have responsibilities beyond serving addressee’s own interest (i.e., read and memorize if you see fit). This is equivalent to an FYI on a memo.

ActClassInvestigation

An formalized inquiry into the circumstances surrounding a particular unplanned event or potential event for the purposes of identifying possible causes and contributing factors for the event. This investigation could be conducted at a local institutional level or at the level of a local or national government.

ActClassInvoiceElement

Represents concepts related to invoice processing in health care

ActClassJurisdictionalPolicy

Description:A mandate, regulation, obligation, requirement, rule, or expectation unilaterally imposed by a jurisdiction on:

  • The activity of another party
  • The behavior of another party
  • The manner in which an act is executed Examples:A jurisdictional mandate regarding the prescribing and dispensing of a particular medication. A jurisdictional privacy or security regulation dictating the manner in which personal health information is disclosed. A jurisdictional requirement that certain services or health conditions are reported to a monitoring program, e.g., immunizations, methadone treatment, or cancer registries.
ActClassLeftLateralDecubitus

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassLocus

Description:The position of a gene (or other significant sequence) on the genome.

ActClassMonitoringProgram

An officially or unofficially instituted program to track acts of a particular type or categorization.

ActClassObservation

Description:An act that is intended to result in new information about a subject. The main difference between Observations and other Acts is that Observations have a value attribute. The code attribute of Observation and the value attribute of Observation must be considered in combination to determine the semantics of the observation. Discussion: Structurally, many observations are name-value-pairs, where the Observation.code (inherited from Act) is the name and the Observation.value is the value of the property. Such a construct is also known as a variable (a named feature that can assume a value) hence, the Observation class is always used to hold generic name-value-pairs or variables, even though the variable valuation may not be the result of an elaborate observation method. It may be a simple answer to a question or it may be an assertion or setting of a parameter. As with all Act statements, Observation statements describe what was done, and in the case of Observations, this includes a description of what was actually observed (results or answers); and those results or answers are part of the observation and not split off into other objects. The method of action is asserted by the Observation classCode or its subclasses at the least granular level, by the Observation.code attribute value at the medium level of granularity, and by the attribute value of observation.methodCode when a finer level of granularity is required. The method in whole or in part may also appear in the attribute value of Observation.value when using coded data types to express the value of the attribute. Relevant aspects of methodology may also be restated in value when the results themselves imply or state a methodology. An observation may consist of component observations each having their own Observation.code and Observation.value. In this case, the composite observation may not have an Observation.value for itself. For instance, a white blood cell count consists of the sub-observations for the counts of the various granulocytes, lymphocytes and other normal or abnormal blood cells (e.g., blasts). The overall white blood cell count Observation itself may therefore not have a value by itself (even though it could have one, e.g., the sum total of white blood cells). Thus, as long as an Act is essentially an Act of recognizing and noting information about a subject, it is an Observation, regardless of whether it has a simple value by itself or whether it has sub-observations. Even though observations are professional acts (see Act) and as such are intentional actions, this does not require that every possible outcome of an observation be pondered in advance of it being actually made. For instance, differential white blood cell counts (WBC) rarely show blasts, but if they do, this is part of the WBC observation even though blasts might not be predefined in the structure of a normal WBC. Clinical documents commonly have Subjective and Objective findings, both of which are kinds of Observations. In addition, clinical documents commonly contain Assessments, which are also kinds of Observations. Thus, the establishment of a diagnosis is an Observation. Examples:

  • Recording the results of a Family History Assessment
  • Laboratory test and associated result
  • Physical exam test and associated result
  • Device temperature
  • Soil lead level
ActClassObservationSeries

Container for Correlated Observation Sequences sharing a common frame of reference. All Observations of the same cd must be comparable and relative to the common frame of reference. For example, a 3-channel ECG device records a 12-lead ECG in 4 steps (3 leads at a time). Each of the separate 3-channel recordings would be in their own “OBSCOR”. And, all 4 OBSCOR would be contained in one OBSSER because all the times are relative to the same origin (beginning of the recording) and all the ECG signals were from a fixed set of electrodes.

ActClassOrganizationalPolicy

Description:A mandate, obligation, requirement, rule, or expectation unilaterally imposed by an organization on:

  • The activity of another party
  • The behavior of another party
  • The manner in which an act is executed Examples:A clinical or research protocols imposed by a payer, a malpractice insurer, or an institution to which a provider must adhere. A mandate imposed by a denominational institution for a provider to provide or withhold certain information from the patient about treatment options.
ActClassOutbreak

An outbreak represents a series of public health cases. The date on which an outbreak starts is the earliest date of onset among the cases assigned to the outbreak, and its ending date is the last date of onset among the cases assigned to the outbreak.

ActClassOutbreak2

An Outbreak is a concern resulting from a series of public health cases.

ActClassOverlayRoi

A Region of Interest (ROI) specified for an image using an overlay shape. Typically used to make reference to specific regions in images, e.g., to specify the location of a radiologic finding in an image or to specify the site of a physical finding by “circling” a region in a schematic picture of a human body. The units of the coordinate values are in pixels. The origin is in the upper left hand corner, with positive X values going to the right and positive Y values going down. The relationship between a ROI and its referenced Act is specified through an ActRelationship of type “subject” (SUBJ), which must always be present.

ActClassPhenotype

Description:A genomic phenomenon that is expressed externally in the organism.

ActClassPolicy

Description:A mandate, regulation, obligation, requirement, rule, or expectation unilaterally imposed by one party on:

  • The activity of another party
  • The behavior of another party
  • The manner in which an act is executed
ActClassPolypeptide

Description:A polypeptide resulting from the translation of a gene.

ActClassPosition

An observation denoting the physical location of a person or thing based on a reference coordinate system.

ActClassPositionAccuracy

Description:An observation representing the degree to which the assignment of the spatial coordinates, based on a matching algorithm by a geocoding engine against a reference spatial database, matches true or accepted values.

ActClassPositionCoordinate

Description:An observation representing one of a set of numerical values used to determine the position of a place. The name of the coordinate value is determined by the reference coordinate system.

ActClassProcedure

An Act whose immediate and primary outcome (post-condition) is the alteration of the physical condition of the subject. Examples: : Procedures may involve the disruption of some body surface (e.g. an incision in a surgical procedure), but they also include conservative procedures such as reduction of a luxated join, chiropractic treatment, massage, balneotherapy, acupuncture, shiatsu, etc. Outside of clinical medicine, procedures may be such things as alteration of environments (e.g. straightening rivers, draining swamps, building dams) or the repair or change of machinery etc.

ActClassProcessStep

ActCodeProcessStep - Property applies to value sets that contain classCode values in structural vocabularies. It identifies by name the Concept Domain(s) that represent(s) the concepts that are sub-types of the concept collection established by the value sets of class codes.

ActClassProne

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassPublicHealthCase

A public health case is an Observation representing a condition or event that has a specific significance for public health. Typically it involves an instance or instances of a reportable infectious disease or other condition. The public health case can include a health-related event concerning a single individual or it may refer to multiple health-related events that are occurrences of the same disease or condition of interest to public health. An outbreak involving multiple individuals may be considered as a type of public health case. A public health case definition (Act.moodCode = “definition”) includes the description of the clinical, laboratory, and epidemiologic indicators associated with a disease or condition of interest to public health. There are case definitions for conditions that are reportable, as well as for those that are not. There are also case definitions for outbreaks. A public health case definition is a construct used by public health for the purpose of counting cases, and should not be used as clinical indications for treatment. Examples include AIDS, toxic-shock syndrome, and salmonellosis and their associated indicators that are used to define a case.

ActClassPublicHealthCase2

A public health case is a Concern about an observation or event that has a specific significance for public health. The creation of a PublicHealthCase initiates the tracking of the object of concern. The decision to track is related to but somewhat independent of the underlying event or observation.

ActClassROI

Regions of Interest (ROI) within a subject Act. Primarily used for making secondary observations on a subset of a subject observation. The relationship between a ROI and its referenced Act is specified through an ActRelationship of type “subject” (SUBJ), which must always be present.

ActClassRecordOrganizer

No description

ActClassRegistration

Represents the act of maintaining information about the registration of its associated registered subject. The subject can be either an Act or a Role, and includes subjects such as lab exam definitions, drug protocol definitions, prescriptions, persons, patients, practitioners, and equipment. The registration may have a unique identifier - separate from the unique identification of the subject - as well as a core set of related participations and act relationships that characterize the registration event and aid in the disposition of the subject information by a receiving system.Usage notes:

ActClassReverseTrendelenburg

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassReview

The act of examining and evaluating the subject, usually another act. For example, “This prescription needs to be reviewed in 2 months.”

ActClassRightLateralDecubitus

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassRoot

A record of something that is being done, has been done, can be done, or is intended or requested to be done. Examples:The kinds of acts that are common in health care are (1) a clinical observation, (2) an assessment of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such as medication, surgery, physical and psychological therapy), (5) assisting, monitoring or attending, (6) training and education services to patients and their next of kin, (7) and notary services (such as advanced directives or living will), (8) editing and maintaining documents, and many others. Discussion and Rationale: Acts are the pivot of the RIM; all domain information and processes are represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of intentional and occasionally non-intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an action. Acts connect to Entities in their Roles through Participations and connect to other Acts through ActRelationships. Participations are the authors, performers and other responsible parties as well as subjects and beneficiaries (which includes tools and material used in the performance of the act, which are also subjects). The moodCode distinguishes between Acts that are meant as factual records, vs. records of intended or ordered services, and the other modalities in which act can appear. One of the Participations that all acts have (at least implicitly) is a primary author, who is responsible of the Act and who “owns” the act. Responsibility for the act means responsibility for what is being stated in the Act and as what it is stated. Ownership of the act is assumed in the sense of who may operationally modify the same act. Ownership and responsibility of the Act is not the same as ownership or responsibility of what the Act-object refers to in the real world. The same real world activity can be described by two people, each being the author of their Act, describing the same real world activity. Yet one can be a witness while the other can be a principal performer. The performer has responsibilities for the physical actions; the witness only has responsibility for making a true statement to the best of his or her ability. The two Act-instances may even disagree, but because each is properly attributed to its author, such disagreements can exist side by side and left to arbitration by a recipient of these Act-instances. In this sense, an Act-instance represents a “statement” according to Rector and Nowlan (1991) [Foundations for an electronic medical record. Methods Inf Med. 30.] Rector and Nowlan have emphasized the importance of understanding the medical record not as a collection of facts, but “a faithful record of what clinicians have heard, seen, thought, and done.” Rector and Nowlan go on saying that “the other requirements for a medical record, e.g., that it be attributable and permanent, follow naturally from this view.” Indeed the Act class is this attributable statement, and the rules of updating acts (discussed in the state-transition model, see Act.statusCode) versus generating new Act-instances are designed according to this principle of permanent attributable statements. Rector and Nolan focus on the electronic medical record as a collection of statements, while attributed statements, these are still mostly factual statements. However, the Act class goes beyond this limitation to attributed factual statements, representing what is known as “speech-acts” in linguistics and philosophy. The notion of speech-act includes that there is pragmatic meaning in language utterances, aside from just factual statements; and that these utterances interact with the real world to change the state of affairs, even directly cause physical activities to happen. For example, an order is a speech act that (provided it is issued adequately) will cause the ordered action to be physically performed. The speech act theory has culminated in the seminal work by Austin (1962) [How to do things with words. Oxford University Press]. An activity in the real world may progress from defined, through planned and ordered to executed, which is represented as the mood of the Act. Even though one might think of a single activity as progressing from planned to executed, this progression is reflected by multiple Act-instances, each having one and only one mood that will not change along the Act-instance life cycle. This is because the attribution and content of speech acts along this progression of an activity may be different, and it is often critical that a permanent and faithful record be maintained of this progression. The specification of orders or promises or plans must not be overwritten by the specification of what was actually done, so as to allow comparing actions with their earlier specifications. Act-instances that describe this progression of the same real world activity are linked through the ActRelationships (of the relationship category “sequel”). Act as statements or speech-acts are the only representation of real world facts or processes in the HL7 RIM. The truth about the real world is constructed through a combination (and arbitration) of such attributed statements only, and there is no class in the RIM whose objects represent “objective state of affairs” or “real processes” independent from attributed statements. As such, there is no distinction between an activity and its documentation. Every Act includes both to varying degrees. For example, a factual statement made about recent (but past) activities, authored (and signed) by the performer of such activities, is commonly known as a procedure report or original documentation (e.g., surgical procedure report, clinic note etc.). Conversely, a status update on an activity that is presently in progress, authored by the performer (or a close observer) is considered to capture that activity (and is later superceded by a full procedure report). However, both status update and procedure report are acts of the same kind, only distinguished by mood and state (see statusCode) and completeness of the information.

ActClassScopeOfPracticePolicy

Description:An ethical or clinical obligation, requirement, rule, or expectation imposed or strongly encouraged by organizations that oversee particular clinical domains or provider certification which define the boundaries within which a provider may practice and which may have legal basis or ramifications on:

  • The activity of another party
  • The behavior of another party
  • The manner in which an act is executed Examples:An ethical obligation for a provider to fully inform a patient about all treatment options. An ethical obligation for a provider not to disclose personal health information that meets certain criteria, e.g., where disclosure might result in harm to the patient or another person. The set of health care services which a provider is credentialed or privileged to provide.
ActClassSemiFowlers

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassSitting

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassSpecimenCollection

A procedure for obtaining a specimen from a source entity.

ActClassSpecimenObservation

An observation on a specimen in a laboratory environment that may affect processing, analysis or result interpretation

ActClassSpecimenTreatment

A procedure or treatment performed on a specimen to prepare it for analysis

ActClassStandardOfPracticePolicy

Description:A requirement, rule, or expectation typically documented as guidelines, protocols, or formularies imposed or strongly encouraged by an organization that oversees or has authority over the practices within a domain, and which may have legal basis or ramifications on:

  • The activity of another party
  • The behavior of another party
  • The manner in which an act is executed Examples:A payer may require a prescribing provider to adhere to formulary guidelines. An institution may adopt clinical guidelines and protocols and implement these within its electronic health record and decision support systems.
ActClassStanding

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassStateTransitionControl

Sender transmits a status change pertaining to the focal act of the payload. This status of the focal act is the final state of the state transition. This can be either a request or a command, according to the mood of the control act.

ActClassStorage

The act of putting something away for safe keeping. The “something” may be physical object such as a specimen, or information, such as observations regarding a specimen.

ActClassSubjectBodyPosition

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassSubjectPhysicalPosition

The spatial relationship of a subject whether human, other animal, or plant, to a frame of reference such as gravity or a collection device.

ActClassSubstanceAdministration

The act of introducing or otherwise applying a substance to the subject. Discussion: The effect of the substance is typically established on a biochemical basis, however, that is not a requirement. For example, radiotherapy can largely be described in the same way, especially if it is a systemic therapy such as radio-iodine. This class also includes the application of chemical treatments to an area. Examples: Chemotherapy protocol; Drug prescription; Vaccination record

ActClassSubstanceExtraction

No description

ActClassSubstitution

Definition: Indicates that the subject Act has undergone or should undergo substitution of a type indicated by Act.code. Rationale: Used to specify “allowed” substitution when creating orders, “actual” susbstitution when sending events, as well as the reason for the substitution and who was responsible for it.

ActClassSupine

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassSupply

Supply orders and deliveries are simple Acts that focus on the delivered product. The product is associated with the Supply Act via Participation.typeCode=”product”. With general Supply Acts, the precise identification of the Material (manufacturer, serial numbers, etc.) is important. Most of the detailed information about the Supply should be represented using the Material class. If delivery needs to be scheduled, tracked, and billed separately, one can associate a Transportation Act with the Supply Act. Pharmacy dispense services are represented as Supply Acts, associated with a SubstanceAdministration Act. The SubstanceAdministration class represents the administration of medication, while dispensing is supply.

ActClassTopic

A group of entries within a composition that are related to a common clinical theme - such as a specific disorder or problem, prevention, screening and provision of contraceptive services. A topic may contain categories and entries.

ActClassTransfer

Definition: The act of transferring information without the intent of imparting understanding about a topic to the subject that is the recipient or holder of the transferred information where the participation association must be RCV or HLD.

ActClassTransmissionExposure

Description: A transmission exposure act describes the proximity (time and location) over which the participating source entity was capable of transmitting a physical (including energy), chemical or biological substance agent to another entity. The transmission exposure act is used in conjunction with acquisition exposure acts as part of an analysis technique for contact tracing. Although an exposure can be decomposed into transmission and acquisition exposures, there is no requirement that all exposures be treated in this fashion. Constraints: The Transmission Exposure inherits the participation constraints that apply to Exposure with the following exception. The EXPTRGT (exposure target) participation must never be associated with the Transmission Exposure either directly or via context conduction.

ActClassTransportation

Transportation is the moving of a payload (people or material) from a location of origin to a destination location. Thus, any transport service has the three target instances of type payload, origin, and destination, besides the targets that are generally used for any service (i.e., performer, device, etc.)

ActClassTrendelenburg

Deprecation Comment: This value set has been deprecated because its root code was deprecated in an earlier vocabulary release.

ActClassVerification

An act which describes the process whereby a ‘verifying party’ validates either the existence of the Role attested to by some Credential or the actual Vetting act and its details.

ActClassWorkingList

Working list collects a dynamic list of individual instances of Act via ActRelationship which reflects the need of an individual worker, team of workers, or an organization to manage lists of acts for many different clinical and administrative reasons. Examples of working lists include problem lists, goal lists, allergy lists, and to-do lists.

ActCodeProcessStep

No description

ActConditionList

List of condition observations.

ActConsentDirective

ActConsentDirective codes are used to specify the type of Consent Directive to which a Consent Directive Act conforms.

ActConsentDirectiveType

ActConsentDirective and ActConsentType codes are used to specify the type of Consent Directive or Consent Type to which, for example, a Consent Act conforms, to which a Security Observation (Security Label) refers to, or to which a Privacy or Security Act refers. > Steward: Security WG

ActConsentInformationAccessOverrideReason

Definition: Use to convey the reason that a provider may or has accessed personal healthcare information. Typically, this involves overriding the subject’s consent directives.

ActConsentType

Definition: The type of consent directive, e.g., to consent or dissent to collect, access, or use in specific ways within an EHRS or for health information exchange; or to disclose health information for purposes such as research.

ActContainerRegistrationCode

Constrains the ActCode to the domain of Container Registration

ActControlVariable

An observation form that determines parameters or attributes of an Act. Examples are the settings of a ventilator machine as parameters of a ventilator treatment act; the controls on dillution factors of a chemical analyzer as a parameter of a laboratory observation act; the settings of a physiologic measurement assembly (e.g., time skew) or the position of the body while measuring blood pressure. Control variables are forms of observations because just as with clinical observations, the Observation.code determines the parameter and the Observation.value assigns the value. While control variables sometimes can be observed (by noting the control settings or an actually measured feedback loop) they are not primary observations, in the sense that a control variable without a primary act is of no use (e.g., it makes no sense to record a blood pressure position without recording a blood pressure, whereas it does make sense to record a systolic blood pressure without a diastolic blood pressure).

ActCoverageAssessmentObservationValue

Codes specify the category of observation, evidence, or document used to assess for services, e.g., discharge planning, or to establish eligibility for coverage under a policy or program. The type of evidence is coded as observation values.

ActCoverageAuthorizationConfirmationCode

Indication of authorization for healthcare service(s) and/or product(s). If authorization is approved, funds are set aside.

ActCoverageConfirmationCode

Response to an insurance coverage eligibility query or authorization request.

ActCoverageLimitCode

Criteria that are applicable to the authorized coverage.

ActCoverageMaximaCodes

Definition: Codes representing the maximum coverate or financial participation requirements.

ActCoverageQuantityLimitCode

Maximum amount paid or maximum number of services/products covered; or maximum amount or number covered during a specified time period under the policy or program.

ActCoverageReason

Description:Codes used to specify reasons or criteria relating to coverage provided under a policy or program. May be used to convey reasons pertaining to coverage contractual provisions, including criteria for eligibility, coverage limitations, coverage maximums, or financial participation required of covered parties.

ActCoverageTypeCode

Definition: Set of codes indicating the type of insurance policy or program that pays for the cost of benefits provided to covered parties.

ActCredentialedCareCode

Description:The type and scope of legal and/or professional responsibility taken-on by the performer of the Act for a specific subject of care as described by a credentialing agency, i.e. government or non-government agency. Failure in executing this Act may result in loss of credential to the person or organization who participates as performer of the Act. Excludes employment agreements. Example:Hospital license; physician license; clinic accreditation.

ActCredentialedCareProvisionPersonCode

Description:The type and scope of legal and/or professional responsibility taken-on by the performer of the Act for a specific subject of care as described by an agency for credentialing individuals.

ActCredentialedCareProvisionProgramCode

Description:The type and scope of legal and/or professional responsibility taken-on by the performer of the Act for a specific subject of care as described by an agency for credentialing individuals.

ActDetectedIssueCode

Identifies types of detected issues for Act class “ALRT”

ActDetectedIssueManagementCode

Codes dealing with the management of Detected Issue observations

ActDietCode

Code set to define specialized/allowed diets

ActEmergencyEncounterCode

Definition:A patient encounter that takes place at a dedicated healthcare service delivery location where the patient receives immediate evaluation and treatment, provided until the patient can be discharged or responsibility for the patient’s care is transferred elsewhere (for example, the patient could be admitted as an inpatient or transferred to another facility.)

ActEncounterAccommodationCode

Accommodation type. In Intent mood, represents the accommodation type requested. In Event mood, represents accommodation assigned/used. In Definition mood, represents the available accommodation type.

ActEncounterCode

Domain provides codes that qualify the ActEncounterClass (ENC)

ActExposureCode

Concepts that identify the type or nature of exposure interaction. Examples include “household”, “care giver”, “intimate partner”, “common space”, “common substance”, etc. to further describe the nature of interaction.

ActExposureLevelCode

A qualitative measure of the degree of exposure to the causative agent. This includes concepts such as “low”, “medium” and “high”. This quantifies how the quantity that was available to be administered to the target differs from typical or background levels of the substance.

ActFieldEncounterCode

Definition:A patient encounter that takes place both outside a dedicated service delivery location and outside a patient’s residence. Example locations might include an accident site and at a supermarket.

ActFinancialStatusObservationValue

Code specifying financial indicators used to assess or establish eligibility for coverage under a policy or program; e.g., pay stub; tax or income document; asset document; living expenses.

ActFinancialTransactionCode

No description

ActHealthInformationManagementReason

The rationale or purpose for an act relating to health information management, such as archiving information for the purpose of complying with an organization policy or jurisdictional law relating to data retention.

ActHealthInsuranceTypeCode

Definition: Set of codes indicating the type of health insurance policy that covers health services provided to covered parties. A health insurance policy is a written contract for insurance between the insurance company and the policyholder, and contains pertinent facts about the policy owner (the policy holder), the health insurance coverage, the insured subscribers and dependents, and the insurer. Health insurance is typically administered in accordance with a plan, which specifies (1) the type of health services and health conditions that will be covered under what circumstances (e.g., exclusion of a pre-existing condition, service must be deemed medically necessary; service must not be experimental; service must provided in accordance with a protocol; drug must be on a formulary; service must be prior authorized; or be a referral from a primary care provider); (2) the type and affiliation of providers (e.g., only allopathic physicians, only in network, only providers employed by an HMO); (3) financial participations required of covered parties (e.g., co-pays, coinsurance, deductibles, out-of-pocket); and (4) the manner in which services will be paid (e.g., under indemnity or fee-for-service health plans, the covered party typically pays out-of-pocket and then file a claim for reimbursement, while health plans that have contractual relationships with providers, i.e., network providers, typically do not allow the providers to bill the covered party for the cost of the service until after filing a claim with the payer and receiving reimbursement).

ActHomeHealthEncounterCode

Definition:Healthcare encounter that takes place in the residence of the patient or a designee

ActIncidentCode

Set of codes indicating the type of incident or accident.

ActIneligibilityReason

Identifies the reason or rational for why a person is not eligibile for benefits under an insurance policy. Examples are client deceased & adopted client has been given a new policy identifier.

ActInformationAccess

Definition: Consent to access healthcare information.

ActInformationAccessCode

The type of personal health information to which the subject of the information, or the delegate of the subject, consents or dissents to authorize access.

ActInformationAccessContextCode

Conveyance of the type of context in which authorization given under jurisdictional law, by organizational policy, or by a patient consent directive permits the collection, access, use or disclosure of specified patient health information. Steward: Security WG

ActInformationCategoryCode

Definition:Indicates the set of information types which may be manipulated or referenced, such as for recommending access restrictions.

ActInformationSensitivityPolicy

ActSensitivity codes are used to bind information to an Act.confidentialityCode according to local sensitivity policy so that those confidentiality codes can then govern its handling across enterprises. Internally to a policy domain, however, local policies guide the access control system on how end users in that policy domain are able to use information tagged with these sensitivity values.

ActInformationTransferCode

Description: Conveyance of the type of information transfer protocol.

ActInjuryCodeCSA

No description

ActInpatientEncounterCode

An inpatient encounter is an encounter in which the patient is admitted to a hospital or equivalent facility.

ActInsurancePolicyCode

Set of codes indicating the type of insurance policy or other source of funds to cover healthcare costs.

ActInsuranceTypeCode

Definition: Set of codes indicating the type of insurance policy. Insurance, in law and economics, is a form of risk management primarily used to hedge against the risk of potential financial loss. Insurance is defined as the equitable transfer of the risk of a potential loss, from one entity to another, in exchange for a premium and duty of care. A policy holder is an individual or an organization enters into a contract with an underwriter which stipulates that, in exchange for payment of a sum of money (a premium), one or more covered parties (insureds) is guaranteed compensation for losses resulting from certain perils under specified conditions. The underwriter analyzes the risk of loss, makes a decision as to whether the risk is insurable, and prices the premium accordingly. A policy provides benefits that indemnify or cover the cost of a loss incurred by a covered party, and may include coverage for services required to remediate a loss. An insurance policy contains pertinent facts about the policy holder, the insurance coverage, the covered parties, and the insurer. A policy may include exemptions and provisions specifying the extent to which the indemnification clause cannot be enforced for intentional tortious conduct of a covered party, e.g., whether the covered parties are jointly or severably insured. Discussion: In contrast to programs, an insurance policy has one or more policy holders, who own the policy. The policy holder may be the covered party, a relative of the covered party, a partnership, or a corporation, e.g., an employer. A subscriber of a self-insured health insurance policy is a policy holder. A subscriber of an employer sponsored health insurance policy is holds a certificate of coverage, but is not a policy holder; the policy holder is the employer. See CoveredRoleType.

ActInvoiceAdjudicationPaymentCode

Codes representing a grouping of invoice elements (totals, sub-totals), reported through a Payment Advice or a Statement of Financial Activity (SOFA). The code can represent summaries by day, location, payee and other cost elements such as bonus, retroactive adjustment and transaction fees.

ActInvoiceAdjudicationPaymentGroupCode

Codes representing adjustments to a Payment Advice such as retroactive, clawback, garnishee, etc.

ActInvoiceAdjudicationPaymentSummaryCode

Codes representing a grouping of invoice elements (totals, sub-totals), reported through a Payment Advice or a Statement of Financial Activity (SOFA). The code can represent summaries by day, location, payee, etc.

ActInvoiceDetailClinicalProductCode

An identifying data string for healthcare products.

ActInvoiceDetailCode

Codes representing a service or product that is being invoiced (billed). The code can represent such concepts as “office visit”, “drug X”, “wheelchair” and other billable items such as taxes, service charges and discounts.

ActInvoiceDetailDrugProductCode

An identifying data string for A substance used as a medication or in the preparation of medication.

ActInvoiceDetailGenericAdjudicatorCode

The billable item codes to identify adjudicator specified components to the total billing of a claim.

ActInvoiceDetailGenericCode

The detail item codes to identify charges or changes to the total billing of a claim due to insurance rules and payments.

ActInvoiceDetailGenericModifierCode

The billable item codes to identify modifications to a billable item charge. As for example after hours increase in the office visit fee.

ActInvoiceDetailGenericProviderCode

The billable item codes to identify provider supplied charges or changes to the total billing of a claim.

ActInvoiceDetailPreferredAccommodationCode

An identifying data string for medical facility accommodations.

ActInvoiceDetailTaxCode

The billable item codes to identify modifications to a billable item charge by a tax factor applied to the amount. As for example 7% provincial sales tax.

ActInvoiceElementCode

Type of invoice element that is used to assist in describing an Invoice that is either submitted for adjudication or for which is returned on adjudication results.

ActInvoiceElementModifier

Processing consideration and clarification codes.

ActInvoiceElementSummaryCode

Identifies the different types of summary information that can be reported by queries dealing with Statement of Financial Activity (SOFA). The summary information is generally used to help resolve balance discrepancies between providers and payors.

ActInvoiceGroupCode

Type of invoice element that is used to assist in describing an Invoice that is either submitted for adjudication or for which is returned on adjudication results. Invoice elements of this type signify a grouping of one or more children (detail) invoice elements. They do not have intrinsic costing associated with them, but merely reflect the sum of all costing for it’s immediate children invoice elements.

ActInvoiceInterGroupCode

Type of invoice element that is used to assist in describing an Invoice that is either submitted for adjudication or for which is returned on adjudication results. Invoice elements of this type signify a grouping of one or more children (detail) invoice elements. They do not have intrinsic costing associated with them, but merely reflect the sum of all costing for it’s immediate children invoice elements. The domain is only specified for an intermediate invoice element group (non-root or non-top level) for an Invoice.

ActInvoiceOverrideCode

Includes coded responses that will occur as a result of the adjudication of an electronic invoice at a summary level and provides guidance on interpretation of the referenced adjudication results.

ActInvoicePaymentCode

No description

ActInvoiceRootGroupCode

Type of invoice element that is used to assist in describing an Invoice that is either submitted for adjudication or for which is returned on adjudication results. Invoice elements of this type signify a grouping of one or more children (detail) invoice elements. They do not have intrinsic costing associated with them, but merely reflect the sum of all costing for it’s immediate children invoice elements. Codes from this domain reflect the type of Invoice such as Pharmacy Dispense, Clinical Service and Clinical Product. The domain is only specified for the root (top level) invoice element group for an Invoice.

ActListCode

Provides codes associated with ActClass value of LIST (working list)

ActMedicalServiceCode

General category of medical service provided to the patient during their encounter.

ActMedicationList

List of medications.

ActMedicationTherapyDurationWorkingListCode

No description

ActMonitoringProtocolCode

Identifies types of monitoring programs

ActMood

A code distinguishing whether an Act is conceived of as a factual statement or in some other manner as a command, possibility, goal, etc. Constraints: An Act-instance must have one and only one moodCode value. The moodCode of a single Act-instance never changes. Mood is not state. To describe the progression of a business activity from defined to planned to executed, etc. one must instantiate different Act-instances in the different moods and link them using ActRelationship of general type “sequel”. (See ActRelationship.type.)

ActMoodActRequest

No description

ActMoodAppointment

A planned Act for a specific time and place.

ActMoodAppointmentRequest

A request for the booking of an appointment.

ActMoodCompletionTrack

These are moods describing activities as they progress in the business cycle, from defined, through planned and ordered to completed.

ActMoodCriterion

A criterion or condition over actual and potential services that must apply for an associated service to be considered. Matches records any ActMoodCompletionTrack moods.

ActMoodDefinition

A definition of a service (master). Historical note: in previous RIM versions, the definition mood was captured as a separate class hierarchy, called Master_service.

ActMoodDesire

No description

ActMoodEventCriterion

A criterion or condition over service events that must apply for an associated service to be considered.

ActMoodEventOccurrence

A service that actually happens, may be an ongoing service or a documentation of a past service. Historical note: in previous RIM versions, the event mood was captured as a separate class hierarchy, called Patient_service_event, and later Service_event.

ActMoodExpectation

Definition:An act that is considered likely to occur in the future. The essential feature of an act expressed in expectation mood is that it is likely to occur. An expectation may be desirable, undesirable or neutral in effect. Examples:Prognosis of a condition, Expected date of discharge from hospital, patient will likely need an emergency decompression of the intracranial pressure by morning. Discussion:INT (intent) reflects a plan for the future, which is a declaration to do something. This contrasts with expectation, which is a prediction that something will happen in the future. GOL (goal) reflects a hope rather than a prediction. RSK (risk) reflects a potential negative event that may or may not be expected to happen.

ActMoodGoal

Definition:An observation that is considered to be desirable to occur in the future. The essential feature of a goal is that if it occurs it would be considered as a marker of a positive outcome or of progress towards a positive outcome. Examples:Target weight below 80Kg, Stop smoking, Regain ability to walk, goal is to administer thrombolytics to candidate patients presenting with acute myocardial infarction. Discussion: INT (intent) reflects a plan for the future, which is a declaration to do something. This contrasts with goal which doesn’t represent an intention to act, merely a hope for an eventual result. A goal is distinct from the intended actions to reach that goal. “I will reduce the dose of drug x to 20mg” is an intent. “I hope to be able to get the patient to the point where I can reduce the dose of drug x to 20mg” is a goal. EXPEC (expectation) reflects a prediction rather than a hope. RSK (risk) reflects a potential negative event rather than a hope.

ActMoodIntent

An intention or plan to perform a service. Historical note: in previous RIM versions, the intent mood was captured as a separate class hierarchy, called Service_intent_or_order.

ActMoodOption

An option is an alternative set of property-value bindings. Options specify alternative sets of values, typically used in definitions or orders to describe alternatives. An option can only be used as a group, that is, all assigned values must be used together. Historical note: in HL7 v2.x option existed in the special case for alternative medication routes (RXR segment).

ActMoodPermission

A kind of service which is authorized to be performed.

ActMoodPermissionRequest

A request for authorization to perform a kind of service. This is distinct from RQO which is a request for an actual act. PERMRQ is merely a request for permission to perform an act.Discussion:

ActMoodPotential

No description

ActMoodPredicate

Any of the above service moods (e.g., event, intent, or goal) can be turned into a predicate used as a criterion to express conditionals (or queries.) However, currently we allow only criteria on service events.

ActMoodPromise

An intent to perform a service that has the strength of a commitment, i.e., other parties may rely on the originator of such promise that said originator will see to it that the promised act will be fulfilled. A promise can be either solicited or unsolicited.

ActMoodProposal

A non-mandated intent to perform an act. Used to record intents that are explicitly not Orders. Professional responsibility for the ‘proposal’ may or may not be present.

ActMoodRecommendation

A non-mandated intent to perform an act where a level of professional responsibility is being accepted by making the proposal.

ActMoodRequest

A request or order for a service is an intent directed from a placer (request author) to a fulfiller (service performer). Rationale: The concepts of a “request” and an “order” are viewed as different, because there is an implication of a mandate associated with order. In practice, however, this distinction has no general functional value in the inter-operation of health care computing. “Orders” are commonly refused for a variety of clinical and business reasons, and the notion of a “request” obligates the recipient (the fulfiller) to respond to the sender (the author). Indeed, in many regions, including Australia and Europe, the common term used is “request.” Thus, the concept embodies both notions, as there is no useful distinction to be made. If a mandate is to be associated with a request, this will be embodied in the “local” business rules applied to the transactions. Should HL7 desire to provide a distinction between these in the future, the individual concepts could be added as specializations of this concept. The critical distinction here, is the difference between this concept and an “intent”, of which it is a specialization. An intent involves decisions by a single party, the author. A request, however, involves decisions by two parties, the author and the fulfiller, with an obligation on the part of the fulfiller to respond to the request indicating that the fulfiller will indeed fulfill the request.

ActMoodResourceSlot

Periods of time on a schedule for a resource. Appointments occupy sets of one or more booked slots. A slot that is open for appointments is considered available and a slot that is held back for administrative purposes is considered blocked. A Resource slot that is “tentatively” booked is referred to as reserved.

ActMoodRisk

Definition:An act that may occur in the future and which is regarded as undesirable. The essential feature of a risk is that if it occurs this would be regarded as a marker of a negative outcome or of deterioration towards a negative outcome. Recording a risk indicates that it is seen as more likely to occur in the subject than in a general member of the population but does not mean it is expected to occur. Examples:Increased risk of DVT, at risk for sub-acute bacterial endocarditis. Discussion:Note: An observation in RSK mood expresses the undesirable act, and not the underlying risk factor. A risk factor that is present (e.g. obesity, smoking, etc) should be expressed in event mood. INT (intent) reflects a plan for the future, which is a declaration to do something. This contrasts with RSK (risk), which is the potential that something negative will occur that may or may not ever happen. GOL (goal) reflects a hope to achieve something. EXPEC (expectation) is the prediction of a positive or negative event. This contrasts with RSK (risk), which is the potential that something negative will occur that may or may not ever happen, and may not be expected to happen.

ActNoImmunizationReason

A coded description of the reason for why a patient did not receive a scheduled immunization. (important for public health strategy

ActNonObservationIndicationCode

Description:Concepts representing indications (reasons for clinical action) other than diagnosis and symptoms.

ActObservationList

No description

ActObservationVerificationType

Identifies the type of verification investigation being undertaken with respect to the subject of the verification activity. Examples:

  1. Verification of eligibility for coverage under a policy or program - aka enrolled/covered by a policy or program
  2. Verification of record - e.g., person has record in an immunization registry
  3. Verification of enumeration - e.g. NPI
  4. Verification of Board Certification - provider specific
  5. Verification of Certification - e.g. JAHCO, NCQA, URAC
  6. Verification of Conformance - e.g. entity use with HIPAA, conformant to the CCHIT EHR system criteria
  7. Verification of Provider Credentials
  8. Verification of no adverse findings - e.g. on National Provider Data Bank, Health Integrity Protection Data Base (HIPDB)
ActPatientAnnotationType

Provides a categorization for annotations recorded directly against the patient

ActPatientTransportationModeCode

Definition: Characterizes how a patient was or will be transported to the site of a patient encounter. Examples: Via ambulance, via public transit, on foot.

ActPaymentCode

Code identifying the method or the movement of payment instructions. Codes are drawn from X12 data element 591 (PaymentMethodCode)

ActPharmacySupplyType

Identifies types of dispensing events

ActPolicyType

Description:Types of policies that further specify the ActClassPolicy value set.

ActPriority

A code or set of codes (e.g., for routine, emergency,) specifying the urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen. Discussion: This attribute is used in orders to indicate the ordered priority, and in event documentation it indicates the actual priority used to perform the act. In definition mood it indicates the available priorities.

ActPriorityCallback

Filler should contact the placer (or target) to schedule the service. (Was “C” in HL7 version 2.3’s TQ-priority component.)

ActPrivacyLaw

ActPrivacyLaw codes may be associated with an Act or a Role to indicate the legal provision to which the assignment of an Act.confidentialityCode or Role.confidentialtyCode complies. May be used to further specify rationale for assignment of other ActPrivacyPolicy codes in the US realm, e.g., ETH and 42CFRPart2 can be differentiated from ETH and Title38Part1.

ActPrivacyPolicy

ActPrivacyPolicyType codes support the designation of the 1..* policies that are applicable to an Act such as a Consent Directive, a Role such as a VIP Patient, or an Entity such as a patient who is a minor. 1..* ActPrivacyPolicyType values may be associated with an Act or Role to indicate the policies that govern the assignment of an Act or Role confidentialityCode. Use of multiple ActPrivacyPolicyType values enables fine grain specification of applicable policies, but must be carefully assigned to ensure cogency and avoid creation of conflicting policy mandates. Statutory title may be named in the ActClassPolicy Act Act.title to specify which privacy policy is being referenced.

ActProductAcquisitionCode

The method that a product is obtained for use by the subject of the supply act (e.g. patient). Product examples are consumable or durable goods.

ActProgramTypeCode

Definition: A set of codes used to indicate coverage under a program. A program is an organized structure for administering and funding coverage of a benefit package for covered parties meeting eligibility criteria, typically related to employment, health, financial, and demographic status. Programs are typically established or permitted by legislation with provisions for ongoing government oversight. Regulations may mandate the structure of the program, the manner in which it is funded and administered, covered benefits, provider types, eligibility criteria and financial participation. A government agency may be charged with implementing the program in accordance to the regulation. Risk of loss under a program in most cases would not meet what an underwriter would consider an insurable risk, i.e., the risk is not random in nature, not financially measurable, and likely requires subsidization with government funds. Discussion: Programs do not have policy holders or subscribers. Program eligibles are enrolled based on health status, statutory eligibility, financial status, or age. Program eligibles who are covered parties under the program may be referred to as members, beneficiaries, eligibles, or recipients. Programs risk are underwritten by not for profit organizations such as governmental entities, and the beneficiaries typically do not pay for any or some portion of the cost of coverage. See CoveredPartyRoleType.

ActRelationshipAccounting

Codes that describe the relationship between an Act and a financial instrument such as a financial transaction, account or invoice element.

ActRelationshipActProvenance

Used to convey the relationship between two or more Acts for purpose of tracking provenance relationships such as the following:

  • A predecessor Act and a successor Act (e.g., a predecessor Lab Result from which a successor Lab Result in derived)
  • A ProvenanceEvent Act and a target Act for which it records the Provenance (e.g., a target Act is an update of a predecessor Act)
  • A predecessor ProvenanceEvent Act and a successor ProvenanceEvent Act UsageConstraint: The v:ActRelationshipActProvenance is intended to limit the types of relationships that could be conveyed by the ActRelationshipType codes to a subset that pertains to these provenance relations.
ActRelationshipActiveImmunizationAgainst

No description

ActRelationshipAdjunctCurativeIndication

No description

ActRelationshipAdjunctMitigation

No description

ActRelationshipAdjunctiveTreatment

No description

ActRelationshipArrival

The relationship that links to a Transportation Act (target) from another Act (source) indicating that the subject of the source Act entered into the source Act by means of the target Transportation act.

ActRelationshipAssignsName

Used to assign a “name” to a condition thread. Source is a condition node, target can be any service.

ActRelationshipAuthorizedBy

A relationship in which the target act authorizes or certifies the source act.

ActRelationshipBlocks

Definition: The source act is performed to block the effects of the target act. This act relationship should be used when describing near miss type incidents where potential harm could have occurred, but the action described in the source act blocked the potential harmful effects of the incident actually occurring.

ActRelationshipCheckpoint

A code specifying when in the course of an Act a precondition for the Act is evaluated (e.g., before the Act starts for the first time, before every repetition, after each repetition but not before the first, or throughout the entire time of the Act.) Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Before each step is executed and has preconditions these conditions are tested and if the test is positive, the Act has clearance for execution. The repeatNumber may indicate that an Act may be repeatedly executed. The checkpointCode is specifies when the precondition is checked and is analogous to the various conditional statements and loop constructs in programming languages “while-do” vs. “do-while” or “repeat-until” vs. “loop-exit”. For all checkpointCodes, except “end”, preconditions are being checked at the time when the preceding step of the plan has terminated and this step would be next in the sequence established by the sequenceNumber attribute. When the checkpointCode for a criterion of a repeatable Act is “end”, the criterion is tested only at the end of each repetition of that Act. When the condition holds true, the next repetition is ready for execution. When the checkpointCode is “entry” the criterion is checked at the beginning of each repetition (if any) whereas “beginning” means the criterion is checked only once before the repetition “loop” starts. The checkpointCode “through” is special in that it requires the condition to hold throughout the execution of the Act, even throughout a single execution. As soon as the condition turns false, the Act should receive an interrupt event (see interruptibleInd) and will eventually terminate. The checkpointCode “exit” is only used on a special plan step that represents a loop exit step. This allows an action plan to exit due to a condition tested inside the execution of this plan. Such exit criteria are sequenced with the other plan components using the ActRelationship.sequenceNumber.

ActRelationshipCheckpointBeginning

Condition is tested every time before execution of the service (WHILE condition DO service).

ActRelationshipCheckpointEnd

Condition is tested at the end of a repeated service execution. The service is repeated only if the condition is true (DO service WHILE condition).

ActRelationshipCheckpointEntry

Condition is tested once before the service is executed (IF condition THEN service).

ActRelationshipCheckpointExit

Condition is a loop checkpoint, i.e. it is a step of an activity plan and, if negative causes the containing loop to exit.

ActRelationshipCheckpointThrough

Condition must be true throughout the execution and the service is interrupted (asynchronously) as soon as the condition turns false (asynchronous WHILE loop). The service must be interruptible.

ActRelationshipCompliesWith

No description

ActRelationshipConcurrentWith

No description

ActRelationshipConditional

Specifies under what circumstances (target Act) the source-Act may, must, must not or has occurred

ActRelationshipContainsEndOf

No description

ActRelationshipContainsStartOf

No description

ActRelationshipContainsStartOfEndsBeforeEndOf

No description

ActRelationshipContainsTimeOf

No description

ActRelationshipCostTracking

Expresses values for describing the relationship relationship between an InvoiceElement or InvoiceElementGroup and a billable act.

ActRelationshipCoveredBy

A relationship in which the source act is covered by or is under the authority of a target act. A financial instrument such as an Invoice Element is covered by one or more specific instances of an Insurance Policy.

ActRelationshipCurativeIndication

No description

ActRelationshipDeparture

The relationship that links to a Transportation Act (target) from another Act (source) indicating that the subject of the source Act departed from the source Act by means of the target Transportation act.

ActRelationshipDiagnosis

No description

ActRelationshipDocumentHQMF

The reasons that may be used when relating a Quality Measure Document to other document types.

ActRelationshipDocumentProvenance

Used to convey the relationship between two or more Documents for purpose of tracking provenance relationships such as a predecessor Document and a successor Document. For example, a predecessor Clinical Summary Document from which a successor Clinical Summary Document is derived.

ActRelationshipDocuments

The source act documents the target act.

ActRelationshipDuring

No description

ActRelationshipEndsAfterEndOf

No description

ActRelationshipEndsAfterOrConcurrentWithEndOf

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipEndsAfterOrConcurrentWithStartOf

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipEndsAfterStartOf

No description

ActRelationshipEndsBeforeEnd

The source Act ends after the end of the target Act (i.e. if we say “ActOne EBE ActTwo”, it means that ActOne ends before the end of ActTwo, therefore ActOne is the source and ActTwo is the target).

ActRelationshipEndsBeforeOrConcurrentWithEndOf

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipEndsBeforeOrConcurrentWithStartOf

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipEndsBeforeStartOf

No description

ActRelationshipEndsConcurrentWith

No description

ActRelationshipEndsConcurrentWithStart

The source Act ends when the target act starts (i.e. if we say “ActOne ECWS ActTwo”, it means that ActOne ends when ActTwo starts, therefore ActOne is the source and ActTwo is the target).

ActRelationshipEndsDuring

No description

ActRelationshipEndsNearEnd

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipEndsNearStarts

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipEpisodelink

Expresses an association that links two instances of the same act over time, indicating that the instance are part of the same episode, e.g. linking two condition nodes for episode of illness; linking two encounters for episode of encounter.

ActRelationshipEvaluatesGoal

A goal-evaluation links an observation (intent or actual) to a goal to indicate that the observation evaluates the goal. Given the goal and the observation, a “goal distance” (e.g., goal to observation) can be “calculated” and need not be sent explicitly.

ActRelationshipExacerbatredBy

No description

ActRelationshipExcerpt

The source is an excerpt from the target.

ActRelationshipExcerptVerbatim

The source is a direct quote from the target.

ActRelationshipFulfills

The source act fulfills (in whole or in part) the target act. Source act must be in a mood equal or more actual than the target act.

ActRelationshipHasBaseline

No description

ActRelationshipHasBoundedSupport

A specialization of “has support” (SPRT), used to relate a secondary observation to a Region of Interest on a multidimensional observation, if the ROI specifies the true boundaries of the secondary observation as opposed to only marking the approximate area. For example, if the start and end of an ST elevation episode is visible in an EKG, this relation would indicate the ROI bounds the “ST elevation” observation – the ROI defines the true beginning and ending of the episode. Conversely, if a ROI simply contains ST elevation, but it does not define the bounds (start and end) of the episode, the more general “has support” relation is used. Likewise, if a ROI on an image defines the true bounds of a “1st degree burn”, the relation “has bounded support” is used; but if the ROI only points to the approximate area of the burn, the general “has support” relation is used.

ActRelationshipHasCharge

A relationship that provides an ability to associate a financial transaction (target) as a charge to a clinical act (source). A clinical act may have a charge associated with the execution or delivery of the service. The financial transaction will define the charge (bill) for delivery or performance of the service. Charges and costs are distinct terms. A charge defines what is charged or billed to another organization or entity within an organization. The cost defines what it costs an organization to perform or deliver a service or product.

ActRelationshipHasComponent

A collection of sub-services as steps or subtasks performed for the source service. Services may be performed sequentially or concurrently.

ActRelationshipHasContinuingObjective

A desired state that a service action aims to maintain. E.g., keep systolic blood pressure between 90 and 110 mm Hg. Source is an intervention service. Target must be an observation in criterion mood.

ActRelationshipHasContra-indication

A contraindication is just a negation of a reason, i.e. it gives a condition under which the action is not to be done. Both, source and target can be any kind of service; target service is in criterion mood. How the strength of a contraindication is expressed (e.g., relative, absolute) is left as an open issue. The priorityNumber attribute could be used.

ActRelationshipHasControlVariable

A relationship from an Act to a Control Variable. For example, if a Device makes an Observation, this relates the Observation to its Control Variables documenting the device’s settings that influenced the observation.

ActRelationshipHasCost

A relationship that provides an ability to associate a financial transaction (target) as a cost to a clinical act (source). A clinical act may have an inherit cost associated with the execution or delivery of the service. The financial transaction will define the cost of delivery or performance of the service. Charges and costs are distinct terms. A charge defines what is charged or billed to another organization or entity within an organization. The cost defines what it costs an organization to perform or deliver a service or product.

ActRelationshipHasCredit

A credit relationship ties a financial transaction (target) to an account (source). A credit, once applied (posted), may have either a positive or negative effect on the account balance, depending on the type of account. An asset account credit will decrease the account balance. A non-asset account credit will decrease the account balance.

ActRelationshipHasDebit

A debit relationship ties a financial transaction (target) to an account (source). A debit, once applied (posted), may have either a positive or negative effect on the account balance, depending on the type of account. An asset account debit will increase the account balance. A non-asset account debit will decrease the account balance.

ActRelationshipHasExplanation

This is the inversion of support. Used to indicate that a given observation is explained by another observation or condition.

ActRelationshipHasFinalObjective

A desired outcome that a service action aims to meet finally. Source is any service (typically an intervention). Target must be an observation in criterion mood.

ActRelationshipHasGeneralization

The generalization relationship can be used to express categorical knowledge about services (e.g., amilorid, triamterene, and spironolactone have the common generalization potassium sparing diuretic).

ActRelationshipHasGoal

A goal that one defines given a patient’s health condition. Subsequently planned actions aim to meet that goal. Source is an observation or condition node, target must be an observation in goal mood.

ActRelationshipHasMember

No description

ActRelationshipHasMetadata

No description

ActRelationshipHasOption

A relationship between a source Act that provides more detailed properties to the target Act. The source act thus is a specialization of the target act, but instead of mentioning all the inherited properties it only mentions new property bindings or refinements. The typical use case is to specify certain alternative variants of one kind of Act. The priorityNumber attribute is used to weigh refinements as preferred over other alternative refinements. Example: several routing options for a drug are specified as one SubstanceAdministration for the general treatment with attached refinements for the various routing options.

ActRelationshipHasPart

No description

ActRelationshipHasPre-condition

A requirement to be true before a service is performed. The target can be any service in criterion mood. For multiple pre-conditions a conjunction attribute (AND, OR, XOR) is applicable.

ActRelationshipHasPreviousInstance

A relationship in which the target act is a predecessor instance to the source act. Generally each of these instances is similar, but no identical. In healthcare coverage it is used to link a claim item to a previous claim item that might have claimed for the same set of services.

ActRelationshipHasQualifier

No description

ActRelationshipHasReferenceValues

Reference ranges are essentially descriptors of a class of result values assumed to be “normal”, “abnormal”, or “critical.” Those can vary by sex, age, or any other criterion. Source and target are observations, the target is in criterion mood. This link type can act as a trigger in case of alarms being triggered by critical results.

ActRelationshipHasRisk

A noteworthy undesired outcome of a patient’s condition that is either likely enough to become an issue or is less likely but dangerous enough to be addressed.

ActRelationshipHasStep

No description

ActRelationshipHasSubject

Relates an Act to its subject Act that the first Act is primarily concerned with. Examples

  1. The first Act may be a ControlAct manipulating the subject Act
  2. The first act is a region of interest (ROI) that defines a region within the subject Act.
  3. The first act is a reporting or notification Act, that echos the subject Act for a specific new purpose. Constraints An Act may have multiple subject acts. Rationale The ActRelationshipType “has subject” is similar to the ParticipationType “subject”, Acts that primarily operate on physical subjects use the Participation, those Acts that primarily operate on other Acts (other information) use the ActRelationship.
ActRelationshipHasSupport

Used to indicate that an existing service is suggesting evidence for a new observation. The assumption of support is attributed to the same actor who asserts the observation. Source must be an observation, target may be any service (e.g., to indicate a status post.)

ActRelationshipHasTrigger

A pre-condition that if true should result in the source Act being executed. The target is in typically in criterion mood. When reported after the fact (i.e. the criterion has been met) it may be in Event mood. A delay between the trigger and the triggered action can be specified. Discussion: This includes the concept of a required act for a service or financial instrument such as an insurance plan or policy. In such cases, the trigger is the occurrence of a specific condition such as coverage limits being exceeded.

ActRelationshipHasValue

No description

ActRelationshipICSRInvestigation

Description: The ways that product safety Investigations, about which information is captured in an Individual Case Safety Report, are related to each other. One investigation may be performed at a patient care institution, and the second by a manufacturer, a third by a regulatory agency. They may all investigate the same case and are thus related. Other kinds of relationships are replacement (if the mode of the Investigation is changed).

ActRelationshipImmunizationAgainst

No description

ActRelationshipIndependentOfTimeOf

No description

ActRelationshipInstantiatesMaster

Used to capture the link between a potential service (“master” or plan) and an actual service, where the actual service instantiates the potential service. The instantiation may override the master’s defaults.

ActRelationshipInterferedBy

No description

ActRelationshipIsAppendage

An addendum (source) to an existing service object (target), containing supplemental information. The addendum is itself an original service object linked to the supplemented service object. The supplemented service object remains in place and its content and status are unaltered.

ActRelationshipIsDerivedFrom

Associates a derived Act with its input parameters. E.G., an anion-gap observation can be associated as being derived from given sodium-, (potassium-,), chloride-, and bicarbonate-observations. The narrative content (Act.text) of a source act is wholly machine-derived from the collection of target acts.

ActRelationshipIsEtiologyFor

An assertion that a new observation was assumed to be the cause for another existing observation. The assumption is attributed to the same actor who asserts the observation. This is stronger and more specific than the support link. For example, a growth of Staphylococcus aureus may be considered the cause of an abscess. The source (cause) is typically an observation, but may be any service, while the target must be an observation.

ActRelationshipIsManifestationOf

An assertion that a new observation may be the manifestation of another existing observation or action. This assumption is attributed to the same actor who asserts the manifestation. This is stronger and more specific than an inverted support link. For example, an agitated appearance can be asserted to be the manifestation (effect) of a known hyperthyroxia. This expresses that one might not have realized a symptom if it would not be a common manifestation of a known condition. The target (cause) may be any service, while the source (manifestation) must be an observation.

ActRelationshipItemsLocated

Items located

ActRelationshipJoin

A code specifying how concurrent Acts are resynchronized in a parallel branch construct. Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Branches exist when multiple components have the same sequenceNumber. Branches are parallel if the splitCode specifies that more than one branch can be executed at the same time. The joinCode then specifies if and how the braches are resynchronized. The principal re-synchronization actions are (1) the control flow waits for a branch to terminate (wait-branch), (2) the branch that is not yet terminated is aborted (kill-branch), (3) the branch is not re-synchronized at all and continues in parallel (detached branch). A kill branch is only executed if there is at least one active wait (or exclusive wait) branch. If there is no other wait branch active, a kill branch is not started at all (rather than being aborted shortly after it is started.) Since a detached branch is unrelated to all other branches, active detached branches do not protect a kill-branch from being aborted.

ActRelationshipJoinDetached

Detach this branch from the other branches so it will not be resynchronized with the other branches.

ActRelationshipJoinExclusiveWait

Wait for any one of the branches in the set of exclusive wait branches to terminate, then discontinue all the other exclusive wait branches.

ActRelationshipJoinKill

When all other concurrent branches are terminated, interrupt and discontinue this branch.

ActRelationshipJoinWait

Wait for this branch to terminate.

ActRelationshipLimitedBy

A relationship that limits or restricts the source act by the elements of the target act. For example, an authorization may be limited by a financial amount (up to $500). Target Act must be in EVN.CRIT mood.

ActRelationshipMaintenanceTreatment

No description

ActRelationshipMatchesTrigger

A trigger-match links an actual service (e.g., an observation or procedure that took place) with a service in criterion mood. For example if the trigger is “observation of pain” and pain is actually observed, and if that pain-observation caused the trigger to fire, that pain-observation can be linked with the trigger.

ActRelationshipMitigates

The source act removes or lessens the occurrence or effect of the target act.

ActRelationshipModifies

Definition: Used to link a newer version or ‘snapshot’ of a business object (source) to an older version or ‘snapshot’ of the same business object (target). Usage:The identifier of the Act should be the same for both source and target. If the identifiers are distinct, RPLC should be used instead. Name from source to target = “modifiesPrior” Name from target to source = “modifiesByNew”

ActRelationshipObjective

The target act is a desired outcome of the source act. Source is any act (typically an intervention). Target must be an observation in criterion mood.

ActRelationshipOccurrence

The source act is a single occurrence of a repeatable target act. The source and target act can be in any mood on the “completion track” but the source act must be as far as or further along the track than the target act (i.e., the occurrence of an intent can be an event but not vice versa).

ActRelationshipOutcome

An observation that should follow or does actually follow as a result or consequence of a condition or action (sometimes called “post-condition”.) Target must be an observation as a goal, risk or any criterion. For complex outcomes a conjunction attribute

ActRelationshipOverlapsWith

No description

ActRelationshipPalliates

No description

ActRelationshipPassiveImmunizationAgainst

No description

ActRelationshipPertains

This is a very unspecific relationship from one item of clinical information to another. It does not judge about the role the pertinent information plays.

ActRelationshipPosting

Expresses values for describing the relationship between a FinancialTransaction and an Account.

ActRelationshipProphylaxisOf

No description

ActRelationshipProvidesEvidenceFor

Indicates that the target Act provides evidence in support of the action represented by the source Act. The target is not a ‘reason’ for the source act, but rather gives supporting information on why the source act is an appropriate course of action. Possible targets might be clinical trial results, journal articles, similar successful therapies, etc. Rationale: Provides a mechanism for conveying clinical justification for non-approved or otherwise non-traditional therapies.

ActRelationshipRe-challenge

Description:A relationship in which the target act is carried out to determine whether an effect attributed to the source act can be recreated.

ActRelationshipReason

The reason or rationale for a service. A reason link is weaker than a trigger, it only suggests that some service may be or might have been a reason for some action, but not that this reason requires/required the action to be taken. Also, as opposed to the trigger, there is no strong timely relation between the reason and the action. Discussion: In prior releases, the code “SUGG” (suggests) was expressed as “an inversion of the reason link.” That code has been retired in favor of the inversion indicator that is an attribute of ActRelationship.

ActRelationshipRecovery

Definition: The source act is performed to recover from the effects of the target act.

ActRelationshipReferencesOrder

Relates either an appointment request or an appointment to the order for the service being scheduled.

ActRelationshipRefersTo

A relationship in which the target act is referred to by the source act. This permits a simple reference relationship that distinguishes between the referent and the referee.

ActRelationshipRelievedBy

No description

ActRelationshipReplaces

A replacement source act replaces an existing target act. The state of the target act being replaced becomes obselete, but the act is typically still retained in the system for historical reference. The source and target must be of the same type.

ActRelationshipReverses

A relationship between a source Act that seeks to reverse or undo the action of the prior target Act. Example: A posted financial transaction (e.g., a debit transaction) was applied in error and must be reversed (e.g., by a credit transaction) the credit transaction is identified as an undo (or reversal) of the prior target transaction. Constraints: the “completion track” mood of the target Act must be equally or more “actual” than the source act. I.e., when the target act is EVN the source act can be EVN, or any INT. If the target act is INT, the source act can be INT.

ActRelationshipSchedulesRequest

Associates a specific time (and associated resources) with a scheduling request or other intent.

ActRelationshipSequel

An act relationship indicating that the source act follows the target act. The source act should in principle represent the same kind of act as the target. Source and target need not have the same mood code (mood will often differ). The target of a sequel is called antecedent. Examples for sequel relationships are: revision, transformation, derivation from a prototype (as a specialization is a derivation of a generalization), followup, realization, instantiation.

ActRelationshipSplit

A code specifying how branches in an action plan are selected among other branches. Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Branches exist when multiple components have the same sequenceNumber. The splitCode specifies whether a branch is executed exclusively (case-switch) or inclusively, i.e., in parallel with other branches. In addition to exlusive and inclusive split the splitCode specifies how the pre-condition (also known as “guard conditions” on the branch) are evaluated. A guard condition may be evaluated once when the branching step is entered and if the conditions do not hold at that time, the branch is abandoned. Conversely execution of a branch may wait until the guard condition turns true. In exclusive wait branches, the first branch whose guard conditions turn true will be executed and all other branches abandoned. In inclusive wait branches some branches may already be executed while other branches still wait for their guard conditions to turn true.

ActRelationshipSplitExclusiveTryOnce

The pre-condition associated with the branch is evaluated once and if true the branch may be entered. All other exclusive branches compete with each other and only one will be selected. This implements a COND, IF and CASE conditionals, or “XOR-split.” The order in which the branches are considered may be specified in the priorityNumber attribute.

ActRelationshipSplitExclusiveWait

A branch is selected as soon as the pre-condition associated with the branch evaluates to true. If the condition is false, the branch may be entered later, when the condition turns true. All other exclusive branches compete with each other and only one will be selected. Each waiting branch executes in parallel with the default join code wait (see below). The order in which the branches are considered may be specified in the Service_relationship.priority_nmb.

ActRelationshipSplitInclusiveTryOnce

A branch is executed if its associated preconditions permit. If associated preconditions do not permit, the branch is dropped. Inclusive branches are not suppressed and do not suppress other branches.

ActRelationshipSplitInclusiveWait

A branch is executed as soon as its associated conditions permit. If the condition is false, the branch may be entered later, when the condition turns true. Inclusive branches are not suppressed and do not suppress other branches. Each waiting branch executes in parallel with the default join code wait (see below).

ActRelationshipStartAfterStartOfContainsEndOf

No description

ActRelationshipStartsAfterEndOf

Description:A relationship in which the target act takes place with a defined temporal relationship with respect to the time at which the source act terminates.

ActRelationshipStartsAfterOrConcurrentWithEndOf

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipStartsAfterOrConcurrentWithStartOf

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipStartsAfterStartOf

The source Act starts after the start of the target Act (i.e. if we say “ActOne SAS ActTwo”, it means that ActOne starts after the start of ActTwo, therefore ActOne is the source and ActTwo is the target).

ActRelationshipStartsAfterStartOfEndsWith

No description

ActRelationshipStartsAfterStartofEndsAfterEndOf

No description

ActRelationshipStartsBeforeEnd

The source Act starts after the end of the target Act (i.e. if we say “ActOne SBE ActTwo”, it means that ActOne starts before the end of ActTwo, therefore ActOne is the source and ActTwo is the target).

ActRelationshipStartsBeforeOrConcurrentWithEndOf

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipStartsBeforeOrConcurrentWithStartOf

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipStartsBeforeStartOf

No description

ActRelationshipStartsBeforeStartOfEndsBeforeEndOf

No description

ActRelationshipStartsBeforeStartOfEndsWith

No description

ActRelationshipStartsConcurrentWith

No description

ActRelationshipStartsConcurrentWithEnd

The source Act starts when the target act ends (i.e. if we say “ActOne SCWE ActTwo”, it means that ActOne starts when ActTwo ends, therefore ActOne is the source and ActTwo is the target).

ActRelationshipStartsDuring

No description

ActRelationshipStartsNearEnd

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipStartsNearStart

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipStartsWithEndsAfterEndOf

No description

ActRelationshipStartsWithEndsBeforeEndOf

No description

ActRelationshipSubset

Used to indicate that the target of the relationship will be a filtered subset of the total related set of targets. Used when there is a need to limit the number of components to the first, the last, the next, the total, the average or some other filtered or calculated subset.

ActRelationshipSucceeds

Definition: A new act that carries forward the intention of the original act, but does not completely replace it. The status of the predecessor act must be ‘completed’. The original act is the target act and the successor is the source act.

ActRelationshipSummarizedBy

An act that contains summary values for a list or set of subordinate acts. For example, a summary of transactions for a particular accounting period.

ActRelationshipSymptomaticRelief

Used in the diagnosis of the indicated disease.

ActRelationshipTemporallyPertains

No description

ActRelationshipTemporallyPertainsApproximates

Pro-forma value set for each head code in the ActRelationshipType code system; all codes present and future below the head code.

ActRelationshipTemporallyPertainsEnd

No description

ActRelationshipTemporallyPertainsStart

No description

ActRelationshipTransformation

Used when the target Act is a transformation of the source Act. (For instance, used to show that a CDA document is a transformation of a DICOM SR document.)

ActRelationshipTreats

No description

ActRelationshipType

A code specifying the meaning and purpose of every ActRelationship instance. Each of its values implies specific constraints to what kinds of Act objects can be related and in which way. Discussion: The types of act relationships fall under one of 5 categories: 1.) (De)-composition, with composite (source) and component (target) 2.) Sequel which includes follow-up, fulfillment, instantiation, replacement, transformation, etc. that all have in common that source and target are Acts of essentially the same kind but with variances in mood and other attributes, and where the target exists before the source and the source refers to the target that it links back to. 3.) Pre-condition, trigger, reason, contraindication, with the conditioned Act at the source and the condition or reason at the target. 4.) Post-condition, outcome, goal and risk, with the Act at the source having the outcome or goal at the target. 5.) A host of functional relationships including support, cause, derivation, etc. generalized under the notion of “pertinence”.

ActRelationshipUpdate

Description: Deprecation Comment: Was mis-named, and a proper representation has been provided. Replaced by value set ActRelationshipCompliesWith.

ActRelationshipUpdatesCondition

A condition thread relationship specifically links condition nodes together to form a condition thread. The source is the new condition node and the target links to the most recent node of the existing condition thread.

ActRelationshipUses

No description

ActResearchInformationAccess

Definition: Consent to have healthcare information in an electronic health record accessed for research purposes.

ActShortStayEncounterCode

Definition:An encounter where the patient is admitted to a health care facility for a predetermined length of time, usually less than 24 hours.

ActSpecObsCode

Identifies the type of observation that is made about a specimen that may affect its processing, analysis or further result interpretation

ActSpecObsDilutionCode

An observation that reports the dilution of a sample.

ActSpecObsInterferenceCode

An observation that relates to factors that may potentially cause interference with the observation

ActSpecObsVolumeCode

An observation that reports the volume of a sample.

ActSpecimenTreatmentCode

Set of codes related to specimen treatments

ActStatus

Contains the names (codes) for each of the states in the state-machine of the RIM Act class.

ActStatusAborted

The Act has been terminated prior to the originally intended completion.

ActStatusAbortedCancelledCompleted

Description: The status of an assessment for indications of an abnormal condition.

ActStatusActive

The Act can be performed or is being performed

ActStatusActiveAborted

** none supplied **

ActStatusActiveSuspendedObsolete

** none supplied **

ActStatusCancelled

The Act has been abandoned before activation.

ActStatusCompleted

An Act that has terminated normally after all of its constituents have been performed.

ActStatusHeld

An Act that is still in the preparatory stages has been put aside. No action can occur until the Act is released.

ActStatusNew

An Act that is in the preparatory stages and may not yet be acted upon

ActStatusNormal

Encompasses the expected states of an Act, but excludes “nullified” and “obsolete” which represent unusual terminal states for the life-cycle.

ActStatusNullified

This Act instance was created in error and has been ‘removed’ and is treated as though it never existed. A record is retained for audit purposes only.

ActStatusObsolete

This Act instance has been replaced by a new instance.

ActStatusSuspended

An Act that has been activated (actions could or have been performed against it), but has been temporarily disabled. No further action should be taken against it until it is released

ActSubstanceAdminSubstitutionCode

No description

ActSubstanceAdministrationCode

Describes the type of substance administration being performed.

ActSubstanceAdministrationImmunizationCode

The introduction of an immunogen with the intent of stimulating an immune response, aimed at preventing subsequent infections by more viable agents.

ActSuppliedItemDetectedIssueCode

Identifies types of detected issues regarding the administration or supply of an item to a patient.

ActSupplyFulfillmentRefusalReason

Indicates why a fulfiller refused to fulfill a supply order, and considered it important to notify other providers of their decision. E.g. “Suspect fraud”, “Possible abuse”, “Contraindicated”. (used when capturing ‘refusal to fill’ annotations)

ActTaskClinicalNoteEntryCode

A clinician enters a clinical note about a given patient

ActTaskClinicalNoteReviewCode

A person reviews a clinical note of a given patient.

ActTaskCode

Description: A task or action that a user may perform in a clinical information system.

ActTaskMedicationListReviewCode

A person reviews a list of medication orders submitted to a given patient

ActTaskMicrobiologyResultsReviewCode

A person reviews a list of microbiology results of a given patient.

ActTaskOrderEntryCode

No description

ActTaskPatientDocumentationCode

A person enters documentation about a given patient.

ActTaskPatientInformationReviewCode

A person (e.g., clinician, the patient herself) reviews patient information in the electronic medical record.

ActTaskRiskAssessmentInstrumentCode

A person reviews a Risk Assessment Instrument report of a given patient.

ActTherapyDurationWorkingListCode

Codes used to identify different types of ‘duration-based’ working lists. Examples include “Continuous/Chronic”, “Short-Term” and “As-Needed”.

ActTransportationModeCode

Characterizes how a transportation act was or will be carried out. Examples: Via private transport, via public transit, via courier.

ActUSPrivacyLaw

Deprecation Comment: Content moved to ActCode, and is now represented in value set ActPrivacyLaw.

ActUncertainty

A code indicating whether the Act statement as a whole, with its subordinate components has been asserted to be uncertain in any way. Examples: Patient might have had a cholecystectomy procedure in the past (but isn’t sure). Constraints: Uncertainty asserted using this attribute applies to the combined meaning of the Act statement established by all descriptive attributes (e.g., Act.code, Act.effectiveTime, Observation.value, SubstanceAdministration.doseQuantity, etc.), and the meanings of any components. Discussion:This is not intended for use to replace or compete with uncertainty associated with a Observation.values alone or other individual attributes of the class. Such pointed indications of uncertainty should be specified by applying the PPD, UVP or UVN data type extensions to the specific attribute. Particularly if the uncertainty is uncertainty of a quantitative measurement value, this must still be represented by a PPD<PQ> in the value and NOT using the uncertaintyCode. Also, when differential diagnoses are enumerated or weighed for probability, the UVP<CD> or UVN<CD> must be used, not the uncertaintyCode. The use of the uncertaintyCode is appropriate only if the entirety of the Act and its dependent Acts is questioned. Note that very vague uncertainty may be thought related to negationInd, however, the two concepts are really independent. One may be very uncertain about an event, but that does not mean that one is certain about the negation of the event.

ActVirtualEncounterCode

Definition:A patient encounter where the patient and the practitioner(s) are not in the same physical location. Examples include telephone conference, email exchange, robotic surgery, and televideo conference.

Action Participant Role

Either a practitioner role or a relationship type. Note from UTG import - may have been a temporary entry that subsequently disappeared from the FHIR source; unable to locate. Version set to 0.1.0

ActionType

The type of action to be performed.

ActivityDefinitionCategory

High-level categorization of the type of activity.

AdditionalLocator

This can be a unit designator, such as apartment number, suite number, or floor. There may be several unit designators in an address (e.g., “3rd floor, Appt. 342”.) This can also be a designator pointing away from the location (e.g. Across the street from).

AddressLine

Description: An address line is for either an additional locator, a delivery address or a street address.

AddressPartType

Discussion: The hierarchical nature of these concepts shows composition. E.g. “Street Name” is part of “Street Address Line”

AddressRepresentationUse

Description:Identifies the different representations of a Address. The representation may affect how the address is used. (E.g. use of Ideographic for formal communications.)

AddressUse

No description

AdjudicatedWithAdjustments

The invoice element has been accepted for payment but one or more adjustment(s) have been made to one or more invoice element line items (component charges). Also includes the concept ‘Adjudicate as zero’ and items not covered under a particular Policy. Invoice element can be reversed (nullified). Recommend that the invoice element is saved for DUR (Drug Utilization Reporting).

Adjudication Reason Codes

This value set includes smattering of Adjudication Reason codes.

Adjudication Value Codes

This value set includes a smattering of Adjudication Value codes which includes codes to indicate the amounts eligible under the plan, the amount of benefit, copays etc.

AdjudicationError

This value set includes a smattering of adjudication codes.

AdministrableDrugForm

Indicates the form in which the drug product should be administered. This element only needs to be specified when (a) the form in which the drug is measured for dispensing differs from the form in which the drug is administered; and (b) the form in which the quantity of the administered drug being administered is not expressed as a discrete measured mass or volume.Usage:

AdministrationDetectedIssueCode

Administration of the proposed therapy may be inappropriate or contraindicated as proposed

AdministrationMedicalDevice

A device intended to administer a substance to a subject

AdministrativeContactRoleType

A role type that is used to further qualify an entity playing a role where the role class attribute is set to RoleClassCommissioningParty.

AdministrativeGender

The gender of a person used for adminstrative purposes (as opposed to clinical gender)

Admit source

This value set defines a set of codes that can be used to indicate from where the patient came in.

AdoptedChild

The player of the role is a child taken into a family through legal means and raised by the scoping person (parent) as his or her own child.

Adverse Event Clinical Research Causality Relatedness

Value set for stating if a suspected entity is Not Related, Unlikely Related, Possibly Related, or Related to the cause of the adverse event. Using NCI codes. The values originate with ICH. For information on ICH see https://admin.ich.org/sites/default/files/inline-files/OID_Information_Paper_1.pdf from the INTERNATIONAL CONFERENCE ON HARMONISATION OF TECHNICAL REQUIREMENTS FOR REGISTRATION OF PHARMACEUTICALS FOR HUMAN USE (ICH) document ICH E2B(R3), the Electronic Transmission of Individual Case Safety Reports (ICSRs) Implementation Guide Data Elements and Message Specification, and ICH M8, the Electronic Common Technical Document

Adverse Event Clinical Research Grades

Value set of grades used in Adverse Event Clinical Research, especially in Oncology clinical trials

Adverse Event Clinical Research Outcomes

This value set includes codes that describe the type of outcome from the adverse event as typically used in reporting for Clinical Research, post-market surveillance (e.g. Medwatch forms). NCI codes used here This list originates from the ICH E2B R3 (https://database.ich.org/sites/default/files/E2D_Guideline.pdf), specifically CDISC CL.C66768.OUT. For information on ICH see https://admin.ich.org/sites/default/files/inline-files/OID_Information_Paper_1.pdf from the INTERNATIONAL CONFERENCE ON HARMONISATION OF TECHNICAL REQUIREMENTS FOR REGISTRATION OF PHARMACEUTICALS FOR HUMAN USE (ICH) document ICH E2B(R3), the Electronic Transmission of Individual Case Safety Reports (ICSRs) Implementation Guide Data Elements and Message Specification, and ICH M8, the Electronic Common Technical Document.

Adverse Event Clinical Research Seriousness Criteria

Action criteria usually associated with serious events that pose a threat to a patient’s life or functioning. Adverse Events criteria to expand on the seriousness of the adverse event. Typically used in reporting for Clinical Research, post-market surveillance (e.g. Form FDA 3500A MedWatch). The adverse event seriousness criteria value set is based on the ICH E2D Post-Approval Safety Data Management: Definitions and Standards for Expedited Reporting guidance (https://database.ich.org/sites/default/files/E2D_Guideline.pdf). For information on ICH see https://admin.ich.org/sites/default/files/inline-files/OID_Information_Paper_1.pdf from the INTERNATIONAL CONFERENCE ON HARMONISATION OF TECHNICAL REQUIREMENTS FOR REGISTRATION OF PHARMACEUTICALS FOR HUMAN USE (ICH) document ICH E2B(R3), the Electronic Transmission of Individual Case Safety Reports (ICSRs) Implementation Guide Data Elements and Message Specification, and ICH M8, the Electronic Common Technical Document

AdverseEventCategory

Overall categorization of the event, e.g. product-related or situational.

AdverseEventCausalityAssessment

Codes for the assessment of whether the entity caused the event.

AdverseEventCausalityMethod

TODO.

AdverseEventSeriousness

Overall seriousness of this event for the patient.

AdverseEventSeverity

The severity of the adverse event itself, in direct relation to the subject.

AerosolDrugForm

No description

AgeDetectedIssueCode

Proposed therapy may be inappropriate or contraindicated due to patient age

AgeGroupObservationValue

Observation values used to indicate the age group of a person in terms of age group concept codes.

Aleut

No description

Algic

No description

Algonquian

No description

AlgorithmicDecisionObservationMethod

Reaching a decision through the application of an algorithm designed to weigh the different factors involved.

Allergy Status

The clinical status of an allergy disposition (Clinical Focus) Used in Program: C-CDA, C-CDA R2.1 2017-06-09 using this value set

AllergyIntolerance Clinical Status Codes

Preferred value set for AllergyIntolerance Clinical Status.

AllergyIntolerance Verification Status

The verification status to support or decline the clinical status of the allergy or intolerance.

AllergyIntoleranceCertainty

Statement about the degree of clinical certainty that a specific substance was the cause of the manifestation in a reaction event.

AllergyIntoleranceSubstanceExposureRisk

The risk of an adverse reaction (allergy or intolerance) for this patient upon exposure to the substance (including pharmaceutical products).

AllergyTestValue

Indicates the result of a particular allergy test. E.g. Negative, Mild, Moderate, Severe

AlternativeCodeKind

Indicates the type of use for which the code is defined.

AlternativeCodeKind

Indicates the type of use for which the code is defined.

Ambulance

No description

AmbulanceHIPAA

An emergency vehicle used for transporting patients to a health care facility after injury or illness. Types of ambulances used in the United States include ground (surface) ambulance, rotor-wing (helicopter), and fixed-wing aircraft (airplane).

AmericanIndianAlaskaNativeLanguages

No description

AmnioticFluidSacRoute

Amniotic fluid sac

AnnotationType

No description

Apachean

No description

ApplicationMediaType

Application specific media type.

Appointment cancellation reason

This example value set defines a set of reasons for the cancellation of an appointment.

Appropriateness Score

The scoring for appropriateness of an action based upon RAND.

AppropriatenessDetectedIssueCode

No description

ArapahoGrosVentre

No description

Arapahoan

No description

Artifact Identifier Type

Identifier types for an artifact (e.g. version-independent, version-specific, short-name, endorser, publisher)

Artifact Version Policy

The versioning policy of an artifact or set of artifacts (metadata or strict)

ArtificialDentition

Artificial dentition, artificial subsitutes for the natural dentition

AskedButUnknown

Information was sought but not found (e.g., patient was asked but didn’t know)

AssignedNonPersonLivingSubjectRoleType

Description:A role type that is used to further qualify a non-person subject playing a role where the role class attribute is set to RoleClass AssignedEntity

Athapaskan

No description

AthapaskanEyak

No description

AudioMediaType

Audio media type.

Audit Event Outcome

The type of process where the audit event originated from.

Audit Event Source Type

The type of process where the audit event originated from.

AuditEventEntityRole

Code representing the role the entity played in the audit event.

AuthorizationIssueManagementCode

No description

AuthorizedParticipationFunction

This code is used to specify the exact function an actor is authorized to have in a service in all necessary detail.

AuthorizedReceiverParticipationFunction

This code is used to specify the exact function an actor is authorized to have as a receiver of information that is the subject of a consent directive or consent override.

AutomobileInsurancePolicy

Definition: An insurance policy for losses sustained in an automobile accident that typically covers losses incurred by the named insured and parties who may be claimants for losses, such as pedestrians and passengers.

BarDrugForm

No description

BarSoapDrugForm

No description

Basic Resource Types

This value set defines codes for resources not yet supported by (or which will never be supported by) FHIR. Many of the codes listed here will eventually be turned into official resources. However, there is no guarantee that any particular resource will be created nor that the scope will be exactly as defined by the codes presented here. Codes in this set will be deprecated if/when formal resources are defined that encompass these concepts.

Benefit Category Codes

This value set includes examples of Benefit Category codes.

Benefit Term Codes

This value set includes a smattering of Benefit Term codes.

Benefit Type Codes

This value set includes a smattering of Benefit type codes.

Benefit cost applicability

Whether the cost applies to in-network or out-of-network providers.

BiliaryRoute

Biliary tract

BindingRealm

Description: All coded binding realms for terminology constraint context binding.

BiotherapeuticNon-personLivingSubjectRoleType

Description:Animals, including fish and insects, and microorganisms which may participate as assigned entities in biotherapies.

BlisterPackEntityType

A bubblepack. Medications sealed individually, separated into doses.

BodySurfaceRoute

Body surface

BottleEntityType

A container, typically rounded, either glass or plastic with a narrow neck and capable of storing liquid.

BuccalMucosaRoute

Buccal mucosa

BuccalTablet

No description

BuildingNumber

The number of a building, house or lot alongside the street. Also known as “primary street number”. This does not number the street but rather the building.

CQL Access Modifier

Access modifiers defined by the Clinical Quality Language (CQL) specification in the Access Modifiers topic.

CUI

Information the US Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls. Purpose: Supports the selection of the entire ControlledUnclassifiedInformation value set for e.g., rules engine policy set purposes.

CUILabel

Information the US Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls Purpose: Supports the selection of ControlledUnclassifiedInformation leaf concepts for use, e.g., in security labels.

CVDiagTherPracticeSetting

A practice setting where cardiovascular diagnostic procedures or therapeutic interventions are performed (e.g., cardiac catheterization lab, echocardiography suite)

Caddoan

No description

Cahitan

No description

Calendar

No description

CalendarCycle

No description

CalendarCycleOneLetter

One letter calendar cycle abbreviations (Temporary - remove when RoseTree is fixed)

CalendarCycleTwoLetter

Two letter calendar cycle abbreviations (Temporary - remove when RoseTree is fixed)

CalendarType

No description

CaliforniaAthapaskan

No description

Can-push-updates

Ability of the primary source to push updates/alerts

CapsuleDrugForm

A solid dosage form in which the drug is enclosed within either a hard or soft soluble container or “shell” made from a suitable form of gelatin.

CardClinPracticeSetting

No description

CaseTransmissionMode

Code for the mechanism by which disease was acquired by the living subject involved in the public health case. Includes sexually transmitted, airborne, bloodborne, vectorborne, foodborne, zoonotic, nosocomial, mechanical, dermal, congenital, environmental exposure, indeterminate.

CatalogType

The type of catalog.

Catawba

No description

CecostomyRoute

Cecostomy

CentralAlaskaYukon

No description

CentralMuskogean

No description

CentralNumic

No description

CentralSalish

No description

CervicalRoute

Cervix of the uterus

CharacteristicMethod

The method used to determine the characteristic(s) of the variable.

ChargeItemCode

Example set of codes that can be used for billing purposes.

Charset

Internet Assigned Numbers Authority (IANA) Charset Types

Chew

Chew

Child

The player of the role is a child of the scoping entity.

ChildInLaw

The player of the role is the spouse of scoping person’s child.

Chimakuan

No description

Chinookan

No description

ChiwereWinnebago

No description

ChoiceListOrientation

Direction in which lists of possible answers should be displayed.

ChronicCareFacility

(1) A hospital including a physical plant and personnel that provides multidisciplinary diagnosis and treatment for diseases that have one or more of the following characteristics: is permanent; leaves residual disability; is caused by nonreversible pathological alteration; requires special training of the patient for rehabilitation; and/or may be expected to require a long period of supervision or care. In addition, patients require the safety, security, and shelter of these specialized inpatient or partial hospitalization settings. (2) A hospital that provides medical and skilled nursing services to patients with long-term illnesses who are not in an acute phase but who require an intensity of services not available in nursing homes

CitizenRoleType

A role type used to qualify a person’s legal status within a country or nation. Examples:

  • Full citizen
  • Asylum seeker
  • Permit card holder
Claim Care Team Role Codes

Claim roles of the care team members providing products and services.

Claim Information Category Codes

This value set includes sample Information Category codes.

Claim Type Codes

This value set includes Claim Type codes.

ClaimPayeeResourceType

The type of Claim payee Resource.

ClaimantCoveredPartyRoleType

DescriptionA role recognized through the eligibility of a party play a claimant for benefits covered or provided under an insurance policy.

ClassNullFlavor

Description: Subset of null flavors, used for associations as needed for the ITS, and used in InfrastructureRoot.

Clinical Discharge Disposition

This value set defines a set of codes that can be used to where the patient left the hospital. Note that this value set explicitly removes ‘oth’ (Other) to allow the binding strength to be extensible and therefore allow the exchange of additional concepts without requiring mapping to ‘oth.’

ClinicalResearchEventReason

Definition:Specifies the reason that an event occurred in a clinical research study.

ClinicalResearchObservationReason

Definition:SSpecifies the reason that a test was performed or observation collected in a clinical research study. Note:This set of codes are not strictly reasons, but are used in the currently Normative standard. Future revisions of the specification will model these as ActRelationships and thes codes may subsequently be retired. Thus, these codes should not be used for new specifications.

ClinicalResearchReason

Definition:Contains domains for act reasons used in clinical research.

CochimiYuman

No description

CodeIsNotValid

No description

CodeSystem

Code systems used in HL7 standards.

CodeSystemType

How a code system is maintained by HL7

CodingRationale

Identifies how to interpret the instance of the code, codeSystem value in a set of translations. Since HL7 (or a government body) may mandate that codes from certain code systems be sent in conformant messages, other synonyms that are sent in the translation set need to be distinguished among the originally captured source, the HL7 specified code, or some future role. When this code is NULL, it indicates that the translation is an undefined type. When valued, this property must contain one of the following values: SRC - Source (or original) code HL7 - HL7 Specified or Mandated SH - both HL7 mandated and the original code (precoordination) There may be additional values added to this value set as we work through the use of codes in messages and determine other Use Cases requiring special interpretation of the translations.

CombinedPharmacyOrderSuspendReasonCode

Description:Indicates why the prescription should be suspended.

Common Tags

Common Tag Codes defined by FHIR project

Common UCUM units

Commonly encountered UCUM units (for purposes of helping populate look ups).

CommunicationCategory

Codes for general categories of communications such as alerts, instructions, etc.

CommunicationFunctionType

Describes the type of communication function that the associated entity plays in the associated transmission.

CommunicationNotDoneReason

Codes for the reason why a communication did not happen.

CommunicationTopic

Codes describing the purpose or content of the communication.

Compartment

A named tag set for metadata used to populate a security category label field that “segments” an IT resource per policy by indicating that access and use is restricted to members of a defined community or project. (HL7 Healthcare Privacy and Security Classification System) Usage Note: This is the healthcare analog to the US Intelligence Community’s concept of a Special Access Program. Compartment codes may be used in as a field value in an initiator’s clearance to indicate permission to access and use an IT Resource with a security label having the same compartment value in security category label field. Map: Aligns with ISO 2382-8 definition of Compartment - “A division of data into isolated blocks with separate security controls for the purpose of reducing risk.”

ComplianceAlert

No description

ComplianceDetectedIssueCode

There may be an issue with the patient complying with the intentions of the proposed therapy

CompliancePackageEntityType

A container intended to contain sufficient material for more than one use, but grouped or organized to provide individual access to sufficient material for a single use. Often used to ensure that the proper type and amount of material is consumed/expended for each use.

CompositeMeasureScoring

The composite scoring method of the measure.

CompositeMeasureScoring

Observation values that communicate the method used in a quality measure to combine the component measure results that are included in a composite measure. Steward: CQI WG

CompressionAlgorithm

No description

ConceptPropertyId

Property identifiers for a concept code

Condition Category Codes

Preferred value set for Condition Categories.

Condition Clinical Status Codes

Preferred value set for Condition Clinical Status.

ConditionDetectedIssueCode

Proposed therapy may be inappropriate or contraindicated due to an existing/recent patient condition or diagnosis

ConditionState

Enumeration indicating whether the condition is currently active, inactive, or has been resolved.

ConditionVerificationStatus

The verification status to support or decline the clinical status of the condition or diagnosis.

Conditional

Some conditions may be attached to an allowable substitution. An allowable substitution is based on a match to any other attributes that may be specified.

Confidentiality

Concepts drawn from the HL7 V3 Confidentiality code system . Used in Version 2 messaging in the Security Classification elements in the Message Header segment (MSH) and the Access Restrictions segment (ARV).

Confidentiality

Set of codes used to value Act.Confidentiality and Role.Confidentiality attribute in accordance with the definition for concept domain “Confidentiality”.

ConfidentialityModifiers

Modifiers of role based access rights (multiple allowed) Usage Note: All codes that are referenced by this value set were retired as of the November 2013 Harmonization cycle. Guidance for what to use instead of the v:ConfidentialityModifers leaf concepts: celebrity, sensitive, and taboo: These codes have been revised and are now included under v:ActCode at:

  • V:ActInformationSensitivityPolicy:2.16.840.1.113883.1.11.20429 - taboo
  • V:InformationSensitivityPolicy:2.16.840.1.113883.1.11.20428 - celebrity/VIP and patient requested sensitivity
ConformanceExpectation

Indicates the degree of adherence to a specified behavior or capability expected for a system to be deemed conformant with a specification.

Consent Action Codes

This value set includes sample Consent Action codes.

Consent PolicyRule Codes

This value set includes sample Regulatory consent policy types from the US and other regions.

Consent Scope Codes

This value set includes the four Consent scope codes.

Consent Verification Codes

This value set includes base Consent Verification codes.

ConsenterParticipationFunction

This code is used to specify the exact function an actor is authorized to have in authoring a consent directive.

ConsultedPrescriberManagementCode

Consulted prescriber, therapy confirmed

Contact entity type

This example value set defines a set of codes that can be used to indicate the purpose for which you would contact a contact party.

ContactRoleType

Types of contact for Role code “CON”

ContainerCap

Color of the container cap.

ContainerCap

The type of cap associated with a container

ContainerEntityType

Material intended to hold another material for purpose of storage or transport.

ContainerSeparator

A material in a blood collection container that facilites the separation of of blood cells from serum or plasma

ContentProcessingMode

Description:Identifies the order in which content should be processed.

ContextConductionStyle

No description

ContextControl

A code that specifies how an ActRelationship or Participation contributes to the context of an Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see also attributes Participation.contextControlCode, ActRelationship.contextControlCode, ActRelationship.contextConductionInd).

ContextControlAdditive

The association adds to the existing context associated with the Act. Both this association and any associations propagated from ancestor Acts are interpreted as being related to this Act.

ContextControlAdditiveNon-propagating

The association adds to the existing context associated with the Act, but will not propagate to any descendant Acts reached by conducting ActRelationships (see contextControlCode). Examples: If an ‘Author’ Participation were marked as “Additive, Non-Propagating” it means that the author will be added to the set of author participations that have propagated from ancestor Acts for the purpose of this Act. However only the previously propagated authors will propagate to any child Acts that allow context to be propagated.

ContextControlAdditivePropagating

The association adds to the existing context associated with the Act, and will propagate to any descendant Acts reached by conducting ActRelationships (see contextControlCode). Examples: If an ‘Author’ Participation were marked as “Additive, Propagating” it means that the author will be added to the set of author participations that have propagated from ancestor Acts, and will itself propagate with the other authors to any child Acts that allow context to be propagated.

ContextControlNonPropagating

The association applies only to the current Act and will not propagate to any child Acts that are related via a conducting ActRelationship (refer to contextConductionInd).

ContextControlOverriding

The association adds to the existing context associated with the Act, but replaces associations propagated from ancestor Acts whose typeCodes are the same.

ContextControlOverridingNon-propagating

The association is added to the existing context associated with the Act, but overrides an association with the same typeCode. However, this overriding association will not propagate to any descendant Acts reached by conducting ActRelationships (see contextControlCode). Examples: If an ‘Author’ Participation were marked as “Overriding, Non-Propagating” it means that the author will replace the set of author participations that have propagated from ancestor Acts. Furthermore, no author participations whatsoever will propagate to any child Acts that allow context to be propagated.

ContextControlOverridingPropagating

The association is added to the existing context associated with the Act, but overrides an association with the same typeCode. This overriding association will propagate to any descendant Acts reached by conducting ActRelationships (see contextControlCode). Examples: If an ‘Author’ Participation were marked as “Overriding, Propagating” it means that the author will replace the set of author participations that have propagated from ancestor Acts, and will itself be the only author to propagate to any child Acts that allow context to be propagated.

ContextControlPropagating

The association propagates to any child Acts that are related via a conducting ActRelationship (refer to contextConductionInd).

Contract Action Codes

This value set includes sample Contract Action codes.

Contract Actor Role Codes

This value set includes sample Contract Actor Role codes.

Contract Content Derivation Codes

This is an example set of Content Derivative type codes, which represent the minimal content derived from the basal information source at a specific stage in its lifecycle, which is sufficient to manage that source information, for example, in a repository, registry, processes and workflows, for making access control decisions, and providing query responses.

Contract Signer Type Codes

This value set includes sample Contract Signer Type codes.

Contract Subtype Codes

This value set includes sample Contract Subtype codes.

Contract Term Subtype Codes

This value set includes sample Contract Term SubType codes.

Contract Term Type Codes

This value set includes sample Contract Term Type codes.

Contract Type Codes

This value set includes sample Contract Type codes.

ContractDataMeaning

How a resource reference is interpreted when evaluating contract offers.

ControlActNullificationReasonCode

Description:Identifies reasons for nullifying (retracting) a particular control act. Examples:“Entered in error”, “altered decision”, etc.

ControlActNullificationRefusalReasonType

No description

ControlActReason

Identifies why a specific query, request, or other trigger event occurred.

ControlledSubstanceMonitoringProtocol

A monitoring program that focuses on narcotics and/or commonly abused substances that are subject to legal restriction.

Coosan

No description

CopyNumberEvent

Copy Number Event.

Country

Countries of the world. ISO 3166, part 1, alpha-3 set.

Country2

Countries of the world. ISO 3166, part 1, alpha-2 set.

CountryEntityType

A set of codes identifying specific countries.

Coverage Class Codes

This value set includes Coverage Class codes.

Coverage Copay Type Codes

This value set includes sample Coverage Copayment Type codes.

Coverage SelfPay Codes

This value set includes Coverage SelfPay codes.

CoverageEligibilityReason

Description:Identifies the reason or rational for why a person is eligible for benefits under an insurance policy or program. Examples: A new employee is eligible for health insurance as an employment benefit. A person meets eligibility criteria for government program coverage based on financial, age or health status.

CoverageEligibilityResponse Auth Support Codes

This value set includes CoverageEligibilityResponse Auth Support codes.

CoverageLevelObservationValue

Description:Coded observation values for types of covered parties under a policy or program based on their personal relationships or employment status.

CoverageLimitObservationValue

Description:Coded observation values for coverage limitations, for e.g., types of claims or types of parties covered under a policy or program.

CoverageParticipationFunction

Definition: Set of codes indicating the manner in which sponsors, underwriters, and payers participate in a policy or program.

CoverageRoleType

Role recognized through the issuance of insurance coverage to an identified covered party who has this relationship with the policy holder such as the policy holder themselves (self), spouse, child, etc

CoverageSponsorRoleType

Description:Codes that indicate a specific type of sponsor. Used when the sponsor’s role is only either as a fully insured sponsor or only as a self-insured sponsor. NOTE: Where a sponsor may be either, use the SponsorParticipationFunction.code (fully insured or self insured) to indicate the type of responsibility. (CO6-0057)

CoveredPartyRoleType

A role recognized through the eligibility of an identified living subject for benefits covered under an insurance policy or a program. Eligibility as a covered party may be conditioned on a relationship with (1) the policy holder such as the policy holder who is covered as an individual under a poliy or as a party sponsored for coverage by the policy holder. Example:An employee as a subscriber; or (2) on being scoped another covered party such as the subscriber, as in the case of a dependent. Discussion: The Abstract Value Set “CoverageRoleType”, which was developed for use in the Canadian realm “pre-coordinate” coverage roles with other roles that a covered party must play in order to be eligible for coverage, e.g., “handicapped dependent”. Other codes in the Abstract Value Set CoveredPartyRoleType domain can be “post-coordinated” with the EligiblePartyRoleType codes to denote comparable concepts. Decoupling the concepts is intended to support a wider range of concepts and semantic comparability of coded concepts.

CreamDrugForm

A semisolid dosage form containing one or more drug substances dissolved or dispersed in a suitable base; more recently, the term has been restricted to products consisting of oil-in-water emulsions or aqueous microcrystalline dispersions of long chain fatty acids or alcohols that are water washable and more cosmetically and aesthetically acceptable.

CreditCard

No description

Cree

No description

CreeMontagnais

No description

CriticalityObservationValue

Recommended values for criticality observations > Steward: Security WG

Cupan

No description

Currency

The currency unit as defined in ISO 4217

Dakotan

No description

Decision Observation Method

Provides codes for decision methods, initially for assessing the causality of events.

DedicatedClinicalLocationRoleType

A role of a place that further classifies the clinical setting (e.g., cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) in which care is delivered during an encounter.

DedicatedNonClinicalLocationRoleType

A role of a place that further classifies a setting that is intended to house the provision of non-clinical services.

DedicatedServiceDeliveryLocationRoleType

A role of a place that further classifies a setting that is intended to house the provision of services.

DefinitionStatus

Codes identifying the lifecycle stage of a definition.

DefinitionTopic

High-level categorization of the definition, used for searching, sorting, and filtering.

Delawaran

No description

DeliveryAddressLine

A delivery address line is frequently used instead of breaking out delivery mode, delivery installation, etc. An address generally has only a delivery address line or a street address line, but not both.

DeltaCalifornia

No description

DentistHIPAA

A dentist is a person qualified by a doctorate in dental surgery (D.D. S.) or dental medicine (D.M.D.). licensed by the state to practice dentistry, and practicing within the scope of that license. Many dentists are general practitioners who handle a wide variety of dental needs. Other dentists practice in one of eight specialty areas recognized by the American Dental Association: oral and maxillofacial surgery, orthodontics, periodontics, prosthodontics, endodontics, public health, oral pathology and pediatric dentistry.

Dentition

No description

DependentCoveredPartyRoleType

Description: A role recognized through the eligibility of a party to play a dependent for benefits covered or provided under a health insurance policy because of an association with the subscriber that is recognized by the policy underwriter.

DeviceAlertLevel

Domain values for the Device.Alert_levelCode

DeviceDefinitionParameterGroup

Codes identifying groupings of parameters; e.g. Cardiovascular.

DeviceSafety

Codes used to identify medical devices safety characteristics. These codes are taken from the NCI Thesaurus and are provided here as a suggestive example.

DeviceType

Codes used to identify medical devices.

Dhegiha

No description

DiagTherPracticeSetting

A practice setting where diagnostic procedures or therapeutic interventions are performed

DiagnosisICD9CM

No description

DiagnosisRole

This value set defines a set of codes that can be used to express the role of a diagnosis on the Encounter or EpisodeOfCare record.

Diegueno

No description

Diet

This value set defines a set of codes that can be used to indicate dietary preferences or restrictions a patient may have.

Diffusion

Diffusion

Digital Certificate

This value set defines a set of codes that can be used to choose digital certification.

Discharge disposition

This value set defines a set of codes that can be used to where the patient left the hospital.

DiseaseProgram

Definition: A public or government health program that administers and funds coverage for health and social services to assist program eligible who meet financial and health status criteria related to a particular disease. Example: Reproductive health, sexually transmitted disease, and end renal disease programs.

DispensableDrugForm

No description

Dissolve

Dissolve

DocumentCompletion

Identifies the current completion state of a clinical document.

DocumentSectionType

The type of document section. Possible values: review of systems, medical history, family history, microscopic findings, etc.

DocumentStorage

Identifies the storage status of a document.

DocumentStorageActive

A storage status in which a document is available on-line.

DosageProblem

No description

DosageProblemDetectedIssueCode

Proposed dosage instructions for therapy differ from standard practice.

DoseAndRateType

The kind of dose or rate specified.

DoseDurationDetectedIssueCode

Proposed length of therpay differs from standard practice

DoseDurationHighDetectedIssueCode

Proposed length of therapy is longer than standard practice

DoseDurationLowDetectedIssueCode

Proposed length of therapy is shorter than that necessary for therapeutic effect

DoseHighDetectedIssueCode

Proposed dosage exceeds standard practice

DoseIntervalDetectedIssueCode

Proposed dosage interval/timing differs from standard practice

DoseLowDetectedIssueCode

Proposed dosage is below suggested therapeutic levels

Douche

Douche

DropsDrugForm

No description

Drug Entity

A value representing the specific kind of Drug Entity the instance represents.

DuplicateTherapyAlert

No description

ECGObservationSeriesType

No description

EPSG-GeodeticParameterDataset

Description: The EPSG (European Petroleum Survey Group) dataset represents all Datums, coordinate references (projected and 2D geographic) and coordinate systems (including Cartesian coordinate systems) used in surveying worldwide. Each record includes a 4-8 digit unique identifier. The current version is available from http://www.epsg.org/. The database contains over 4000 records covering spatial data applications worldwide.

ERPracticeSetting

The section of a health care facility for providing rapid treatment to victims of sudden illness or trauma.

EasternAlgonquin

No description

EasternApachean

No description

EasternMiwok

No description

EducationLevel

No description

ElectroOsmosisRoute

Electro-osmosis

EligibilityActReasonCode

Description:Identifies the reason or rational for why a person is eligible for benefits under an insurance policy or program. Examples: A new employee is eligible for health insurance as an employment benefit. A person meets eligibility criteria for government program coverage based on financial, age or health status.

EmergencyMedicalServiceProviderHIPAA

Broad category for individuals who complete additional training and education in the area of pre-hospital emergency services and are licensed and/or practice within the scope of that training.

EmergencyPharmacySupplyType

A supply action where there is no ‘valid’ order for the supplied medication. E.g. Emergency vacation supply, weekend supply (when prescriber is unavailable to provide a renewal prescription)

EmployeeJobClass

A code qualifying the employment in various ways, such as, full-time vs. part time, etc.

EmploymentStatusUB92

No description

Encounter class

This value set defines a set of codes that can be used to indicate the class of encounter: a specific code indicating class of service provided.

Encounter subject status

This example value set defines a set of codes that can be used to indicate the status of the subject within the encounter

Encounter type

This example value set defines a set of codes that can be used to indicate the type of encounter: a specific code indicating type of service provided.

EncounterAdmissionSource

No description

EncounterSpecialCourtesy

A code identifying special courtesies extended to the patient. For example, no courtesies, extended courtesies, professional courtesy, VIP courtesies.

EndocervicalRoute

Endocervical

EndocrinologyClinic

No description

Endpoint Connection Type

This is an example value set defined by the FHIR project, that could be used to represent possible connection type profile values.

Enema

Enema

Enteral Formula Additive Type Code

EnteralFormulaAdditiveType: Codes for the type of modular component such as protein, carbohydrate or fiber to be provided in addition to or mixed with the base formula. This value set is provided as a suggestive example.

EnteralRoute

Enteral

EntericCoatedCapsule

No description

EntericCoatedTablet

No description

EntityClass

Classifies the Entity class and all of its subclasses. The terminology is hierarchical. At the top is this HL7-defined domain of high-level categories (such as represented by the Entity subclasses). Each of these terms must be harmonized and is specializable. The value sets beneath are encoded in Entity.code and are drawn from multiple, frequently external, domains that reflect much more fine-grained typing.

EntityClassAnimal

A living subject from the animal kingdom.

EntityClassCertificateRepresentation

A physical artifact that stores information about the granting of authorization.

EntityClassChemicalSubstance

A substance that is fully defined by an organic or inorganic chemical formula, includes mixtures of other chemical substances. Refine using, e.g., IUPAC codes.

EntityClassCityOrTown

The territory of a city, town or other municipality.

EntityClassContainer

A container of other entities.

EntityClassCountry

The territory of a sovereign nation.

EntityClassCountyOrParish

The territory of a county, parish or other division of a state or province.

EntityClassDevice

A subtype of ManufacturedMaterial used in an activity, without being substantially changed through that activity. The kind of device is identified by the code attribute inherited from Entity. Usage: This includes durable (reusable) medical equipment as well as disposable equipment.

EntityClassFood

Naturally occurring, processed or manufactured entities that are primarily used as food for humans and animals.

EntityClassGroup

A grouping of resources (personnel, material, or places) to be used for scheduling purposes. May be a pool of like-type resources, a team, or combination of personnel, material and places.

EntityClassHealthChartEntity

A health chart included to serve as a document receiving entity in the management of medical records.

EntityClassHolder

A type of container that can hold other containers or other holders.

EntityClassImagingModality

Class to contain unique attributes of diagnostic imaging equipment.

EntityClassLivingSubject

Anything that essentially has the property of life, independent of current state (a dead human corpse is still essentially a living subject.)

EntityClassManufacturedMaterial

Corresponds to the ManufacturedMaterial class

EntityClassMaterial

Any thing that has extension in space and mass, may be of living or non-living origin.

EntityClassMicroorganism

All single celled living organisms including protozoa, bacteria, yeast, viruses, etc.

EntityClassNation

A politically organized body of people bonded by territory and known as a nation.

EntityClassNonPersonLivingSubject

No description

EntityClassOrganization

A social or legal structure formed by human beings.

EntityClassPerson

A living subject of the species homo sapiens.

EntityClassPlace

A physicial place or site with its containing structure. May be natural or man-made. The geographic position of a place may or may not be constant.

EntityClassPlant

A living subject from the order of plants.

EntityClassPublicInstitution

An agency of the people of a state often assuming some authority over a certain matter. Includes government, governmental agencies, associations.

EntityClassRoot

Corresponds to the Entity class

EntityClassState

A politically organized body of people bonded by territory, culture, or ethnicity, having sovereignty (to a certain extent) granted by other states (enclosing or neighboring states). This includes countries (nations), provinces (e.g., one of the United States of America or a French departement), counties or municipalities. Refine using, e.g., ISO country codes, FIPS-PUB state codes, etc.

EntityClassStateOrProvince

The territory of a state, province, department or other division of a sovereign country.

EntityCode

A value representing the specific kind of Entity the instance represents. Examples: A medical building, a Doberman Pinscher, a blood collection tube, a tissue biopsy. Rationale: For each Entity, the value for this attribute is drawn from one of several coding systems depending on the Entity classCode, such as living subjects (animal and plant taxonomies), chemical substance (e.g., IUPAC code), organizations, insurance company, government agency, hospital, park, lake, syringe, etc. It is possible that Entity.code may be so fine grained that it represents a single instance. An example is the CDC vaccine manufacturer code, modeled as a concept vocabulary, when in fact each concept refers to a single instance.

EntityDeterminer

EntityDeterminer in natural language grammar is the class of words that comprises articles, demonstrative pronouns, and quantifiers. In the RIM, determiner is a structural code in the Entity class to distinguish whether any given Entity object stands for some, any one, or a specific thing.

EntityDeterminerDescribedGroup

A standard value set allowing reference to all EntityDeterminer codes that are equal to or specializations of GROUPKIND. This is the value set used when a model indicates that the binding is to “<= GROUPKIND”.

EntityDeterminerDescribedQuantified

The described quantified determiner indicates that the given Entity is taken as a general description of a specific amount of a thing. For example, QUANTIFIED_KIND of syringe (quantity = 3,) stands for exactly three syringes.

EntityDeterminerDetermined

The described determiner is used to indicate that the given Entity is taken as a general description of a kind of thing that can be taken in whole, in part, or in multiples.

EntityDeterminerSpecific

The specific determiner indicates that the given Entity is taken as one specific thing instance. For example, a human INSTANCE (quantity = 1,) stands for exactly one human being.

EntityDeterminerSpecificGroup

A standard value set allowing reference to all EntityDeterminer codes that are equal to or specializations of GROUP. This is the value set used when a model indicates that the binding is to “<= GROUP”.

EntityHandling

Special handling requirements for an Entity. Example:Keep at room temperature; Keep frozen below 0 C; Keep in a dry environment; Keep upright, do not turn upside down.

EntityInformationSensitivityPolicy

EntitySensitivity codes are used to convey a policy that is applicable to sensitive information conveyed by an entity attribute. May be used to bind a Role.confidentialityCode associated with an Entity per organizational policy. Role.confidentialityCode is defined in the RIM as “an indication of the appropriate disclosure of information about this Role with respect to the playing Entity.”

EntityNamePartQualifier

No description

EntityNamePartQualifierR2

Description:The qualifier is a set of codes each of which specifies a certain subcategory of the name part in addition to the main name part type. For example, a given name may be flagged as a nickname, a family name may be a pseudonym or a name of public records.

EntityNamePartType

No description

EntityNamePartTypeR2

Description:Indicates whether the name part is a given name, family name, prefix, suffix, etc.

EntityNameUse

No description

EntityNameUseR2

Description:A set of codes advising a system or user which name in a set of names to select for a given purpose.

EntityRisk

The vocabulary table for the Entity.riskCode attribute

EntityStatus

Codes representing the defined possible states of an Entity, as defined by the Entity class state machine.

EntityStatusActive

The state representing the fact that the Entity record is currently active.

EntityStatusInactive

Definition: The state representing the fact that the entity is inactive.

EntityStatusNormal

The ‘typical’ state. Excludes “nullified” which represents the termination state of an Entity record instance that was created in error.

EntityStatusNullified

The state representing the termination of an Entity record instance that was created in error.

EpiduralRoute

Epidural

Episode of care type

This example value set defines a set of codes that can be used to express the usage type of an EpisodeOfCare record.

EquipmentAlertLevel

No description

EskimoAleut

No description

Eskimoan

No description

Ethnicity

In the United States, federal standards for classifying data on ethnicity determine the categories used by federal agencies and exert a strong influence on categorization by state and local agencies and private sector organizations. The federal standards do not conceptually define ethnicity, and they recognize the absence of an anthropological or scientific basis for ethnicity classification. Instead, the federal standards acknowledge that ethnicity is a social-political construct in which an individual’s own identification with a particular ethnicity is preferred to observer identification. The standards specify two minimum ethnicity categories: Hispanic or Latino, and Not Hispanic or Latino. The standards define a Hispanic or Latino as a person of “Mexican, Puerto Rican, Cuban, South or Central America, or other Spanish culture or origin, regardless of race.” The standards stipulate that ethnicity data need not be limited to the two minimum categories, but any expansion must be collapsible to those categories. In addition, the standards stipulate that an individual can be Hispanic or Latino or can be Not Hispanic or Latino, but cannot be both.

EthnicityHispanic

No description

EthnicityHispanicCentralAmerican

No description

EthnicityHispanicMexican

No description

EthnicityHispanicSouthAmerican

No description

EthnicityHispanicSpaniard

No description

EvidenceDirectness

The quality of how direct the match is.

EvidenceVariableRole

The role that the assertion variable plays.

Example Claim SubType Codes

This value set includes sample Claim SubType codes which are used to distinguish the claim types for example within type institutional there may be subtypes for emergency services, bed stay and transportation.

Example Coverage Financial Exception Codes

This value set includes Example Coverage Financial Exception Codes.

Example Diagnosis Related Group Codes

This value set includes example Diagnosis Related Group codes.

Example Diagnosis Type Codes

This value set includes example Diagnosis Type codes.

Example Diagnosis on Admission Codes

This value set includes example Diagnosis on Admission codes.

Example Message Reason Codes

Example Message Reasons. These are the set of codes that might be used an updating an encounter using admin-update.

Example Payment Type Codes

This value set includes example Payment Type codes.

Example Procedure Type Codes

This value set includes example Procedure Type codes.

Example Program Reason Codes

This value set includes sample Program Reason Span codes.

Example Provider Qualification Codes

This value set includes sample Provider Qualification codes.

Example Related Claim Relationship Codes

This value set includes sample Related Claim Relationship codes.

Example Revenue Center Codes

This value set includes sample Revenue Center codes.

Example Service Place Codes

This value set includes a smattering of Service Place codes.

Example Use Codes for List

Example use codes for the List resource - typical kinds of use.

Example Vision Prescription Product Codes

This value set includes a smattering of Prescription Product codes.

Exception Codes

This value set includes sample Exception codes.

ExpansionParameterSource

Declares what the source of a parameter is.

ExpansionProcessingRule

Defines how concepts are processed into the expansion when it’s for UI presentation.

ExpectedSubset

An occurrence that is scheduled to occur in the future. An Act whose effective time is greater than ‘now’, where ‘now’ is the time the instance is authored.

ExposureMode

Code for the mechanism by which the exposure agent was exchanged or potentially exchanged by the participants involved in the exposure.

ExtendedReleaseCapsule

A solid dosage form in which the drug is enclosed within either a hard or soft soluble container made from a suitable form of gelatin, and which releases a drug (or drugs) in such a manner to allow a reduction in dosing frequency as compared to that drug (or drugs) presented as a conventional dosage form.

ExtendedReleaseSuspension

No description

ExtendedReleaseTablet

A solid dosage form containing a drug which allows at least a reduction in dosing frequency as compared to that drug presented in conventional dosage form.

ExtraAmnioticRoute

Extra-amniotic

ExtracorporealCirculationRoute

Extracorporeal circulation

FHIR Device Types

Codes used to identify medical devices. Includes concepts from SNOMED CT (http://www.snomed.org/) where concept is-a 49062001 (Device) and is provided as a suggestive example.

FHIRDeviceStatusReason

The availability status reason of the device.

FHIRdeviceStatus

The availability status of the device.

Failure-action

The result if validation fails

FamilyHistoryAbsentReason

Codes describing the reason why a family member’s history is not available.

FamilyMember

A relationship between two people characterizing their “familial” relationship

Financial Task Codes

This value set includes Financial Task codes.

Financial Task Input Type Codes

This value set includes Financial Task Input Type codes.

FirstFillPharmacySupplyType

The initial fill against an order. (This includes initial fills against refill orders.)

Flag Category

Example list of general categories for flagged issues. (Not complete or necessarily appropriate.)

Flush

Flush

FoamDrugForm

No description

FontStyle

(abstract) Defines font rendering characteristics

Forms

This value set includes a sample set of Forms codes.

FosterChild

The player of the role is a child receiving parental care and nurture from the scoping person (parent) but not related to him or her through legal or blood ties.

Funds Reservation Codes

This value set includes sample funds reservation type codes.

GIClinicPracticeSetting

No description

GIDiagTherPracticeSetting

A practice setting where GI procedures (such as endoscopies) are performed

GTIN

Description:Global Trade Item Number is an identifier for trade items developed by GS1 (comprising the former EAN International and Uniform Code Council).

GTSAbbreviation

No description

GTSAbbreviationBase

Description:Basic abbreviations defined for the General timing Specification data type.

GTSAbbreviationHolidays

Holidays

GTSAbbreviationHolidaysChristianRoman

Christian Holidays (Roman/Gregorian “Western” Tradition.)

GTSAbbreviationHolidaysUSNational

United States National Holidays (public holidays for federal employees established by U.S. Federal law 5 U.S.C. 6103.)

GTSAbbreviationOther

Description:Other, more specific, abbreviations defined for the General timing Specification data type, that are specializations of one of the Base concepts.

GasDrugForm

Any elastic aeriform fluid in which the molecules are separated from one another and have free paths.

GasLiquidMixture

No description

GasSolidSpray

No description

GastricRoute

Gastric

GelDrugForm

A semisolid system consisting of either suspensions made up of small inorganic particles or large organic molecules interpenetrated by a liquid.

Gender Identity

Codes that indicate a individual’s gender identity. This value set is a minimum set of commonly used values. It is expected and encouraged that specific jurisdictions or communities will use additional gender identity concepts that are relevant within their community.

GenderStatus

A value representing whether the primary reproductive organs of NonPersonLivingSubject are present.

GeneralAcuteCareHospital

(X12N 282N00000N)

GeneralAddressUse

No description

GeneralPurposeOfUse

Supports communication of purpose of use at a general level.

GenericUpdateReasonCode

Description:Identifies why a change is being made to a record.

GeneticObservationInterpretation

Codes that specify interpretation of genetic analysis, such as “positive”, “negative”, “carrier”, “responsive”, etc.

GeneticObservationMethod

A code that provides additional detail about the means or technique used to ascertain the genetic analysis. Example, PCR, Micro Array

GeneticObservationType

Description: Identifies the kinds of genetic observations that can be performed.

GeneticObservationValue

Description: The domain contains genetic analysis specific observation values, e.g. Homozygote, Heterozygote, etc.

GenitourinaryRoute

Genitourinary

GingivalRoute

Gingival

Goal achievement status

Describes the progression, or lack thereof, towards the goal against the target.

Goal category

Example codes for grouping goals to use for filtering or presentation.

Goal priority

Indicates the level of importance associated with reaching or sustaining a goal.

GoalAcceptanceStatus

Codes indicating whether the goal has been accepted by a stakeholder.

GoalRelationshipType

Types of relationships between two goals.

GrandChild

The player of the role is a child of the scoping person’s son or daughter.

Grandparent

parent of a parent of the subject

GreatGrandparent

The player of the role is a parent of the scoping person’s grandparent.

GregorianCalendarCycle

No description

GuideParameterCode

Code of parameter that is input to the guide.

HL7 Value Set for State/Province

Concepts used to specify a state or province. Used in Version 2 messaging in the Extended Composite ID with Check Digit (CX), Performing Person Time Stamp (PPN), and Extended Composite ID Number and Name for Persons (XCN) values as well as the Accident (ACC) segment.

HL7 ValueSet of Format Codes for use with Document Sharing

The HL7-FormatCodes value set is defined to be the set of FormatCode(s) defined by implementation guides published by HL7 and other SDOs. The use of a formatCode from the FormatCodes value set specifies the technical format that a document conforms to. The formatCode is a further specialization more detailed than the mime-type. The formatCode provides sufficient information to allow any potential document content consumer to know if it can process and/or display the content of the document based on the document encoding, structure and template conformance indicated by the formatCode. The set of formatCodes is intended to be extensible. The Content Logical Description is defined intentionally to permit formatCodes defined by other Standards Development Organizations to be added by inclusion of additional formatCode Code Systems.

HL7AccommodationCode

Description:Accommodation type. In Intent mood, represents the accommodation type requested. In Event mood, represents accommodation assigned/used. In Definition mood, represents the available accommodation type.

HL7CalendarCycle

No description

HL7ITSVersionCode

HL7 implementation technology specification versions. These codes will document the ITS type and version for message encoding. The code will appear in the instances based upon rules expressed in the ITS, and do not appear in the abstract message, either as it is presented to received from the ITS.

HL7SearchUse

No description

HL7StandardVersionCode

This is the domain of HL7 version codes for the Version 3 standards. Values are to be determined by HL7 and added with each new version of the HL7 Standard.

HL7UpdateMode

The possible modes of updating that occur when an attribute is received by a system that already contains values for that attribute.

HL7Workgroup

An HL7 administrative unit that owns artifacts in the FHIR specification.

HairRoute

Hair

HalfSibling

The player of the role is related to the scoping entity by sharing only one biological parent.

HandlingConditionSet

Set of handling instructions prior testing of the specimen.

HealthCareCommonProcedureCodingSystem

This value set includes all HCPCS Level II codes.

HealthQualityMeasureDocument

No description

HealthcareServiceLocation

A comprehensive classification of locations and settings where healthcare services are provided. This value set is based on the CMS Place of Service code set NHSN location code system that has been developed over a number of years through CDCaTMs interaction with a variety of healthcare facilities and is intended to serve a variety of reporting needs where coding of healthcare service locations is required. Excluded codes are those that do not represent an actual location where health care services can be delivered, IE: Float, or a location aggregation.

HeightSurfaceAreaAlert

Proposed therapy may be inappropriate based on the patient’s height or body surface area

HemClinPracticeSetting

No description

Hokan

No description

HomeAddress

No description

Homeless

Definition: Living arrangements lacking a permanent residence.

HospitalPracticeSetting

An acute care institution that provides medical, surgical, or psychiatric care and treatment for the sick or the injured.

HospitalUnitPracticeSetting

No description

HtmlLinkType

HtmlLinkType values are drawn from HTML 4.0 and describe the relationship between the current document and the anchor that is the target of the link

HumanActSite

An anatomical location on a human which can be the focus of an act. OpenIssue: This value set was approved for deletion in November 2008, and was deleted at release #762. Subsequently, however, it was found that this deletion caused the legacy software embedded in the RMIM Designer in Visio to fail to show appropriate options for concepts in the subject area of this value set. For that reason, the value set was re-added in releasse 813 and DEPRECATED from general use at the same time. This value set should be deleted as soon as it is no longer required to support of the legacy software.

HumanLanguage

Codes for the representation of the names of human languages.

HumanSubstanceAdministrationSite

The set of body locations to or through which a drug product may be administered.

ICUPracticeSetting

No description

IDClinPracticeSetting

No description

IdentifierReliability

Description: The identifier was issued by the system responsible for constructing the instance.

IdentifierScope

Description: Codes to specify the scope in which the identifier applies to the object with which it is associated, and used in the datatype property II.

ImageMediaType

Image media type.

Immunization Evaluation Dose Status Reason codes

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the reason why an administered dose has been assigned a particular status. Often, this reason describes why a dose is considered invalid. This value set is provided as a suggestive example.

Immunization Evaluation Dose Status codes

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the validity of a dose relative to a particular recommended schedule. This value set is provided as a suggestive example.

Immunization Funding Source

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the source of the vaccine administered. This value set is provided as a suggestive example.

Immunization Program Eligibility

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the patient’s eligibility for a vaccination program. This value set is provided as a suggestive example.

Immunization Recommendation Status Codes

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the status of the patient towards perceived immunity against a vaccine preventable disease. This value set is provided as a suggestive example.

Immunization Subpotent Reason

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the reason why a dose is considered to be subpotent. This value set is provided as a suggestive example.

ImmunizationObservationType

Description: Indicates the valid antigen count.

Implant Status

A set codes that define the functional status of an implanted device.

Implantation

Implantation

IncidentalServiceDeliveryLocationRoleType

No description

IndividualCaseSafetyReportType

All codes from code system ActCode._IndividualCaseSafetyReportType

IndividualInsuredCoveredPartyRoleType

DescriptionA role recognized through the eligibility of a party to play an individual insured for benefits covered or provided under an insurance policy where the party is also the policy holder.

IndividualPackageEntityType

Container intended to contain sufficient material for only one use.

IndustryClassificationSystem

No description

InformationSensitivityPolicy

Value Set of codes that specify the reason for the restricted access. Sensitivity codes are not useful for interoperability outside of a policy domain because sensitivity policies are typically localized and vary drastically across policy domains even for the same information category because of differing organizational business rules, security policies, and jurisdictional requirements. For example, an “employee” sensitivity code would make little sense for use outside of a policy domain. “Taboo” would rarely be useful outside of a policy domain unless there are jurisdictional requirements requiring that a provider disclose sensitive information to a patient directly. Sensitivity codes may be more appropriate in a legacy system’s Master Files in order to notify those who access a patient’s orders and observations about the sensitivity policies that apply. Newer systems may have a security engine that uses a sensitivity policy’s criteria directly. The specializable Sensitivity Act.code may be useful in some scenarious if used in combination with a sensitivity identifier and/or Act.titleValue Set of codes that specify the reason for the restricted access. Note that this resource was created in THO in error due to an oversight in the import processing.

InformationSensitivityPolicy

Sensitivity codes are not useful for interoperability outside of a policy domain because sensitivity policies are typically localized and vary drastically across policy domains even for the same information category because of differing organizational business rules, security policies, and jurisdictional requirements. For example, an “employee” sensitivity code would make little sense for use outside of a policy domain. “Taboo” would rarely be useful outside of a policy domain unless there are jurisdictional requirements requiring that a provider disclose sensitive information to a patient directly. Sensitivity codes may be more appropriate in a legacy system’s Master Files in order to notify those who access a patient’s orders and observations about the sensitivity policies that apply. Newer systems may have a security engine that uses a sensitivity policy’s criteria directly. The specializable Sensitivity Act.code may be useful in some scenarious if used in combination with a sensitivity identifier and/or Act.title.

Infusion

Infusion

InhalantDrugForm

No description

Inhalation

Inhalation

InhalerMedicalDevice

A small device used for inhaling medicine in the form of a vapour or gas in order to ease a respiratory condition such as asthma or to relieve nasal congestion.

Injection

Injection

InjectionMedicalDevice

A device intended to administer liquid into a subject via a

Insertion

Insertion

Instillation

Instillation

Institution

Institution

Insurance plan type

This example value set defines a set of codes that can be used to indicate a type of insurance plan.

IntegrityCheckAlgorithm

No description

InteractionDetectedIssueCode

No description

InterameningealRoute

Interameningeal

InteriorSalish

No description

InterstitialRoute

Interstitial

IntraabdominalRoute

Intra-abdominal

IntraarterialInjection

Injection, intraarterial

IntraarterialRoute

Intra-arterial

IntraarticularRoute

Intraarticular

IntrabronchialRoute

Intrabronchial

IntrabursalRoute

Intrabursal

IntracardiacInjection

Injection, intracardiac

IntracardiacRoute

Intracardiac

IntracartilaginousRoute

Intracartilaginous

IntracaudalRoute

Intracaudal

IntracavernosalRoute

Intracavernosal

IntracavitaryRoute

Intracavitary

IntracerebralRoute

Intracerebral

IntracervicalRoute

Intracervical

IntracisternalRoute

Intracisternal

IntracornealRoute

Intracorneal

IntracoronalRoute

Intracoronal (dental)

IntracoronaryInjection

Injection, intracoronary

IntracoronaryRoute

Intracoronary

IntracorpusCavernosumRoute

Intracorpus cavernosum

IntradermalRoute

Intradermal

IntradiscalRoute

Intradiscal

IntraductalRoute

Intraductal

IntraduodenalRoute

Intraduodenal

IntraduralRoute

Intradural

IntraepidermalRoute

Intraepidermal

IntraepithelialRoute

Intraepithelial

IntraesophagealRoute

Intraesophageal

IntragastricRoute

Intragastric

IntrailealRoute

Intraileal

IntralesionalRoute

Intralesional

IntraluminalRoute

Intraluminal

IntralymphaticRoute

Intralymphatic

IntramedullaryRoute

Intramedullary

IntramuscularInjection

Injection, intramuscular

IntramuscularRoute

Intramuscular

IntraocularRoute

Intraocular

IntraosseousRoute

Intraosseous

IntraovarianRoute

Intraovarian

IntrapericardialRoute

Intrapericardial

IntraperitonealRoute

Intraperitoneal

IntrapleuralRoute

Intrapleural

IntraprostaticRoute

Intraprostatic

IntrapulmonaryRoute

Intrapulmonary

IntrasinalRoute

Intrasinal

IntraspinalRoute

Intraspinal

IntrasternalRoute

Intrasternal

IntrasynovialRoute

Intrasynovial

IntratendinousRoute

Intratendinous

IntratesticularRoute

Intratesticular

IntrathecalRoute

Intrathecal

IntrathoracicRoute

Intrathoracic

IntratrachealRoute

Intratracheal

IntratubularRoute

Intratubular

IntratumorRoute

Intratumor

IntratympanicRoute

Intratympanic

IntrauterineRoute

Intrauterine

IntravascularRoute

Intravascular

IntravenousInfusion

Infusion, intravenous

IntravenousInjection

Injection, intravenous

IntravenousRoute

Intravenous

IntraventricularRoute

Intraventricular

IntravesicleRoute

Intravesicle

IntravitrealRoute

Intravitreal

InuitInupiaq

No description

InvoiceElementAdjudicated

Total counts and total net amounts adjudicated for all Invoice Groupings that were adjudicated within a time period based on the adjudication date of the Invoice Grouping.

InvoiceElementPaid

Total counts and total net amounts paid for all Invoice Groupings that were paid within a time period based on the payment date.

InvoiceElementSubmitted

Total counts and total net amounts billed for all Invoice Groupings that were submitted within a time period. Adjudicated invoice elements are included.

IontophoresisRoute

Iontophoresis

Iroquoian

No description

Irrigation

Irrigation

IrrigationSolution

A sterile solution intended to bathe or flush open wounds or body cavities; they’re used topically, never parenterally.

IssueFilterCode

Description:Indicates how result sets should be filtered based on whether they have associated issues.

JejunumRoute

Jejunum

Jurisdiction ValueSet

This value set defines a base set of codes for country, country subdivision and region for indicating where a resource is intended to be used. Note: The codes for countries and country subdivisions are taken from ISO 3166 while the codes for “supra-national” regions are from UN Standard country or area codes for statistical use (M49).

Kalapuyan

No description

Keresan

No description

KiowaTanoan

No description

KitEntityType

A container for a diverse collection of products intended to be used together for some purpose (e.g. Medicinal kits often contain a syringe, a needle and the injectable medication).

KnowledgeSubjectObservationCode

No description

KnowledgeSubjectObservationValue

Observation values used to indicate a knowledge subject of interest for which knowledge content is requested (e.g., a medication, a laboratory test, a medical condition).

KnowledgeSubtopicObservationCode

No description

KnowledgeSubtopicObservationValue

Observation values used to indicate a knowledge subtopic of interest for which knowledge content is requested (e.g., treatment, etiology, prognosis).

KoyukonIngalik

No description

KutchinHan

No description

LOINCObservationActContextAgeDefinitionCode

Identifies a type of observation that captures the age of an entity involved in an act with no implied method of determination.

LOINCObservationActContextAgeType

Definition:The set of LOINC codes for the act of determining the period of time that has elapsed since an entity was born or created.

LabResultReportingProcessStepCode

No description

LabResultTriggerEvents

Description:Trigger Event ID as published in the standard.

LabSpecimenCollectionProviders

No description

Laboratory Observation Sub-Type

Value Set of codes specifying an observation sub-type used with observation type code RSLT (Result).

LacrimalPunctaRoute

Lacrimal puncta

LanguageAbilityMode

A value representing the method of expression of the language. Example:Expressed spoken, expressed written, expressed signed, received spoken, received written, received signed.

LanguageAbilityProficiency

A value representing the level of proficiency in a language. Example:Excellent, good, fair, poor.

LaryngealRoute

Laryngeal

LavageRoute

Lavage

LengthOutOfRange

No description

LibraryType

The type of knowledge asset this library contains.

LifeInsurancePolicy

Definition: A policy under which the insurer agrees to pay a sum of money upon the occurrence of the covered partys death. In return, the policyholder agrees to pay a stipulated amount called a premium at regular intervals. Life insurance indemnifies the beneficiary for the loss of the insurable interest that a beneficiary has in the life of a covered party. For persons related by blood, a substantial interest established through love and affection, and for all other persons, a lawful and substantial economic interest in having the life of the insured continue. An insurable interest is required when purchasing life insurance on another person. Specific exclusions are often written into the contract to limit the liability of the insurer; for example claims resulting from suicide or relating to war, riot and civil commotion. Discussion:A life insurance policy may be used by the covered party as a source of health care coverage in the case of a viatical settlement, which is the sale of a life insurance policy by the policy owner, before the policy matures. Such a sale, at a price discounted from the face amount of the policy but usually in excess of the premiums paid or current cash surrender value, provides the seller an immediate cash settlement. Generally, viatical settlements involve insured individuals with a life expectancy of less than two years. In countries without state-subsidized healthcare and high healthcare costs (e.g. United States), this is a practical way to pay extremely high health insurance premiums that severely ill people face. Some people are also familiar with life settlements, which are similar transactions but involve insureds with longer life expectancies (two to fifteen years).

LineAccessMedicalDevice

A hollow tube used to administer a substance into a vein, artery or body cavity

LingualRoute

Lingual

Liquid

A state of substance that is an intermediate one entered into as matter goes from solid to gas; liquids are also intermediate in that they have neither the orderliness of a crystal nor the randomness of a gas. (Note: This term should not be used to describe solutions, only pure chemicals in their liquid state.)

LiquidCleanser

No description

LiquidLiquidEmulsion

A two-phase system in which one liquid is dispersed throughout another liquid in the form of small droplets.

LiquidSolidSuspension

A liquid preparation which consists of solid particles dispersed throughout a liquid phase in which the particles are not soluble.

List Empty Reasons

General reasons for a list to be empty. Reasons are either related to a summary list (i.e. problem or medication list) or to a workflow related list (i.e. consultation list).

List Order Codes

Base values for the order of the items in a list resource.

ListStyle

Defines list rendering characteristics

LivingArrangement

A code depicting the living arrangements of a person

LivingSubjectProductionClass

Code indicating the primary use for which a living subject is bred or grown

Loan

Temporary supply of a product without transfer of ownership for the product.

LocalMarkupIgnore

Tells a receiver to ignore just the local markup tags (local_markup, local_header, local_attr) when value=”markup”, or to ignore the local markup tags and all contained content when value=”all”

LocalRemoteControlState

A value representing the current state of control associated with the device. Examples: A device can either work autonomously (localRemoteControlStateCode=”Local”) or it can be controlled by another system (localRemoteControlStateCode=”Remote”). Rationale: The control status of a device must be communicated between devices prior to remote commands being transmitted. If the device is not in “Remote” status then external commands will be ignored.

Location type

This example value set defines a set of codes that can be used to indicate the physical form of the Location.

LogicalObservationIdentifierNamesAndCodes

The LOINC database provides a set of universal names and ID codes for identifying laboratory and clinical test results. The purpose is to facilitate the exchange and pooling of results, such as blood hemoglobin, serum potassium, or vital signs, for clinical care, outcomes management, and research. The LOINC codes are not intended to transmit all possible information about a test or observation. They are only intended to identify the test result or clinical observation. http://www.regenstrief.org/LOINC/LOINC.htm

LoincDocumentOntologyInternational

The LOINC Document Ontology constrained for usage in the Universal Realm by removal of “regional” Document Types such as the “VA Compensation and Pension” codes.

LotionDrugForm

The term “lotion” has been used to categorize many topical suspensions, solutions and emulsions intended for application to the skin.

MIF Concept Relationship Kind

Codes for use in the ext-mif-relationship-relationshipKind to capture V3 Model Interchange Format (MIF) SupportedConceptRelationship.relationshipKind values

MIF Concept Relationship Reflexivity

Codes for use in the ext-mif-relationship-reflexivity to capture V3 Model Interchange Format (MIF) SupportedConceptRelationship.reflexivity values

MIF Concept Relationship Symmetry

Codes for use in the ext-mif-relationship-symmetry to capture V3 Model Interchange Format (MIF) SupportedConceptRelationship.symmetry values

MIF Concept Relationship Transitivity

Codes for use in the ext-mif-relationship-transitivity to capture V3 Model Interchange Format (MIF) SupportedConceptRelationship.transitivity values

Maiduan

No description

ManagedCarePolicy

Definition: Government mandated program providing coverage, disability income, and vocational rehabilitation for injuries sustained in the work place or in the course of employment. Employers may either self-fund the program, purchase commercial coverage, or pay a premium to a government entity that administers the program. Employees may be required to pay premiums toward the cost of coverage as well. Managed care policies specifically exclude coverage for losses insured under a disability policy, workers’ compensation program, liability insurance (including automobile insurance); or for medical expenses, coverage for on-site medical clinics or for limited dental or vision benefits when these are provided under a separate policy. Discussion: Managed care policies are offered by managed care plans that contract with selected providers or health care organizations to provide comprehensive health care at a discount to covered parties and coordinate the financing and delivery of health care. Managed care uses medical protocols and procedures agreed on by the medical profession to be cost effective, also known as medical practice guidelines. Providers are typically reimbursed for covered services by a capitated amount on a per member per month basis that may reflect difference in the health status and level of services anticipated to be needed by the member.

ManagedParticipationStatus

Codes representing the defined possible states of a Managed Participation, as defined by the Managed Participation class state machine.

ManagedParticipationStatusActive

The state representing the fact that the Participation is in progress.

ManagedParticipationStatusCancelled

The terminal state resulting from cancellation of the Participation prior to activation.

ManagedParticipationStatusCompleted

The terminal state representing the successful completion of the Participation.

ManagedParticipationStatusNormal

The ‘typical’ state. Excludes “nullified” which represents the termination state of a participation instance that was created in error.

ManagedParticipationStatusNullified

The state representing the termination of a Participation instance that was created in error.

ManagedParticipationStatusPending

The state representing that fact that the Participation has not yet become active.

Manufacturer Model Name Example

An example value set representing the ManufacturerModelName concept domain used to convey a coded name for the software used to author content.

MapRelationship

The closeness or quality of the mapping between the HL7 concept (as represented by the HL7 concept identifier) and the source coding system. The values are patterned after the similar relationships used in the UMLS Metathesaurus. Because the HL7 coding sy

MaritalStatus

The domestic partnership status of a person. Example:Married, separated, divorced, widowed, common-law marriage.

MatchGrade

A Master Patient Index (MPI) assessment of whether a candidate patient record is a match or not.

MaterialDangerInfectious

Material known to be infectious with human pathogenic microorganisms. Those who handle this material must take precautions for their protection.

MaterialDangerInflammable

Material is highly inflammable and in certain mixtures (with air) may lead to explosions. Keep away from fire, sparks and excessive heat.

MaterialEntityClassType

Types of Material for EntityClass “MAT”

MaxOccurs

Flags an element as having unlimited repetitions.

Measure Aggregate Method

Aggregation method for a measure (e.g. sum, average, median, minimum, maximum, count)

MeasureDataUsage

The intended usage for supplemental data elements in the measure.

MeasureImprovementNotation

Observation values that indicate what change in a measurement value or score is indicative of an improvement in the measured item or scored issue.

MeasurePopulationType

The type of population.

MeasureScoring

The scoring type of the measure.

MeasureSupplementalData

Supplemental data in a population for measuring purposes.

MeasureType

The type of measure (includes codes from 2.16.840.1.113883.1.11.20368).

MedOncClinPracticeSetting

No description

MediaType

Internet Assigned Numbers Authority (IANA) Mime Media Types

MedicalDevice

A device with direct or indirect therapeutic purpose. Values for EntityCode when EntityClass = “DEV”

Medication administration performer function codes

MedicationAdministration Performer Function Codes

Medication dispense performer function codes

MedicationDispense Performer Function Codes

Medication knowledge characteristic codes

MedicationKnowledge Characteristic Codes

Medication knowledge package type codes

MedicationKnowledge Package Type Codes

Medication knowledge status codes

MedicationKnowledge Status Codes

Medication request category codes

MedicationRequest Category Codes

Medication request course of therapy codes

MedicationRequest Course of Therapy Codes

Medication request status reason codes

MedicationRequest Status Reason Codes

MedicationAdministrationLocation

Direction in which lists of possible answers should be displayed.

MedicationCap

Cap types for medication containers

MedicationGeneralizationRoleType

Identifies the specific hierarchical relationship between the playing and scoping medications. Examples: Generic, Generic Formulation, Therapeutic Class, etc.

MedicationObservationType

No description

MedicationOrderAbortReasonCode

No description

MedicationOrderReleaseReasonCode

Definition:A collection of concepts that indicate why the prescription should be released from suspended state.

MedicationRequestAdministrationLocation

Direction in which lists of possible answers should be displayed.

MedicationUsageAdministrationLocation

Direction in which lists of possible answers should be displayed.

MemberRoleType

A role type that is used to further qualify an entity playing a role where the role class attribute is set to RoleClassMember.

MessageWaitingPriority

Indicates the highest importance level of the set of messages the acknowledging application has waiting on a queue for the receiving application. Discussion: These messages would need to be retrieved via a query. This facilitates receiving applications that cannot receive unsolicited messages (i.e. polling). The specific code specified identifies how important the most important waiting message is (and may govern how soon the receiving application is required to poll for the message). Priority may be used by local agreement to determine the timeframe in which the receiving application is expected to retrieve the messages from the queue.

MilitaryHospital

A health care facility operated by the Department of Defense or other military operation.

MilitaryRoleType

Definition: A person playing the role of program eligible under a program based on military status. Discussion: This CoveredPartyRoleType.code is typically used when the CoveredPartyRole class code is either “program eligible” or “subscriber” and the person’s status as a member of the military meets jurisdictional or program criteria

Missing Tooth Reason Codes

This value set includes sample Missing Tooth Reason codes.

MississippiValley

No description

MissouriRiver

No description

Miwokan

No description

MobileUnit

Location (mobile) where healthcare service was delivered.

MobilityImpaired

No description

ModelMediaType

Model media type.

Modifier type Codes

This value set includes sample Modifier type codes.

ModifyIndicator

Indicates whether the subscription to a query is new or is being modified.

ModifyPrescriptionReasonType

Indicates why an existing prescription is changed.

MucosalAbsorptionRoute

Mucosal absorption

MucousMembraneRoute

Mucous membrane

MultiUseContainerEntityType

A container intended to contain sufficient material for more than one use. (I.e. Material is intended to be removed from the container at more than one discrete time period.)

MultipartMediaType

Multipart Media Type

Muskogean

No description

NUCCProviderCodes

In the absence of an all-encompassing Provider Classification System, both X12N and the National Provider System Workgroup from the Centers for Medicare and Medicaid Services (CMS) commenced work on identifying and coding an external provider table that would be able to codify provider type and provider area of specialization for all medical related providers. CMS’ intent was to provide a single coding structure to support work on the National Provider System, while X12N needed a single common table for trading partner use. The two projects worked independently to some extent until April 1996 when the lists were coordinated and a single taxonomy was proposed. A sub-group of the X12N TG2 WG 15 was charged with resolving differences in the two proposed taxonomies. Their work resulted in a single taxonomy that both CMS and members of X12N found meaningful, easy to use, and functional for electronic transactions. The sub-group initially started with the CMS draft taxonomy. This list incorporated all types of providers associated with medical care in various ways. Many of the providers listed, such as technologists or technicians, support or repair equipment/machinery. A number of the providers offer medical services, in concert with others, and do not or cannot bill independently for their portion. The amount of research to validate and classify all providers using the proposed hierarchical structure was enormous. The X12N sub-group focused on medical providers who are licensed practitioners, those who bill for health-related services rendered, and those who appeared on the Medicare CMS Provider Specialty listing. This included providers who were licensed to practice medicine via state licensure agencies. In addition, a very broad definition of “areas of specialization” was used, which included nationally recognized specialties, provider self-designated specialties, areas of practice focus, and any request by any agency or trading partner submitted before the first taxonomy release. This level of detail captured specialty information in categories detailed enough to support those trading credentialing information, yet broad enough to support those wishing to trade directory level specialization information. In 2001, ANSI ASC X12N asked the NUCC to become the official maintainer of the Health Care Provider Taxonomy List. The NUCC has a formal operating protocol and its membership includes representation from key provider and payer organizations, as well as state and federal agencies, standard development organizations and the National Uniform Billing Committee (NUBC). Criteria for membership includes a national scope and representation of a unique constituency affected by health care electronic commerce, with an emphasis on maintaining a provider/payer balance.

Nadene

No description

NailRoute

Nail

NameLegalUse

No description

NasalInhalation

Inhalation, nasal

NasalRoute

Nasal

NationEntityType

Codes identifying nation states. Allows for finer grained specification of Entity with classcode <= NAT Example:ISO3166 country codes.

NativeEntityAlaska

NATIVE ENTITIES WITHIN THE STATE OF ALASKA RECOGNIZED AND ELIGIBLE TO RECEIVE SERVICES FROM THE UNITED STATES BUREAU OF INDIAN AFFAIRS

NativeEntityContiguous

NATIVE ENTITIES WITHIN THE CONTIGUOUS 48 STATES

NaturalChild

A child as determined by birth.

NaturalParent

No description

NaturalSibling

The player of the role has both biological parents in common with the scoping entity.

Nebulization

Nebulization

NebulizationInhalation

Inhalation, nebulization

Need

The frequency with which the target must be validated

NephClinPracticeSetting

No description

Network Type Codes

This value set includes a smattering of Network type codes.

NieceNephew

The player of the role is a child of scoping person’s brother or sister or of the brother or sister of the scoping person’s spouse.

NoInformation

Description:The value is exceptional (missing, omitted, incomplete, improper). No information as to the reason for being an exceptional value is provided. This is the most general exceptional value. It is also the default exceptional value.

NonDrugAgentEntity

Indicates types of allergy and intolerance agents which are non-drugs. (E.g. foods, latex, etc.)

NonRigidContainerEntityType

A container having dimensions that adjust somewhat based on the amount and shape of the material placed within it.

Nootkan

No description

NorthernCaddoan

No description

NorthernIroquoian

No description

NullFlavor

No description

Numic

No description

NursingOrCustodialCarePracticeSetting

No description

Nutrition intake category codes

NutritionIntake Category Codes

ObligationPolicy

Conveys the mandated workflow action that an information custodian, receiver, or user must perform. Examples:

  • encrypt Usage Note: Per OASIS XACML, an obligation is an operation specified in a policy or policy that is performed in conjunction with the enforcement of an access control decision.
Observation Category Codes

Observation Category codes.

Observation Reference Range Meaning Codes

This value set defines a set of codes that can be used to indicate the meaning/use of a reference range for a particular target population.

ObservationActContextAgeGroupType

Identifies a type of observation that captures the age of a person in terms of age group concept codes.

ObservationActContextAgeType

Definition:The ways the age of an entity involved in an act can be measured, calculated or otherwise expressed in order to provide context for another act.

ObservationAlert

No description

ObservationAllergyType

Hypersensitivity to an agent caused by an immunologic response to an initial exposure.

ObservationAssetValue

Codes specifying asset indicators used to assess or establish eligibility for coverage under a policy or program.

ObservationCategory

High level observation categories for the general type of observation being made. Steward: OO WG

ObservationCoordinateAxisType

No description

ObservationCoordinateSystemType

No description

ObservationDetectedIssueCode

Proposed therapy may be inappropriate or contraindicated due to conditions or characteristics of the patient

ObservationDiagnosisTypes

An observation about the presence (or absence) of a particular disease state in a subject.

ObservationDrugIntoleranceType

Hypersensitivity resulting in an adverse reaction upon exposure to a drug.

ObservationEligibilityIndicatorValue

Code specifying eligibility indicators used to assess or establish eligibility for coverage under a policy or program eligibility status, e.g., certificates of creditable coverage; student enrollment; adoption, marriage or birth certificate.

ObservationEnvironmentalIntoleranceType

Hypersensitivity resulting in an adverse reaction upon exposure to environmental conditions.

ObservationFoodIntoleranceType

Hypersensitivity resulting in an adverse reaction upon exposure to food.

ObservationHealthStatusValue

Code specifying non-clinical indicators related to health status used to assess or establish eligibility for coverage under a policy or program, e.g., pregnancy, disability, drug use, mental health issues.

ObservationIncomeValue

Code specifying financial indicators used to assess or establish eligibility for coverage under a policy or program; e.g., pay stub; tax or income document; asset document; living expenses.

ObservationInterpretation

One or more codes providing a rough qualitative interpretation of the observation,such as “normal” / “abnormal”, “low” / “high”, “better” / “worse”, “resistant” / “susceptible”, “expected” / “not expected”. The value set is intended to be for ANY use where coded representation of an interpretation is needed. Usage Note: This is being communicated in v2.x in OBX-8, in v3 in ObservationInterpretation (CWE) in R1 (Representative Realm) and in FHIR Observation.interpretation. Historically these values come from the laboratory domain, and these codes are extensively used.

ObservationInterpretationChange

Interpretations of change of quantity and/or severity, such as “better”, “worse”, “increased”, etc. At most one of B or W and one of U or D allowed.

ObservationInterpretationDetected

Interpretations of the presence or absence of a component / analyte or organism in a test or of a sign in a clinical observation. In keeping with laboratory data processing practice, these concepts provide a categorical interpretation of the “meaning” of the quantitative value for the same observation.

ObservationInterpretationExceptions

Technical exceptions resulting in the inability to provide an interpretation. At most one allowed. Does not imply normality or severity.

ObservationInterpretationExpectation

Observation interpretation codes for expected results based on additional information (contraindicators) about the patient’s situation.

ObservationInterpretationNormality

Interpretation of normality or degree of abnormality (including critical or “alert” level). Concepts in this category are mutually exclusive, i.e., at most one is allowed.

ObservationInterpretationNormalityAbnormal

Interpretation of degree of abnormality (including critical or “alert” level). Concepts in this category are mutually exclusive, i.e., at most one is allowed.

ObservationInterpretationNormalityCriticallyAbnormal

Interpretation of a critical (or “alert”) degree of abnormality. Concepts in this category are mutually exclusive, i.e., at most one is allowed.

ObservationInterpretationNormalityHigh

Interpretation for a quantitative observation of degree of abnormality (including critical or “alert” level) above the upper limit of the reference range.

ObservationInterpretationNormalityLow

Interpretation for a quantitative observation of degree of abnormality (including critical or “alert” level) below the lower limit of the reference range.

ObservationInterpretationOustsideThreshold

The observation/test result is interpreted as being outside the inclusion range for a particular protocol within which the result is being reported. Example: A positive result on a Hepatitis screening test. Open Issue: We are not deprecating this value set at this time, but instead are leaving open the consideration of deprecation in the future. [Note: The concepts included in this value set have also been suggested for future deprecation, and there are no associated concept subdomains or bindings. Note also that the name of the value set appears to have a typo in it from the old cycle when it was originally added.]

ObservationInterpretationProtocolInclusion

The observation/test result is interpreted as being outside the inclusion range for a particular protocol within which the result is being reported. Example: A positive result on a Hepatitis screening test. Open Issue: We are not deprecating this value set at this time, but instead are leaving open the consideration of deprecation in the future. [Note: The concepts included in this value set have also been suggested for future deprecation, and there are no associated concept subdomains or bindings.]

ObservationInterpretationSusceptibility

Interpretations of anti-microbial susceptibility testing results (microbiology). At most one allowed.

ObservationIntoleranceType

Hypersensitivity resulting in an adverse reaction upon exposure to an agent.

ObservationIssueTriggerCodedObservationType

Distinguishes the kinds of coded observations that could be the trigger for clinical issue detection. These are observations that are not measurable, but instead can be defined with codes. Coded observation types include: Allergy, Intolerance, Medical Condition, Pregnancy status, etc.

ObservationLivingDependencyValue

Continued living in private residence requires functional and health care assistance from spouse or life partner.

ObservationLivingExpenseValue

Codes specifying living expense indicators used to assess or establish eligibility for coverage under a policy or program.

ObservationLivingSituationValue

Code specifying observations related to living situation for a person in a private residence.

ObservationMeasureCountableItems

A collection of items that can be counted by a quality measure (e.g., patients, encounters, procedures, etc.) for Observation.value used in the HQMF R2 MeasureAttribute class.

ObservationMeasureScoring

No description

ObservationMeasureType

Observation values used to indicate what kind of health quality measure is used.

ObservationMethod

A code that provides additional detail about the means or technique used to ascertain the observation. Examples: Blood pressure measurement method: arterial puncture vs. sphygmomanometer (Riva-Rocci), sitting vs. supine position, etc. Constraints: In all observations the method is already partially specified by the Act.code. In this case, the methodCode NEED NOT be used at all. The methodCode MAY still be used to identify this method more clearly in addition to what is implied from the Act.code. However, an information consumer system or process SHOULD NOT depend on this methodCode information for method detail that is implied by the Act.code. If the methodCode is used to express method detail that is also implied by the Act.code, the methodCode MUST NOT be in conflict with the implied method of the Act.code.

ObservationMethodAggregate

A set of codes that defines how a set of values are summarized in an aggregated computation, for use with sets of values do describe which aggregated statistic functions are to be applied (e.g., average, mode, min, max, standard deviation, variance).

ObservationNonAllergyIntoleranceType

Hypersensitivity to an agent caused by a mechanism other than an immunologic response to an initial exposure

ObservationPopulationInclusion

Observation values used to assert various populations that a subject falls into.

ObservationQualityMeasureAttribute

Codes used to define various metadata aspects of a health quality measure.

ObservationSequenceType

No description

ObservationSeriesType

No description

ObservationSocioEconomicStatusValue

Code specifying observations or indicators related to socio-economic status used to assess to assess for services, e.g., discharge planning, or to establish eligibility for coverage under a policy or program.

ObservationType

Identifies the kinds of observations that can be performed

OilDrugForm

An unctuous, combustible substance which is liquid, or easily liquefiable, on warming, and is soluble in ether but insoluble in water. Such substances, depending on their origin, are classified as animal, mineral, or vegetable oils.

OintmentDrugForm

A semisolid preparation intended for external application to the skin or mucous membranes.

Ojibwayan

No description

OphthalmicRoute

Ophthalmic

Oral Site Codes

This value set includes a smattering of FDI oral site codes.

OralCapsule

No description

OralInhalation

Inhalation, oral

OralRoute

Oral

OralSolution

No description

OralSuspension

No description

OralTablet

No description

OrderableDrugForm

No description

OrderedListStyle

Defines rendering characteristics for ordered lists

OregonAthapaskan

No description

Organization type

This example value set defines a set of codes that can be used to indicate a type of organization.

OrganizationEntityType

Further classifies entities of classCode ORG.

OrganizationIndustryClassNAICS

No description

OrganizationNamePartQualifier

No description

OrganizationNameUse

No description

OromucosalRoute

Oromucosal

OropharyngealRoute

Oropharyngeal

OrthoClinPracticeSetting

No description

Other

The actual value is not an element in the value domain of a variable. (e.g., concept not provided by required code system).

OtherActionTakenManagementCode

Order is performed as issued, but other action taken to mitigate potential adverse effects

OticRoute

Otic

OutpatientFacilityPracticeSetting

No description

OverriderParticipationFunction

This code is used to specify the exact function an actor is authorized to have in authoring a consent override.

PHVS_ManufacturersOfVaccinesMVX_CDC_NIP

Value Set of codes that specify the organization that manufactures a vaccine. The values are maintained by the US Centers of Disease Control. Note that the source of truth for these code values are maintained by the CDC, and the code system may be accessed via https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.12.227

PHVS_Race_HL7_2x

This race value set is based upon CDC check-digit codes, but using the HL7 table 0005. HL7 adopted the CDC Race and Ethnicity codes in HL7 Table 0005 in 2005. This value set has been created for backward compatibility and some historic Implementation guides (E.g. Immunization). Recommend using Race Category value set based upon CDC Race & Ethnicity code system.

PHVS_VaccinesAdministeredCVX_CDC_NIP

Value Set of codes that specify the administered vaccines. The values are maintained by the US Centers of Disease Control.. The code system is maintained by the CDC, and may be found at URL; https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.1

PacificCoastAthapaskan

No description

PackageEntityType

A material intended to hold other materials for purposes of storage or transportation

PadDrugForm

No description

Pai

No description

Palaihnihan

No description

ParanasalSinusesRoute

Paranasal sinuses

Parent

one that begets or brings forth offspring or a person who brings up and cares for another (Webster’s Collegiate Dictionary)

ParentInLaw

The player of the role is the parent of scoping person’s husband or wife.

ParenteralRoute

Parenteral

PartialCompletionScale

No description

ParticipationAdmitter

The practitioner who is responsible for admitting a patient to a patient encounter.

ParticipationAnalyte

No description

ParticipationAncillary

Participations related, but not primary to an act. The Referring, Admitting, and Discharging practitioners must be the same person as those authoring the ControlAct event for their respective trigger events.

ParticipationAttender

The practitioner that has responsibility for overseeing a patient’s care during a patient encounter.

ParticipationAuthenticator

A verifier who attests to the accuracy of an act, but who does not have privileges to legally authenticate the act. An example would be a resident physician who sees a patient and dictates a note, then later signs it. Their signature constitutes an authentication.

ParticipationAuthorOriginator

Definition: A party that originates the Act and therefore has responsibility for the information given in the Act and ownership of this Act. Example: the report writer, the person writing the act definition, the guideline author, the placer of an order, the EKG cart (device) creating a report etc. Every Act should have an author. Authorship is regardless of mood always actual authorship. Examples of such policies might include:

  • The author and anyone they explicitly delegate may update the report;
  • All administrators within the same clinic may cancel and reschedule appointments created by other administrators within that clinic; A party that is neither an author nor a party who is extended authorship maintenance rights by policy, may only amend, reverse, override, replace, or follow up in other ways on this Act, whereby the Act remains intact and is linked to another Act authored by that other party.
ParticipationBaby

In an obstetric service, the baby.

ParticipationBeneficiary

Target on behalf of whom the service happens, but that is not necessarily present in the service. Can occur together with direct target to indicate that a target is both, as in the case where the patient is the indirect beneficiary of a service rendered to a family member, e.g. counseling or given home care instructions. This concept includes a participant, such as a covered party, who derives benefits from a service act covered by a coverage act. Note that the semantic role of the intended recipient who benefits from the happening denoted by the verb in the clause. Thus, a patient who has no coverage under a policy or program may be a beneficiary of a health service while not being the beneficiary of coverage for that service.

ParticipationCallbackContact

A person or organization who should be contacted for follow-up questions about the act in place of the author.

ParticipationCatalyst

No description

ParticipationCausativeAgent

Definition: A factor, such as a microorganism, chemical substance, or form of radiation, whose presence, excessive presence, or (in deficiency diseases) relative absence is essential, in whole or in part, for the occurrence of a condition. Constraint: The use of this participation is limited to observations.

ParticipationConsultant

An advisor participating in the service by performing evaluations and making recommendations.

ParticipationConsumable

Target that is taken up, is diminished, and disappears in the service.

ParticipationCoverageTarget

The target participation for an individual in a health care coverage act in which the target role is either the policy holder of the coverage, or a covered party under the coverage.

ParticipationCustodian

An entity (person, organization or device) that is in charge of maintaining the information of this act (e.g., who maintains the report or the master service catalog item, etc.).

ParticipationDataEntryPerson

A person entering the data into the originating system. The data entry person is collected optionally for internal quality control purposes. This includes the transcriptionist for dictated text.

ParticipationDestination

The destination for services. May be a static building (or room therein) or a movable facility (e.g., ship).

ParticipationDischarger

The practitioner who is responsible for the discharge of a patient from a patient encounter.

ParticipationDistributor

Distributes material used in or generated during the act.

ParticipationDonor

In some organ transplantation services and rarely in transfusion services a donor will be a target participant in the service. However, in most cases transplantation is decomposed in three services: explantation, transport, and implantation. The identity of the donor (recipient) is often irrelevant for the explantation (implantation) service.

ParticipationEntryLocation

A location where data about an Act was entered.

ParticipationEscort

Only with Transportation services. A person who escorts the patient.

ParticipationExposureagent

Description: The entity playing the associated role is the physical (including energy), chemical or biological substance that is participating in the exposure. For example in communicable diseases, the associated playing entity is the disease causing pathogen.

ParticipationExposureparticipation

Description:Direct participation in an exposure act where it is unknown that the participant is the source or subject of the exposure. If the participant is known to be the contact of an exposure then the EXPTRGT participation type should be used. If the participant is known to be the source then the EXSRC participation type should be used.

ParticipationExposuresource

Description:The entity playing the associated role is the source of exposure.

ParticipationExposuretarget

Description: The entity playing the associated role is the target (contact) of exposure.

ParticipationFunction

This code is used to specify the exact function an actor had in a service in all necessary detail. This domain may include local extensions (CWE).

ParticipationGuarantorParty

The target person or organization contractually recognized by the issuer as a participant who has assumed fiscal responsibility for another personaTMs financial obligations by guaranteeing to pay for amounts owed to a particular account Example:The subscriber of the patientaTMs health insurance policy signs a contract with the provider to be fiscally responsible for the patient billing account balance amount owed.

ParticipationHolder

Participant who posses an instrument such as a financial contract (insurance policy) usually based on some agreement with the author.

ParticipationIndirectTarget

Target that is not substantially present in the act and which is not directly affected by the act, but which will be a focus of the record or documentation of the act.

ParticipationInformant

A source of reported information (e.g., a next of kin who answers questions about the patient’s history). For history questions, the patient is logically an informant, yet the informant of history questions is implicitly the subject.

ParticipationInformationGenerator

Parties that may or should contribute or have contributed information to the Act. Such information includes information leading to the decision to perform the Act and how to perform the Act (e.g., consultant), information that the Act itself seeks to reveal (e.g., informant of clinical history), or information about what Act was performed (e.g., informant witness).

ParticipationInformationRecipient

A party, who may or should receive or who has recieved the Act or subsequent or derivative information of that Act. Information recipient is inert, i.e., independent of mood.” Rationale: this is a generalization of a too diverse family that the definition can’t be any more specific, and the concept is abstract so one of the specializations should be used.

ParticipationInformationTranscriber

An entity entering the data into the originating system. The data entry entity is collected optionally for internal quality control purposes. This includes the transcriptionist for dictated text transcribed into electronic form.

ParticipationLegalAuthenticator

A verifier who legally authenticates the accuracy of an act. An example would be a staff physician who sees a patient and dictates a note, then later signs it. Their signature constitutes a legal authentication.

ParticipationMode

Identifies the primary means by which an Entity participates in an Act.

ParticipationModeElectronicData

Participation by non-human-languaged based electronic signal

ParticipationModeVerbal

Participation by voice communication

ParticipationModeWritten

Participation by human language recorded on a physical material

ParticipationNon-reuseableDevice

A device that changes ownership due to the service, e.g., a pacemaker, a prosthesis, an insulin injection equipment (pen), etc. Such material may need to be restocked after he service.

ParticipationOrigin

The location of origin for services. May be a static building (or room therein) or a movable facility (e.g., ship).

ParticipationParticipation

Indicates that the target of the participation is involved in some manner in the act, but does not qualify how. This should not be used except when no more specific participation type is known or when the participation type is further clarified elsewhere. It should not be used lightly, and should never be used as a “placeholder” when a more appropriate specific type does not yet exist.

ParticipationPhysicalPerformer

A person who actually and principally carries out the action. Need not be the principal responsible actor, e.g. a surgery resident operating under supervision of attending surgeon, and may be the patient in self-care, e.g. fingerstick blood sugar. The traditional order filler is a performer. This information should accompany every service event.

ParticipationPrimaryInformationRecipient

Information recipient to whom an act statement is primarily directed. E.g., a primary care provider receiving a discharge letter from a hospitalist, a health department receiving information on a suspected case of infectious disease. Multiple of these participations may exist on the same act without requiring that recipients be ranked as primary vs. secondary.

ParticipationPrimaryPerformer

The principal or primary performer of the act.

ParticipationProduct

A material target that is brought forth (produced) in the service (e.g., specimen in a specimen collection, access or drainage in a placement service, medication package in a dispense service). It doesn’t matter whether the material produced had existence prior to the service, or whether it is created in the service (e.g., in supply services the product is taken from a stock).

ParticipationReceiver

The person (or organization) who receives the product of an Act.

ParticipationRecordTarget

The record target indicates whose medical record holds the documentation of this act. This is especially important when the subject of a service is not the patient himself.

ParticipationReferredBy

A participant (e.g. provider) who has referred the subject of an act (e.g. patient). Typically, a referred by participant will provide a report (e.g. referral).

ParticipationReferredTo

The person who receives the patient

ParticipationReferrer

A person having referred the subject of the service to the performer (referring physician). Typically, a referring physician will receive a report.

ParticipationRemote

Some services take place at multiple concurrent locations (e.g., telemedicine, telephone consultation). The location where the principal performing actor is located is taken as the primary location (LOC) while the other location(s) are considered “remote.”

ParticipationResponsibleParty

The person or organization that has primary responsibility for the act. The responsible party is not necessarily present in an action, but is accountable for the action through the power to delegate, and the duty to review actions with the performing actor after the fact. This responsibility may be ethical, legal, contractual, fiscal, or fiduciary in nature. Example: A person who is the head of a biochemical laboratory; a sponsor for a policy or government program.

ParticipationReusableDevice

A device that does not change ownership due to the service, i.e., a surgical instrument or tool or an endoscope. The distinction between reuseable and non-reuseable must be made in order to know whether material must be re-stocked.

ParticipationSecondaryPerformer

A person assisting in an act through his substantial presence and involvement This includes: assistants, technicians, associates, or whatever the job titles may be.

ParticipationSignature

A code specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed. Examples: A surgical Procedure act object (representing a procedure report) requires a signature of the performing and responsible surgeon, and possibly other participants. (See also: Participation.signatureText.)

ParticipationSpecimen

The subject of non-clinical (e.g. laboratory) observation services is a specimen.

ParticipationSubset

Used to indicate that the participation is a filtered subset of the total participations of the same type owned by the Act. Used when there is a need to limit the participations to the first, the last, the next or some other filtered subset.

ParticipationTargetDevice

Something used in delivering the service without being substantially affected by the service (i.e. durable or inert with respect to that particular service.) Examples are: monitoring equipment, tools, but also access/drainage lines, prostheses, pace maker, etc.

ParticipationTargetDirect

Target that is substantially present in the service and which is directly affected by the service action (includes consumed material, devices, etc.).

ParticipationTargetLocation

The facility where the service is done. May be a static building (or room therein) or a moving location (e.g., ambulance, helicopter, aircraft, train, truck, ship, etc.)

ParticipationTargetSubject

The principle target that the service acts on. E.g. the patient in physical examination, a specimen in a lab observation. May also be a patient’s family member (teaching) or a device or room (cleaning, disinfecting, housekeeping). Note: not all direct targets are subjects, consumables, and devices used as tools for a service are not subjects. However, a device may be a subject of a maintenance service.

ParticipationTracker

A secondary information recipient, who receives copies (e.g., a primary care provider receiving copies of results as ordered by specialist).

ParticipationType

A code specifying the meaning and purpose of every Participation instance. Each of its values implies specific constraints on the Roles undertaking the participation.

ParticipationTypeCDASectionOverride

Identifies the set of participation types context that can be blocked (overridden) at the CDA section or sub-section level of a document.

ParticipationUgentNotificationContact

An information recipient to notify for urgent matters about this Act. (e.g., in a laboratory order, critical results are being called by phone right away, this is the contact to call; or for an inpatient encounter, a next of kin to notify when the patient becomes critically ill).

ParticipationVerifier

A person who verifies the correctness and appropriateness of the service (plan, order, event, etc.) and hence takes on accountability.

ParticipationVia

For services, an intermediate location that specifies a path between origin an destination.

ParticipationWitness

Only with service events. A person witnessing the action happening without doing anything. A witness is not necessarily aware, much less approves of anything stated in the service event. Example for a witness is students watching an operation or an advanced directive witness.

PastSubset

An occurrence that occurred or was scheduled to occur in the past. An Act whose effective time is less than ‘now’. (‘now’ is the time the instance is authored.)

PasteDrugForm

A semisolid dosage form that contains one or more drug substances intended for topical application.

PatchDrugForm

A drug delivery system that contains an adhesived backing and that permits its ingredients to diffuse from some portion of it (e.g., the backing itself, a reservoir, the adhesive, or some other component) into the body from the external site where it is applied.

PatientImmunizationRelatedObservationType

Description: Reporting codes that are related to an immunization event.

PatientImportance

Patient VIP code

PatientProfileQueryReasonCode

No description

Payee Type Codes

Codes indicating the type of party to be reimbursed for cost of the products and service.

PayeeResourceType

The type of payee Resource.

Payment Adjustment Reason Codes

This value set includes smattering of Payment Adjustment Reason codes.

Payment Status Codes

This value set includes a sample set of Payment Status codes.

Payment Type Codes

This value set includes sample Payment Type codes.

PaymentTerms

Describes payment terms for a financial transaction, used in an invoice. This is typically expressed as a responsibility of the acceptor or payor of an invoice.

PayorParticipationFunction

Definition: Set of codes indicating the manner in which payors participate in a policy or program.</

PayorRoleType

Description:PayorRoleType for a particular type of policy or program benefit package or plan where more detail about the coverage administration role of the Payor is required. The functions performed by a Payor qualified by a PayorRoleType may be specified by the PayorParticpationFunction value set. Examples:A Payor that is a TPA may administer a managed care plan without underwriting the risk.

PedsClinPracticeSetting

No description

PedsICUPracticeSetting

No description

PedsPracticeSetting

No description

Penutian

No description

PerianalRoute

Perianal

PeriarticularRoute

Periarticular

PeriduralRoute

Peridural

PerinealRoute

Perineal

PerineuralRoute

Perineural

PeriodontalRoute

Periodontal

PermanentDentition

Permanent dentition, the natural teeth of adulthood that replace or are added to the deciduous teeth

PersonDisabilityType

A code identifying a person’s disability.

PersonNameUse

A code indicating the type of name (e.g. nickname, alias, maiden name, legal, adopted)

Personal Pronouns

Codes that indicate the pronouns to be used when communicating with or about an individual.

PersonalAndLegalRelationshipRoleType

A ‘personal and legal’ relationship records the role of a person in relation to another person, or a person to himself or herself. This value set is to be used when recording relationships based on personal or family ties or through legal assignment of responsibility.

PersonalRelationshipRoleType

Types of personal relationships between two living subjects. Example:Parent, sibling, unrelated friend, neighbor

PharmacistHIPAA

An individual who is licensed to prepare and sell or dispense drugs and compounds and to make up prescriptions.

PharmacySupplyEventAbortReason

Definition:Identifies why the dispense event was not completed

PharmacySupplyEventStockReasonCode

No description

PharmacySupplyRequestFulfillerRevisionRefusalReasonCode

Definition:Indicates why the request to transfer a prescription from one dispensing facility to another has been refused.

PharmacySupplyRequestRenewalRefusalReasonCode

Definition:A collection of concepts that identifies why a renewal prescription has been refused.

Pidgin

No description

PillDrugForm

A small, round solid dosage form containing a medicinal agent intended for oral administration.

PlaceEntityType

Types of places for EntityClass “PLC”

PlanDefinitionType

The type of PlanDefinition.

PlasticBottleEntityType

A bottle made of plastic

PlateauPenutian

No description

PolicyOrProgramCoverageRoleType

Description: A role recognized through the eligibility of an identified party for benefits covered under an insurance policy or a program based on meeting eligibility criteria. Eligibility as a covered party may be conditioned on the party meeting criteria to qualify for coverage under a policy or program, which may be mandated by law. These criteria may be:

  1. The sole basis for coverage, e.g., being differently abled may qualify a person for disability coverage
  2. May more fully qualify a covered party role e.g, being differently abled may qualify an adult child as a dependent
  3. May impact the level of coverage for a covered party under a policy or program, e.g., being differently abled may qualify a program eligible for additional benefits. Discussion: The Abstract Value Set “CoverageRoleType”, which was developed for use in the Canadian realm “pre-coordinate” coverage roles with other roles that a covered party must play in order to be eligible for coverage, e.g., “handicapped dependent”. These role.codes may only be used with COVPTY to avoid overlapping concepts that would result from using them to specify the specializations of COVPTY, e.g., the role.class DEPEN should not be used with the role.code family dependent because that relationship has overlapping concepts due to the role.code precoodination and is conveyed in FICO with the personal relationship role that has a PART role link to the covered party role. For the same reasons, the role.class DEPEN should not be used with the role.code HANDIC (handicapped dependent); the role.code DIFFABLE (differently abled) should be used instead. In summary, the coded concepts in the Abstract Value Set “CoveredPartyRoleType” can be “post-coordinated” with the “RoleClassCoveredParty” Abstract Value Set. Decoupling these concepts is intended to support an expansive range of covered party concepts and their semantic comparability.
Pomoan

No description

PopulationInclusionObservationType

Observation types for specifying criteria used to assert that a subject is included in a particular population.

PostalAddressUse

No description

PowderDrugForm

An intimate mixture of dry, finely divided drugs and/or chemicals that may be intended for internal or external use.

PowerOfAttorney

A relationship between two people in which one person authorizes another to act for him in a manner which is a legally binding upon the person giving such authority as if he or she personally were to do the acts.

PrescriptionDispenseFilterCode

A “helper” vocabulary used to construct complex query filters based on how and whether a prescription has been dispensed.

Present on Admission Indicators

Concepts that describe whether a condition is present when a patient is admitted to a healthcare facility.

Primary-source-type

Type of the validation primary source

PrimaryDentition

Primary dentition, the first teeth to errupt and usually replaced with permanent dentition

PrivacyMark

Codes used for human readable marks indicating, e.g., the level of confidentiality protection, an authorized compartment, the integrity, or the handling instruction required by applicable policy. Such markings must be displayed as directed by applicable policy on electronically rendered information content and any electronic transmittal envelope or container; or on hardcopy information and any physical transmittal envelope or container. Purpose: Supports the selection of the entire PrivacyMark value set with head code for e.g., rules engine policy set purposes.

PrivateResidence

Definition: A living arrangement within a private residence for single family.

ProbabilityDistributionType

No description

Process Priority Codes

This value set includes the financial processing priority codes.

ProcessingID

This attribute defines whether the message is part of a production, training, or debugging system.

ProcessingMode

This attribute defines whether the message is being sent in current processing, archive mode, initial load mode, restore from archive mode, etc.

Program

This value set defines an example set of codes that could be can be used to classify groupings of service-types/specialties.

ProgramEligibleCoveredPartyRoleType

Description:A role recognized through the eligibility of a party to play a program eligible for benefits covered or provided under a program.

Provenance participant type

The type of participation a provenance participant.

ProvenanceEventCurrentState

Specifies the state change of a target Act, such as a document or an entry, from its previous state as a predecessor Act. For example, if the target Act is the result of a predecessor Act being “obsoleted” and replaced with the target Act, the source ProvenanceEventCurrentState Act code would be “obsoleted”.

ProvenanceEventCurrentState-AS

Specifies the state change of a target Act, using ActStatus codes, from its previous state as a predecessor Act. For example, if the target Act is the result of a predecessor Act being “obsoleted” and replaced with the target Act, the source ProvenanceEventCurrentState Act code would be “obsoleted”.

ProvenanceEventCurrentState-DC

Specifies the state change of a target Act using DocuymentCompletion codes, from its previous state as a predecessor Act. For example, if the target Act is the result of a predecessor Act being “obsoleted” and replaced with the target Act, the source ProvenanceEventCurrentState Act code would be “obsoleted”.

PublicHealthcareProgram

Definition: A a public or governmental health program with an organized structure for administering and funding coverage of a benefit package for covered parties meeting eligibility criteria, typically related to employment, health and financial status. These programs are established by legislation with provisions for ongoing government oversight. Regulations mandate the structure of the program, the manner in which it is funded and administered, covered benefits, provider types, eligibility criteria and financial participation. A government agency may be charged with implementing the program in accordance to the regulation. For example, A Canadian provincial or national health plan such as the BC MSP (British Columbia Medical Services Plan) OHIP (Ontario Health Insurance Plan), NHS (National Health Service). Examples of U.S. government funded health programs include those for maternity case management, behavioral health, and HIV-AIDs, such as the Ryan White program.

PulmonaryRoute

Pulmonary

PurposeOfUse

Supports communication of purpose of use at a general level.

Push-type-available

Type of alerts/updates the primary source can send

QualityMeasureSectionType

A type of document section within a health quality measure (aka eMeasure), used to cluster the various parts of the eMeasure into a more human navigable format.

QualityOfEvidenceRating

A rating system that describes the quality of evidence such as the GRADE, DynaMed, or Oxford CEBM systems.

QualitySpecimenRoleType

A specimen specifically used to verify the sensitivity, specificity, accuracy or other perfomance parameter of a diagnostic test.

QueryPriority

Identifies the time frame in which the response is expected.

QueryRequestLimit

Definition: The number of matching instances (number of focal classes). The document header class is the focal class of a document, a record would therefore be equal to a document.

QueryResponse

A code classifying the general nature of the response to a given query. Includes whether or not data was found, or whether an error occurred.

QueryStatusCode

A code specifying the state of the Query.

QuestionnaireItemUsageMode

Identifies the modes of usage of a questionnaire that should enable a particular questionnaire item.

ROIOverlayShape

Shape of the region on the object being referenced

Race

In the United States, federal standards for classifying data on race determine the categories used by federal agencies and exert a strong influence on categorization by state and local agencies and private sector organizations. The federal standards do not conceptually define race, and they recognize the absence of an anthropological or scientific basis for racial classification. Instead, the federal standards acknowledge that race is a social-political construct in which an individual’s own identification with one more race categories is preferred to observer identification. The standards use a variety of features to define five minimum race categories. Among these features are descent from “the original peoples” of a specified region or nation. The minimum race categories are American Indian or Alaska Native, Asian, Black or African American, Native Hawaiian or Other Pacific Islander, and White. The federal standards stipulate that race data need not be limited to the five minimum categories, but any expansion must be collapsible to those categories.

RaceAfricanAmericanAfrican

No description

RaceAlaskanIndian

No description

RaceAlaskanIndianAthabascan

No description

RaceAlaskanNative

No description

RaceAlaskanNativeAleut

No description

RaceAlaskanNativeAleutAlutiiq

No description

RaceAlaskanNativeAleutBristolBay

No description

RaceAlaskanNativeAleutChugach

No description

RaceAlaskanNativeAleutKoniag

No description

RaceAlaskanNativeAleutUnangan

No description

RaceAlaskanNativeEskimo

No description

RaceAlaskanNativeInupiatEskimo

No description

RaceAlaskanNativeSiberianEskimo

No description

RaceAlaskanNativeYupikEskimo

No description

RaceAmericanIndian

No description

RaceAmericanIndianApache

No description

RaceAmericanIndianArapaho

No description

RaceAmericanIndianAssiniboineSioux

No description

RaceAmericanIndianCaddo

No description

RaceAmericanIndianCahuilla

No description

RaceAmericanIndianCalifornia

No description

RaceAmericanIndianChemakuan

No description

RaceAmericanIndianCherokee

No description

RaceAmericanIndianCheyenne

No description

RaceAmericanIndianChickahominy

No description

RaceAmericanIndianChinook

No description

RaceAmericanIndianChippewa

No description

RaceAmericanIndianChippewaCree

No description

RaceAmericanIndianChoctaw

No description

RaceAmericanIndianChumash

No description

RaceAmericanIndianComanche

No description

RaceAmericanIndianCoushatta

No description

RaceAmericanIndianCreek

No description

RaceAmericanIndianCupeno

No description

RaceAmericanIndianDelaware

No description

RaceAmericanIndianDiegueno

No description

RaceAmericanIndianEasternTribes

No description

RaceAmericanIndianGrosVentres

No description

RaceAmericanIndianHoopa

No description

RaceAmericanIndianIowa

No description

RaceAmericanIndianIroquois

No description

RaceAmericanIndianKickapoo

No description

RaceAmericanIndianKiowa

No description

RaceAmericanIndianKlallam

No description

RaceAmericanIndianLongIsland

No description

RaceAmericanIndianLuiseno

No description

RaceAmericanIndianMaidu

No description

RaceAmericanIndianMiami

No description

RaceAmericanIndianMicmac

No description

RaceAmericanIndianNavajo

No description

RaceAmericanIndianNorthwestTribes

No description

RaceAmericanIndianOttawa

No description

RaceAmericanIndianPaiute

No description

RaceAmericanIndianPassamaquoddy

No description

RaceAmericanIndianPawnee

No description

RaceAmericanIndianPeoria

No description

RaceAmericanIndianPequot

No description

RaceAmericanIndianPima

No description

RaceAmericanIndianPomo

No description

RaceAmericanIndianPonca

No description

RaceAmericanIndianPotawatomi

No description

RaceAmericanIndianPueblo

No description

RaceAmericanIndianPugetSoundSalish

No description

RaceAmericanIndianSacFox

No description

RaceAmericanIndianSeminole

No description

RaceAmericanIndianSerrano

No description

RaceAmericanIndianShawnee

No description

RaceAmericanIndianShoshone

No description

RaceAmericanIndianShoshonePaiute

No description

RaceAmericanIndianSioux

No description

RaceAmericanIndianTohonoOOdham

No description

RaceAmericanIndianUmpqua

No description

RaceAmericanIndianUte

No description

RaceAmericanIndianWampanoag

No description

RaceAmericanIndianWashoe

No description

RaceAmericanIndianWinnebago

No description

RaceAmericanIndianYuman

No description

RaceAmericanIndianYurok

No description

RaceAsian

No description

RaceBlackOrAfricanAmerican

No description

RaceCanadianLatinIndian

No description

RaceHawaiianOrPacificIsland

No description

RaceNativeAmerican

No description

RacePacificIslandMelanesian

No description

RacePacificIslandMicronesian

No description

RacePacificIslandPolynesian

No description

RaceSoutheastAlaskanIndian

No description

RaceSoutheastAlaskanIndianTlingit

No description

RaceSoutheastAlaskanIndianTsimshian

No description

RaceWhite

No description

RaceWhiteArab

No description

RaceWhiteEuropean

No description

RaceWhiteMiddleEast

No description

RadDiagTherPracticeSetting

A practice setting where radiology services (diagnostic or therapeutic) are provided (X12N 261QR0200N)

ReactionDetectedIssueCode

Proposed therapy may be inappropriate or contraindicated based on the potential for a patient reaction to the proposed product

ReactionParticipant

No description

ReactivityObservationInterpretation

Interpretations of the presence and level of reactivity of the specified component / analyte with the reagent in the performed laboratory test.

Reason Medication Given Codes

This value set is provided as an example. The value set to instantiate this attribute should be drawn from a robust terminology code system that consists of or contains concepts to support the medication process.

Recorded Sex Or Gender Type

Codes that represent the type of the recorded sex and gender.

RectalInstillation

Instillation, rectal

RectalRoute

Rectal

ReferralMethod

The methods of referral can be used when referring to a specific HealthCareService resource.

RefillPharmacySupplyType

A fill against an order that has already been filled (or partially filled) at least once.

RefrainPolicy

Conveys prohibited actions which an information custodian, receiver, or user is not permitted to perform unless otherwise authorized or permitted under specified circumstances. Examples:

  • prohibit redisclosure without consent directive
RefusalReasonCode

No description

RegulationPolicyActCode

Description: A rule set by regulators of product that somehow constrain the use of products. Regulator may be any organization with a mandate to issue such rules, regardless of level, regional, country, state, and local (e.g., an institutional Pharmaceutical and Treatment Committee.) Examples:

  • Prescription Only
  • Controlled Substance Schedule II
  • Standard of Practice
RehabilitationHospital

(X12N 283X00000N)

RejectionCriterion

Criterion for rejection of the specimen by laboratory.

RelatedReactionDetectedIssueCode

Proposed therapy may be inappropriate or contraindicated because of a potential patient reaction to a cross-sensitivity related product.

RelationalOperator

Identifies common relational operators used in selection criteria.

RelationshipConjunction

A code specifying the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exclusive-or.) Constraints: All AND criteria must be true. If OR and AND criteria occur together, one criterion out of the OR-group must be true and all AND criteria must be true also. If XOR criteria occur together with OR and AND criteria, exactly one of the XOR criteria must be true, and at least one of the OR criteria and all AND criteria must be true. In other words, the sets of AND, OR, and XOR criteria are in turn combined by a logical AND operator (all AND criteria and at least one OR criterion and exactly one XOR criterion.) To overcome this ordering, Act criteria can be nested in any way necessary.

ReligiousAffiliation

Assigment of spiritual faith affiliation

RepetitionsOutOfRange

No description

ResearchStudyObjectiveType

Codes for the kind of study objective.

ResearchStudyPhase

Codes for the stage in the progression of a therapy from initial experimental use in humans in clinical trials to post-market evaluation.

ResearchStudyPrimaryPurposeType

Codes for the main intent of the study.

ResearchStudyReasonStopped

Codes for why the study ended prematurely.

ResearchSubjectMilestone

Indicates the progression of a study subject through the study milestones.

ResearchSubjectRoleBasis

Specifies the administrative functionality within a formal experimental design for which the ResearchSubject role was established. Examples: screening - role is used for pre-enrollment evaluation portion of the design; enrolled - role is used for subjects admitted to the active treatment portion of the design.

ResearchSubjectState

Indicates the progression of a study subject through a study.

ResearchSubjectStateType

Identifies the kind of state being refered to.

ResidentialTreatmentPracticeSetting

No description

ResourceGroupEntityType

Codes to characterize a Resource Group using categories that typify its membership and/or function . Example: PractitionerGroup

ResourceSecurityCategory

Provides general guidance around the kind of access Control to Read, Search, Create, Update, or Delete a resource.

RespiratoryTractRoute

Respiratory tract

ResponseLevel

Specifies whether a response is expected from the addressee of this interaction and what level of detail that response should include

ResponseModality

Defines the timing and grouping of the response instances.

ResponseMode

Specifies the mode, immediate versus deferred or queued, by which a receiver should communicate its receiver responsibilities.

ResponsibleParty

The role played by a party who has legal responsibility for another party.

RetrobulbarRoute

Retrobulbar

RheumClinPracticeSetting

No description

RigidContainerEntityType

A container having a fixed and inflexible dimensions and volume

Rinse

Rinse

Risk Probability

Codes representing the likelihood of a particular outcome in a risk assessment.

Ritwan

No description

River

No description

RoleClass

This table includes codes for the Role class hierarchy. The values in this hierarchy, represent a Role which is an association or relationship between two entities - the entity that plays the role and the entity that scopes the role. Roles names are derived from the name of the playing entity in that role. The role hierarchy stems from three core concepts, or abstract domains:

  • RoleClassOntological is an abstract domain that collects roles in which the playing entity is defined or specified by the scoping entity.
  • RoleClassPartitive collects roles in which the playing entity is in some sense a “part” of the scoping entity.
  • RoleClassAssociative collects all of the remaining forms of association between the playing entity and the scoping entity. This set of roles is further partitioned between:
    • RoleClassPassive which are roles in which the playing entity is used, known, treated, handled, built, or destroyed, etc. under the auspices of the scoping entity. The playing entity is passive in these roles in that the role exists without an agreement from the playing entity.
    • RoleClassMutualRelationship which are relationships based on mutual behavior of the two entities. The basis of these relationship may be formal agreements or they may be de facto behavior. Thus, this sub-domain is further divided into:
      • RoleClassRelationshipFormal in which the relationship is formally defined, frequently by a contract or agreement.
      • Personal relationship which inks two people in a personal relationship. The hierarchy discussed above is represented In the current vocabulary tables as a set of abstract domains, with the exception of the “Personal relationship” which is a leaf concept.
RoleClassAccess

A role in which the playing entity (material) provides access to another entity. The principal use case is intravenous (or other bodily) access lines that preexist and need to be referred to for medication routing instructions.

RoleClassActiveIngredient

A therapeutically active ingredient (player) in a mixture (scoper), where the mixture is typically a manufactured pharmaceutical.

RoleClassActiveIngredientBasis

No description

RoleClassActiveIngredientMoietyBasis

No description

RoleClassActiveIngredientReferenceBasis

No description

RoleClassActiveMoiety

The molecule or ion that is responsible for the intended pharmacological action of the drug substance, excluding those appended or associated parts of the molecule that make the molecule an ester, salt (including a salt with hydrogen or coordination bonds), or other noncovalent derivative (such as a complex, chelate, or clathrate). Examples: heparin-sodium and heparin-potassium have the same active moiety, heparin; the active moiety of morphine-hydrochloride is morphine.

RoleClassAdditive

An ingredient (player) that is added to a base (scoper), that amounts to a minor part of the overall mixture.

RoleClassAdjacency

No description

RoleClassAdjuvant

No description

RoleClassAdministerableMaterial

A material (player) that can be administered to an Entity (scoper).

RoleClassAffiliate

Player of the Affiliate role has a business/professional relationship with scoper. Player and scoper may be persons or organization. The Affiliate relationship does not imply membership in a group, nor does it exist for resource scheduling purposes. Example: A healthcare provider is affiliated with another provider as a business associate.

RoleClassAgent

An entity (player) that acts or is authorized to act on behalf of another entity (scoper).

RoleClassAliquot

A portion (player) of an original or source specimen (scoper) used for testing or transportation.

RoleClassAssignedEntity

An agent role in which the agent is an Entity acting in the employ of an organization. The focus is on functional role on behalf of the organization, unlike the Employee role where the focus is on the ‘Human Resources’ relationship between the employee and the organization.

RoleClassAssociative

A general association between two entities that is neither partitive nor ontological.

RoleClassBase

A base ingredient (player) is what comprises the major part of a mixture (scoper). E.g., Water in most i.v. solutions, or Vaseline in salves. Among all ingredients of a material, there should be only one base. A base substance can, in turn, be a mixture.

RoleClassBirthplace

Relates a place (playing Entity) as the location where a living subject (scoping Entity) was born.

RoleClassCaregiver

A person responsible for the primary care of a patient at home.

RoleClassCaseSubject

A person, non-person living subject, or place that is the subject of an investigation related to a notifiable condition (health circumstance that is reportable within the applicable public health jurisdiction)

RoleClassChild

The player of the role is a child of the scoping entity, in a generic sense.

RoleClassCitizen

Citizen of apolitical entity

RoleClassClaimant

Description: A role played by a party making a claim for coverage under a policy or program. A claimant must be either a person or organization, or a group of persons or organizations. A claimant is not a named insured or a program eligible. Discussion: With respect to liability insurance such as property and casualty insurance, a claimant must file a claim requesting indemnification for a loss that the claimant considers covered under the policy of a named insured. The claims adjuster for the policy underwriter will review the claim to determine whether the loss meets the benefit coverage criteria under a policy, and base any indemnification or coverage payment on that review. If a third party is liable in whole or part for the loss, the underwriter may pursue third party liability recovery. A claimant may be involved in civil or criminal legal proceedings involving claims against a defendant party that is indemnified by an insurance policy or to protest the finding of a claims adjustor. With respect to life insurance, a beneficiary designated by a named insured becomes a claimant of the proceeds of coverage, as in the case of a life insurance policy. However, a claimant for coverage under life insurance is not necessarily a designated beneficiary. Note: A claimant is not a named insured. However, a named insured may make a claim under a policy, e.g., an insured driver may make a claim for an injury under his or her comprehensive automobile insurance policy. Similarly, a program eligible may make a claim under program, e.g., an unemployed worker may claim benefits under an unemployment insurance program, but parties playing these covered party role classes are not, for purposes of this vocabulary and in an effort to clearly distinguish role classes, considered claimants. In the case of a named insured making a claim, a role type code INSCLM (insured claimant) subtypes the class to indicate that either a named insured or an individual insured has filed a claim for a loss. In the case of a program eligible, a role type code INJWKR (injured worker) subtypes the class to indicate that the covered party in a workers compensation program is an injured worker, and as such, has filed a “claim” under the program for benefits. Likewise, a covered role type code UNEMP (unemployed worker) subtypes the program eligible class to indicate that the covered party in an unemployment insurance program has filed a claim for unemployment benefits. Example: A claimant under automobile policy that is not the named insured.

RoleClassClinicalResearchInvestigator

A role played by a provider, always a person, who has agency authority from a Clinical Research Sponsor to direct the conduct of a clinical research trial or study on behalf of the sponsor.

RoleClassClinicalResearchSponsor

A role played by an entity, usually an organization, that is the sponsor of a clinical research trial or study. The sponsor commissions the study, bears the expenses, is responsible for satisfying all legal requirements concerning subject safety and privacy, and is generally responsible for collection, storage and analysis of the data generated during the trial. No scoper is necessary, as a clinical research sponsor undertakes the role on its own authority and declaration. Clinical research sponsors are usually educational or other research organizations, government agencies or biopharmaceutical companies.

RoleClassColorAdditive

A substance (player) influencing the optical aspect of material (scoper).

RoleClassCommissioningParty

An Entity that is authorized to issue or instantiate permissions, privileges, credentials or other formal/legal authorizations.

RoleClassConnection

No description

RoleClassContact

A person or an organization (player) which provides or receives information regarding another entity (scoper). Examples; patient NOK and emergency contacts; guarantor contact; employer contact.

RoleClassContactCode

No description

RoleClassContaminantIngredient

No description

RoleClassContent

Relates a material as the content (player) to a container (scoper). Unlike ingredients, the content and a container remain separate (not mixed) and the content can be removed from the container. A content is not part of an empty container.

RoleClassContinuity

No description

RoleClassCoverageSponsor

A role played by an entity, usually an organization that is the sponsor of an insurance plan or a health program. A sponsor is the party that is ultimately accountable for the coverage by employment contract or by law. A sponsor can be an employer, union, government agency, or association. Fully insured sponsors establish the terms of the plan and contract with health insurance plans to assume the risk and to administer the plan. Self-insured sponsors delegate coverage administration, but not risk, to third-party administrators. Program sponsors designate services to be covered in accordance with statute. Program sponsors may administer the coverage themselves, delegate coverage administration, but not risk to third-party administrators, or contract with health insurance plans to assume the risk and administrator a program. Sponsors qualify individuals who may become

  1. a policy holder of the plan;
  2. where the sponsor is the policy holder, who may become a subscriber or a dependent to a policy under the plan; or
  3. where the sponsor is a government agency, who may become program eligibles under a program. The sponsor role may be further qualified by the SponsorRole.code. Entities playing the sponsor role may also play the role of a Coverage Administrator. Example: An employer, union, government agency, or association.
RoleClassCoveredParty

Description: A relationship between a party that receives benefit coverage under the terms of an insurance policy or program and the underwriter of the policy or program. The role is played by the party that receives benefit coverage under the terms of a particular insurance policy or program. The organization playing the underwriter of that policy or program is the scoping entity. A covered party receives coverage under a policy because of some contractual or other relationship with the policy holder. In most cases, the policy holder has discretion over which parties may be covered under a policy, unless the policy holder assigns or is required by a court to assign this right. A covered party receives coverage under a program by being determined eligible based on program eligibility criteria specified by the program sponsor. Discussion: This reason for coverage is specified by use of a role type code from either of the abstract value sets beneath the PolicyOrProgramCoverageRoleType abstract value set. The CoverageRoleType abstract value set can only be used when the role class is the concept code “covered party” (COVPTY) because this value set contains precoordinated coded concepts relating to coverage criteria that was developed for the Canadian realm. This is to avoid overlapping concepts, e.g., the DEPEN role.class cannot be used with the FAMDEP Role.code The CoveredPartyRoleType abstract value set may be used with any of the covered party role class codes to support post coordination of coverage criteria. Where coverage under a policy depends on the concurrence of a policy holder, a relationship link with type code of indirect authority should be included using the policy holder role as the source, and the covered party role as the target. Note: A particular policy may cover several parties, one of whom may be, but need not be, the policy holder. Thus the notion of covered party is a role that is distinct from that of the policy holder. Note: The entity playing the role of covered party is an organization, a non-person living subject or a group of persons, the role class codes Subscriber and Dependent may not be used.

RoleClassCredentialedEntity

A role played by an entity that receives credentials from the scoping entity.

RoleClassDedicatedServiceDeliveryLocation

A role of a place (player) that is intended to house the provision of services. Scoper is the Entity (typically Organization) that provides these services. This is not synonymous with “ownership.”

RoleClassDependent

Description: A role played by a person covered under a policy or program based on an association with a subscriber, which is recognized by the policy holder. Note: The party playing the role of a dependent is not a claimant in the sense conveyed by the RoleClassCoveredParty CLAIM (claimant). However, a dependent may make a claim under a policy, e.g., a dependent under a health insurance policy may become the claimant for coverage under that policy for wellness examines or if injured and there is no liable third party. In the case of a dependent making a claim, a role type code INSCLM (insured claimant) subtypes the class to indicate that the dependent has filed a claim for services covered under the health insurance policy. Example: The dependent has an association with the subscriber such as a financial dependency or personal relationship such as that of a spouse, or a natural or adopted child. The policy holder may be required by law to recognize certain associations or may have discretion about the associations. For example, a policy holder may dictate the criteria for the dependent status of adult children who are students, such as requiring full time enrollment, or may recognize domestic partners as dependents. Under certain circumstances, the dependent may be under the indirect authority of a responsible party acting as a surrogate for the subscriber, for example, if the subscriber is differently abled or deceased, a guardian ad Lidem or estate executor may be appointed to assume the subscriberaTMs legal standing in the relationship with the dependent.

RoleClassDistributedMaterial

A material (player) distributed by a distributor (scoper) who functions between a manufacturer and a buyer or retailer.

RoleClassEmergencyContact

An entity to be contacted in the event of an emergency.

RoleClassEmployee

A relationship between a person or organization and a person or organization formed for the purpose of exchanging work for compensation. The purpose of the role is to identify the type of relationship the employee has to the employer, rather than the nature of the work actually performed. (Contrast with AssignedEntity.)

RoleClassEquivalentEntity

No description

RoleClassEventLocation

No description

RoleClassExposedEntity

A role played by an entity that has been exposed to a person or animal suffering a contagious disease, or with a location from which a toxin has been distributed. The player of the role is normally a person or animal, but it is possible that other entity types could become exposed. The role is scoped by the source of the exposure, and it is quite possible for a person playing the role of exposed party to also become the scoper a role played by another person. That is to say, once a person has become infected, it is possible, perhaps likely, for that person to infect others. Management of exposures and tracking exposed parties is a key function within public health, and within most public health contexts - exposed parties are known as “contacts.”

RoleClassExposureAgentCarrier

An exposure agent carrier is an entity that is capable of conveying an exposure agent from one entity to another. The scoper of the role must be the exposure agent (e.g., pathogen).

RoleClassExposureVector

Description: A vector is a living subject that carries an exposure agent. The vector does not cause the disease itself, but exposes targets to the exposure agent. A mosquito carrying malaria is an example of a vector. The scoper of the role must be the exposure agent (e.g., pathogen).

RoleClassFlavorAdditive

A substance (player) added to a mixture (scoper) to make it taste a certain way. In food the use is obvious, in pharmaceuticals flavors can hide disgusting taste of the active ingredient (important in pediatric treatments).

RoleClassFomite

Description: A fomite is a non-living entity that is capable of conveying exposure agent from one entity to another. A doorknob contaminated with a Norovirus is an example of a fomite. Anyone touching the doorknob would be exposed to the virus. The scoper of the role must be the exposure agent (e.g., pathogen).

RoleClassGuarantor

A person or organization (player) that serves as a financial guarantor for another person or organization (scoper).

RoleClassGuardian

Guardian of a ward

RoleClassHasGeneric

A special link between pharmaceuticals indicating that the target (scoper) is a generic for the source (player).

RoleClassHealthChart

The role of a material (player) that is the physical health chart belonging to an organization (scoper).

RoleClassHealthcareProvider

An Entity (player) that is authorized to provide health care services by some authorizing agency (scoper).

RoleClassHeldEntity

Entity that is currently in the possession of a holder (scoper), who holds, or uses it, usually based on some agreement with the owner.

RoleClassICSRInvestigationSubject

Description: The class of the primary role by which the party is identified as the subject of an adverse event assessment.

RoleClassIdentifiedEntity

Roles played by entities and scoped by entities that identify them for various purposes.

RoleClassInactiveIngredient

No description

RoleClassIncidentalServiceDeliveryLocation

A role played by a place at which health care services may be provided without prior designation or authorization.

RoleClassIndividual

Description: A role played by a party covered under a policy as the policy holder. An individual may be either a person or an organization. Note: The party playing the role of an individual insured is not a claimant in the sense conveyed by the RoleClassCoveredParty CLAIM (claimant). However, a named insured may make a claim under a policy, e.g., a party that is the named insured and policy holder under a comprehensive automobile insurance policy may become the claimant for coverage under that policy if injured in an automobile accident and there is no liable third party. In the case of an individual insured making a claim, a role type code INSCLM (insured claimant) subtypes the class to indicate that an individual insured has filed a claim for a loss. Example: The individual insured under a comprehensive automobile, disability, or property and casualty policy that is the policy holder.

RoleClassIngredientEntity

Relates a component (player) to a mixture (scoper). E.g., Glucose and Water are ingredients of D5W, latex may be an ingredient in a tracheal tube.

RoleClassInstance

An individual piece of material (player) instantiating a class of material (scoper).

RoleClassInvestigationSubject

An entity that is the subject of an investigation. This role is scoped by the party responsible for the investigation.

RoleClassInvoicePayor

The role of an organization that undertakes to accept claims invoices, assess the coverage or payments due for those invoices and pay to the designated payees for those invoices. This role may be either the underwriter or a third-party organization authorized by the underwriter. The scoping entity is the organization that underwrites the claimed coverage.

RoleClassIsSpeciesEntity

Relates a specialized material concept (player) to its generalization (scoper).

RoleClassIsolate

A microorganism that has been isolated from other microorganisms or a source matrix.

RoleClassLicensedEntity

A relationship in which the scoper certifies the player ( e. g. a medical care giver, a medical device or a provider organization) to perform certain activities that fall under the jurisdiction of the scoper (e.g., a health authority licensing healthcare prlviders, a medical quality authority certifying healthcare professionals,)

RoleClassLocatedEntity

Relates an entity (player) to a location (scoper) at which it is present in some way. This presence may be limited in time.

RoleClassMaintainedEntity

An entity (player) that is maintained by another entity (scoper). This is typical role held by durable equipment. The scoper assumes responsibility for proper operation, quality, and safety.

RoleClassManagedEntity

Description:A value set of role classCodes related to entity management.

RoleClassManufacturedProduct

Scoped by the manufacturer

RoleClassMechanicalIngredient

No description

RoleClassMember

A role played by an entity that is a member of a group. The group provides the scope for this role. Among other uses, groups as used in insurance (groups of covered individuals) and in scheduling where resources may be grouped for scheduling and logistical purposes.

RoleClassMilitaryPerson

A role played by a member of a military service. Scoper is the military service (e.g. Army, Navy, Air Force, etc.) or, more specifically, the unit (e.g. Company C, 3rd Battalion, 4th Division, etc.)

RoleClassMolecularBond

No description

RoleClassMolecularFeatures

No description

RoleClassMolecularPart

No description

RoleClassMutualRelationship

A relationship that is based on mutual behavior of the two Entities as being related. The basis of such relationship may be agreements (e.g., spouses, contract parties) or they may be de facto behavior (e.g. friends) or may be an incidental involvement with each other (e.g. parties over a dispute, siblings, children).

RoleClassNamedInsured

Description: A role played by a party to an insurance policy to which the insurer agrees to indemnify for losses, provides benefits for, or renders services. A named insured may be either a person, non-person living subject, or an organization, or a group of persons, non-person living subjects, or organizations. Discussion: The coded concept NAMED should not be used where a more specific child concept in this Specializable value set applies. In some cases, the named insured may not be the policy holder, e.g., where a policy holder purchases life insurance policy in which another party is the named insured and the policy holder is the beneficiary of the policy. Note: The party playing the role of a named insured is not a claimant in the sense conveyed by the RoleClassCoveredParty CLAIM (claimant). However, a named insured may make a claim under a policy, e.g., e.g., a party that is the named insured and policy holder under a comprehensive automobile insurance policy may become the claimant for coverage under that policy e.g., if injured in an automobile accident and there is no liable third party. In the case of a named insured making a claim, a role type code INSCLM (insured claimant) subtypes the class to indicate that a named insured has filed a claim for a loss. Example: The named insured under a comprehensive automobile, disability, or property and casualty policy that is the named insured and may or may not be the policy holder.

RoleClassNextOfKin

An individual designated for notification as the next of kin for a given entity.

RoleClassNotaryPublic

No description

RoleClassNurse

No description

RoleClassNursePractitioner

No description

RoleClassOntological

A relationship in which the scoping Entity defines or specifies what the playing Entity is. Thus, the player’s “being” (Greek: ontos) is specified.

RoleClassOwnedEntity

An Entity (player) for which someone (scoper) is granted by law the right to call the material (player) his own. This entitles the scoper to make decisions about the disposition of that material.

RoleClassPart

An association between two Entities where the playing Entity is considered in some way “part” of the scoping Entity, e.g., as a member, component, ingredient, or content. Being “part” in the broadest sense of the word can mean anything from being an integral structural component to a mere incidental temporary association of a playing Entity with a (generally larger) scoping Entity.

RoleClassPartitive

An association between two Entities where the playing Entity is considered in some way “part” of the scoping Entity, e.g., as a member, component, ingredient, or content. Being “part” in the broadest sense of the word can mean anything from being an integral structural component to a mere incidental temporary association of a playing Entity with a (generally larger) scoping Entity.

RoleClassPassive

An association for a playing Entity that is used, known, treated, handled, built, or destroyed, etc. under the auspices of the scoping Entity. The playing Entity is passive in these roles (even though it may be active in other roles), in the sense that the kinds of things done to it in this role happen without an agreement from the playing Entity.

RoleClassPatient

Description:A Role of a LivingSubject (player) as a recipient of health care services from a healthcare provider (scoper).

RoleClassPayee

The role of an organization or individual designated to receive payment for a claim against a particular coverage. The scoping entity is the organization that is the submitter of the invoice in question.

RoleClassPersonalRelationship

Links two people in a personal relationship. The character of the relationship must be defined by a PersonalRelationshipRoleType code. The player and scoper are determined by PersonalRelationshipRoleType code as well.

RoleClassPhysician

No description

RoleClassPhysicianAssistant

No description

RoleClassPlaceOfDeath

Definition: Relates a place (playing Entity) as the location where a living subject (scoping Entity) died.

RoleClassPolicyHolder

A role played by a person or organization that holds an insurance policy. The underwriter of that policy is the scoping entity. Discussion:The identifier of the policy is captured in ‘Role.id’ when the Role is a policy holder. A particular policy may cover several individuals one of whom may be, but need not be, the policy holder. Thus the notion of covered party is a role that is distinct from that of the policy holder.

RoleClassPreservative

A substance (player) added to a mixture (scoper) to prevent microorganisms (fungi, bacteria) to spoil the mixture.

RoleClassProductRelated

Description:A value set of product related role classCodes

RoleClassProgramEligible

Description: A role played by a party that meets the eligibility criteria for coverage under a program. A program eligible may be either a person, non-person living subject, or an organization, or a group of persons, non-person living subjects, or organizations. Discussion: A program as typically government administered coverage for parties determined eligible under the terms of the program. Note: The party playing a program eligible is not a claimant in the sense conveyed by the RoleClassCoveredParty CLAIM (claimant). However a program eligible may make a claim under program, e.g., an unemployed worker may claim benefits under an unemployment insurance program, but parties playing these covered party role classes are not, for purposes of this vocabulary and in an effort to clearly distinguish role classes, considered claimants. In the case of a program eligible, a role type code INJWKR (injured worker) subtypes the class to indicate that the covered party in a workers compensation program is an injured worker, and as such, has filed a “claim” under the program for benefits. Likewise, a covered role type code UNEMP (unemployed worker) subtypes the program eligible class to indicate that the covered party in an unemployment insurance program has filed a claim for unemployment benefits. Example: A party meeting eligibility criteria related to health or financial status, e.g., in the U.S., persons meeting health, demographic, or financial criteria established by state and federal law are eligible for Medicaid.

RoleClassQualifiedEntity

An entity (player) that has been recognized as having certain training/experience or other characteristics that would make said entity an appropriate performer for a certain activity. The scoper is an organization that educates or qualifies entities.

RoleClassRegulatedProduct

A product regulated by some governmentatl orgnization. The role is played by Material and scoped by Organization. Rationale: To support an entity clone used to identify the NDC number for a drug product.

RoleClassRelationshipFormal

A relationship between two entities that is formally recognized, frequently by a contract or similar agreement.

RoleClassResearchSubject

Definition:Specifies the administrative functionality within a formal experimental design for which the ResearchSubject role was established. Examples: Screening - role is used for pre-enrollment evaluation portion of the design; enrolled - role is used for subjects admitted to the experimental portion of the design.

RoleClassRetailedMaterial

Material (player) sold by a retailer (scoper), who also give advice to prospective buyers.

RoleClassRoot

Corresponds to the Role class

RoleClassSame

The “same” roleclass asserts an identity between playing and scoping entities: that they are in fact instances of the same entity and, in the case of discrepancies (e.g different DOB, gender), that one or both are in error. Usage: playing and scoping entities must have same classcode, but need not have identical attributes or values. Example: a provider registry maintains sets of conflicting demographic data for what is reported to be the same individual.

RoleClassServiceDeliveryLocation

A role played by a place at which services may be provided.

RoleClassSigningAuthorityOrOfficer

The role of a person (player) who is the officer or signature authority for of a scoping entity, usually an organization (scoper).

RoleClassSpecimen

A role played by a material entity that is a specimen for an act. It is scoped by the source of the specimen.

RoleClassStabilizer

A stabilizer (player) added to a mixture (scoper) in order to prevent the molecular disintegration of the main substance.

RoleClassStoredEntity

Relates an entity (player) (e.g. a device) to a location (scoper) at which it is normally found or stored when not used.

RoleClassStudent

A role played by an individual who is a student of a school, which is the scoping entity.

RoleClassSubscriber

Description: A role played by a person covered under a policy based on association with a sponsor who is the policy holder, and whose association may provide for the eligibility of dependents for coverage. Discussion: The policy holder holds the contract with the policy or program underwriter. The subscriber holds a certificate of coverage under the contract. In legal proceedings concerning the policy or program, the terms of the contract takes precedence over the terms of the certificate of coverage if there are any inconsistencies. Note: The party playing the role of a subscriber is not a claimant in the sense conveyed by the RoleClassCoveredParty CLAIM (claimant). However, a subscriber may make a claim under a policy, e.g., a subscriber under a health insurance policy may become the claimant for coverage under that policy for wellness examines or if injured and there is no liable third party. In the case of a subscriber making a claim, a role type code INSCLM (insured claimant) subtypes the class to indicate that the subscriber has filed a claim for services covered under the health insurance policy. Example: An employee or a member of an association.

RoleClassSubstancePresence

The presence of an bio-chemical entity (substance) at a location or environment, such as an ingredient in a mixture, molecular part of a complex, a located entity at a cellular structure, or content of a container, such as a vesicle.

RoleClassSubsumedBy

Relates a prevailing record of an Entity (scoper) with another record (player) that it subsumes. Examples: Show a correct new Person object (scoper) that subsumes one or more duplicate Person objects that had accidentally been created for the same physical person. Constraints: Both the player and scoper must have the same classCode.

RoleClassSubsumer

An entity that subsumes the identity of another. Used in the context of merging documented entity instances. Both the player and scoper must have the same classCode. The use of this code is deprecated in favor of the term SUBY which is its inverse and is more ontologically correct.

RoleClassTerritoryOfAuthority

Relates a place entity (player) as the region over which the scoper (typically an Organization) has certain authority (jurisdiction). For example, the Calgary Regional Health Authority (scoper) has authority over the territory “Region 4 of Alberta” (player) in matters of health.

RoleClassTherapeuticAgent

A manufactured material (player) that is used for its therapeutic properties. The manufacturer is the scoper.

RoleClassUnderwriter

A role played by a person or an organization. It is the party that

  1. accepts fiscal responsibility for insurance plans and the policies created under those plans;
  2. administers and accepts fiscal responsibility for a program that provides coverage for services to eligible individuals; and/or
  3. has the responsibility to assess the merits of each risk and decide a suitable premium for accepting all or part of the risk. If played by an organization, this role may be further specified by an appropriate RoleCode. Example:
  4. A health insurer;
  5. Medicaid Program;
  6. Lloyd’s of London
RoleClassUsedEntity

Description:An entity (player) that is used by another entity (scoper)

RoleClassWarrantedProduct

A role a product plays when a guarantee is given to the purchaser by the seller (scoping entity) stating that the product is reliable and free from known defects and that the seller will repair or replace defective parts within a given time limit and under certain conditions.

RoleInformationSensitivityPolicy

RoleSensitivity codes are used to bind information to a Role.confidentialityCode per organizational policy. Role.confidentialityCode is defined in the RIM as “an indication of the appropriate disclosure of information about this Role with respect to the playing Entity.”

RoleLinkHasContact

No description

RoleLinkHasDirectAuthorityOver

The source Role has direct authority over the target role in a chain of authority.

RoleLinkHasIndirectAuthorityOver

The source Role has indirect authority over the target role in a chain of authority.

RoleLinkHasPart

The target Role is part of the Source Role.

RoleLinkIdentification

Definition: The source role provides identification for the target role. The source role must be IDENT. The player entity of the source role is constrained to be the same as the player of the target role if present. If the player is absent from the source role, then it is assumed to be the same as the player of the target role.

RoleLinkIsBackupFor

This relationship indicates the source Role is available to the target Role as a backup. An entity in a backup role will be available as a substitute or replacement in the event that the entity assigned the role is unavailable. In medical roles where it is critical that the function be performed and there is a possibility that the individual assigned may be ill or otherwise indisposed, another individual is assigned to cover for the individual originally assigned the role. A backup may be required to be identified, but unless the backup is actually used, he/she would not assume the assigned entity role.

RoleLinkRelated

An action taken with respect to a subject Entity by a regulatory or authoritative body with supervisory capacity over that entity. The action is taken in response to behavior by the subject Entity that body finds to be undesirable. Suspension, license restrictions, monetary fine, letter of reprimand, mandated training, mandated supervision, etc.Examples:

RoleLinkReplaces

This relationship indicates that the source Role replaces (or subsumes) the target Role. Allows for new identifiers and/or new effective time for a registry entry or a certification, etc.

RoleLinkStatus

No description

RoleLinkStatusActive

No description

RoleLinkStatusCancelled

No description

RoleLinkStatusCompleted

No description

RoleLinkStatusNormal

No description

RoleLinkStatusNullified

No description

RoleLinkStatusPending

No description

RoleLinkType

A code specifying the meaning and purpose of every RoleLink instance. Each of its values implies specific constraints to what kinds of Role objects can be related and in which way.

RoleLocationIdentifiedEntity

Description:Describes types of identifiers other than the primary location registry identifier for a service delivery location. Identifiers may be assigned by a local service delivery organization, a formal body capable of accrediting the location for the capability to provide specific services or the identifier may be assigned at a jurisdictional level.

RoleStatus

Codes representing the defined possible states of an Role, as defined by the Role class state machine.

RoleStatusActive

The state representing the fact that the Entity is currently active in the Role.

RoleStatusCancelled

The terminal state resulting from cancellation of the role prior to activation.

RoleStatusNormal

The ‘typical’ state. Excludes “nullified” which represents the termination state of a Role instance that was created in error.

RoleStatusNullified

The state representing the termination of a Role instance that was created in error.

RoleStatusPending

The state representing that fact that the role has not yet become active.

RoleStatusSuspended

The state that represents a suspension of the Entity playing the Role. This state is arrived at from the “active” state.

RoleStatusTerminated

The state representing the successful termination of the Role.

RouteByMethod

Route of substance administration classified by administration method.

RouteBySite

Route of substance administration classified by site.

RouteOfAdministration

The path the administered medication takes to get into the body or into contact with the body.

SCDHEC-GISSpatialAccuracyTiers

Description: The South Carolina Department of Health and Environmental Control GIS Spatial Data Accuracy Tiers have been derived from the National Standard for Spatial Data Accuracy as a means to categorize the accuracy of spatial data assignment utilizing a variety of tools for capturing coordinates including digitizers, geocoding software and global positioning system devices.

SNOMED International Global Patient Set (GPS)

SNOMED International Global Patient Set (GPS) value set. The value set includes all of the codes from the SNOMED International Global Patient Set (GPS) subset of SNOMED CT. The current version of the value set contains all concepts (26,158) from the September 2020 release of the GPS (based on the July 2020 SNOMED CT International Edition release).

This value set is provided as a FHIR ValueSet resource instance for the convenience of implementers.

Sahaptian

No description

Salishan

No description

SaukFoxKickapoo

No description

ScalpRoute

Scalp

SchedulingActReason

Reasons for cancelling or rescheduling an Appointment

SecurityAlterationIntegrityObservationType

<pType of security metadata observation made about the alteration integrity of an IT resource (data, information object, service, or system capability), which indicates the mechanism used for authorized transformations of the resource.</p>

SecurityAlterationIntegrityObservationValue

No description

SecurityCategoryObservationType

Type of security metadata observation made about the category of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security category metadata is defined by ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-1995 as: “A nonhierarchical grouping of sensitive information used to control access to data more finely than with hierarchical security classification alone.”

SecurityCategoryObservationValue

Security observation values used to indicate security category metadata. V:SecurityCategoryObservationValue is the union of V:PrivacyPolicyType, V:ActPrivacyLaw, V:ActConsentDirective, V:InformationSensitivityPolicy, V:ActInformationSensitivityPolicy, V:RoleInformationSensitivityPolicy, V:EntityInformationSensitivityPolicy, and the V:ActConsentType value used to populate the SecurityCategoryObservationValue attribute in order to convey one or more nonhierarchical categories of sensitivity metadata, which are used to control access to data more finely than with hierarchical security classification alone. Could be bound R1 to a V:ActUSPrivacyPolicy in a future US Realm.

SecurityClassificationObservationType

Type of security metadata observation made about the classification of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security classification is defined by ISO/IEC 2382-8:1998(E/F)/ T-REC-X.812-1995 as: “The determination of which specific degree of protection against access the data or information requires, together with a designation of that degree of protection.” Security classification metadata is based on an analysis of applicable policies and the risk of financial, reputational, or other harm that could result from unauthorized disclosure.

SecurityClassificationObservationValue

Security observation values used to indicate security classification metadata.

SecurityControlObservationType

Type of security metadata observation made about the control of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security control metadata conveys instructions for secure distribution, transmission, storage or use.

SecurityControlObservationValue

Security observation values used to indicate security control metadata. V:SecurityControl is the union of V:SecurityPolicy, V:ObligationPolicy, V:RefrainPolicy, V:PurposeOfUse, and V:GeneralPurpose of Use, V:PrivacyMark, V:SecurityLabelMark, and V:ControlledUnclassifiedInformation used to populate the SecurityControlObservationValue attribute in order to convey one or more nonhierarchical security control metadata dictating handling caveats including, purpose of use, obligation policy, refrain policy, dissemination controls and privacy marks to which a custodian or receiver is required to comply.

SecurityDataIntegrityObservationType

Type of security metadata observation made about the data integrity of an IT resource (data, information object, service, or system capability), which indicates the security mechanism used to preserve resource accuracy and consistency. Data integrity is defined by ISO 22600-23.3.21 as: “The property that data has not been altered or destroyed in an unauthorized manner”, and by ISO/IEC 2382-8: The property of data whose accuracy and consistency are preserved regardless of changes made.”

SecurityDataIntegrityObservationValue

No description

SecurityIntegrityConfidenceObservationType

Type of security metadata observation made about the integrity confidence of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions.

SecurityIntegrityConfidenceObservationValue

No description

SecurityIntegrityObservationType

Type of security metadata observation made about the integrity of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions.

SecurityIntegrityObservationValue

No description

SecurityIntegrityProvenanceAssertedByObservationType

Type of security metadata observation made about the integrity provenance of an IT resource (data, information object, service, or system capability), which indicates the entity that made assertions about the resource. The asserting entity may not be the original informant about the resource.

SecurityIntegrityProvenanceAssertedByObservationValue

No description

SecurityIntegrityProvenanceObservationType

Type of security metadata observation made about the provenance integrity of an IT resource (data, information object, service, or system capability), which indicates the lifecycle completeness or workflow status of an IT resource, such as its creation, modification, suspension, and deletion; locations in which the resource has been collected or archived, from which it may be retrieved, and the history of its distribution and disclosure. Integrity provenance metadata about an IT resource may be used to assess its veracity, reliability, and trustworthiness.

SecurityIntegrityProvenanceObservationValue

No description

SecurityIntegrityProvenanceReportedByObservationType

Type of security metadata observation made about the integrity provenance of an IT resource (data, information object, service, or system capability), which indicates the entity that reported the existence of the resource. The reporting entity may not be the original author of the resource.

SecurityIntegrityProvenanceReportedByObservationValue

No description

SecurityIntegrityStatusObservation

Security observation values used to indicate security integrity status metadata.

SecurityIntegrityStatusObservationType

Type of security metadata observation made about the integrity status of an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Indicates the completeness or workflow status of an IT resource, which may impact users that are authorized to access and use the resource.

SecurityLabelMark

Codes used for displayed Security Label tags. Supports selection of SecurityLabelMark value set with head code for e.g., rules engine policy set purposes.

SecurityLabelMarkLabel

Codes used for displayed Security Label tags. Supports the selection of SecurityLabelMark leaf concepts for use, e.g., in security labels.

SecurityObservationType

Type of security metadata observation made about an IT resource (data, information object, service, or system capability), which may be used to make access control decisions. Security metadata are used in security labels. According to ISO/TS 22600-3:2009(E) A.9.1.7 SECURITY LABEL MATCHING, Security label matching compares the initiator’s clearance to the target’s security label. All of the following must be true for authorization to be granted:

  • The security policy identifiers shall be identical,
  • The classification level of the initiator shall be greater than or equal to that of the target (that is, there shall be at least one value in the classification list of the clearance greater than or equal to the classification of the target), and
  • For each security category in the target label, there shall be a security category of the same type in the initiator’ijs clearance and the initiator’s classification level shall dominate that of the target.
SecurityObservationValue

Observation values used to indicate security observation metadata.

SecurityPolicy

Types of security policies that further specify the ActClassPolicy value set. Examples:

  • encrypt
  • prohibit redisclosure without consent directive
SecurityTrustAccreditationObservationType

Type of security metadata observation made about the formal declaration by an authority or neutral third party that validates the technical, security, trust, and business practice conformance of Trust Agents to facilitate security, interoperability, and trust among participants within a security domain or trust framework.

SecurityTrustAccreditationObservationValue

Values for security metadata observation made about the formal declaration by an authority or neutral third party that validates the technical, security, trust, and business practice conformance of Trust Agents to facilitate security, interoperability, and trust among participants within a security domain or trust framework.

SecurityTrustAgreementObservationType

Type of security metadata observation made about security requirements for a security domain. [ISO IEC 10181-1]

SecurityTrustAgreementObservationValue

Type of security metadata observation made about security requirements for a security domain. [ISO IEC 10181-1] Definition Is Immutable: true

SecurityTrustAssuranceObservationType

Values for security metadata observation made about the digital quality or reliability of a trust assertion, activity, capability, information exchange, mechanism, process, or protocol.

SecurityTrustAssuranceObservationValue

Values for security metadata observation made about the digital quality or reliability of a trust assertion, activity, capability, information exchange, mechanism, process, or protocol.

SecurityTrustCertificateObservationType

Type of security metadata observation made about a set of security-relevant data issued by a security authority or trusted third party, together with security information which is used to provide the integrity and data origin authentication services for an IT resource (data, information object, service, or system capability). [Based on ISO IEC 10181-1]

SecurityTrustCertificateObservationValue

Values for security metadata observation made about a set of security-relevant data issued by a security authority or trusted third party, together with security information which is used to provide the integrity and data origin authentication services for an IT resource (data, information object, service, or system capability). [Based on ISO IEC 10181-1]

SecurityTrustFrameworkObservationType

Type of security metadata observation made about a complete set of contracts, regulations, or commitments that enable participating actors to rely on certain assertions by other actors to fulfill their information security requirements. [Kantara Initiative]

SecurityTrustFrameworkObservationValue

Values for security metadata observation made about a complete set of contracts, regulations, or commitments that enable participating actors to rely on certain assertions by other actors to fulfill their information security requirements. [Kantara Initiative]

SecurityTrustMechanismObservationType

Type of security metadata observation made about a complete set of contracts, regulations, or commitments that enable participating actors to rely on certain assertions by other actors to fulfill their information security requirements. [Kantara Initiative]

SecurityTrustMechanismObservationValue

Values for security metadata observation made about a complete set of contracts, regulations, or commitments that enable participating actors to rely on certain assertions by other actors to fulfill their information security requirements. [Kantara Initiative]

SecurityTrustObservationType

Type of security metadata observation made about aspects of trust applicable to an IT resource (data, information object, service, or system capability). Trust applicable to IT resources is established and maintained in and among security domains, and may be comprised of observations about the domain’s trust authority, trust framework, trust policy, trust interaction rules, means for assessing and monitoring adherence to trust policies, mechanisms that enforce trust, and quality and reliability measures of assurance in those mechanisms. [Based on ISO IEC 10181-1 and NIST SP 800-63-2] Usage Note: SecurityTrustObservationType may be used as a trust attribute in a computable trust policy, trust credential, trust assertion, or trust label field in a security label and populated with trust observation values. The valued trust attributes may be used for used for authentication, authorization, and access control decisions. These may also be used to negotiate trust relationships, adjudicate or bridge trust policies, and to specify requirements for participation in a Trust Domain or for asserting compliance with a Trust Framework.

SecurityTrustObservationValue

Values for security metadata observation made about aspects of trust applicable to an IT resource (data, information object, service, or system capability). Trust applicable to IT resources is established and maintained in and among security domains, and may be comprised of observations about the domain’s trust authority, trust framework, trust policy, trust interaction rules, means for assessing and monitoring adherence to trust policies, mechanisms that enforce trust, and quality and reliability measures of assurance in those mechanisms. [Based on ISO IEC 10181-1 and NIST SP 800-63-2]

Sequencing

Specifies sequence of sort order.

SerranoGabrielino

No description

Service category

This value set defines an example set of codes that can be used to classify groupings of service-types/specialties.

Service type

This value set defines an example set of codes of service-types.

ServiceDeliveryLocationRoleType

A role of a place that further classifies the setting (e.g., accident site, road side, work site, community location) in which services are delivered.

ServiceProvisionConditions

The code(s) that detail the conditions under which the healthcare service is available/offered.

SetOperator

No description

SeverityObservation

Potential values for observations of severity.

SeverityObservationCode

No description

Sex Parameter for Clinical Use

A summary parameter that provides guidance on how a receiver should apply settings or reference ranges that are derived from observable information such as an organ inventory, recent hormone lab tests, genetic testing, menstrual status, obstetric history, etc..

Shasta

No description

Sibling

One person who shares a parent or parents with another.

SiblingInLaw

The player of the role is: (1) a sibling of the scoping person’s spouse, or (2) the spouse of the scoping person’s sibling, or (3) the spouse of a sibling of the scoping person’s spouse.

SignificantOtherRoleType

A person who is important to one’s well being; especially a spouse or one in a similar relationship. (The player is the one who is important)

SinusUnspecifiedRoute

Sinus, unspecified

Siouan

No description

SiouanCatawba

No description

SirenikskiYupik

No description

SkinRoute

Skin

SmartCapabilities

Codes that define what the server is capable of.

SnodentAnteriorInterarchDeviationTypeInternational

The SNODENT identifiers for dental anterior inter-arch deviations utilized to calculate the Salzmann Malocclusion Severity Index. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentCraniofacialAnomalyInternational

The SNODENT identifiers for the most common craniofacial anomalies that may influence the course of orthodontic treatment to be performed. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentDentalAbnormalityInternational

The SNODENT identifiers for tooth-specific abnormalities that impact orthodontic treatment. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentDentalFrenumRegionInternational

The SNODENT identifiers for the regions of the human frenum within the mouth. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentDentalPeriodontalProbingPositionInternational

The SNODENT identifiers for the relative positions around the tooth that are probed and measured in assessing a patient’s periodontal health. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentDentalToothFurcationSiteInternational

The SNODENT identifiers for the relative location of a human tooth root that is being observed for furcation. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentDentalToothMobilityMillerClassificationInternational

The SNODENT identifiers for the recognized grades of tooth mobility according to the Miller Classification system. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentDentalUniversalNumberingSystemInternational

The SNODENT identifiers for all of the possible human teeth, both adult and adolescent. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentDentitionStateInternational

The SNODENT identifiers for the stages of dentition an individual progresses through during a lifetime. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentJawTypeInternational

The SNODENT identifiers for the two jaws (mandible and maxilla). This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentOralCavityAreaInternational

The SNODENT identifiers for regions in the mouth utilized to calculate the Salzmann Malocclusion Severity Index. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentOrthodonticDiagnosticFeatureInternational

The SNODENT identifiers for gross patient findings that inform the course of orthodontic treatment to be performed. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentOrthodonticTreatmentPreconditionInternational

The SNODENT identifiers for patient conditions that may preclude starting orthodontic treatment. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentPosteriorInterarchDeviationTypeInternational

The SNODENT identifiers for dental posterior inter-arch deviations utilized to calculate the Salzmann Malocclusion Severity Index. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SnodentSalzmannInterarchDeviationMaxillaryToothInternational

The SNODENT identifiers for the teeth in the maxilla assessed for tooth-specific inter-arch deviations as part of calculating the Salzmann Malocclusion Severity Index. This value set contains content from SNODENT® Copyright American Dental Association (ADA). All rights reserved. SNODENT is a registered trademark of the ADA. http://www.ada.org/en/member-center/member-benefits/practice-resources/dental-informatics/snodent/licensing-snodent Steward: Attachments WG

SoftTissueRoute

Soft tissue

Software Name Example

An example value set representing the SoftwareName concept domain used to convey a coded name for a device..

Software System Type

Types of software systems that support knowledge artifact authoring and evaluation (authoring, testing, tooling, evaluation)

SolidDrugForm

No description

SolutionDrugForm

A liquid preparation that contains one or more chemical substances dissolved, i.e., molecularly dispersed, in a suitable solvent or mixture of mutually miscible solvents.

SouthernAlaska

No description

SouthernCaddoan

No description

SouthernNumic

No description

Special arrangements

This value set defines a set of codes that can be used to indicate the kinds of special arrangements in place for a patients visit.

SpecialValues

A set of generally useful codes defined so they can be included in value sets.

SpecimenAdditiveEntity

Set of codes related to specimen additives

SpecimenEntityType

No description

SpecimenRoleType

No description

SponsorParticipationFunction

Definition: Set of codes indicating the manner in which sponsors participate in a policy or program. NOTE: use only when the Sponsor is not further specified with a SponsorRoleType as being either a fully insured sponsor or a self insured sponsor.

Spouse

Description:A relationship between two people characterizing their “familial” relationship

StandardsStatus

HL7 Ballot/Standards status of artifact.

StateChangeReason

Indicates why the state of the subject changed.

StatisticAttributeEstimateType

Method of reporting variability of estimates, such as confidence intervals, interquartile range or standard deviation.

StatisticCertaintyRating

The relative quality of the statistic.

StatisticCertaintySubcomponentRating

The quality rating of the subcomponent of a quality of evidence rating.

StatisticCertaintySubcomponentType

The subcomponent classification of quality of evidence rating systems.

StatisticStatisticType

The type of a specific statistic.

StatisticStudyType

The type of study a statistic was derived from.

StatisticSynthesisType

Types of combining results from a body of evidence (eg. summary data meta-analysis).

StatisticsCode

The statistical operation parameter -“statistic” codes.

StatusRevisionRefusalReasonCode

Indicates why the act revision (status update) is being refused.

StepChild

The player of the role is a child of the scoping person’s spouse by a previous union.

StepParent

The player of the role is the spouse of the scoping person’s parent and not the scoping person’s natural parent.

StepSibling

The player of the role is a child of the scoping person’s stepparent.

StreetAddressLine

No description

StreetName

No description

StrengthOfRecommendationRating

A rating system that describes the strength of the recommendation, such as the GRADE, DynaMed, or HGPS systems.

Structure Definition Use Codes / Keywords

Structure Definition Use Codes / Keywords

StudentRoleType

Covered party to an insurance policy has coverage through full-time or part-time attendance at a recognized educational institution as defined by a particular insurance policy.

StyleType

(abstract) Used within an instance to give the author some control over various aspects of rendering

SubarachnoidRoute

Subarachnoid

SubconjunctivalRoute

Subconjunctival

SubcutaneousRoute

Subcutaneous

SublesionalRoute

Sublesional

SublingualRoute

Sublingual

SubmucosalRoute

Submucosal

SubscriberCoveredPartyRoleType

Description: A role recognized through the eligibility of a party to play a subscriber for benefits covered or provided under a health insurance policy.

SubscriberPolicyholder Relationship Codes

This value set includes codes for the relationship between the Subscriber and the Beneficiary (insured/covered party/patient).

Subscription Error Codes

Codes to represent subscription error details

SubscriptionChannel Type Codes

Codes to represent subscription error details

SubscriptionStatusAtEvent

A status code for the state of the Subscription.

SubscriptionTag

Tags to put on a resource after subscriptions have been sent.

SubsidizedHealthProgram

Definition: A government health program that provides coverage for health services to persons meeting eligibility criteria such as income, location of residence, access to other coverages, health condition, and age, the cost of which is to some extent subsidized by public funds.

Substance Category Codes

Substance category codes

SubstanceAdminGenericSubstitution

Substitution occurred or is permitted with another product in the same generic ingredient.

SubstanceAdminSubstitutionNotAllowedReason

Reasons why substitution of a substance administration request is not permitted.

SubstanceAdminSubstitutionReason

No description

SubstanceAdministrationPermissionRefusalReasonCode

Definition:Indicates why the requested authorization to prescribe or dispense a medication has been refused.

SubstitutionCondition

Identifies what sort of change is permitted or has occurred between the item that was ordered/requested and the one that was/will be provided.

SupernumeraryTooth

Supernumerary tooth, any tooth in addition to the normal permanent and primary dentition

Supply Item Type

This value sets refers to a specific supply item.

Supply Type

This value sets refers to a Category of supply.

SupplyAppropriateManagementCode

Confirmed supply action appropriate

SupplyDetectedIssueCode

Supplying the product at this time may be inappropriate or indicate compliance issues with the associated therapy

SupplyOrderAbortReasonCode

Definition:A collection of concepts that indicates why the prescription should no longer be allowed to be dispensed (but can still administer what is already being dispensed).

SupplyRequestReason

The reason why the supply item was requested.

SuppositoryDrugForm

A solid body of various weights and shapes, adapted for introduction into the rectal, vaginal, or urethral orifice of the human body; they usually melt, soften, or dissolve at body temperature.

SuppositoryRoute

Suppository

Surface Codes

This value set includes a smattering of FDI tooth surface codes.

SurgClinPracticeSetting

No description

SusceptibilityObservationMethodType

Description:Test methods designed to determine a microorganism’s susceptibility to an antibiotic.

SuspensionDrugForm

No description

SwabDrugForm

A wad of absorbent material usually wound around one end of a small stick and used for applying medication or for removing material from an area.

Swish

Swish

TableCellHorizontalAlign

These values are defined within the XHTML 4.0 Table Model

TableCellScope

These values are defined within the XHTML 4.0 Table Model

TableCellVerticalAlign

These values are defined within the XHTML 4.0 Table Model

TableFrame

These values are defined within the XHTML 4.0 Table Model

TableRuleStyle

(abstract) Defines table cell rendering characteristics

TableRules

These values are defined within the XHTML 4.0 Table Model

TabletDrugForm

A solid dosage form containing medicinal substances with or without suitable diluents.

Takelman

No description

Takic

No description

Tanana

No description

TananaTutchone

No description

Taracahitan

No description

TargetAwareness

A code specifying the extent to which the Entity playing the participating Role (usually as a target Participation) is aware of the associated Act. Examples: For diagnostic observations, is the patient, family member or other participant aware of his terminal illness? Discussion: If the awareness, denial, unconsciousness, etc. is the subject of medical considerations (e.g., part of the problem list), one should use explicit observations in these matters as well, and should not solely rely on this simple attribute in the Participation.

TelecommunicationAddressUse

No description

TelecommunicationCapabilities

Description: Concepts that define the telecommunication capabilities of a particular device. Used to identify the expected capabilities to be found at a particular telecommunication address.

Tepiman

No description

Test script operation code

This value set defines a set of codes that are used to indicate the supported operations of a testing engine or tool.

Test script profile destination type

This value set defines a set of codes that are used to indicate the profile type of a test system when acting as the destination within a TestScript.

Test script profile origin type

This value set defines a set of codes that are used to indicate the profile type of a test system when acting as the origin within a TestScript.

TextMediaType

For any text

TherapeuticProductDetectedIssueCode

Proposed therapy may interact with an existing or recent therapeutic product

TherapyAppropriateManagementCode

Confirmed drug therapy appropriate

TimingDetectedIssueCode

No description

TimingEvent

No description

Tiwa

No description

TopicalAbsorptionRoute

Topical absorption

TopicalApplication

Topical application

TopicalPowder

No description

TopicalSolution

No description

TracheostomyRoute

Tracheostomy

Transdermal

Transdermal

TransdermalPatch

No description

Transfer

Transfer of ownership for a product.

TransferActReason

The explanation for why a patient is moved from one location to another within the organization

TransmissionRelationshipTypeCode

Description:A code specifying the meaning and purpose of every TransmissionRelationship instance. Each of its values implies specific constraints to what kinds of Transmission objects can be related and in which way.

TransmucosalRoute

Transmucosal

TransplacentalRoute

Transplacental

TranstrachealRoute

Transtracheal

TranstympanicRoute

Transtympanic

TribalEntityUS

INDIAN ENTITIES RECOGNIZED AND ELIGIBLE TO RECEIVE SERVICES FROM THE UNITED STATES BUREAU OF INDIAN AFFAIRS

TriggerEventID

No description

TrustPolicy

A mandate, obligation, requirement, rule, or expectation conveyed as security metadata between senders and receivers required to establish the reliability, authenticity, and trustworthiness of their transactions. Trust security metadata are observation made about aspects of trust applicable to an IT resource (data, information object, service, or system capability). Trust applicable to IT resources is established and maintained in and among security domains, and may be comprised of observations about the domain’s trust authority, trust framework, trust policy, trust interaction rules, means for assessing and monitoring adherence to trust policies, mechanisms that enforce trust, and quality and reliability measures of assurance in those mechanisms. [Based on ISO IEC 10181-1 and NIST SP 800-63-2]

Tsamosan

No description

Tsimshianic

No description

Types of Edible Substances

This value set represents codes for types of edible substances and is provided as a suggestive example. It include codes from SNOMED CT where concept is-a 762766007 Edible Substance (substance).

UCUM Codes

Unified Code for Units of Measure (UCUM). This value set includes all UCUM codes

UNSPSC

Description:United Nations Standard Products and Services Classification, managed by Uniform Code Council (UCC): www.unspsc.org

UPC

Description:Universal Product Code is one of a wide variety of bar code languages widely used in the United States and Canada for items in stores.

URLScheme

A Universal Resource Locator (URL) is a type of telecommunications address specified as Internet standard RFC 1738 [http://www.ietf.org/rfc/rfc1738.txt]. The URL specifies the protocol and the contact point defined by that protocol for the resource.

USCLS Codes

This value set includes a smattering of USCLS codes.

USEncounterDischargeDisposition

No description

USEncounterReferralSource

No description

UnderwriterParticipationFunction

Definition: Set of codes indicating the manner in which underwriters participate in a policy or program.

Unit Type Codes

This value set includes a smattering of Unit type codes.

UnitsOfMeasureCaseSensitive

Description: All units of measure.

Unknown

A proper value is applicable, but not known.

UnorderedListStyle

Defines rendering characteristics for unordered lists

UpdateRefusalReasonCode

No description

UpperChinook

No description

UreteralRoute

Ureteral

UrethralRoute

Urethral

UrinaryBladderIrrigation

Irrigation, urinary bladder

UrinaryBladderRoute

Urinary bladder

UrinaryTractRoute

Urinary tract

UsageContextType

A code that specifies a type of context being specified by a usage context.

Utian

No description

UtoAztecan

No description

V2 Table 0942 Version Master

Value Set of codes that specify the type of measurement of the state of an automated laboratory instrument.

VaccineEntityType

A Type of medicine that creates an immune protection without the recipient experiencing the disease.

VaccineManufacturer

The manufacturer of a vaccine.

VaccineType

The kind of vaccine.

VaginalCream

No description

VaginalFoam

No description

VaginalGel

No description

VaginalOintment

No description

VaginalRoute

Vaginal

Validation-process

The primary process by which the target is validated

Validation-status

Status of the validation of the target against the primary source

Validation-type

What the target is validated against

ValidationIssue

No description

VerificationMethod

No description

VerificationOutcomeValue

Values for observations of verification act results Examples: Verified, not verified, verified with warning.

VerificationResult Communication Method

Attested information may be validated by process that are manual or automated. For automated processes it may accomplished by the system of record reaching out through another system’s API or information may be sent to the system of record. This value set defines a set of codes to describing the process, the how, a resource or data element is validated.

VideoMediaType

Video media type.

VitreousHumourRoute

Vitreous humour

Wakashan

No description

WeightAlert

Proposed therapy may be inappropriate based on the patient’s weight

WesternApachean

No description

WesternMiwok

No description

WesternMuskogean

No description

WesternNumic

No description

Wintuan

No description

Wiyot

No description

WorkClassificationODH

Provide the concepts for the value element of the C-CDA Work Classification Observation entry template.

WorkPlace

No description

WorkScheduleODH

Describes an individual’s typical arrangement of working hours for an occupation.

Yaqui

No description

Yes No Unknown NotAsked

This value set contains 4 concepts commonly used as answers to items in a questionnaire.

Yokuts

No description

Yokutsan

No description

Yukian

No description

Yuman

No description

_0272

Testing to measure the minimum concentration of the antibacterial agent in a given culture medium below which bacterial growth is not inhibited.

_0275a

No description

_0280

Test methods designed to determine a microorganismaTMs susceptibility to being killed by an antibiotic.

chromosome-human

Chromosome number for human.

employmentStatusODH

Concepts representing whether a person does or does not currently have a job or is not currently in the labor pool seeking employment.

hl7VS-ReasonForStudy

Value Set of codes that provide additional information to the universal service identifier on why a test, study or review was ordered.

hl7VS-VS-collectionEvent

Value Set of codes specifying the limit for a collection event or process step.

hl7VS-VS-communicationLocation

Value Set of codes specifying a communication location.

hl7VS-VS-limitationTypeCode

Value Set of codes specifying a type of limitation.

hl7VS-VS-observationSubtype

Value Set of codes specifying an observation sub-type.

hl7VS-VS-observationType

Value Set of codes that specify types of observations to enable systems to distinguish between observations sent along with an order, versus observations sent as the result to an order.

hl7VS-accept-applicationAcknowledgmentConditions

Concepts which identify conditions under which accept acknowledgments are required to be returned in response to a message, and required for enhanced acknowledgment mode.

hl7VS-accessRestrictionValue

Value Set of codes that specify the information to which access is restricted. Note that the new codes as of November 2018 have been temporarily loaded into the underlying V2 code system pending availability of the currently unavailable new tooling, at which time this value set will be retired and a value set based on the HL7 V3 ActCode code system will be used instead for this table, and the rendered URL will be valid at terminology.hl7.org.

hl7VS-acknowledgmentCode

Concepts specifying acknowledgment codes used in Version 2.x message. For details of usage, see message processing rules in the published Standard.

hl7VS-actionCode

Concepts which specify actions to be taken with respect to the specimens that accompany or precede an order. The purpose of these are to further qualify (when appropriate) the general action indicated by the order control code (code system xxxx).

hl7VS-actionCode

Concepts used in Patient Care for the intent of a problem or goal. Used in Version 2 messaging in the GOL segment.

hl7VS-actionCode

Status codes of record operations.

hl7VS-actionTakenInResponseToTheEvent

Value Set of codes that define the action taken as a result of an event related to a product issue.

hl7VS-active-inactive

Value Set of codes that specify whether a person is currently a valid staff member.

hl7VS-actpriority

Value Set of codes specifying the priority for a shipment.

hl7VS-additivePreservative

Concepts specifying any additive introduced to the specimen before or at the time of collection. These additives may be introduced in order to preserve, maintain or enhance the particular nature or component of the specimen. Used in Version 2 messaging in the SPM segment.

hl7VS-addressExpirationReason

Value Set of codes that specify the reason this address was marked as “ended”.

hl7VS-addressType

Concepts specifying types or kinds of addresses.

hl7VS-addressUsage

Value Set of codes that specify how an address is intended to be used.

hl7VS-adjustmentAction

Value Set of codes used to specify the action requested of a party that receives an adjustment.

hl7VS-adjustmentCategoryCode

Value Set of codes used to specify the category of adjustment and is used to assist in determining which table is used for Adjustment Reason.

hl7VS-administrationDevice

Value Set of codes that specify the mechanical device used to aid in the administration of the drug or other treatment. Common examples are IV-sets of different types.

hl7VS-administrationMethod

Value Set of codes that specify the specific method requested for the administration of the drug or treatment to the patient.

hl7VS-administrativeSex

Concepts specifying a patient’s sex for administrative purposes.

hl7VS-administriveSite

Concepts that specify a body site from which a specimen is obtained.

hl7VS-admissionLevelOfCareCode

Value Set of codes specifying the acuity level assigned to the patient at the time of admission.

hl7VS-admissionType

Value Set of codes that specify the circumstances under which the patient was or will be admitted.

hl7VS-advanceDirectiveCode

Value Set of codes specifying the patient’s instructions to the healthcare facility.

hl7VS-advancedBeneficiaryNoticeCode

Status codes specifying a patient’s or a patient’s representative’s consent for responsibility to pay for potentially uninsured services. Note that this set of codes is generally used in the US only.

hl7VS-alertDeviceCode

Value Set of codes specifying any type of allergy alert device the patient may be carrying or wearing.

hl7VS-alertLevel

Value Set of codes that identify the highest level of the alert state (e.g.,highest alert severity) that is associated with the indicated equipment (e.g. processing event, inventory event, QC event).

hl7VS-allergyClinicalStatus

Value Set of codes specifying the verification status for the allergy.

hl7VS-allergySeverity

Value Set of codes that specify the general severity of an allergy.

hl7VS-allergyType

Value Set of codes that specify classification of general allergy categories (drug, food, pollen, etc.).

hl7VS-allowSubstitution

Value Set of codes that specify whether substitutions are allowed and, if so, the type of substitutions allowed.

hl7VS-allowSubstitutionCodes

Value Set of codes that indicate whether the appointment resource may be substituted for another by the entity assigned to fulfill the appointment.

hl7VS-alternateCharacterSetHandlingScheme

Concepts that specify the scheme used when any alternative character sets are specified in the second or later iterations of MSH-18 Character Set, and if any special handling scheme is needed.

hl7VS-alternateCharacterSets

Value Set of codes that identify one of a number of possible standard alternate character sets for a message, either single-byte or double-byte.

hl7VS-ambulatoryPaymentClassificationCode

Value Set of codes that specify the derived Ambulatory Payment Classification (APC) code.

hl7VS-ambulatoryStatus

Value Set of codes that specify permanent or transient handicapped conditions of a person.

hl7VS-amountClass

Value Set of codes that specify the amount quantity class.

hl7VS-amountType

Value Set of codes that specify amount quantity type.

hl7VS-analyteRepeatStatus

Value Set of codes identifying the repeat status for the analyte/result (e.g. original, rerun, repeat, reflex). The following are assumptions regarding the table values: Repeated without dilution — performed usually to confirm correctness of r

hl7VS-annotations

Value Set of codes that specify the coded entry associated with a given point in time during the waveform recording. Note codes beyond 9903 may exist; extensions to this table may be done by incrementing the code value.

hl7VS-applicationChangeType

Value Set of codes that specify a type of change being requested (if NMR query) or announced (if NMD unsolicited update).

hl7VS-appointmentReasonCodes

Value Set of codes that describe the kind of appointment or the reason why an appointment has been scheduled.

hl7VS-appointmentTypeCodes

Value Set of codes that an appointment request to describe the kind of appointment.

hl7VS-approvingRegulatoryAgency

Value Set of codes that specify the regulatory agency by which the item has been approved, such as the FDA or AMA.

hl7VS-armStick

Value Set of codes specifying the arm(s) receiving a stick.

hl7VS-artificialBlood

Value Set of codes that identify the artificial blood identifier associated with the specimen.

hl7VS-assignmentOfBenefits

Value Set of codes which indicate whether an insured person agreed to assign the insurance benefits to a healthcare provider. If so, the insurance will pay the provider directly.

hl7VS-authorizationMode

Concepts of forms of authorization a recorder may receive from the responsible practitioner to create or change an order. Used in Version 2 messaging for orders in the ORC segment.

hl7VS-auto-DilutionType

Value Set of codes that specify the pre‑configured dilution to be applied on the instrument, which can be used instead of a numeric declaration.

hl7VS-bedStatus

Value Set of codes that specify the state of a bed in an inpatient setting, and is used to determine if a patient may be assigned to it or not.

hl7VS-benefitGroup

Value Set of codes that specify the benefit group.

hl7VS-bloodProductCode

Value Set of codes specifying the blood product code.

hl7VS-bloodProductDispenseStatus

Value Set of codes that specify the current status of the specified blood product as indicated by the filler or placer. For example, the first status change of a product that may trigger a Blood Product Dispense Status Message occurs when it fir

hl7VS-bloodProductProcessingRequirements

Value Set of codes that specify additional information about the blood component class associated with the Universal Service ID. The placer of the order can specify any required processing of the blood product that must be completed prior to t

hl7VS-bloodProductTransfusion-dispositionStatus

Value Set of codes that specify the current status of the specified blood product as indicated by the placer. For example, the placer may return the blood product to the transfusion service unused because an IV could not be started. The blood co

hl7VS-bloodUnitType

Value Set of codes used to specify the type of blood unit

hl7VS-bodyParts

Value Set of codes that specify the part of the body.

hl7VS-bodySiteModifier

Value Set of codes that specify the modifier for the body site.

hl7VS-bolusType

Value Set of codes specifying a type of bolus.

hl7VS-bpObservationStatusCodesInterpretation

Value Set of codes that specify the interpretation for the blood product observation status codes. A status is considered preliminary until a blood product has reached a final disposition for the patient. For example, when the product is first c

hl7VS-calendarAlignment

Value Set of codes that specify an alignment of the repetition to a calendar (e.g., to distinguish every 30 days from “the 5th of every month”).

hl7VS-caseCategoryCode

Value Set of codes specifying the reason a non-urgent patient presents to the emergency room for treatment instead of a clinic or physican office.

hl7VS-causalityObservations

Value Set of codes that record event observations regarding what may have caused a product related event.

hl7VS-cclValue

Value Set of codes that specify the clinical complexity level (CCL) value for the determined diagnosis related group (DRG) for this diagnosis.

hl7VS-certificateStatus

Value Set of codes that specify the status of the certificate held by a health professional.

hl7VS-certificationCategoryCode

Value Set of codes specifying the code for a certification category.

hl7VS-certificationStatus

Value Set of codes that specify the status of the practitioner’s speciality certification.

hl7VS-certificationTypeCode

Value Set of codes specifying the code for a certification type.

hl7VS-chargeOnIndicator

Value Set of codes that define the event upon which a charge should be generated.

hl7VS-chargeType

Value Set of codes that specify someone or something other than the patient to be billed for a service.

hl7VS-chargeTypeReason

Value Set of codes that specify the choice of, and providing the clinical rationale for, a selected charge type.

hl7VS-checkDigitScheme

Concepts used to identify the check digit scheme employed when a check digit is used in various HL7 Version 2.x datatypes.

hl7VS-codingSystem

Names of coding systems. Each coding system is assigned a unique identifier, which is generally a short mnemonic derived from the full name of the coding system.

hl7VS-commandResponse

Value Set of codes identifying the response of the previously issued command.

hl7VS-commentType

Value Set of codes that identify the type of comment text being sent in the specific comment record.

hl7VS-completionStatus

Status codes used in the workflow of treatment administration events.

hl7VS-computationType

Value Set of codes that specify if the change is computed as a percent change or as an absolute change.

hl7VS-confidentiality

Value Set of codes specifying the confidentiality for a shipment.

hl7VS-confidentialityCode

Value Set of codes that specify the degree to which special confidentiality protection should be applied to the observation.

hl7VS-consentBypassReason

Value Set of codes that specify the reason the subject’s consent was not sought.

hl7VS-consentDisclosureLevel

Value Set of codes that specify how much information was disclosed to the subject as part of the informed consent process.

hl7VS-consentMode

Value Set of codes that specify the method in which a subject provides consent.

hl7VS-consentNon-disclosureReason

Value Set of codes that specify a reason the subject did not receive full disclosure.

hl7VS-consentStatus

Value Set of codes that specify whether the consent has been sought and granted.

hl7VS-consentType

Value Set of codes that specify to what the subject is consenting, i.e. what type of service, surgical procedure, information access/release or other event.

hl7VS-contactRole2

Concepts which specify a relationship role that the next of kin/associated parties plays with regard to the patient. Built on the updated code system. Also used in referrals, for example, it may be necessary to identify the contact representative at the clinic that sent a referral.

hl7VS-containerCondition

Value Set of codes that specify at each receipt the status of the container in which the specimen is shipped in chain of custody cases where specimens are moved from lab to lab. If the container is compromised in any way (seal broken, container

hl7VS-containerStatus

Value Set of codes that identify the status of the unique container in which the specimen resides at the time the transaction was initiated.

hl7VS-continuationStyleCode

Value Set of codes identifying whether it is a fragmented message or part of an interactive continuation message.

hl7VS-controlledSubstanceSchedule

Value Set of codes that specify the class of the drug or other substance if its usage is controlled by legislation.

hl7VS-coordinationOfBenefits

Value Set of codes that specify whether this insurance works in conjunction with other insurance plans or if it provides independent coverage and payment of benefits regardless of other insurance that might be available to the patient.

hl7VS-countryCode-3alpha

Value Set of codes that identifies a country of origin for a message. It will be used primarily to specify default elements, such as currency denominations. The values to be used are those of ISO 3166. The ISO 3166 table has three separate forms for the codes for each country, this value set includes only the 3-character alpha form.

hl7VS-coverageType

Note that this set of codes is used generally in the US only.

hl7VS-cumulativeDosageLimitUom

Value Set of codes specifying the unit of measure (UoM) for the cumulative dosage limit.

hl7VS-cweStatuses

Concepts that represent an exception identifier code; that is, a code that is not defined in the value set (either model or site-extended). These are occationsally referred to a ‘flavors of null’ although this set of concepts is specific to the CWE datatype used in Version 2 messaging, and the codes may be used in the ‘identifier’ component of the ‘triplets’ in that datatype.

hl7VS-cycleType

Value Set of codes that specify the type of cycle that is being executed. A cycle type is a specific sterilization method used for a specific type of supply item.

hl7VS-cyclicEntryExitIndicator

Value Set of codes that specify if this service request is the first or last service request in a cyclic series of service requests.

hl7VS-dataTypes

Value Set of codes specifying the data type.

hl7VS-date-timeSelectionQualifier

Value Set of codes that allow the specification of certain types of values within the date/time range.

hl7VS-dateFormat

Value Set of codes that specify the date format for a decontamination/sterilization instance.

hl7VS-dayType

Value Set of codes that specify whether the days are denied, pending or approved.

hl7VS-daysOfTheWeek

Value Set of codes that identify the day(s) of the week when a location may be scheduled for appointments.

hl7VS-deferredResponseType

Value Set of codes which specify which type of deferred query resonse is desired, as specified with the query parameters.

hl7VS-degreeLicenseCertificate

Concepts specifying an educational degree (e.g., MD). Used in the CNN datatype (names and identifiers of clinicians) in Version 2 messaging. Used in Version 2 messaging; note that in releases of HL7 prior to 2.3.1, was also used in person names (XPN), but this use was deprecated, then withdrawn in 2.7.

hl7VS-delayedAcknowledgmentType

Concepts which specify a response type used in deferred processing two phase reply for delayed acknowldgement mode of the original acknowledgement mechanism defined in HL7 Version 2.x messaging.

hl7VS-derivedSpecimen

Value Set of codes that specify the parents and children for diagnostic studies, especially in microbiology, where the initial specimen (e.g., blood) is processed to produce results (e.g., the identity of the bacteria grown out of the culture). The pro

hl7VS-deviceDataState

Value Set of codes that specify the state of the data as provided from a device.

hl7VS-deviceStatus

Value Set of codes that specify the state of a device.

hl7VS-deviceType

Value Set of codes that specify the kind of device as defined by the manufacturer.

hl7VS-diagnosisClassification

Value Set of codes that classify whether a patient visit can be related to a diagnosis.

hl7VS-diagnosisPriority

Concepts that identify the significance or priority of the diagnosis code. Note that the codes are numeric, and the number of the code represents the ordinal priority of the associated diagnosis. Used in the DG1 segment in Version 2 messaging.

hl7VS-diagnosisType

Concepts specifying a type of diagnosis being sent in HL7 Version 2.x messages.

hl7VS-diagnosticServiceSectionId

Concepts which specify a section of a diagnostic service where the observation may be performed.

hl7VS-dietType

Value Set of codes that specify the type of diet.

hl7VS-disabledPerson

Value Set of codes that specify to which person the disability information relates in the message. For example, if the value is PT, the disability information relates to the patient.

hl7VS-dispenseMethod

Value Set of codes that specify the method by which treatment is dispensed.

hl7VS-dispenseType

Value Set of codes that specify the type of dispensing event that occurred.

hl7VS-documentAvailabilityStatus

Value Set of codes that define whether a patient document is appropriate or available for use in patient care.

hl7VS-documentCompletionStatus

Value Set of codes that record the state of a document in a workflow.

hl7VS-documentConfidentialityStatus

Value Set of codes that specify the degree to which special confidentiality protection should be applied to information. The assignment of data elements to these categories is left to the discretion of the healthcare organization.

hl7VS-documentStorageStatus

Value Set of codes that describe the availability of a document in relation to the type of storage.

hl7VS-donationDurationUnits

Value Set of codes specifying the units of donation duration.

hl7VS-drgDiagnosisDeterminationStatus

Value Set of codes that specify the status of a diagnosis for a diagnosis related group (DRG) determination.

hl7VS-drgGroupingStatus

Value Set of codes that specify the status of the use of the gender information for diagnosis related group (DRG) determination.

hl7VS-drgProcedureDeterminationStatus

Value Set of codes that specify the status of the use of this particular procedure for the diagnosis related group (DRG) determination.

hl7VS-drgProcedureRelevance

Value Set of codes that specify the relevance of this particular procedure for the diagnosis related group (DRG) determination.

hl7VS-drgStatusFinancialCalculation

Value Set of codes that specify the status of the diagnosis related group (DRG) calculation regarding the financial aspects.

hl7VS-drgTransferType

Value Set of codes that specify a type of hospital receiving a transfer patient, which affects how a facility is reimbursed under diagnosis related group (DRG’s), for example, exempt or non-exempt.

hl7VS-durationCategories

Value Set of codes that classify an observation definition as intended to measure a patient’s state at a point in time.

hl7VS-eligibilitySource

Value Set of codes that specify the source of information about the insured’s eligibility for benefits.

hl7VS-employmentStatus

Value Set of codes that specify the guarantor’s employment status.

hl7VS-encoding

Concept identifying the type of IETF encoding used to represent successive octets of binary data as displayable ASCII characters.

hl7VS-equipmentState

Value Set of codes that identify the status the equipment was in at the time the transaction was initiated.

hl7VS-errorSeverity

Concepts documenting the severity of an application error as reported during acknowledgment of messages.

hl7VS-escortRequired

Value Set of codes indicating whether a patient must be accompanied while travelling to a diagnostic service department.

hl7VS-ethnicGroup

Concepts further defining a patient’s ancestry. In the US, a current use is to use these codes to report ethnicity in line with US federal standards for Hispanic origin. Used for HL7 Version 2 messaging in the PID segment.

hl7VS-eventConsequence

Value Set of codes that describe the impact of an event on a patient.

hl7VS-eventExpected

Value Set of codes that communicate whether an event has been judged to be expected or unexpected.

hl7VS-eventQualification

Value Set of codes that qualify an event related to a product experience.

hl7VS-eventReason

Value Set of codes that specify the reason for an event.

hl7VS-eventRelatedPeriod

Value Set of codes that specify a common (periodical) activity of daily living.

hl7VS-eventReportedTo

Value Set of codes that identify the type of entity to which the event has been reported.

hl7VS-eventSeriousness

Value Set of codes that a sender to designate an event as serious or significant.

hl7VS-eventType

Value Set of codes specifying the type of event of the message.

hl7VS-eventTypeCode

Concepts specifying the trigger event for Version 2.x interface messages.

hl7VS-exclusiveTest

Concepts that define if a test should be a specific event with no other tests to be performed with this test, or not, or other special circumstances.

hl7VS-expandedYes-NoIndicator

Value Set of codes that specify an expansion on the original Yes/No indicator table by including “flavors of null”. It is intended to be applied to fields where the response is not limited to “yes” or “no”.

hl7VS-extendedPriorityCodes

Concepts describing the urgency of a request carried in an order. Used in Version 2 messaging in timing/quantity; in older versions of the Standard was used in the TQ datatype, but in later versions it is used in the TQ1 segment (which replaced the TQ datatype which has been withdrawn). Many of the codes are widely recognized values used in healthcare settings in the english-speaking world.

hl7VS-facilityType

Value Set of codes that specify the type of facility.

hl7VS-file-levelEventCode

Concepts specifying file-level events for master files. Used in HL7 Version 2 messaging in the MFI segment.

hl7VS-fillerStatusCodes

Value Set of codes that describe an appointment status from the perspective of the entity assigned to fulfill the appointment.

hl7VS-formularyStatus

Value Set of codes that specify whether or not the service (pharmaceutical) is in the formulary.

hl7VS-formularyStatus

Value Set of codes that specify whether or not the pharmaceutical substance is part of the local formulary.

hl7VS-gestationCategoryCode

Value Set of codes specifying the status of the birth in relation to the gestation

hl7VS-governmentReimbursementProgram

Value Set of codes that specify codes that indicate an agency that the practitioner is authorized to bill for medical services. Existing codes only for use in the United States.

hl7VS-grouperStatus

Value Set of codes that specify the status of a grouper in general.

hl7VS-hospitalService

Value Set of codes that specify the treatment or type of surgery the patient is scheduled to receive.

hl7VS-identifierType

Concepts specifying types of identififiers, as used in person and organization identification datatypes in HL7 Version 2 standards.

hl7VS-identityMayBeDivulged

Value Set of codes that define whether the primary observer has given permission for their identification information to be provided to a product manufacturer.

hl7VS-identityReliabilityCode

Value Set of codes that specify the reliability of patient/person identifying data transmitted via a transaction.

hl7VS-immunizationRegistryStatus

Immunization registry status codes of a patient. Used in Version 2 messaging in the PD1 segment.

hl7VS-inactiveReasonCode

Value Set of codes that specify the reason the staff member is inactive.

hl7VS-incidentTypeCode

Value Set of codes specifying a classification of the incident type.

hl7VS-indirectExposureMechanism

Value Set of codes that identify the mechanism of product transmission when the product has not been directly applied to the patient.

hl7VS-informPersonCode

Value Set of codes that specify who (if anyone) shouldor should not be informed of an error.

hl7VS-institutionRelationshipType

Value Set of codes that specify the relationship the staff person has with the institution for whom he/she provides services.

hl7VS-insuranceCompanyContactReason

Value Set of codes that describe why an insurance company has been contacted.

hl7VS-intendedProcedureType

Value Set of codes specifying the type of intended procedure.

hl7VS-invoiceControlCode

Value Set of codes that specify what invoice action is being performed by this message.

hl7VS-invoiceProcessingResultsStatus

Value Set of codes used to specify the processing status for an Invoice Processing Result.

hl7VS-invoiceReasonCodes

Value Set of codes that specify the reason for an invoice.

hl7VS-invoiceType

Value Set of codes that specify the type of invoice.

hl7VS-itemImportanceCodes

Value Set of codes that denote a level or importance of an inventory item within the context of an inventory location.

hl7VS-itemStatus

Value Set of codes that specify the status (useful for reporting and item usage purposes) that applies to an item.

hl7VS-itemStatusCodes

Value Set of codes that specify the state of an inventory item within the context of an inventory location.

hl7VS-itemType

Value Set of codes that specify a classification of material items into like groups as defined and utilized within an operating room setting for charting procedures.

hl7VS-jobStatus

Value Set of codes that specify a next of kin/associated party’s job status.

hl7VS-jurisdictionalBreadth

Value Set of codes that specify the breadth/extent of the jurisdiction where the qualification is valid.

hl7VS-kindOfQuantity

Value Set of codes that describe the underlying kind of property represented by an observation. The categories distinguish concentrations from total amounts, molar concentrations from mass concentrations, partial pressures from colors, and so

hl7VS-laborCalculationType

Value Set of codes that specify the method used to calculate employee labor and measure employee productivity.

hl7VS-languageAbility

Value Set of codes that specify codes that indicate the ability that a Staff Member possesses with respect to the language.

hl7VS-languageProficiency

Value Set of codes which specify the level of knowledge a person possesses with respect to a language ability identified.

hl7VS-levelOfCare

Value Set of codes that identify the level of care a patient may be afforded when assigned to this location definition.

hl7VS-livingArrangement

Concepts characterizing the situation that patient-associated parties live in at their residential address.

hl7VS-livingDependency

Value Set of codes identifying specific living conditions (e.g., spouse dependent on patient, walk-up) that are relevant to an evaluation of the patient’s healthcare needs.

hl7VS-livingWill

Value Set of codes that specify whether or not the patient has a living will and, if so, whether a copy fo the living will is on file at the healthcare facility. If the patient does not have a living will, the value of this field indicates whether the

hl7VS-loadStatus

Value Set of codes that specify the status of the information provided in a device sterilization or decontamination cycle.

hl7VS-local-remoteControlState

Value Set of codes that identify the current state of control associated with the equipment. Equipment can either work autonomously (‘Local’ control state) or it can be controlled by another system, e.g., LAS computer (‘Remote’ control state)

hl7VS-locationCharacteristicId

Value Set of codes that specify an identifier code to show which characteristic is being communicated with the segment.

hl7VS-locationEquipment

Value Set of codes that identify the equipment available in a location definition identified as a room or bed.

hl7VS-locationRelationshipId

Value Set of codes that specify an identifier code to show which relationship is being communicated with the segment.

hl7VS-locationServiceCode

Value Set of codes specifying the types of services provided by the location.

hl7VS-lotControl

Value Set of codes that specify whether the sterilization load for a device is built in the sub-sterile area adjacent to an Operating Room or the Central Processing Department.

hl7VS-mailClaimParty

Value Set of codes that specify a party to which a claim should be mailed when claims are sent by mail.

hl7VS-maritalStatus

Value Set of codes that specify a person’s marital (civil/legal) status.

hl7VS-marketingBasis

Value Set of codes that specify the basis for marketing approval.

hl7VS-masterFileIdentifierCode

Concepts which are represented by codes identifying HL7Versions 2.x Master Files.

hl7VS-masterfileActionCode

Concepts specifying an action for a master file record. Used in HL7 V2.x messaging in the MFE segment.

hl7VS-matchAlgorithms

Value Set of codes identifying the name or identity of the specific search algorithm to which the RCP-5 Search Confidence Threshold and the QRI-1 Candidate Confidence refer.

hl7VS-matchReason

Value Set of codes identifying what search components (e.g., name, birthdate, social security number) of the record returned matched the original query where the responding system does not assign numeric match weights or confidence levels. It

hl7VS-medicalRoleExecutingPhysician

Value Set of codes specifying the role of the physician (“self-employed” or “employed”).

hl7VS-messageErrorConditionCodes

HL7 (communications) error codes, as transmitted in a message acknowledgement.

hl7VS-messageStructure

HL7 abstract message structure codes.

hl7VS-messageType

Concepts which specify message types for HL7 Version 2.x messaging.

hl7VS-messageWaitingPriority

Value Set of codes that specify how important the most important waiting mesasge is. For example, if there are 3 low priority messages, 1 medium priority message and 1 high priority message, the message waiting priority would be “high”, because

hl7VS-mfnRecode-levelErrorReturn

Concepts which code status values for requested master file record update operations.

hl7VS-militaryService

Value Set of codes that specify the military branch. This field is defined by CMS or other regulatory agencies.

hl7VS-militaryStatus

Value Set of codes that specify the military status of the patient. This field is defined by CMS or other regulatory agencies.

hl7VS-mimeBase64EncodingCharacters

Value Set of codes that are used for base64 MIME encoding. Base64 is defined as follows (adapted from MIME Internet standard RFC 1521).

hl7VS-mimeTypes

Value Set of codes specifying the general type of data.

hl7VS-modeOfArrivalCode

Value Set of codes specifying how the patient was brought to the healthcare facility.

hl7VS-modifyIndicator

Value Set of codes identifying whether the subscription is new or is being modified.

hl7VS-moodCodes

Value Set of codes that specify the functional state of an order.

hl7VS-name-addressRepresentation

Value Set of codes that specify an indication of the representation provided by the data item.

hl7VS-name-addressRepresentation

Value Set of codes that provide an indication of the kind of representation provided by a name or address, but does not necessarily specify the character sets used for the data. It is used to provides hints for a receiver, so it can make choic

hl7VS-nameAssemblyOrder

Value Set of codes specifying the preferred display order of the components of this person name.

hl7VS-nameType

Concepts for types of names for persons.

hl7VS-natureOfAbnormalTesting

Value Set of codes that specify the nature of an abnormal test.

hl7VS-natureOfChallenge

Value Set of codes that further describe an observation definition that is characterized as a challenge observation.

hl7VS-natureOfServiceTestObservation

Concepts specifying an identification of a test battery, an entire functional procedure or study, a single test value (observation), multiple test batteries or functional procedures as an orderable unit (profile), or a single test value (observation) calculated from other independent observations, typically used as an indicator for Master Files.

hl7VS-networkSourceType

Value Set of codes that indicate (in certain systems) whether a lower level source identifier is an initiate or accept type.

hl7VS-newbornCode

Value Set of codes specifying whether the baby was born in or out of the facility.

hl7VS-non-subjectConsenterReason

Value Set of codes that specify a reason consent was granted by a person other than the subject of the consent.

hl7VS-notifyClergyCode

Value Set of codes that specify whether the clergy should be notified.

hl7VS-observationResultHandling

Concepts regarding the handling of a result.

hl7VS-observationResultStatus

Concepts which specify observation result status. These codes reflect the current completion status of the results for one Observation Identifier.

hl7VS-occurrenceCode

Concepts drawn from the National Uniform Billing Committee (NUBC) code for the event or occurrence relating to a bill that may affect payer processing. Used in Version 2 messaging in the Occurrence Code and Date (OCD) value.

hl7VS-occurrenceSpan

Concepts drawn from the National Uniform Billing Committee (NUBC) code that identifies an event that relates to the payment of a claim. Used in Version 2 messaging in the Occurrence Span Code and Date (OSP) value.

hl7VS-onlineVerificationResult

Code values used to indicate the result of an online verification of insurance data.

hl7VS-onlineVerificationResultErrorCodes

V2 Table 0971 Version Master (Online Verification Result Error Code)

hl7VS-orderControl

Concepts which are used to determine the function of the order segment. Depending on the message, the action specifies by one of these control codes may refer to an order or an individual service.

hl7VS-orderControlCodeReason

Value Set of codes that describe reasons for the chosen order control codes.

hl7VS-orderStatus

Value Set of codes that specify the status of an order. The purpose of these values are to report the status of an order either upon request (solicited), or when the status changes (unsolicited). The values are not intended to initiate action. It is as

hl7VS-orderStatusModifier

Value Set of codes that further define an identified status.

hl7VS-orderType

Value Set of codes that specify whether the order is to be executed in an inpatient setting or an outpatient setting.

hl7VS-organDonor

Value Set of codes that specify whether the patient wants to donate his/her organs and whether an organ donor card or similar documentation is on file with the healthcare organization.

hl7VS-organization-Agency-Department

Value Set of codes that specify the agency or department that assigned a specified identifier.

hl7VS-organizationUnitType

Value Set of codes that specify the environment in which the provider acts in the role associated with the provider type, and inludes codes for venues outside of formal organized healthcare settings, such as Home. The provider environment is no

hl7VS-organizationUnitType-Org

Value Set of codes that specify the classification of the organization unit.

hl7VS-organizationalNameType

Concepts used to specify the type of name for an organization i.e., legal name, display name.

hl7VS-otherEnvironmentalFactors

Value Set of codes that identify the other environmental factors associated with the specimen in a specific container, e.g., atmospheric exposure.

hl7VS-outlierType

Value Set of codes that specify the type of outlier (i.e. period of care beyond DRG-standard stay in facility) that has been paid.

hl7VS-overallClaimDispositionCode

Value Set of codes specifying the final status of the claim.

hl7VS-override

Value Set of codes that define whether a Charge Description Master description may be overridden or if it must be overridden.

hl7VS-overrideType

Value Set of codes that specify what type of override can be used to override the specific error identified.

hl7VS-package

Value Set of codes specifying the packaging unit in which this inventory supply item can be ordered or issued when purchased from the vendor in the related vendor segment.

hl7VS-packagingStatusCode

Value Set of codes that specify the packaging status of the service.

hl7VS-participation

Concepts that represent functional involvement of a caregiver or member of a care team with an activity being transmitted (e.g., Case Manager, Evaluator, Transcriber, Nurse Care Practitioner, Midwife, Physician Assistant, etc.)

hl7VS-patientClass

Concepts used by systems to categorize patients by sites.

hl7VS-patientConditionCode

Value Set of codes specifying the patient’s current medical condition for the purpose of communicating to non-medical outside parties, e.g. family, employer, religious minister, media, etc.

hl7VS-patientLocationType

Value Set of codes that identify the kind of location described in the location definition.

hl7VS-patientOutcome

Value Set of codes that describe the overall state of a patient as a result of patient care.

hl7VS-patientResultsReleaseCategorizationScheme

Value Set of codes specifying the scheme for the patient results release categorization.

hl7VS-patientStatusCode

Value Set of codes that define the state of a care episode for a patient.

hl7VS-patient’sRelationshipToInsured

Value Set of codes that specify the relationship of the patient to the insured, as defined by CMS or other regulatory agencies.

hl7VS-payeeRelationshipToInvoice

Value Set of codes used to specify the relationship to the invoice for Person Payee Types.

hl7VS-payeeType

Value Set of codes that specify the type of payee (e.g., organization, person).

hl7VS-paymentAdjustmentCode

Value Set of codes that specify any payment adjustment due to drugs or medical devices.

hl7VS-paymentMethodCode

Value Set of codes used to specify the method for the movement of payment.

hl7VS-pcaType

Value Set of codes specifying a type of PCA.

hl7VS-penaltyType

Value Set of codes that specify whether the amount is currency or a percentage.

hl7VS-personLocationType

Value Set of codes that specify the categorization of the person’s location.

hl7VS-pharmacyOrderTypes

Value Set of codes that specify the general category of pharmacy order which may be used to determine the processing path the order will take.

hl7VS-phlebotomyIssue

Value Set of codes specifying a phlebotomy issue.

hl7VS-phlebotomyStatus

Value Set of codes specifying the status of a phlebotomy.

hl7VS-policyType

Value Set of codes that specify the policy type.

hl7VS-practitionerIdNumberType

Value Set of codes that specify the type of number used for the practitioner identification.

hl7VS-precautionCode

Value Set of codes specifying non-clincal precautions that need to be taken with the patient.

hl7VS-precertificationPatientType

Value Set of codes that specify the category or type of patient for which this certification is requested.

hl7VS-precision

Value Set of codes used to specify the degree of precision of a time stamp.

hl7VS-preferredMethodOfContrct

Value Set of codes that specify which of a group of multiple phone numbers is the preferred method of contact for this person.

hl7VS-preferredSpecimen-AttributeStatus

Concepts that indicate whether a Specimen/Attribute is Preferred or Alternate for collection of a particular specimen.

hl7VS-presentOnAdmission(poa)Indicator

Value Set of codes specifying the present on admission indicator for this particular diagnosis.

hl7VS-priceType

Value Set of codes that identify the intent for the dollar amount on a pricing transaction.

hl7VS-primaryKeyValueType

Value Set of codes that specify the type for the master file record identifier.

hl7VS-primaryObserver'sQualification

Value Set of codes that provide a general description of the kind of health care professional who provided the primary observation.

hl7VS-priority

Value Set of codes that specify the allowed priorities for obtaining the specimen.

hl7VS-privacyLevel

Value Set of codes that identify the level of privacy a patient will be afforded when assigned to this location definition.

hl7VS-procedureDrgType

Value Set of codes that specify a procedure’s priority ranking relative to its DRG.

hl7VS-procedureFunctionalType

Value Set of codes that classify a procedure.

hl7VS-procedurePractitionerType

Value Set of codes of concepts which specify the different types of practitioners associated with this procedure. This set of codes is known to be incomplete.

hl7VS-procedurePriority

Value Set of codes specifying a number that identifies the significance or priority of the procedure code.

hl7VS-processInterruption

Value Set of codes specifying whether a process was interrrupted and whether a needle had been inserted in the donor’s arm prior to the interruption.

hl7VS-processInterruptionReason

Value Set of codes specifying the reason for a process interruption.

hl7VS-processingConsiderationCodes

Value Set of codes that specify special processing requested of Payer for this Product/Service Line Item (e.g., hold until paper supporting documentation is received by Payer).

hl7VS-processingId

Value Set of codes that specify whether the message is part of a production, training or debugging system.

hl7VS-processingMode

Concepts that indicate an archival process or an initial load process.

hl7VS-processingPriority

Value Set of codes that specify one or more available priorities for performing the observation or test.

hl7VS-processingType

Value Set of codes identifying the processing type that applies to the test code. If this attribute is omitted, then regular production is the default.

hl7VS-product-serviceStatus

Value Set of codes that specify the processing status for the Product/Service Code.

hl7VS-product-servicesClarification

Value Set of codes that specify the Product/Service Code.

hl7VS-productSource

Value Set of codes that describe the evaluation state of a product identified in an incident.

hl7VS-productionClassCode

Value Set of codes specifying the code and/or text indicating the primary use for which the living subject was bred or grown.

hl7VS-protectionCode

Value Set of codes that specify that an address needs to be treated with special care or sensitivity.

hl7VS-providerAdjustmentReasonCode

Value Set of codes used to specify the reason for this adjustment.

hl7VS-providerBilling

Value Set of codes that specify how provider services are billed.

hl7VS-providerRole

Value Set of codes that define the relationship between a referral recipient and a patient or between a referral initiator and a patient.

hl7VS-providerRole

Value Set of codes that specify the functional involvement with the activity being transmitted (e.g., Case Manager, Evaluator, Transcriber, Nurse Care Practitioner, Midwife, Physician Assistant, etc.).

hl7VS-publicityCode

Concepts specifying a level of publicity of information about a patient for a specific visit.

hl7VS-purgeStatus

Value Set of codes that define the state of a visit relative to its place in a purge workflow.

hl7VS-quantityLimitedRequest

Concepts which specify the maximum length of a query response that can be accepted by a requesting system, and are expressed as units of mesaure of query response objects.

hl7VS-quantityMethod

Value Set of codes that specify the method by which the quantity distributed is measured.

hl7VS-quantityUnits

Value Set of codes that specify the adjustment quantity.

hl7VS-queryFormatCode

Value Set of codes which specify which of several types of formats for data to be returned in response to a query.

hl7VS-queryPriority

Concepts which specify a time frame in which a querry response is expected.

hl7VS-queryResponseStatus

Concepts defining precise response status concepts in support of HL7 Version 2 query messaging.

hl7VS-queryResultsLevel

Value Set of codes which are used to control level of detail in query results.

hl7VS-rangeType

Value Set of codes that specify whether a composite price range is experssed as a flat rate or a percentage.

hl7VS-re-admissionIndicator

Value Set of codes which are used to specify that a patient is being re-admitted to a healthcare facility from which they were discharged, and indicates the circumstances around such re-admission.

hl7VS-recreationalDrugUseCode

Value Set of codes specifying what recreational drugs the patient uses.

hl7VS-referralCategory

Value Set of codes that describe the patient care setting where a referral should take place.

hl7VS-referralDisposition

Value Set of codes that identify the expected response from the healthcare professional receiving a referral.

hl7VS-referralPriority

Value Set of codes that designate the urgency of a referral.

hl7VS-referralReason

Value Set of codes that specify the reason for which the referral will take place.

hl7VS-referralStatus

Value Set of codes that define the state of a referral.

hl7VS-referralType

Value Set of codes that identify the general category of healthcare professional desired to satisfy a referral.

hl7VS-reimbursementTypeCode

Value Set of codes that specify the fee schedule reimbursement type applied to a line item.

hl7VS-relatednessAssessment

Value Set of codes that provide an estimate of whether an issue with a product was the cause of an event.

hl7VS-relationalConjunction

Value Set of codes used with relational operator values to group more than one segment field name.

hl7VS-relationalOperator

Value Set of codes that define the relationship between HL7 segment field names identified in a query construct.

hl7VS-relationship

Concepts specifying an actual personal relationship that the next of kin/associated party has to a patient. Used in HL7 Version 2.x messaging in the NK1 segment.

hl7VS-relationshipModifier

Value Set of codes that an observation definition to describe the subject of an observation in relation to a patient.

hl7VS-relationshipType

Value Set of codes that specify the type of relationship that is established between the instances of Source Information and Target Information.

hl7VS-relevantClincialInformation

Value Set of codes that specify additional clinical information about the patient or specimen to report the supporting and/or suspected diagnosis and clinical findings on requests for interpreted diagnostic studies.

hl7VS-religion2

Value Set of codes that specify a person’s religion.

hl7VS-remoteControlCommand

Value Set of codes that identify the comment the component is to initiate.

hl7VS-reorderTheoryCodes

Value Set of codes that specify the calculation method used to determine the resupply schedule.

hl7VS-repeatPattern

Value Set of codes that specify the interval between repeated services. See the Comment/Usage Note in the table below, as the table contains both precoordinated codes that may be used in an HL7 field or component and also explanatory patterns i

hl7VS-reportPriority

Value Set of codes which specify the priority associated with a report or update run using a query.

hl7VS-reportSource

Value Set of codes that identify where a report sender learned about an event.

hl7VS-reportTiming

Value Set of codes that identify the time span of a report or the reason for a report sent to a regulatory agency.

hl7VS-reportTypeCode

Value Set of codes that identify the kind of patient document.

hl7VS-reportingPriority

Value Set of codes that specify the available priorities reporting the test results when the user is asked to specify the reporting priority independent of the processing priority.

hl7VS-responseFlag

Value Set of codes allowing the placer (sending) application to determine the amount of information to be returned from the filler.

hl7VS-responseLevel

Concepts specifying application response levels defined for a given Master File Message at the MFE segment level, and used for MFN-Master File Notification message. Specifies additional detail (beyond MSH-15 - Accept Acknowledgment Type and MSH-16 - Application Acknowledgment Type) for application-level acknowledgment paradigms for Master Files transactions.

hl7VS-responseModality

Value Set of codes identifying the timing and grouping of the response message(s).

hl7VS-resultStatus-Obr

Concepts which specify a status of results for an order. Used in HL7 Version 2.x messaging in the OBR segment.

hl7VS-revenueCode

Value Set of codes specifying a revenue code as specified in the National Uniform Billing Committee (NUBC) UB-04 manual, UB form locator 42, the service line revenue code. These are claim codes indicating the identifying number for the product or service provided. The UB-04 Data Specifications Manual with the codes is available by subscription from NUBC at http://www.nubc.org/become.html.

hl7VS-riskCodes

Value Set of codes that specify any known or suspected specimen hazards, e.g., exceptionally infectious agent or blood from a hepatitis patient.

hl7VS-riskManagementIncidentCode

Value Set of codes specifying the incident that occurred during a patient’s stay.

hl7VS-roleExecutingPhysician

Value Set of codes specifying the account role of the physician, for example, only billing for the professional part, the technical part or both.

hl7VS-roomType

Value Set of codes that specify the room type.

hl7VS-rootCause

Value Set of codes specifying a root cause.

hl7VS-route

Value Set of codes that are used to indicate a means of administrating a medication dose.

hl7VS-routeOfAdministration

Value Set of codes that specify the route of administration.

hl7VS-rulingAct

Value Set of codes that specify an act containing a rule that the item is legally required to be included in notification reporting.

hl7VS-rxComponentType

Value Set of codes that specify the RX component type.

hl7VS-schoolType

Value Set of codes that specify a categorization of an academic institution that grants a degree to a Staff Member.

hl7VS-securityCheckScheme

Value Set of codes specifying the scheme for a security check.

hl7VS-segmentActionCode

Concepts specifying actions to be applied for segments when an HL7 version 2 interface is operating in “action code mode” (a kind of update mode in the Standard).

hl7VS-segmentGroup

Value Set of codes that specify the optional segment groups which are to be included in a response.

hl7VS-sensitivityToCausativeAgentCode

Value Set of codes specifying the reason the patient should not be exposed to a substance.

hl7VS-sequenceCondition

Value Set of codes that identify whether sequence conditions or a repeating cycle of orders is defined, as part of the Order Sequence Definition.

hl7VS-sequenceConditionCode

Value Set of codes that specify the relationship between the start/end of the related service request(s) and the current service request.

hl7VS-sequenceResultsFlag

Value Set of codes that specify the sequencing relationship between the current service request and a related service request(s) specified in the same information model structure.

hl7VS-sequencing

Value Set of codes identifying how the field or parameter will be sorted and, if sorted, whether the sort will be case sensitive (the default) or not.

hl7VS-serviceRequestRelationship

Value Set of codes that specify an additional or alternate relationship between this service request and other service requests.

hl7VS-severityOfIllnessCode

Value Set of codes specifying the severity ranking of a patient’s illness.

hl7VS-shipmentStatus

Value Set of codes specifying the status of a shipment.

hl7VS-sideOfBody

Value Set of codes specifying the side of the body (“left” or “right”).

hl7VS-signatory'sRelationshipToSubject

Value Set of codes that specify the relationship of the consenter to the subject.

hl7VS-signatureCode

Concepts that indicate how a patient/subscriber authorization signature is obtained and how it is being retained by a provider.

hl7VS-siteAdministered

Value Set of codes that specify a location on the body where a dose is to be administered, e.g., IV, IM, Subcutaneous.

hl7VS-sourceOfComment

Concepts which are used to specify the source of a comment, as used in HL7 Version 2.x messaging in the NTE segment.

hl7VS-sourceOfSpecimen

Value Set of codes which specify sources for speciments for clinical testing. These concepts are used in HL7 Version 2.x messaging in the OBR segment prior to version 2.7, and was replaced by the concepts in table 0487 Specimen Type and table

hl7VS-specialHandlingConsiderations

Concepts describing how a specimen and/or container needs to be handled from the time of collection through the initiation of testing. Used in Version 2 messaging in the SPM segment.

hl7VS-specialProgramCode

Value Set of codes that record a health insurance program required for healthcare visit reimbursement.

hl7VS-specialtyType

Value Set of codes that identify the specialty of the care professional who is supported when using this location definition.

hl7VS-specimenAppropriateness

Value Set of codes that specify the suitability of the specimen for the particular planned use as determined by the filler.

hl7VS-specimenChildRole

Value Set of codes that specify for child specimens the relationship between this specimen and the parent specimen.

hl7VS-specimenCollectionMethod

Concepts to document procedures or processes by which a specimen may be collected. This is one of two code systems that are used instead of table 0070 (code system xxxx) which conflated specimen types and specimen collection methods. Used in Version 2 messaging in the SPM segment.

hl7VS-specimenComponent

Value Set of codes that identify the specimen component, e.g., supernatant, sediment, etc.

hl7VS-specimenCondition

Concepts of modes or states of being that describe the nature of a specimen. Used in Version 2 messaging in the SPM segment.

hl7VS-specimenQuality

Value Set of codes that specify the degree or grade of excellence of the specimen at receipt.

hl7VS-specimenRejectReason

Reasons a specimen may be rejected for a specified observation/result/analysis. Used in Version 2 messaging in the SPM segment.

hl7VS-specimenRole

Value Set of codes that identify the role of a sample.

hl7VS-specimenType

Concepts that describe the precise nature of an entity that may be used as the source material for an observation. This is one of two code systems that are used instead of table 0070 (code system xxxx) which conflated specimen types and specimen collection methods. Used in Version 2 messaging in the SPM segment.

hl7VS-startOfEvaluation

Value Set of codes that describes the status of product evaluation.

hl7VS-statusAdmission

Value Set of codes that specify the admission status for the diagnosis related group (DRG) determination.

hl7VS-statusPatient

Value Set of codes that specify whether the length of stay is normal or respectively shorter or longer than normal.

hl7VS-statusRespirationMinutes

Value Set of codes that specify the status of the use of the respiration minutes information for diagnosis related group (DRG) determination.

hl7VS-statusWeightAtBirth

Value Set of codes that specify the status of the use of the weight at birth for diagnosis related group (DRG) determination.

hl7VS-sterilizationType

Value Set of codes specifying the type of sterilization used for sterilizing the inventory supply item in the ITM segment.

hl7VS-stockLocation

Value Set of codes that specify a stock location.

hl7VS-studentStatus

Value Set of codes that designate whether a guarantor is a full or part time student.

hl7VS-substanceStatus

Value Set of codes identifying the status of the inventoried item. The status indicates the current status of the substance.

hl7VS-substanceType

Value Set of codes identifying the type of substance.

hl7VS-substitutionStatus

Value Set of codes that specify the substitution status.

hl7VS-subtypeOfReferencedData

A subset of the IANA media subtypes of binary data that are encoded in an ascii structure or stream.

hl7VS-supplierType

Value Set of codes specifying the type of supplier that will distribute the supply items associated to a contract number.

hl7VS-supplyRiskCodes

Value Set of codes specifying any known or suspected hazard associated with this material item.

hl7VS-systemInducedContaminants

Value Set of codes that identify the specimen contaminant identifier associated with the specimen in the container.

hl7VS-taxStatus

Value Set of codes used to specify the tax status of a provider.

hl7VS-telecommunicationEquipmentType

Concepts for specifying a type of telecommunication equipment.

hl7VS-telecommunicationExpirationReason

Value Set of codes specifying the reason this contact number/email was marked as “ended”.

hl7VS-telecommunicationUseCode

Concepts for specifying a specific use of a telecommunication number.

hl7VS-temperatureUnits

Value Set of codes specifying the units of transport temperature.

hl7VS-timeDelayPostChallenge

Value Set of codes that classify an observation definition as being a component of a challenge test.

hl7VS-timeSelectionCriteriaParameterClassCodes

Value Set of codes that describe acceptable start and end times, as well as days of the week, for appointment or resource scheduling.

hl7VS-tissueTypeCode

Value Set of codes that specify the type of tissue removed from a patient during a procedure.

hl7VS-tqConjunctionId

Value Set of codes that specify that a second timing specification is to follow using the repeat delimiter.

hl7VS-transactionType

Value Set of codes that specify a type of financial transaction.

hl7VS-transfusionAdverseReaction

Value Set of codes that specify the type of adverse reaction that the recipient of the blood product experienced.

hl7VS-transportArranged

Value Set of codes defining whether patient transportation preparations are in place.

hl7VS-transportationMode

Value Set of codes that specify how (or whether) to transport a patient, when applicable, for an ordered service.

hl7VS-trayType

Value Set of codes that specify the type of dietary tray.

hl7VS-treatment

Value Set of codes that identify the specimen treatment performed during lab processing.

hl7VS-triageCode

Value Set of codes specifying a patient’s prioritization within the context of this abstract.

hl7VS-typeOfAgreement

Concepts which specify codes to further identify an insurance plan.

hl7VS-typeOfData

Concepts declaring the general type of media data that is encoded.

hl7VS-universalIdType

Types of UID (Universal Identifiers).

hl7VS-userAuthenticationCredentialTypeCode

Value Set of codes that specify a type of user authentication credential.

hl7VS-valueType

Concepts which specify the data type of OBX-5, Observation Value, and are a subset of the datatypes defined in HL7 Version 2.x.

hl7VS-versionControlTable

Concepts which are used to identify an HL7 version in the Version 2.x family of published standards.

hl7VS-visitIndicator

Value Set of codes that specify the level on which data are being sent. It is the indicator used to send data at two levels, visit and account. HL7 recommends sending an “A” or no value when the data in the message are at the account level or “V” to i

hl7VS-visitPriorityCode

Value Set of codes that define a relative level of urgency applied to a patient visit.

hl7VS-visitUserCode

Value Set of codes that specify categories of a patient’s visit with respect to an individual institution’s needs, and is expected to be different on a site-specific basis.

hl7VS-volumeUnits

Value Set of codes of units of measure that are used to specify volume.

hl7VS-volumeUnits

Value Set of codes of units of measure that are used to specify volume.

hl7VS-weightUnits

Value Set of codes of units of measure that are used to specify weight.

hl7VS-weightUnits

Value Set of codes of units of measure that are used to specify weight.

hl7VS-whatSubjectFilter

Value Set of codes which specify the kind of information that is required to satisfy a query request. The values define the type of transaction inquiry.

hl7VS-whenToCharge

Value Set of codes that specify codes for an event precipitating/triggering a charge activity.

hl7VS-whichDate-timeQualifier

Value Set of codes that specify the type of date referred to in the other date fields in the QRF segment.

hl7VS-whichDate-timeStatusQualifier

Value Set of codes that specify the status type of objects selected in date range defined by QRF-2 and QRF-3.

hl7VS-yes-no-Indicator

Codes specifying either Yes or No used in fields containing binary answers generally user-specified.

immunizationForecastDate

Set of LOINC codes that identify the type of date that is specified within an immunization forecast step.

immunizationForecastStatusObservationValue

Represents the patient’s status with respect to their immunization guideline as of an evaluation date.

materialForm

A value representing the state (solid, liquid, gas) and nature of the material.

sequenceStatus

Codes providing the status of the variant test result.

v3 Code System ActCode

A code specifying the particular kind of Act that the Act-instance represents within its class. Constraints: The kind of Act (e.g. physical examination, serum potassium, inpatient encounter, charge financial transaction, etc.) is specified with a code from one of several, typically external, coding systems. The coding system will depend on the class of Act, such as LOINC for observations, etc. Conceptually, the Act.code must be a specialization of the Act.classCode. This is why the structure of ActClass domain should be reflected in the superstructure of the ActCode domain and then individual codes or externally referenced vocabularies subordinated under these domains that reflect the ActClass structure. Act.classCode and Act.code are not modifiers of each other but the Act.code concept should really imply the Act.classCode concept. For a negative example, it is not appropriate to use an Act.code “potassium” together with and Act.classCode for “laboratory observation” to somehow mean “potassium laboratory observation” and then use the same Act.code for “potassium” together with Act.classCode for “medication” to mean “substitution of potassium”. This mutually modifying use of Act.code and Act.classCode is not permitted.

v3 Code System ActReason

A set of codes specifying the motivation, cause, or rationale of an Act, when such rationale is not reasonably represented as an ActRelationship of type “has reason” linking to another Act. Examples: Example reasons that might qualify for being coded in this field might be: “routine requirement”, “infectious disease reporting requirement”, “on patient request”, “required by law”.

v3 Code System RoleCode

A set of codes further specifying the kind of Role; specific classification codes for further qualifying RoleClass codes.

v3 Value Set ActSite

An anatomical location on an organism which can be the focus of an act.

workClassificationODH

A person’s employment type as defined by compensation and sector (e.g. paid vs. unpaid, self-employed vs. not self-employed, government vs. private, etc.).

x_AccommodationRequestorRole

No description

x_ActBillableCode

No description

x_ActClassCareProvisionEncounter

Definition: When identifying the “request” that resulted in an encounter, there is a need to distinguish whether the “request” was a general referral (CareProvisionRequest) or a more specific ordered or scheduled encounter (PatientEncounter).

x_ActClassCareProvisionObservation

No description

x_ActClassCareProvisionProcedure

No description

x_ActClassDocumentEntryAct

The set of Act class codes allowed for the ACT class clone in the CDA Clinical Statement model. The scope of this value set are those Act class codes not otherwise covered by specific classes in the CDA Clinical Statement model and required to enable representation of Clinical Statement in CDA.

x_ActClassDocumentEntryOrganizer

No description

x_ActEncounterReason

Administrative reasons for patient encounters. Example:Medical necessity, patient request and dependency.

x_ActFinancialProductAcquisitionCode

The method that a product is obtained for use by the subject of the supply act (e.g. patient), with financial compensation. Product examples are consumable or durable goods.

x_ActInvoiceDetailPharmacyCode

The billable codes selected for use for Pharmacy Invoices. Steward is Financial Management.

x_ActInvoiceDetailPreferredAccommodationCode

The billable codes selected for use for Preferred Accommodation Invoices. Steward is Financial Management.

x_ActMoodCompletionCriterion

Description:These are moods describing activities as they progress in the business cycle, from defined, through planned and ordered to completed, and any applicable criterion or condition over actual and potential services that must apply for an associated service to be considered.

x_ActMoodDefEvn

A grouping of Definition, Event. These specific moods are used in control wrapper override acts. The domain is restricted to acts that are possible to occur or have already occurred.

x_ActMoodDefEvnRqo

No description

x_ActMoodDefEvnRqoPrmsPrp

No description

x_ActMoodDocumentObservation

Used to enumerate the moods that an observation can take within the body of a clinical document.

x_ActMoodEvnOrdPrmsPrp

No description

x_ActMoodIntentEvent

A constraint domain for RMIM design.

x_ActMoodOrdPrms

A grouping of Order, Promise. These specific moods are used in orders.

x_ActMoodOrdPrmsEvn

A grouping of Order, Promise and Event moods.

x_ActMoodPermPermrq

Enumerates the moods that an Act can take when describing privileges.

x_ActMoodRequestEvent

No description

x_ActMoodRqoPrpAptArq

No description

x_ActOrderableOrBillable

No description

x_ActRelationshipDocument

Used to enumerate the relationships between two clinical documents for document management.

x_ActRelationshipDocumentSPL

No description

x_ActRelationshipEntry

Used to enumerate the relationships between a CDA section and its contained entries.

x_ActRelationshipEntryRelationship

Used to enumerate the relationships between two CDA entries.

x_ActRelationshipExternalReference

Used to enumerate the relationships between a CDA entry and an externally referenced act.

x_ActRelationshipPatientTransport

Relates a patient encounter act (source) to the transportation act (target) representing the patient”s arrival at or departure from the site of a patient encounter.

x_ActRelationshipPertinentInfo

No description

x_ActRelationshipRelatedAuthorizations

No description

x_ActReplaceOrRevise

No description

x_ActStatusActiveComplete

No description

x_ActStatusActiveSuspended

No description

x_ActStatusPrevious

Description:Cancelled, nullified and obsolete .

x_AdministeredSubstance

A type of Manufactured Material that is administered to a living subject, either by a healthcare professional or auto-administered, within a healthcare context.

x_AdverseEventCausalityAssessmentMethods

Value set provides methods used to assess the causality of adverse events. New codes should not be added to the domain without first checking with its steward - the Regulated Clinical Research Information Management (RCRIM) technical committee.

x_BasicConfidentialityKind

Description: Used to enumerate the typical confidentiality constraints placed upon a clinical document. Usage Note:x_BasicConfidentialityKind is a subset of Confidentiality codes that are used as metadata indicating the receiver responsibility to comply with normally applicable jurisdictional privacy law or disclosure authorization; that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject; or that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject.

x_BillableProduct

Description:The billable codes selected for Clinical Product Invoices. Steward is Financial Management.

x_ClinicalStatementActMood

No description

x_ClinicalStatementEncounterMood

No description

x_ClinicalStatementExposureMood

No description

x_ClinicalStatementObservationMood

No description

x_ClinicalStatementProcedureMood

No description

x_ClinicalStatementSubstanceMood

No description

x_ClinicalStatementSupplyMood

No description

x_DeterminerInstanceKind

No description

x_DocumentActMood

Used to enumerate the moods that an act can take within the body of a clinical document.

x_DocumentEncounterMood

Used to enumerate the moods that an encounter can take within the body of a clinical document.

x_DocumentEntrySubject

Used to represent the role(s) of those who can serve as subjects of the contents of a clinical document.

x_DocumentProcedureMood

Used to enumerate the moods that a procedure can take within the body of a clinical document.

x_DocumentStatus

Status of a clinical document.

x_DocumentSubject

No description

x_DocumentSubstanceMood

Used to enumerate the moods that a substance administration can take within the body of a clinical document.

x_EncounterAdmissionUrgency

The urgency for starting a patient encounter. Example:Routine, urgent, emergency, and elective.

x_EncounterParticipant

Clones using this x_domain should have a name “encounterParticipant”.

x_EncounterPerformerParticipation

Used to enumerate the ways in which a clinician can directly participate during an encounter which generates a clinical document.

x_EntityClassDocumentReceiving

No description

x_EntityClassPersonOrOrgReceiving

No description

x_InformationRecipient

Used to represent participant(s) who should receive a copy of a document.

x_InformationRecipientRole

Used to represent the role(s) of those who should receive a copy of a document.

x_LabProcessClassCodes

No description

x_MedicationOrImmunization

No description

x_Medicine

A type of Administered Substance that is manufactured from raw organic or inorganic ingredients and used in the course of a patient’s therapy.

x_OrganizationNamePartType

A name for an organization, such as “Health Level Seven, Inc.” An organization name consists only of untyped name parts, prefixes, suffixes, and delimiters.

x_ParticipationAuthorPerformer

One who initiates the control act event, either as its author or its physical performer.

x_ParticipationEntVrf

A person that contributed to recording or validating the act.

x_ParticipationPrfEntVrf

A person that performed, contributed in recording or validating the act.

x_ParticipationVrfRespSprfWit

One who oversees a control act event. Includes either a type of accountability, as in responsible party, verifier (and its children) and witness; or being an assistant to the control act event, as in secondary performer.

x_PayeeRelationshipRoleType

The specification of the relationship to the covered party of the payee in the case when an insurer is not directly paying the healthcare provider (as payee) but reimbursing the party that did pay them.

x_PersonNamePartType

No description

x_PhoneOrEmailURLScheme

Restricts scheme to e-mail or phone numbers at which a human can be reached

x_PhoneURLScheme

Restricts scheme to phone numbers at which a human can be reached

x_PhysicalVerbalParticipationMode

Restricts participation to either physical or verbal

x_RoleClassAccommodationRequestor

The requestor for the accommodation. Steward is Financial Management Technical Committee

x_RoleClassCoverage

An abstract domain that encompasses the roles that arise in the context of providing, purchasing, and managing health care coverage and insurance.

x_RoleClassCoverageInvoice

An abstract domain that encompasses the roles involved in submitting, responding to and managing invoices or claims for health care coverage.

x_RoleClassCredentialedEntity

A role played by an entity that receives credentials from the scoping entity.

x_RoleClassPayeePolicyRelationship

The specification of the relationship of the Payee to the invoice. Can be used in cases when an insurer is not directly paying the healthcare provider (as payee) but reimbursing the party that paid the invoice/claim.

x_SUCC_REPL_PREV

No description

x_ServiceEventPerformer

Clones using this x_domain should have a name “performer”.

x_SubstitutionConditionNoneOrUnconditional

Restricts substitution to effectively a yes/no decision

x_VeryBasicConfidentialityKind

Description:Limits confidentiality to effectively a yes/no decision. Usage Note:x_VeryBasicConfidentialityKind is a subset of Confidentiality codes that are used as metadata indicating the receiver responsibility to comply with normally applicable jurisdictional privacy law or disclosure authorization or that the receiver may not disclose this information except as directed by the information custodian, who may be the information subject.

Terminology: Code Systems

These define new code systems used by systems conforming to this implementation guide.

ABCcodes

Five character alphabetic codes fit into current claims processing software or onto standard paper claim forms. ABC Codes give business parity to licensed CAM and nurse providers who file claims to insurance companies. .

ADA Universal Tooth Designation System

The American Dental Association (ADA) accepted the Universal/National Tooth Designation System and the ISO/ANSI/ADA Specification No. 3950 for Designation System for Teeth and Areas of the Oral Cavity as the human tooth and oral cavity enumeration schemas in 1994. The universal tooth designation or numbering system is accepted and approved by the ADA and is the most commonly used system used by dental professionals in America. Teeth are numbered 1-32, starting with the third molar (1) on the right side of the upper arch, following around the arch to the third molar (16) on the left side, and descending to the lower third molar (17) on the left side, and following that arch to the terminus of the lower jaw, the lower right third molar (32). Supernumerary teeth are identified by the numbers 51 through 82, beginning with the area of the upper right third molar, following around the upper arch and continuing on the lower arch to the area of the lower right third molar (e.g., supernumerary #51 is adjacent to the upper right molar #1; supernumerary #82 is adjacent to the lower right third molar #32). The Universal Numbering System can be found in the ADA Dental Claim Form. For more information see here: https://www.ada.org/publications/cdt/ada-dental-claim-form. A Statement of Understanding (SOU) between ADA and HL7 exists here: http://www.hl7.org/documentcenter/public/mou/ADA%20HL7%20SOU%202021_signed.pdf

AHA NUBC Patient Discharge Status Codes

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 17 - Patient Discharge Status These codes are used to convey the patient discharge status and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

AHA NUBC Point of Origin for Newborn

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 15 - Point of Origin for Admission or Visit for Newborn These codes are used to convey the patient point of origin for an admission or visit and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

AHA NUBC Point of Origin for Non-newborn

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 15 - Point of Origin for Admission or Visit for Non-newborn These codes are used to convey the patient point of origin for an admission or visit and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

AHA NUBC Priority (Type) of Admission or Visit

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 14 - Priority (Type) of Admission or Visit These codes are used to convey the priority of an admission or visit and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

AHA NUBC Revenue Codes

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 42 - Revenue Codes These codes are used to convey the revenue code and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

AHA NUBC Type Of Bill Codes

The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified. This code system consists of the following: * FL 04 - Type of Bill Facility Codes * FL 04 - Type of Bill Frequency Codes A code indicating the specific Type of Bill (TOB), e.g., hospital inpatient, outpatient, replacements, voids, etc. The first digit is a leading zero*. The fourth digit defines the frequency of the bill for the institutional and electronic professional claim. Note that with the advent of UB-04, the matrix methodology of constructing the first component of TOB codes according to digit position was abandoned in favor of specifying valid discrete codes. As a result, the first three digits in TOB have no underlying meaning. To obtain the underlying code systems, please see information here The UB-04 Manual has a 12-month subscription period from June 30 through July 1.

AHFS Pharmacologic-Therapeutic Classification

Description: The AHFS Pharmacologic-Therapeutic Classification has been in use in hospitals in the United States since its inception in 1959. An integral part of the American Hospital Formulary Service, the AHFS classification allows the grouping of drugs with similar pharmacologic, therapeutic, and/or chemical characteristics. Today, the AHFS classification is used by many people outside of hospitals.

AS4 Neurophysiology Codes

AS4 Neurophysiology Codes

ASTM E1238/ E1467 Universal

ASTM E1238/ E1467 Universal

AcknowledgementCondition

The codes identify the conditions under which accept acknowledgements are required to be returned in response to this message. Note that accept acknowledgement address two different issues at the same time: reliable transport as well as syntactical correctness

AcknowledgementDetailCode

OpenIssue:Missing description.

AcknowledgementDetailType

A code identifying the specific message to be provided. Discussion: A textual value may be specified as the print name, or for non-coded messages, as the original text. Examples: ‘Required attribute xxx is missing’, ‘System will be unavailable March 19 from 0100 to 0300’

AcknowledgementType

This attribute contains an acknowledgement code as described in the HL7 message processing rules. OpenIssue: Description was copied from attribute and needs to be improved to be appropriate for a code system.

ActClass

A code specifying the major type of Act that this Act-instance represents. Constraints: The classCode domain is a tightly controlled vocabulary, not an external or user-defined vocabulary. Every Act-instance must have a classCode. If the act class is not further specified, the most general Act.classCode (ACT) is used. The Act.classCode must be a generalization of the specific Act concept (e.g., as expressed in Act.code), in other words, the Act concepts conveyed in an Act must be specializations of the Act.classCode. Especially, Act.code is not a “modifier” that can alter the meaning of a class code. (See Act.code for contrast.)

ActCode

A code specifying the particular kind of Act that the Act-instance represents within its class. Constraints: The kind of Act (e.g. physical examination, serum potassium, inpatient encounter, charge financial transaction, etc.) is specified with a code from one of several, typically external, coding systems. The coding system will depend on the class of Act, such as LOINC for observations, etc. Conceptually, the Act.code must be a specialization of the Act.classCode. This is why the structure of ActClass domain should be reflected in the superstructure of the ActCode domain and then individual codes or externally referenced vocabularies subordinated under these domains that reflect the ActClass structure. Act.classCode and Act.code are not modifiers of each other but the Act.code concept should really imply the Act.classCode concept. For a negative example, it is not appropriate to use an Act.code “potassium” together with and Act.classCode for “laboratory observation” to somehow mean “potassium laboratory observation” and then use the same Act.code for “potassium” together with Act.classCode for “medication” to mean “substitution of potassium”. This mutually modifying use of Act.code and Act.classCode is not permitted.

ActExposureLevelCode

A qualitative measure of the degree of exposure to the causative agent. This includes concepts such as “low”, “medium” and “high”. This quantifies how the quantity that was available to be administered to the target differs from typical or background levels of the substance.

ActInvoiceElementModifier

Processing consideration and clarification codes.

ActMood

OpenIssue: In Ballot 2009May, a strong Negative vote was lodged against several of the concept definitions in the vocabulary used for Act.moodCode. The vote was found “Persuasive With Mod”, with the understanding that M and M would undertake a detailed review of these concept definitions for a future release of the RIM.

ActPriority

A set of codes (e.g., for routine, emergency), specifying the urgency under which the Act happened, can happen, is happening, is intended to happen, or is requested/demanded to happen.

ActReason

A set of codes specifying the motivation, cause, or rationale of an Act, when such rationale is not reasonably represented as an ActRelationship of type “has reason” linking to another Act. Examples: Example reasons that might qualify for being coded in this field might be: “routine requirement”, “infectious disease reporting requirement”, “on patient request”, “required by law”.

ActRelationshipCheckpoint

A code specifying when in the course of an Act a precondition for the Act is evaluated (e.g., before the Act starts for the first time, before every repetition, after each repetition but not before the first, or throughout the entire time of the Act.) Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Before each step is executed and has preconditions these conditions are tested and if the test is positive, the Act has clearance for execution. The repeatNumber may indicate that an Act may be repeatedly executed. The checkpointCode is specifies when the precondition is checked and is analogous to the various conditional statements and loop constructs in programming languages “while-do” vs. “do-while” or “repeat-until” vs. “loop-exit”. For all checkpointCodes, except “end”, preconditions are being checked at the time when the preceding step of the plan has terminated and this step would be next in the sequence established by the sequenceNumber attribute. When the checkpointCode for a criterion of a repeatable Act is “end”, the criterion is tested only at the end of each repetition of that Act. When the condition holds true, the next repetition is ready for execution. When the checkpointCode is “entry” the criterion is checked at the beginning of each repetition (if any) whereas “beginning” means the criterion is checked only once before the repetition “loop” starts. The checkpointCode “through” is special in that it requires the condition to hold throughout the execution of the Act, even throughout a single execution. As soon as the condition turns false, the Act should receive an interrupt event (see interruptibleInd) and will eventually terminate. The checkpointCode “exit” is only used on a special plan step that represents a loop exit step. This allows an action plan to exit due to a condition tested inside the execution of this plan. Such exit criteria are sequenced with the other plan components using the ActRelationship.sequenceNumber.

ActRelationshipJoin

A code specifying how concurrent Acts are resynchronized in a parallel branch construct. Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Branches exist when multiple components have the same sequenceNumber. Branches are parallel if the splitCode specifies that more than one branch can be executed at the same time. The joinCode then specifies if and how the braches are resynchronized. The principal re-synchronization actions are (1) the control flow waits for a branch to terminate (wait-branch), (2) the branch that is not yet terminated is aborted (kill-branch), (3) the branch is not re-synchronized at all and continues in parallel (detached branch). A kill branch is only executed if there is at least one active wait (or exclusive wait) branch. If there is no other wait branch active, a kill branch is not started at all (rather than being aborted shortly after it is started.) Since a detached branch is unrelated to all other branches, active detached branches do not protect a kill-branch from being aborted.

ActRelationshipSplit

A code specifying how branches in an action plan are selected among other branches. Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Branches exist when multiple components have the same sequenceNumber. The splitCode specifies whether a branch is executed exclusively (case-switch) or inclusively, i.e., in parallel with other branches. In addition to exlusive and inclusive split the splitCode specifies how the pre-condition (also known as “guard conditions” on the branch) are evaluated. A guard condition may be evaluated once when the branching step is entered and if the conditions do not hold at that time, the branch is abandoned. Conversely execution of a branch may wait until the guard condition turns true. In exclusive wait branches, the first branch whose guard conditions turn true will be executed and all other branches abandoned. In inclusive wait branches some branches may already be executed while other branches still wait for their guard conditions to turn true.

ActRelationshipSubset

<ns1:p>Used to indicate that the target of the relationship will be a filtered subset of the total related set of targets.</ns1:p><ns1:p>Used when there is a need to limit the number of components to the first, the last, the next, the total, the average or some other filtered or calculated subset.</ns1:p>

ActRelationshipType

The source is an excerpt from the target.

ActSite

An anatomical location on an organism which can be the focus of an act.

ActStatus

Codes representing the defined possible states of an Act, as defined by the Act class state machine.

ActUSPrivacyLaw

A jurisdictional mandate in the US relating to privacy. Deprecation Comment: Content moved to ActCode under _ActPrivacyLaw; use that instead.

ActUncertainty

OpenIssue: Missing Description

ActionType

The type of action to be performed.

Active Ingredient Code

Foreign key for the Active Ingredient Table that relates active ingredients to specific products. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/drug-products/drug-product-database/read-file-drug-product-database-data-extract.html

Active Ingredient Group Code

Part of the active ingredient code number starting at position 3 and ending at position 7. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/drug-products/drug-product-database/terminology.html

Active Ingredient Group Number

The AIG number is a 10 digit number that identifies products that have the same active ingredient(s) and ingredient strength(s). The AIG is comprised of three portions:

  • the first portion (2 digits) identifies the number of active ingredients
  • the second portion(5 digits) identifies the unique groups of active ingredients(s);
  • the last portion (3 digits) identifies the active ingredient group strength. The strength group has a tolerance of -2% to +10%. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/drug-products/drug-product-database/terminology.html
ActivityDefinitionCategory

High-level categorization of the type of activity.

AddressPartType

Description: Code that specifies whether an address part names the street, city, country, postal code, post box, etc. Discussion: The hierarchical nature of these concepts shows composition. E.g. “Street Name” is part of “Street Address Line”

AddressUse

Codes that provide guidance around the circumstances in which a given address should be used.

Adjudication Error Codes

This value set includes a smattering of adjudication codes.

Adjudication Reason Codes

This value set includes smattering of Adjudication Reason codes.

Adjudication Value Codes

This value set includes a smattering of Adjudication Value codes which includes codes to indicate the amounts eligible under the plan, the amount of benefit, copays etc.

AdministrativeGender

The gender of a person used for adminstrative purposes (as opposed to clinical gender)

Admit source

This value set defines a set of codes that can be used to indicate from where the patient came in.

AdverseEventCategory

Overall categorization of the event, e.g. product-related or situational.

AdverseEventCausalityAssessment

Codes for the assessment of whether the entity caused the event.

AdverseEventCausalityMethod

TODO.

AdverseEventSeriousness

Overall seriousness of this event for the patient.

AdverseEventSeverity

The severity of the adverse event itself, in direct relation to the subject.

All Patient Diagnosis Related Groups (AP DRGs)

In 1987, the state of New York passed legislation instituting a DRG-based prospective payment system for all non-Medicare patients. The legislation included a requirement that the New York State Department of Health (NYDH) evaluate the applicability of the DRGs to a non-Medicare population. In particular, the legislation required that the DRGs be evaluated with respect to neonates and patients with Human Immunodeficiency Virus (HIV) infections. NYDH entered into an agreement with 3M HIS to assist with the evaluation of the need for DRG modifications as well as to make the necessary changes in the DRG definitions and software. The DRG definitions developed by NYDH and 3M HIS are referred to as the All Patient DRGs (AP DRGs).

All Patient Refined Diagnosis Related Groups (APR DRGs)

3M APR DRGs have become the standard across the U.S. for classifying hospital inpatients in non-Medicare populations. As of January 2019, 27 state Medicaid programs use 3M APR DRGs to pay hospitals, as do approximately a dozen commercial payers and Medicaid managed care organizations. Over 2,400 hospitals have licensed 3M APR DRGs to verify payment and analyze their internal operations. The 3M APR DRG methodology classifies hospital inpatients according to their reason for admission, severity of illness and risk of mortality. Each year 3M calculates and releases a set of statistics for each 3M APR DRG based on our analysis of large national data sets. These statistics include a relative weight for each 3M APR DRG. The relative weight reflects the average hospital resource use for a patient in that 3M APR DRG relative to the average hospital resource use of all inpatients. Please note that payers and other users of the 3M APR DRG methodology are responsible for ensuring that they use relative weights that are appropriate for their particular populations. The 3M APR DRG statistics also include data for each 3M APR DRG on relative frequency, average length of stay, average charges and incidence of mortality. 3M APR DRGs can be rolled up into broader categories. The 326 base DRGs roll up into 25 major diagnostic categories (MDCs) plus a pre-MDC category. An example is MDC 04, Diseases and Disorders of the Respiratory System. As well, each 3M APR DRG is assigned to a service line that is consistent with the outpatient service lines that are defined by the 3M™ Enhanced Ambulatory Patient Groups (EAPGs).

AllergyIntolerance Clinical Status Codes

Preferred value set for AllergyIntolerance Clinical Status.

AllergyIntolerance Verification Status

The verification status to support or decline the clinical status of the allergy or intolerance.

AllergyIntoleranceCertainty

Statement about the degree of clinical certainty that a specific substance was the cause of the manifestation in a reaction event.

AllergyIntoleranceSubstanceExposureRisk

The risk of an adverse reaction (allergy or intolerance) for this patient upon exposure to the substance (including pharmaceutical products).

AlternativeCodeKind

Indicates the type of use for which the code is defined.

AlternativeCodeKind

Indicates the type of use for which the code is defined.

American College of Radiology finding codes

American College of Radiology finding codes

American Dental Association Area of Oral Cavity System

The Area of Oral Cavity System is accepted and approved by the ADA and is the most commonly used system used by dental professionals in America. Area of the oral cavity is designated by a two-digit code. The Area of Oral Cavity System can be found in the ADA Comprehensive ADA Dental Claim Form Completion Instructions (see https://www.ada.org/-/media/project/ada-organization/ada/ada-org/files/publications/cdt/v2019adadentalclaimcompletioninstructions_v3_2022feb.pdf). For more information see here: https://www.ada.org/publications/cdt/ada-dental-claim-form. A Statement of Understanding (SOU) between ADA and HL7 exists here: http://www.hl7.org/documentcenter/public/mou/ADA%20HL7%20SOU%202021_signed.pdf

AmericanIndianAlaskaNativeLanguages

American Indian and Alaska Native languages currently being used in the United States.

Appointment cancellation reason

This example value set defines a set of reasons for the cancellation of an appointment.

Appropriateness Score

The scoring for appropriateness of an action based upon RAND.

Artifact Identifier Type Codes

Identifier types for an artifact (e.g. version-independent, version-specific, short-name, endorser, publisher)

Artifact Version Policy Codes

The versioning policy of an artifact (metadata, strict)

Audit Event ID

Event Types for Audit Events - defined by DICOM with some FHIR specific additions.

Audit Event Source Type

The type of process where the audit event originated from.

Audit event entity type

Code for the entity type involved in the audit event.

AuditEventEntityRole

Code representing the role the entity played in the audit event.

AuditEventOutcome

Indicates whether the event succeeded or failed.

Basic Resource Types

This value set defines codes for resources not yet supported by (or which will never be supported by) FHIR. Many of the codes listed here will eventually be turned into official resources. However, there is no guarantee that any particular resource will be created nor that the scope will be exactly as defined by the codes presented here. Codes in this set will be deprecated if/when formal resources are defined that encompass these concepts.

Benefit Category Codes

This value set includes examples of Benefit Category codes.

Benefit Term Codes

This value set includes a smattering of Benefit Term codes.

Benefit Type Codes

This value set includes a smattering of Benefit type codes.

Benefit cost applicability

Whether the cost applies to in-network or out-of-network providers.

Brazilian Procedure Codes SUS

Brazilian Procedure Codes used in the National Health System

CAMNCVS

CAM & Nursing Coding Vocabulary Set

CAN/CSA-Z795-96

Inactive since 2015. Nature of injury (NOI) codes, which are part of the Work Injury or Disease Information coding system (CAN/CSA-Z795-96 - R2003). The CSA code set includes 3 parts: Nature of injury (NOI), body part (BP), side of body (SB). For example:

  • NOI - Cut or laceration Injury = 03400
  • BP - Upper Arm body part = 31100
  • SOB - Left Side of Body = L The Body Part codes are qualified by the Side of Body codes code system, to be more precise in specifying the location of the injury being coded. Code set is maintained by the Canadian Standards Association (CSA). set is maintained by the Canadian Standards Association (CSA). The Canadian Standards Association 5060 Spectrum Way Mississauga, Ontario Canada L4W 5N6 Phone: (416) 747-4000 1-800-463-6727 Fax: (416) 747-2473
CDA_RUS

Coding system intended for use in the Russian clinical documents

CDC Analyte Codes

CDC Analyte Codes

CDC Local Coding System

“CDC Public Health Information Network local coding system used for creating the concepts that are not available in the Standard Development Organization (SDO) Vocabulary like SNOMED CT, LOINC, ICD-9, etc.” Versioning numbered according to PHIN VADS convention. For more information, see https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.114222.4.5.274.

CDC Methods/Instruments Codes

CDC Methods/Instruments Codes

CDC Race and Ethnicity

The U.S. Centers for Disease Control and Prevention (CDC) has prepared a code set for use in coding race and ethnicity data. This code set is based on current federal standards for classifying data on race and ethnicity, specifically the minimum race and ethnicity categories defined by the U.S. Office of Management and Budget (OMB) and a more detailed set of race and ethnicity categories maintained by the U.S. Bureau of the Census (BC). The main purpose of the code set is to facilitate use of federal standards for classifying data on race and ethnicity when these data are exchanged, stored, retrieved, or analyzed in electronic form. At the same time, the code set can be applied to paper-based record systems to the extent that these systems are used to collect, maintain, and report data on race and ethnicity in accordance with current federal standards. The content is available at https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238#.

CDC Surveillance

CDC Surveillance

CDS Hooks Indicator

This codesystem captures the indicator codes defined by the CDS Hooks specification. The indicator is included as an element of the cards in a CDS Hooks response and conveys the urgency and/or importance of the information in each card. See Card Attributes in the CDS Hooks specification for more information. Note - the CodeSystem is transitioning from the Vocabulary Work Group to Clinical Decision Support (CDS) Work Group.

CDT-2 Codes

American Dental Association’s Current Dental Terminology 2 (CDT-2) codes.

CEN ECG diagnostic codes

CEN ECG diagnostic codes

CLIP

CLIP

CMS Hierarchical Condition Categories

The CMS-HCC model uses more than 9,000 ICD-10-CM codes, which are mapped to condition categories that predict costs well. The condition categories are based on diagnoses clinically related to one another and with similar predicted cost implications. Hierarchies are imposed on the condition categories to capture the most costly diagnoses. Hierarchy logic is imposed on certain condition categories to account for different hierarchical costs, thus, the term Hierarchical Condition Category, or HCC. For more information, see https://www.cms.gov/Medicare/Health-Plans/MedicareAdvtgSpecRateStats/Risk-Adjustors. The CMS HCCs are in the public domain and are free to use without restriction.

CMS Place of Service Codes (POS)

Place of Service Codes are two-digit codes placed on health care professional claims to indicate the setting in which a service was provided. The Centers for Medicare & Medicaid Services (CMS) maintain POS codes used throughout the health care industry. This code set is required for use in the implementation guide adopted as the national standard for electronic transmission of professional health care claims under the provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA). HIPAA directed the Secretary of HHS to adopt national standards for electronic transactions. These standard transactions require all health plans and providers to use standard code sets to populate data elements in each transaction. The Transaction and Code Set Rule adopted the ASC X12N-837 Health Care Claim: Professional, volumes 1 and 2, as the standard for electronic submission of professional claims. This standard names the POS code set currently maintained by CMS as the code set to be used for describing sites of service in such claims. POS information is often needed to determine the acceptability of direct billing of Medicare, Medicaid and private insurance services provided by a given provider.

CMS Prescription Drug Hierarchical Condition Categories

Starting in 2006, with the implementation of the Part D program, CMS introduced a second major HCC-based risk adjustment model. Created with the passage of the Medicare Modernization Act (MMA) of 2003, the Medicare Part D Prescription Drug benefit became the second major Medicare capitated payment system. CMS developed the Part D RxHCC risk adjustment model to apply to monthly capitated payments to both Medicare Advantage (MA-PDs) and standalone prescription drug plans (PDPs). The Part D RxHCC risk adjustment model implemented in 2006 was developed using a structure similar to the CMS-HCC model, in that it included demographic and diagnosis information clustered into hierarchical condition categories. CMS obtains diagnoses for all Medicare beneficiaries from either fee-for-service claims or Medicare Advantage reporting. In 2011, CMS implemented an updated Part D RxHCC risk adjustment model, incorporating program data derived from prescription drug event (PDE) data. The data used to calibrate this updated model was more recent cost and utilization data, resulting in a model that reflects more recent drug cost and utilization patterns. For more information, see: https://www.cms.gov/Medicare/Health-Plans/MedicareAdvtgSpecRateStats/Risk-Adjustors The CMS RxHCCs are in the public domain and are free to use without restriction.

CMS Present on Admission (POA) Indicator

This code system consists of Present on Admission (POA) indicators which are assigned to the principal and secondary diagnoses (as defined in Section II of the Official Guidelines for Coding and Reporting) and the external cause of injury codes to indicate the presence or absence of the diagnosis at the time of inpatient admission.

COSTART

COSTART

CPT-5

CPT-5

CQL Access Modifier

Access modifiers defined by the Clinical Quality Language (CQL) specification in the Access Modifiers topic.

Calendar

Code system for specifying a type of calendar

Calendar Cycle Codes

Calendar cycle identifiers

CalendarType

Code system for specifying a type of calendar

Can-push-updates

Ability of the primary source to push updates/alerts

Canadian Classification of Health Interventions

CCI (Canadian Classification of Health Interventions) was developed by CIHI to accompany ICD-10-CA. It was designed to be service-provider and service-setting neutral and can be used comprehensively throughout Canada’s health systems. CCI classifies a broad range of interventions including therapeutic and diagnostic interventions and other health care interventions, such as assistance with activities of daily living, environmental assessments and counselling.

Canadian Clinical Drug Data Set

The Canadian Clinical Drug Data Set provides codes for identification and a consistent approach to naming of medications and some medical devices in Canada. It has been designed and developed to reflect current clinical practice and safety advice and is freely available for use in digital health solutions and design applications. CCDD is available in English and Canadian French, and published on Terminology Gateway by Canada Health Infoway. To request content changes, send an email to clinicaldrug@infoway-inforoute.ca

CatalogType

The type of catalog.

CharacteristicMethod

The method used to determine the characteristic(s) of the variable.

ChargeItemCode

Example set of codes that can be used for billing purposes.

Charset

Internet Assigned Numbers Authority (IANA) Charset Types

Chemical abstract codes

Chemical abstract codes

ChoiceListOrientation

Direction in which lists of possible answers should be displayed.

Chronic Illness and Disability Payment System (CDPS)

“The Chronic Illness and Disability Payment System (CDPS) is a diagnostic-based risk adjustment model that is widely used to adjust capitated payments for health plans that enroll Medicaid beneficiaries. CDPS uses International Classification of Disease (ICD) codes to assign CDPS Categories that indicate illness burden related to major body systems (e.g. cardiovascular) or types of chronic disease (e.g. diabetes). Within each major category is a hierarchy reflecting both the clinical severity of the condition and its expected effect on future costs. Each of the hierarchical CDPS Categories is assigned a CDPS weight. CDPS weights are additive across major categories.” “The CDPS model was developed in 2000 using data from seven Fee-for-Service (FFS) Medicaid programs. The model received major updates in 2009 (using national FFS Medicaid data from 2002-2005) and in 2014 (using additional national FFS Medicaid data from 2011). CDPS has also received regular annual updates to include the most recent ICD and NDC codes.” For more information, please visit https://hwsph.ucsd.edu/research/programs-groups/cdps.html.

Claim Care Team Role Codes

Claim roles of the care team members providing products and services.

Claim Information Category Codes

This value set includes sample Information Category codes.

Claim Type Codes

This value set includes Claim Type codes.

ClaimPayeeResourceType

The type of Claim payee Resource.

ClinVar Variant ID

ClinVar is a freely accessible, public archive of reports of the relationships among human variations and phenotypes, with supporting evidence. ClinVar thus facilitates access to and communication about the relationships asserted between human variation and observed health status, and the history of that interpretation. ClinVar processes submissions reporting variants found in patient samples, assertions made regarding their clinical significance, information about the submitter, and other supporting data. The alleles described in submissions are mapped to reference sequences, and reported according to the HGVS standard. ClinVar then presents the data for interactive users as well as those wishing to use ClinVar in daily workflows and other local applications. ClinVar works in collaboration with interested organizations to meet the needs of the medical genetics community as efficiently and effectively as possible. Read more about using ClinVar. ClinVar supports submissions of differing levels of complexity. The submission may be as simple as a representation of an allele and its interpretation (sometimes termed a variant-level submission), or as detailed as providing multiple types of structured observational (case-level) or experimental evidence about the effect of the variation on phenotype. A major goal is to support computational (re)evaluation, both of genotypes and assertions, and to enable the ongoing evolution and development of knowledge regarding variations and associated phenotypes. ClinVar is an active partner of the ClinGen project, providing data for evaluation and archiving the results of interpretation by recognized expert panels and providers of practice guidelines (see https://www.ncbi.nlm.nih.gov/clinvar/docs/review_guidelines/). ClinVar archives and versions submissions which means that when submitters update their records, the previous version is retained for review. Read more about submitting data to ClinVar at https://www.ncbi.nlm.nih.gov/clinvar/docs/submit. The level of confidence in the accuracy of variation calls and assertions of clinical significance depends in large part on the supporting evidence, so this information, when available, is collected and visible to users. Because the availability of supporting evidence may vary, particularly in regard to retrospective data aggregated from published literature, the archive accepts submissions from multiple groups, and aggregates related information, to reflect transparently both consensus and conflicting assertions of clinical significance. A review status is also assigned to any assertion, to support communication about the trustworthiness of any assertion. Domain experts are encouraged to apply for recognition as an expert panel (more info at https://www.ncbi.nlm.nih.gov/clinvar/docs/review_guidelines/). Accessions, with the format SCV000000000.0, are assigned to each submitted record. If there are multiple submitted records about the same variation/condition pair, they are aggregated within ClinVar’s data flow and reported as a reference accession with the format RCV000000000.0. Because of this model, one variant will be included in multiple RCV accessions whenever different conditions are reported for that variant. Submitted records for the same variation are also aggregated and reported as an accession with the format VCV000000000.0. This aggregation lets a user review all submitted data for a variant, regardless of the condition for which it was interpreted. ClinVar archives submitted information, and adds identifiers and other data that may be available about a variant or condition from other public resources. However ClinVar neither curates content nor modifies interpretations independent of an explicit submission. If you have data that differs from what is currently represented in ClinVar, we encourage you to submit your data and the evidence supporting your interpretation. There is a submission wizard to guide you through that process. See https://www.ncbi.nlm.nih.gov/variation/clinvar_single_wizard/. If you are submitting variants that were interpreted as part of work funded by the NIH, please consult your program officer about expectations for submissions to ClinVar.

Clinical Care Classification System

Clinical Care Classification System (formerly Home Health Care Classification system) codes. The Clinical Care Classification (CCC) consists of two taxonomies: CCC of Nursing Diagnoses and CCC of Nursing Interventions both of which are classified by 21 Care Components. Each of these are classified by Care Components which provide a standardized framework for documenting patient care in hospitals, home health agencies, ambulatory care clinics, and other health care settings.

Code on Dental Procedures and Nomenclature

The purpose of the CDT Code is to achieve uniformity, consistency and specificity in accurately documenting dental treatment. One use of the CDT Code is to provide for the efficient processing of dental claims, and another is to populate an Electronic Health Record.

CodeSystem

Code systems used in HL7 standards.

CodingRationale

Identifies how to interpret the instance of the code, codeSystem value in a set of translations. Since HL7 (or a government body) may mandate that codes from certain code systems be sent in conformant messages, other synonyms that are sent in the translation set need to be distinguished among the originally captured source, the HL7 specified code, or some future role. When this code is NULL, it indicates that the translation is an undefined type. When valued, this property must contain one of the following values: SRC - Source (or original) code HL7 - HL7 Specified or Mandated SH - both HL7 mandated and the original code (precoordination) There may be additional values added to this value set as we work through the use of codes in messages and determine other Use Cases requiring special interpretation of the translations.

College of American Pathologists (CAP) eCC (electronic Cancer Checklists)

“The College of American Pathologists (CAP) eCC (electronic Cancer Checklists) enables pathologists to use the CAP Cancer Protocols directly within their laboratory information system (LIS) workflow and to ensure that each report is completed with the necessary required elements. Most anatomic pathology (AP)-LIS vendors offer a CAP eCC synoptic module for reporting on surgical cancer resections and selected biopsies.” “The CAP eCC is based on the CAP Cancer Protocols and is produced under the guidance of the CAP Pathology Electronic Reporting (PERT) Committee along with close interaction and advisement of the Cancer Committee. The eCC is developed in collaboration with and partially underwritten by the Centers for Disease Control and Prevention (CDC). Additional collaborators include the American Joint Committee on Cancer (AJCC), Cancer Care Ontario (CCO), and the North American Association of Central Cancer Registries (NAACCR). The CAP currently is working with the California Cancer Registry (CCR) to offer the benefits of the eCC to California laboratories. CCR and the CAP are seeking out laboratories interested in participating in an ongoing project using the eCC to directly transfer cancer data to the central registry.” “The CAP releases eCC templates on a rolling basis, coordinating as much as possible with the posting of new and revised Cancer Protocols and Cancer Biomarker Reporting Templates. A few weeks prior to each Major or Agile release, email notifications are sent out to all licensed CAP eCC users.” For more information, see page here

Common Tags

Common Tag Codes defined by FHIR project

CommunicationCategory

Codes for general categories of communications such as alerts, instructions, etc.

CommunicationFunctionType

Describes the type of communication function that the associated entity plays in the associated transmission.

CommunicationNotDoneReason

Codes for the reason why a communication did not happen.

CommunicationTopic

Codes describing the purpose or content of the communication.

CompositeMeasureScoring

The composite scoring method of the measure.

CompressionAlgorithm

Type of compression algorithm used

Concept Domains

Concept Domains - includes both v2 abd v3 concept domains

ConceptGenerality

Indicates whether the concept that is the target should be interpreted as itself, or whether it should be expanded to include its child concepts, or both when it is included in the source domain/valueset. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

Condition Category Codes

Preferred value set for Condition Categories.

Condition Clinical Status Codes

Preferred value set for Condition Clinical Status.

ConditionState

Enumeration indicating whether the condition is currently active, inactive, or has been resolved.

ConditionVerificationStatus

The verification status to support or decline the clinical status of the condition or diagnosis.

Confidentiality

A set of codes specifying the security classification of acts and roles in accordance with the definition for concept domain “Confidentiality”.

ConformanceExpectation

Indicates the degree of adherence to a specified behavior or capability expected for a system to be deemed conformant with a specification.

Consent Action Codes

This value set includes sample Consent Action codes.

Consent Category Codes

This value set includes sample Consent Directive Type codes, including several consent directive related LOINC codes; HL7 VALUE SET: ActConsentType(2.16.840.1.113883.1.11.19897); examples of US realm consent directive legal descriptions and references to online and/or downloadable forms such as the SSA-827 Authorization to Disclose Information to the Social Security Administration; and other anticipated consent directives related to participation in a clinical trial, medical procedures, reproductive procedures; health care directive (Living Will); advance directive, do not resuscitate (DNR); Physician Orders for Life-Sustaining Treatment (POLST)

Consent PolicyRule Codes

This value set includes sample Regulatory consent policy types from the US and other regions.

Consent Scope Codes

This value set includes the four Consent scope codes.

Consent Verification Codes

This value set includes base Consent Verification codes.

Contact entity type

This example value set defines a set of codes that can be used to indicate the purpose for which you would contact a contact party.

ContainerCap

Color of the container cap.

ContainerCap

The type of cap associated with a container

ContainerSeparator

A material in a blood collection container that facilites the separation of of blood cells from serum or plasma

ContentProcessingMode

Description:Identifies the order in which content should be processed.

ContextControl

A code that specifies how an ActRelationship or Participation contributes to the context of an Act, and whether it may be propagated to descendent Acts whose association allows such propagation (see also attributes Participation.contextControlCode, ActRelationship.contextControlCode, ActRelationship.contextConductionInd).

Contract Action Codes

This value set includes sample Contract Action codes.

Contract Actor Role Codes

This value set includes sample Contract Actor Role codes.

Contract Content Derivation Codes

This is an example set of Content Derivative type codes, which represent the minimal content derived from the basal information source at a specific stage in its lifecycle, which is sufficient to manage that source information, for example, in a repository, registry, processes and workflows, for making access control decisions, and providing query responses.

Contract Signer Type Codes

This value set includes sample Contract Signer Type codes.

Contract Subtype Codes

This value set includes sample Contract Subtype codes.

Contract Term Subtype Codes

This value set includes sample Contract Term SubType codes.

Contract Term Type Codes

This value set includes sample Contract Term Type codes.

Contract Type Codes

This value set includes sample Contract Type codes.

ContractDataMeaning

How a resource reference is interpreted when evaluating contract offers.

CopyNumberEvent

Copy Number Event.

Country

The territory of a sovereign nation. Note that this has been deprecated in favor of using the ISO 3166 Country codes - 1.0.3166.1 iso3166-1

Coverage Class Codes

This value set includes Coverage Class codes.

Coverage Copay Type Codes

This value set includes sample Coverage Copayment Type codes.

Coverage SelfPay Codes

This value set includes Coverage SelfPay codes.

CoverageEligibilityResponse Auth Support Codes

This value set includes CoverageEligibilityResponse Auth Support codes.

Currency

The currency unit as defined in ISO 4217. Created prior to ISO ruling on OIDs for ISO code tables defined in ISO standards. Retired. Replaced by 1.0.4217 iso4217.

Current Procedural Terminology (CPT®)

The Current Procedural Terminology (CPT) code set, created and maintained by the American Medical Association, is the language of medicine today and the code to its future. This system of terminology is the most widely accepted medical nomenclature used to report medical procedures and services under public and private health insurance programs. CPT coding is also used for administrative management purposes such as claims processing and developing guidelines for medical care review. Each year, via a rigorous, evidence-based and transparent process, the independent CPT Editorial Panel revises, creates or deletes hundreds of codes in order to reflect current medical practice. Designated by the U.S. Department of Health and Human Services under the Health Insurance Portability and Accountability Act (HIPAA) as a national coding set for physician and other health care professional services and procedures, CPT’s evidence-based codes accurately encompass the full range of health care services. All CPT codes are five-digits and can be either numeric or alphanumeric, depending on the category. CPT code descriptors are clinically focused and utilize common standards so that a diverse set of users can have common understanding across the clinical health care paradigm. There are various types of CPT codes: Category I: These codes have descriptors that correspond to a procedure or service. Codes range from 00100–99499 and are generally ordered into sub-categories based on procedure/service type and anatomy. Category II: These alphanumeric tracking codes are supplemental codes used for performance measurement. Using them is optional and not required for correct coding. Category III: These are temporary alphanumeric codes for new and developing technology, procedures and services. They were created for data collection, assessment and in some instances, payment of new services and procedures that currently don’t meet the criteria for a Category I code. Proprietary Laboratory Analyses (PLA) codes: These codes describe proprietary clinical laboratory analyses and can be either provided by a single (“solesource”) laboratory or licensed or marketed to multiple providing laboratories that are cleared or approved by the Food and Drug Administration (FDA)). This category includes but is not limited to Advanced Diagnostic Laboratory Tests (ADLTs) and Clinical Diagnostic Laboratory Tests (CDLTs), as defined under the Protecting Access to Medicare Act of 2014 (PAMA).

DEEDS vocabularies

root for the DEEDS code sets

DEEDS(old)

retired root for DEEDs from earlier work. Superceded.

DEEDS2.10

Code for ED Practitioner Role

DEEDS402

Mode of transport to ED

DEEDS405

ED Source of Referral

DEEDS407

Code for Initial Healthcare Encounter for Chief Complaint

DEEDS408

Code for Acuity Assessment

DEEDS412

ED Responsiveness Assessment

DEEDS414

Glasgow eye opening assessment

DEEDS415

Glasgow verbal component assessment

DEEDS416

Glasgow motor component assessment

DEEDS418

Systolic blood pressure special situation

DEEDS422

Heart rate method

DEEDS424

Respiratory rate special circumstances codes

DEEDS427

Patient temperature route

DEEDS506

Injury Activity

DEEDS508

Safety Equipment Use

DEEDS519

Clinical Finding Data Source

DICOM Audit Message Record Lifecycle Events

Attached is vocabulary for the record lifecycle events, as per DICOM Audit Message,

DICOM Class Label

DICOM Class Label

DICOM Controlled Terminology

Coded concepts defined in PS 3.16 Digital Imaging and Communications in Medicine (DICOM): Part 16: Content Mapping Resource, Annex D: DICOM Controlled Terminology Definition

DICOM Query Label

DICOM Query Label

DICOM modality codes

DICOM modality codes

DataAbsentReason

Used to specify why the normally expected content of the data element is missing.

DataOperation

** MISSING DESCRIPTION **

DataType

Code system retired.

DefinitionStatus

Codes identifying the lifecycle stage of a definition.

DefinitionTopic

High-level categorization of the definition, used for searching, sorting, and filtering.

Dentition

** MISSING DESCRIPTION **

DeviceAlertLevel

Domain values for the Device.Alert_levelCode

DeviceDefinitionParameterGroup

Codes identifying groupings of parameters; e.g. Cardiovascular.

Diagnosis Role

This value set defines a set of codes that can be used to express the role of a diagnosis on the Encounter or EpisodeOfCare record.

Diet

This value set defines a set of codes that can be used to indicate dietary preferences or restrictions a patient may have.

Digital Media Category

Codes for high level media types - whether the media is an image, video, or audio.

Discharge disposition

This value set defines a set of codes that can be used to where the patient left the hospital.

DocumentCompletion

Identifies the current completion state of a clinical document.

DocumentStorage

Identifies the storage status of a document.

DoseAndRateType

The kind of dose or rate specified.

EPSG Geodetic Parameter Dataset

Description: The EPSG (European Petroleum Survey Group) dataset represents all Datums, coordinate references (projected and 2D geographic) and coordinate systems (including Cartesian coordinate systems) used in surveying worldwide. Each record includes a 4-8 digit unique identifier. The current version is available from http://www.epsg.org/. The database contains over 4000 records covering spatial data applications worldwide. Deprecation Comment: This has been superceded by the two code systems EPSG-CRS and EPSG-CA

EUCLIDES

EUCLIDES

EditStatus

The status of an entry as it pertains to its review and incorporation into the HL7 domain specification database.

Education Level

Years of education that a person has completed

EmployeeJobClass

A code qualifying the employment in various ways, such as, full-time vs. part time, etc.

Encounter Acuity

The level of resource intensiveness of patient care. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used. No content.

Encounter subject status

This example value set defines a set of codes that can be used to indicate the status of the subject within the encounter

Encounter type

This example value set defines a set of codes that can be used to indicate the type of encounter: a specific code indicating type of service provided.

EncounterAccident

Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used. No content.

EncounterAdmissionSource

** MISSING DESCRIPTION **

EncounterReferralSource

This domain is defined in UB92 and applies to US realm only Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used. We’ve deprecated all of the codes.

EncounterSpecialCourtesy

** MISSING DESCRIPTION **

Endpoint Connection Type

This is an example value set defined by the FHIR project, that could be used to represent possible connection type profile values.

Endpoint Payload Type

This is an example value set defined by the FHIR project, that could be used to represent possible payload document types.

Enteral Formula Additive Type Code

EnteralFormulaAdditiveType: Codes for the type of modular component such as protein, carbohydrate or fiber to be provided in addition to or mixed with the base formula. This value set is provided as a suggestive example.

EntityClass

Classifies the Entity class and all of its subclasses. The terminology is hierarchical. At the top is this HL7-defined domain of high-level categories (such as represented by the Entity subclasses). Each of these terms must be harmonized and is specializable. The value sets beneath are drawn from multiple, frequently external, domains that reflect much more fine-grained typing.

EntityCode

OpenIssue: Missing description.

EntityDeterminer

EntityDeterminer in natural language grammar is the class of words that comprises articles, demonstrative pronouns, and quantifiers. In the RIM, determiner is a structural code in the Entity class to distinguish whether any given Entity object stands for some, any one, or a specific thing.

EntityHandling

Special handling requirements for an Entity. Example:Keep at room temperature; Keep frozen below 0 C; Keep in a dry environment; Keep upright, do not turn upside down.

EntityNamePartQualifier

OpenIssue: Needs description

EntityNamePartQualifierR2

Description:The qualifier is a set of codes each of which specifies a certain subcategory of the name part in addition to the main name part type. For example, a given name may be flagged as a nickname, a family name may be a pseudonym or a name of public records.

EntityNamePartType

** MISSING DESCRIPTION **

EntityNamePartTypeR2

Description:Indicates whether the name part is a given name, family name, prefix, suffix, etc.

EntityNameUse

** MISSING DESCRIPTION **

EntityNameUseR2

Description:A set of codes advising a system or user which name in a set of names to select for a given purpose.

EntityRisk

Kinds of risks associated with the handling of the material..

EntityStatus

Codes representing the defined possible states of an Entity, as defined by the Entity class state machine.

Enzyme Codes

Enzyme Codes

Episode of care type

This example value set defines a set of codes that can be used to express the usage type of an EpisodeOfCare record.

EquipmentAlertLevel

** MISSING DESCRIPTION **

Ethnicity

Deprecation Information: Deprecated due to UP-265. This code system in NOT the acknowledged source of truth for Ethnicity concepts and codes. It should no longer be used. https://terminology.hl7.org/CodeSystem-CDCREC.html should be used in its place. In the United States, federal standards for classifying data on ethnicity determine the categories used by federal agencies and exert a strong influence on categorization by state and local agencies and private sector organizations. The federal standards do not conceptually define ethnicity, and they recognize the absence of an anthropological or scientific basis for ethnicity classification. Instead, the federal standards acknowledge that ethnicity is a social-political construct in which an individual’s own identification with a particular ethnicity is preferred to observer identification. The standards specify two minimum ethnicity categories: Hispanic or Latino, and Not Hispanic or Latino. The standards define a Hispanic or Latino as a person of “Mexican, Puerto Rican, Cuban, South or Central America, or other Spanish culture or origin, regardless of race.” The standards stipulate that ethnicity data need not be limited to the two minimum categories, but any expansion must be collapsible to those categories. In addition, the standards stipulate that an individual can be Hispanic or Latino or can be Not Hispanic or Latino, but cannot be both.

Euclides Lab equipment codes

Euclides Lab equipment codes

Euclides Lab method codes

Euclides Lab method codes

Euclides quantity codes

Euclides quantity codes

European Petroleum Survey Group Geodetic Parameter Dataset Coordinate Axis

Description:The set of values found in the Coord Axis Code column of the Coordinate Axis table as maintained in the EPSG geodetic parameter dataset. These define the axis for coordinate systems for geographic coordinates.

European Petroleum Survey Group Geodetic Parameter Dataset Coordinate Reference System

Description: The set of values found in the Coord Axis Code column of the Coordinate Axis table as maintained in the EPSG geodetic parameter dataset. These define the axis for coordinate systems for geographic coordinates.

EvidenceDirectness

The quality of how direct the match is.

EvidenceVariableRole

The role that the assertion variable plays.

Example Claim SubType Codes

This value set includes sample Claim SubType codes which are used to distinguish the claim types for example within type institutional there may be subtypes for emergency services, bed stay and transportation.

Example Coverage Financial Exception Codes

This value set includes Example Coverage Financial Exception Codes.

Example Diagnosis Related Group Codes

This value set includes example Diagnosis Related Group codes.

Example Diagnosis Type Codes

This value set includes example Diagnosis Type codes.

Example Diagnosis on Admission Codes

This value set includes example Diagnosis on Admission codes.

Example Message Reason Codes

Example Message Reasons. These are the set of codes that might be used an updating an encounter using admin-update.

Example Payment Type Codes

This value set includes example Payment Type codes.

Example Procedure Type Codes

This value set includes example Procedure Type codes.

Example Program Reason Codes

This value set includes sample Program Reason Span codes.

Example Provider Qualification Codes

This value set includes sample Provider Qualification codes.

Example Related Claim Relationship Codes

This value set includes sample Related Claim Relationship codes.

Example Revenue Center Codes

This value set includes sample Revenue Center codes.

Example Service Place Codes

This value set includes a smattering of Service Place codes.

Example Use Codes for List

Example use codes for the List resource - typical kinds of use.

Example Vision Prescription Product Codes

This value set includes a smattering of Prescription Product codes.

Exception Codes

This value set includes sample Exception codes.

ExpansionParameterSource

Declares what the source of a parameter is.

ExpansionProcessingRule

Defines how concepts are processed into the expansion when it’s for UI presentation.

ExposureMode

Code for the mechanism by which the exposure agent was exchanged or potentially exchanged by the participants involved in the exposure.

FDA K10

FDA K10

FDB HIC Code

The FDB Hierarchical Ingredient Code is a six character identifier that represents an active ingredient and its specific therapeutic classification.

FHIRDeviceStatusReason

The availability status reason of the device.

FIPS_SOC

FIPSPUB92 - GUIDELINE FOR STANDARD OCCUPATIONAL CLASSIFICATION (SOC) CODES, version 1983 February 24. This entry is now obsolete, as FIPS92 was withdrawn from use in February 2005 by the US Government. It has been replaced by 2.16.840.1.113883.6.243; please use that OID instead.

Failure-action

The result if validation fails

FamilyHistoryAbsentReason

Codes describing the reason why a family member’s history is not available.

Financial Task Codes

This value set includes Financial Task codes.

Financial Task Input Type Codes

This value set includes Financial Task Input Type codes.

First DataBank Diagnostic Codes

First DataBank Diagnostic Codes

First DataBank Drug Codes

First DataBank Drug Codes

Flag Category

Example list of general categories for flagged issues. (Not complete or necessarily appropriate.)

Food and Drug Administration Food Canning Establishments

Entered erroneously - do not use. The correct OID for this identifier system is 2.16.840.1.113883.4.345.

Food and Drug Administration Food Facility Registration Numbers

Entered in error originally - do not use. Correct OID for this item is 2.16.840.1.113883.4.344.

Form Codes

This value set includes a sample set of Forms codes.

Funds Reservation Codes

This value set includes sample funds reservation type codes.

GCDF

GCDF Dosage Form Code (2-character) a two-character alphanumeric column that represents a dosage form. The dosage form of a generic drug formulation describes the physical presentation of a drug, such as tablet, capsule, or liquid. It may also incorporate the delivery and release mechanism of the drug. A GCDF is associated to each GCN_SEQNO to identify that component of the generic drug formulation.

GCRT

GCRT Route of Administration Code (1-character) a one-character alphanumeric column that provides the normal site or method by which a drug is administered, such as oral, injection, or topical. A GCRT is associated to each GCN_SEQNO to identify that component of the generic drug formulation.

GTSAbbreviation

Open Issue: It appears that the printnames are suboptimal and should be improved for many of the existing codes.

GenderStatus

A value representing whether the primary reproductive organs of NonPersonLivingSubject are present.

Gene Reference Sequence Collection

The Reference Sequence (RefSeq) is one of the NCBI projects, the RefSeq collection aims to provide a comprehensive, integrated, non-redundant, well-annotated set of sequences, including genomic DNA, transcripts, and proteins. ReqSeq is accessible via BLAST, Entrez, and the NCBI FTP site. Information is also available in Entrez Genomes and Entrez Gene, and for some genomes additional information is available in the Map Viewer. RefSeq entries can be used with the HL7 coded data type. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model, RefSeq entries can be used to as the observation values for genomic reference sequence identifiers (LOINC #: 48013-7). More information may be found at: http://www.ncbi.nlm.nih.gov/RefSeq Versioning informaiton: The latest release of RefSeq was released on May 13, 2009 with the release number of 35. RefSeq generates new releases roughly every two months. The dates of the three previous releases were: Release 34, March 12, 2009 Release 33, January 20, 2009 Release 32, November 17, 2008 RefSeq is a free database for the public.

Genetic Sequence polymorphism database

In collaboration with the National Human Genome Research Institute, The National Center for Biotechnology Information has established the dbSNP database to serve as a central repository for both single base nucleotide substitutions and short deletion and insertion polymorphisms. The entries in the dbSNP database can be used with the HL7 coded data type. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model, dbSNP entries can be used to as the observation values for DNA sequence variation identifiers. For example, OBX|1|CWE|48004-6^DNA Sequence Variation Identifier^LN||rs55538123^^dbSNP Versioning is identified by the build id. A new build is released approximately every six months or every year. The latest build id is 130, and the dbSNP web query for built 130 was available on Apr 30, 2009. dbSNP is a database that can be used freely by the public. More information may be fouond at: http://www.ncbi.nlm.nih.gov/projects/SNP/

Genetic Testing Registry

The Genetic Testing Registry (GTR) provides a central location for voluntary submission of genetic test information by providers. The scope includes the test’s purpose, methodology, validity, evidence of the test’s usefulness, and laboratory contacts and credentials. The overarching goal of the GTR is to advance the public health and research into the genetic basis of health and disease. Each Test is a specific, orderable test from a particular laboratory, and is assigned a unique GTR accession number. The format is GTR00000001.1, with a leading prefix “GTR” followed by 8 digits, a period, then 1 or more digits representing the version. When a laboratory updates a registered test, a new version number is assigned. To find all laboratories in GTR and all registered tests, see here https://www.ncbi.nlm.nih.gov/gtr/all/tests/?term=all%5Bsb%5D

Global Medical Device Nomenclature

http://www.gmdnagency.com/

Goal achievement status

Describes the progression, or lack thereof, towards the goal against the target.

Goal category

Example codes for grouping goals to use for filtering or presentation.

Goal priority

Indicates the level of importance associated with reaching or sustaining a goal.

GoalAcceptanceStatus

Codes indicating whether the goal has been accepted by a stakeholder.

GoalRelationshipType

Types of relationships between two goals.

Gold Standard's Clinical Pharmacology Monograph Number

Gold Standard’s Clinical Pharmacology Monograph Number

GuideParameterCode

Code of parameter that is input to the guide.

HCFA Procedure Codes (HCPCS)

The HCFA Procedure Codes (HCPCS) as originally defined includes three levels of codes. Level I includes CPT codes, Level II includes HCPCS Level II codes, and Level III includes codes that have not been valid since 2003. CPT and HCPCS Level II have their own identifiers. Therefore, this identifier should never be used in current electronic interchange and is maintained for historical reference only.

HIBCC

HIBCC

HL7 Code System Type

Retired code system for HL7 Code System Types. This description added to conform to shareable codesystem profile

HL7 Coded Concept Status

Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

HL7 Document Format Codes

This codeSystem contains codes which specify the technical format of a document. Each code provides sufficient information to allow any potential document consumer to know if it will be able to process the document. The codes are sufficiently specific to ensure processing/display by identifying a document encoding, structure and template. For example, formatCodes can be used in the FHIR DocumentReference resource to characterize the document being referenced.

HL7 ITS Version Code

HL7 implementation technology specification versions. These codes will document the ITS type and version for message encoding. The code will appear in the instances based upon rules expressed in the ITS, and do not appear in the abstract message, either as it is presented to received from the ITS.

HL7 Registered External Coding Systems

External coding systems registered in HL7 with an HL7 OID

HL7 Terminology Maintenance Infrastructure Vocabulary

Codes that may have been strings or other types of data in pre-existing tooling for V3 and V2 terminology maintenance, and moved to codes in this code system for proper handling in the FHIR based UTG maintenance facilities.

HL7 Value Set and Coded Concept Property Codes

Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

HL7ApprovalStatus

Description: Codes for concepts describing the approval level of HL7 artifacts. This code system reflects the concepts expressed in HL7’s Governance & Operations Manual (GOM) past and present.

HL7CMETAttribution

** MISSING DEFINITIONS **

HL7CommitteeIDInRIM

Holds the codes used to identify the committees and SIGS of HL7 in RIM repository tables. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

HL7ConformanceInclusion

These concepts represent theconformance requirments defined for including or valuing an element of an HL7 message. The concepts apply equally to conformance profiles defined for Version 2.x messgaes as defined by the Conformance SIG, and to the conformance columns for Version 3 messages as specified in the HMD. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

HL7ContextConductionStyle

The styles of context conduction usable by relationships within a static model derived from tyhe HL7 Reference Information Model.

HL7DefinedRoseProperty

The property Ids that HL7 has defined for customizing Rational Rose. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

HL7ITSType

Description: Codes identifying types of HL7 Implementation Technology Specifications

HL7PublishingDomain

Description: Codes for HL7 publishing domains (specific content area)

HL7PublishingSection

Description: Codes for HL7 publishing sections (major business categories)

HL7PublishingSubSection

Description: Codes for HL7 publishing sub-sections (business sub-categories)

HL7Realm

Description: Coded concepts representing Binding Realms (used for Context Binding of terminology in HL7 models) and/or Namespace Realms (used to help ensure unique identification of HL7 artifacts). This code system is partitioned into three sections: Affiliate realms, Binding realms and Namespace realms. All affiliate realm codes may automatically be used as both binding realms and namespace realms. Furthermore, affiliate realms are the only realms that have authority over the creation of binding realms. (Note that ‘affiliate’ includes the idea of both international affiliates and the HL7 International organization.) All other codes must be associated with an owning affiliate realm and must appear as a specialization of _BindingRealm or _NamespaceRealm. For affiliates whose concepts align with nations, the country codes from ISO 3166-1 2-character alpha are used for the code when possible so these codes should not be used for other realm types. It is recommended that binding realm and namespace codes submitted by affiliates use the realm code as a prefix to avoid possible collisions with ISO codes. However, tooling does not currently support namepace realm codes greater than 2 characters. Open Issue: The name of the concept property “owningAffiliate” should be changed to better reflect that the property value is the human readable name of the organizational entity that manages the Realm identified by the Realm Code. Open Issue: In spite of the inability of tooling to process codes longer than 2 characters, there is at least one realm codes (‘SOA’) that was added that is 3 characters in length.

HL7StandardVersionCode

This code system holds version codes for the Version 3 standards. Values are to be determined by HL7 and added with each new version of the HL7 Standard.

HL7UpdateMode

The possible modes of updating that occur when an attribute is received by a system that already contains values for that attribute.

HL7V3Conformance

Description: Identifies allowed codes for HL7aTMs v3 conformance property.

HL7VoteResolution

Description: Based on concepts for resolutions from HL7 ballot spreadsheet according to HL7’s Governance & Operations Manual (GOM).

HL7Workgroup

An HL7 administrative unit that owns artifacts in the FHIR specification.

HUGO Gene Nomenclature Committee Gene Group

The HGNC is responsible for approving unique symbols and names for human loci, including protein coding genes, ncRNA genes and pseudogenes, to allow unambiguous scientific communication. For each known human gene we approve a gene name and symbol (short-form abbreviation). All approved symbols are stored in the HGNC database,www.genenames.org, a curated online repository of HGNC-approved gene nomenclature, gene groups and associated resources including links to genomic, proteomic and phenotypic information. Each symbol is unique and we ensure that each gene is only given one approved gene symbol. It is necessary to provide a unique symbol for each gene so that we and others can talk about them, and this also facilitates electronic data retrieval from publications and databases. Please see https://www.genenames.org/ for more info.

HUGO Gene Nomenclature Committee Genes

The HGNC is responsible for approving unique symbols and names for human loci, including protein coding genes, ncRNA genes and pseudogenes, to allow unambiguous scientific communication. For each known human gene we approve a gene name and symbol (short-form abbreviation). All approved symbols are stored in the HGNC database,www.genenames.org, a curated online repository of HGNC-approved gene nomenclature, gene groups and associated resources including links to genomic, proteomic and phenotypic information. Each symbol is unique and we ensure that each gene is only given one approved gene symbol. It is necessary to provide a unique symbol for each gene so that we and others can talk about them, and this also facilitates electronic data retrieval from publications and databases. HGNC gene symbols can be used with the HL7 coded data type. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model Implementation Guide, HGNC gene symbols can be used to as the observation values for gene identifiers. For example, OBX|1|CWE|48018-6^Gene identifier^||BRCA1^HGNC| Versioning Information: The version of the HGNC database is reported using the last updated date and timestamp. The last updated date and timestamp is posted on the main HGNC Search screen in the format like “Monday March 30 23:00:56 2009”. HGNC is updated daily. HGNC is a free database for the public. Please see https://www.genenames.org/ for more info.

HandlingConditionSet

Set of handling instructions prior testing of the specimen.

Health Canada Drug Id Number

A Drug Identification Number (DIN) is a computer-generated eight digit number assigned by Health Canada to a drug product prior to being marketed in Canada. It uniquely identifies all drug products sold in a dosage form in Canada and is located on the label of prescription and over-the-counter drug products that have been evaluated and authorized for sale in Canada. A DIN uniquely identifies the following product characteristics:

  • manufacturer
  • product name
  • active ingredient(s)
  • strength(s) of active ingredient(s)
  • pharmaceutical form, and
  • route of administration. Note: The number has a leading zero. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/drug-products/applications-submissions/guidance-documents/regulatory-requirements-drug-identification-numbers/document.html
Health Canada Natural Product Number

Natural Product Number (NPN) is an eight (8) digit numerical code assigned to each natural health product approved to be marketed under the Natural Health Products Regulations. A Homeopathic Medicine Number (DIN-HM) is an eight (8) digit numerical code assigned to each homeopathic medicine approved to be marketed under the Natural Health Products Regulations. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/natural-non-prescription/applications-submissions/product-licensing/licensed-natural-health-products-database.html

Health Insurance Prospective Payment System (HIPPS)

“Health Insurance Prospective Payment System (HIPPS) rate codes represent specific sets of patient characteristics (or case-mix groups) health insurers use to make payment determinations under several prospective payment systems. Case-mix groups are developed based on research into utilization patterns among various provider types. For the payment systems that use HIPPS codes, clinical assessment data is the basic input. A standard patient assessment instrument is interpreted by case-mix grouping software algorithms, which assign the case mix group. For payment purposes, at least one HIPPS code is defined to represent each case-mix group. These HIPPS codes are reported on claims to insurers. Institutional providers use HIPPS codes on claims in association with special revenue codes. One revenue code is defined for each prospective payment system that requires HIPPS codes. HIPPS codes are placed in data element SV202 on the electronic 837 institutional claims transaction, using an HP qualifier, or in Form Locator (FL) 44 (“HCPCS/rate”) on a paper UB-04 claims form. The associated revenue code is placed in data element SV201 or in FL 42. In certain circumstances, multiple HIPPS codes may appear on separate lines of a single claim.” “HIPPS codes are alpha-numeric codes of five digits. Each code contains intelligence, with certain positions of the code indicating the case mix group itself, and other positions providing additional information. The additional information varies among HIPPS codes pertaining to different payment systems, but often provides information about the clinical assessment used to arrive at the code. Which positions of the code carry the case mix group information may also vary by payment systems.” “Under the Health Insurance Portability and Accountability Act (HIPAA) rules for transactions and code sets, HIPPS codes are defined as a non-medical code set. Therefore, these codes are effective by transaction date. Effective From Dates: HIPPS codes are valid under HIPAA on transactions on or after this date. Since all HIPPS codes to date have been initially created for Original Medicare payment systems, this is also date of service the codes begin to be payable by Medicare. While it is valid under HIPAA rules that a claim for dates of service before this date could be submitted on a transaction after this date, CMS is not aware of a business need for a provider to do so. The code would not be payable by any insurer and no Grouper software would be available to produce a code for those dates. Effective Through Dates: HIPPS codes are no longer valid under HIPAA on transactions on or after this date. This date may vary from the date a code ceases to be payable by Medicare, since other payers may continue to use older HIPPS codes after Medicare transitions to a new payment system. Since CMS, as the HIPPS code set maintainer, may not have complete information about other payers’ uses of these codes, codes may remain effective under HIPAA long after they cease to be payable on Medicare claims. To reflect this, a separate column on the HIPPS Code Master List indicates the Medicare Payment Though Date.”

Health Outcomes

Health Outcomes

Healthcare Common Procedure Coding System (HCPCS) level II alphanumeric codes

The Level II HCPCS codes, which are established by CMS’s Alpha-Numeric Editorial Panel, primarily represent items and supplies and non-physician services not covered by the American Medical Association’s Current Procedural Terminology-4 (CPT-4) codes; Medicare, Medicaid, and private health insurers use HCPCS procedure and modifier codes for claims processing. Level II alphanumeric procedure and modifier codes comprise the A to V range.

Healthcare Provider Taxonomy HIPAA

NUCC Healthcare Provider Taxonomy codes, as cited in US HIPAA regulations. This HL7 copy of the content is made available by request of various HL7 Affiliates,so do have have direect access to the NUCC contnet as they are outside the US. In additions, some concept have been added to this set that are pending being added to the NUCC master.

Home Health Care

HHCC - Home Health Codes

HtmlLinkType

HtmlLinkType values are drawn from HTML 4.0 and describe the relationship between the current document and the anchor that is the target of the link

Human Genome Variation Society nomenclature

HGVS nomenclatures are the guidelines for mutation nomenclature made by the Human Genome Variation Society. HGVS nomenclature can be used with the HL7 coded data type (code data type that accepts expression data, or a coded expression data type). This coded data type should be able to distinguish expressions in HGVS nomenclature from coded concepts. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model, HGVS nomenclature can be used to as the observation values for DNA sequence variations. For example, OBX|1|CWE|48004-6^DNA Sequence Variation^LN||c.1129C>T^^HGVS| Versioning information: The HGVS nomenclature for the description of sequence variants was last modified Feb 20, 2008. The HGVS nomenclature for the description of protein sequence variants was last modified May 12, 2007. The HGVS nomenclature for the description of DNA sequence variants was last modified June 15, 2007 The HGVS nomenclature for the description of RNA sequence variants was last modified May 12, 2007 HGVS nomenclatures can be used freely by the public.

Human Phenotype Ontology

“The Human Phenotype Ontology (HPO) provides a standardized vocabulary of phenotypic abnormalities encountered in human disease. Each term in the HPO describes a phenotypic abnormality, such as Atrial septal defect. The HPO is currently being developed using the medical literature, Orphanet, DECIPHER, and OMIM. HPO currently contains over 13,000 terms and over 156,000 annotations to hereditary diseases. The HPO project and others have developed software for phenotype-driven differential diagnostics, genomic diagnostics, and translational research. The HPO is a flagship product of the Monarch Initiative, an NIH-supported international consortium dedicated to semantic integration of biomedical and model organism data with the ultimate goal of improving biomedical research. The HPO, as a part of the Monarch Initiative, is a central component of one of the 13 driver projects in the Global Alliance for Genomics and Health (GA4GH) strategic roadmap.” Please see https://hpo.jax.org/app/download/ontology. Releases, produced approximately every 2 months, can be found here.

HumanNameAssemblyOrder

A code that represents the preferred display order of the components of a human name.

ICCS

ICCS

ICD-10

International Classification of Diseases revision 10 (ICD 10)

ICD-10 American English

International Statistical Classification of Diseases and Related Health Problems (ICD-10): Americanized Version. 10th rev. Geneva (Switzerland): World Health Organization, 1998.

ICD-10 Dual Coding

ICD-10 allows dual coding. Refer to Section 3.1.3 of the ICD-10 Instruction Manual (2nd Edition, http://www.who.int/entity/classifications/icd/ICD-10_2nd_ed_volume2.pdf). This OID identifies the code system that describes how to encode Dual Coding in a CD compatible expression (for Datatypes R2 CD only). An ICD-10 dual code expression SHALL consist of two ICD-10 codes separated by space. This code system SHALL NOT be used for single ICD-10 codes; the normal ICD-10 code system oid which is 2.16.840.1.113883.6.3 should be used in this case. Dual code expressions SHALL only be used per the rules described in the ICD-10 instruction manual. An example CD:<br></br> <example code=”J21.8 B95.6” codeSystem=”2.16.840.1.113883.6.260”><br></br> <originalText value=”Staph aureus bronchiolitis”/><br></br> </example><br></br><br></br> Where:<br></br> J21.8 is: Acute bronchiolitis due to other specified organisms<br></br> B95.6 is: Staphylococcus aureus as the cause of diseases classified to other chapters

ICD-10 German

Internationale Klassifikation der Krankheiten 10 [German translation of ICD10]. Germany: Deutsches Institut fuer Medizinische Dokumentation und Information, 1998.

ICD-10 Procedure Codes

ICD Procedure Coding System (ICD 10 PCS)

ICD-9 Dual Coding

ICD-9 Dual Coding Expression Syntax”, description: ICD-9 allows dual coding. Refer to Section ?? of the ICD-9 Instruction Manual (ref?). This OID identifies the code system that describes how to encode Dual Coding in a CD compatible expression (for Datatypes R2 CD only). An ICD-9 dual code expression SHALL consist of two ICD-9 codes separated by space. This code system SHALL NOT be used for single ICD-9 codes; the normal ICD-9 code system oid which is 2.16.840.1.113883.6.3 should be used in this case. DisplayName SHALL not be used. Dual code expressions SHALL only be used per the rules described in the ICD-9 instruction manual. An example CD:<br></br><example code=”989.5 E905.9” codeSystem=”2.16.840.1.113883.6.261”><br></br><originalText value=”ANAPHYLAXIS DUE TO BITE OR STING”/><br></br></example><br></br>Where 989.5 is: “Toxic effect of venom” and E905.9 is: “Bite or sting”

ICD-9CM

International Classification of Diseases revision 9, with Clinical Modifications (ICD 9 CM)

ICD10, Dutch Translation

Hirs, W., H.W. Becker, C. van Boven, S.K. Oskam, I.M. Okkes, H. Lamberts. ICD-10, Dutch Translation, 200403. Amsterdam: Department of General Practice, Academic Medical Center/University of Amsterdam, Dutch College of General Practitioners (NHG), March 20

ICD9

ICD9

ICHPPC-2

ICHPPC-2

ICPC2-ICD10 Thesaurus

A diagnostic Terminology for semi-automatic Double Coding in Electronic Patient Records The thesaurus is a part of the CD Rom: “ICPC in the Amsterdam Transition Project. Extended Version. IM Okkes, SK Oskam, H. Lamberts. Amsterdam: Academic Medical Center/University of Amsterdam. Department of Family Medicine”, see also the web site http://www.transitieproject.nl for this application of the thesaurus. This bilingual (English/Dutch) ICPC2-ICD10 thesaurus is derived from an extended version of the CD-Rom ICPC in the Amsterdam Transition Project, that was published as a companion to ICPC-2-R by Oxford University Press (2005). As was the case with the former thesaurus (published in Dutch in 2003), the content of this new thesaurus may be copied for academic purposes, and be used for teaching and research under the usual referencing conditions. Any other and/or commercial use requires prior permission from the authors, represented by Dr. Inge Okkes (see below). It is strongly recommended that you first go through the ICPC Tutorial, the Manual and the Glossary, and consider printing them. Becker, H.W., C. van Boven, S.K. Oskam, I.M. Okkes, W. Hirs, H. Lamberts. ICPC2 - ICD10 Thesaurus, Version March, 2004. Amsterdam: Project “Adaptation ICPC, integration and implementation of ICPC2 and ICD10(-CM).” Department of General Practice, Academic

ICPC2-ICD10 Thesaurus (English)

Becker, H.W., C. van Boven, S.K. Oskam, I.M. Okkes, W. Hirs, H. Lamberts. ICPC2 - ICD10 Thesaurus, Version March, 2004. Amsterdam: Project “Adaptation ICPC, integration and implementation of ICPC2 and ICD10(-CM).” Department of General Practice, Academic

ICPC2-ICD10 Thesaurus, 7-bit

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

ICPC2-ICD10 Thesaurus, Am Engl

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

ICPC2-ICD10ENG Thesaurus, Dutch Translation

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

ICPC2E 1998 Plus

International Classification of Primary Care, Version 2-Plus. Produced by NLM. Bethesda (MD): National Library of Medicine, UMLS project. This node has the various modifications and translations produced under it.

ICPC2E 1998 Plus Am Engl

International Classification of Primary Care, Version 2-Plus, Australian Modification. Americanized English Equivalents, January, 2000. Produced by NLM. Bethesda (MD): National Library of Medicine, UMLS project

ICPC2E Am Engl (Metathesaurus)

Henk Lamberts and Inge Hofmans-Okkes. International Classification of Primary Care 2nd Edition, Electronic, 2E, American English Equivalents. Amsterdam: International Classification of Primary Care / prepared by the Classification Committee of the World Health Organization. Entry derived from the UMLS Metathesaurus.

ICPC2E, Dutch Translation

Hirs, W., H.W. Becker, C. van Boven, S.K. Oskam, I.M. Okkes, H. Lamberts. International Classification of Primary Care 2E: 2nd ed. electronic. Dutch Translation. Amsterdam: Department of General Practice, Academic Medical Center/University of Amsterdam, D

ICPC2P 1998 Plus Austral Mod

International Classification of Primary Care, Version 2-Plus, Australian Modification. January, 2000

IEC 61966-2-1: Colour measurement and management - Part 2-1: Colour management - Default RGB colour space - sRGB

IEC 61966-2-1:1999 is the official specification of sRGB. It provides viewing environment, encoding, and colorimetric details. For more information, please see https://webstore.iec.ch/publication/6168

IETF RFC 1766

Codes representing languages for which a person has some level of proficiency for written or spoken communication. Examples: Spanish, Italian, German, English, American Sign, etc.

ISBT

ISBT 128 is a coding system for blood components, hematopoietic progenitor cells and other tissues. It is comprised of an overall Application Specification, and labeling and coding documents for the separate sections: blood components, hematopoietic progenitor cells (draft), source plasma (draft) and tissues (draft). The documentation is supported by databases: Country/Collection Facility, Product Code (blood components), Product Code (hematopoietic progenitor sells), Product Code (source plasma), Product Code (tissues) and Special Testing. ISBT 128 is designed as a series of data structures that are designed to be technology-independent and can be used for bar coding, radio frequency tag encoding and electronic data interchange. The HL7 Blood Bank SIG is currently designing example messages that incorporate ISBT 128 coding. No changes of any kind will be needed to use ISBT 128 in HL7 messages.

ISO 11073-10101 Health informatics - Point-of-care

The nomenclature relates primarily to vital signs monitoring, but also includes semantics of other medical devices that are commonly used in acute care settings. There are multiple coding partitions each of which has a systematic name consisting of a set of base concepts and differentiating criteria.

ISO 21089 2017 Health Record Lifecycle Events

Attached is vocabulary for the 27 record lifecycle events, as per ISO TS 21089-2017, Health Informatics - Trusted End-to-End Information Flows, Section 3, Terms and Definitions (2017, at ISO Central Secretariat, passed ballot and ready for publication). This will also be included in the FHIR EHR Record Lifecycle Event Implementation Guide, balloted and (to be) published with FHIR STU-3.

ISO 3166 2 Character Country Codes

Two character country codes Note that this OID was erroneously entered into HL7 some years ago, and has recently been replaced by 1.0.3166.1 at the request of ISO.

ISO 3166 3 Character Country Codes

Three character country codes Note that this was erroneously entered into the HL7 system some years ago and has been replaced by 1.0.3166.1.2.3 at the request of ISO.

ISO 3166 Numeric country Codes

Numeric country codes Note that this was erroneously entered into the HL7 system some years ago and has been replaced by 1.0.3166.1.2.1 at the request of ISO.

ISO 3166 Part 1 Country Codes, 2nd Edition

This OID identifies the coding system published in the ISO 3166-1 Standard for Country codes. It contains 3 sets of synonyms for the country codes: 2-character alphabetic, 3-character alphabetic, and numeric. Note that this is the 2nd edition of the standard.

ISO 3166 Part 1 Country Codes, 2nd Edition, Alpha-2

Identifies the coding system published in the ISO 3166-1 Standard for Country codes, 2nd edition, 2-character alphabetic codes.

ISO 3166 Part 1 Country Codes, 2nd Edition, Alpha-3

Identifies the coding system published in the ISO 3166-1 Standard for Country codes, 2nd edition, 3-character alphabetic codes.

ISO 3166 Part 1 Country Codes, 2nd Edition, Numeric

Identifies the coding system published in the ISO 3166-1 Standard for Country codes, 2nd edition, numeric codes.

ISO 3166 Part 2 Country Subdivision Codes

Identifies the coding system published in the ISO 3166-2 Standard for Country Subdivision codes. This standard is released periodically, and a new OID will be assigned by ISO for new editions.

ISO 3166-1 Codes for the representation of names of countries and their subdivisions — Part 1: Country code

ISO 3166-1 establishes codes that represent the current names of countries, dependencies, and other areas of particular geopolitical interest, on the basis of country names obtained from the United Nations.

ISO 3166-2 Codes for the representation of names of countries and their subdivisions — Part 2: Country subdivision code

ISO 3166-2 establishes a code that represents the names of the principal administrative divisions, or similar areas, of the countries and entities included in ISO 3166-1.

ISO 3166-3 Codes for the representation of names of countries and their subdivisions — Part 3: Code for formerly used names of countries

ISO 3166-3 establishes a code that represents non-current country names, i.e. the country names deleted from ISO 3166 since its first publication in 1974.

ISO 4217 Currency Codes

ISO 4217 currency codes.

ISO 4217 Currency code, HL7 use

ISO 4217 currency code Created prior to ISO ruling on OIDs for ISO code tables defined in ISO standards. Recommend using 1.0.4217 iso4217 code system instead.

ISO 639-1 Alpha-2 Language Codes

Codes for the Representation of Names of Languages Part 1: Alpha-2 Code. Used as part of the IETF 3066 specification for languages throughout the HL7 specification. DeprecationComment: This code system is being deprecated, as the OID identifying it has been replaced with the correct ISO OID of 1.0.639.1

ISO 639-1: Codes for the representation of names of languages -- Part 1: Alpha-2 code

Description: Codes for the Representation of Names of Languages Part 1: Alpha-2 Code. Used as part of the IETF 3066 specification for languages throughout the HL7 specification. This part of ISO 639 provides a code consisting of language code elements comprising two-letter language identifiers for the representation of names of languages. The language identifiers according to this part of ISO 639 were devised originally for use in terminology, lexicography and linguistics, but may be adopted for any application requiring the expression of language in two- letter coded form, especially in computerized systems. The alpha-2 code was devised for practical use for most of the major languages of the world that are not only most frequently represented in the total body of the world’s literature, but which also comprise a considerable volume of specialized languages and terminologies. Additional language identifiers are created when it becomes apparent that a significant body of documentation written in specialized languages and terminologies exists. Languages designed exclusively for machine use, such as computer-programming languages, are not included in this code. The code set is available from http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm? csnumber=22109&ICS1=1&ICS2=140&ICS3=20

ISO 639-2 Alpha-3 Language Codes

Codes for the Representation of Names of Languages Part 2: Alpha-3 Code. Used as part of the IETF 3066 specification for languages throughout the HL7 specification. DeprecationComment: This code system is being deprecated, as the OID identifying it has been replaced with the correct ISO OID of 1.0.639.2

ISO 639-2: Codes for the representation of names of languages -- Part 2: Alpha-3 code

Description: Codes for the representation of names of languages, 3 character alphabetic codes. This has been superceded by ISO 639-3 for many purposes. ISO 639-2 was released in 1998. The code set is available from http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=4767

ISO 639-3 Language Codes Alpha 3

Description: ISO 639-3 is a code that aims to define three-letter identifiers for all known human languages. At the core of ISO 639-3 are the individual languages already accounted for in ISO 639-2. The large number of living languages in the initial inventory of ISO 639-3 beyond those already included in ISO 639-2 was derived primarily from Ethnologue (15th edition). Additional extinct, ancient, historic, and constructed languages have been obtained from Linguist List. SIL International has been designated as the ISO 639-3/RA for the purpose of processing requests for alpha-3 language codes comprising the International Standard, Codes for the representation of names of languages - Part 3: Alpha-3 code for comprehensive coverage of languages. The ISO 639-3/RA receives and reviews applications for requesting new language codes and for the change of existing ones according to criteria indicated in the standard. It maintains an accurate list of information associated with registered language codes which can be viewed on or downloaded from this website, and processes updates of registered language codes. Notification of pending and adopted updates are also distributed on a regular basis to subscribers and other parties.

ISO/IEC 21000-6:2004(E) Rights Data Dictionary

ISO/IEC 21000-6:2004 describes a Rights Data Dictionary which comprises a set of clear, consistent, structured, integrated and uniquely identified terms to support the MPEG-21 Rights Expression Language (REL), ISO/IEC 21000-5. Annex A specifies the methodology for and structure of the RDD Dictionary, and specifies how further Terms may be defined under the governance of a Registration Authority, requirements for which are described in Annex C. Taken together, these specifications and the RDD Dictionary and Database make up the RDD System. Use of the RDD System will facilitate the accurate exchange and processing of information between interested parties involved in the administration of rights in, and use of, Digital Items, and in particular it is intended to support ISO/IEC 21000-5 (REL). Clause 6 describes how ISO/IEC 21000-6:2004 relates to ISO/IEC 21000-5. As well as providing definitions of terms for use in ISO/IEC 21000-5, the RDD System is designed to support the mapping of terms from different namespaces. Such mapping will enable the transformation of metadata from the terminology of one namespace (or Authority) into that of another namespace. Mapping, to ensure minimum ambiguity or loss of semantic integrity, will be the responsibility of the Registration Authority. Provision of automated trm look-up is also a requirement. The RDD Dictionary is a prescriptive dctionary, in the sense that it defines a single meaning for a trm represented by a particular RddAuthorized TermName, but it is also inclusive in that it can recognize the prescription of other Headwords and definitions by other Authorities and incorporates them through mappings. The RDD Dictionary also supports the circumstance that the same name may have different meanings under different Authorities. ISO/IEC 21000-6:2004describes audit provisions so that additions, amendments and deletions to Terms and their attributes can be tracked. ISO/IEC 21000-6:2004 recognizes legal definitions as and only as Terms from other Authorities that can be mapped into the RDD Dictionary. Therefore Terms that are directly authorized by the RDD Registration Authority neither define nor prescribe intellectual property rights or other legal entities.

IUPAC/IFCC Component Codes

IUPAC/IFCC Component Codes

IUPAC/IFCC Property Codes

IUPAC/IFCC Property Codes

IdentifierReliability

Specifies the reliability with which the identifier is known. This attribute MAY be used to assist with identifier matching algorithms.

IdentifierScope

Description: Codes to specify the scope in which the identifier applies to the object with which it is associated, and used in the datatype property II.

Immunization Evaluation Dose Status Reason codes

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the reason why an administered dose has been assigned a particular status. Often, this reason describes why a dose is considered invalid. This value set is provided as a suggestive example.

Immunization Evaluation Dose Status codes

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the validity of a dose relative to a particular recommended schedule. This value set is provided as a suggestive example.

Immunization Funding Source

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the source of the vaccine administered. This value set is provided as a suggestive example.

Immunization Origin Codes

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the source of the data when the report of the immunization event is not based on information from the person, entity or organization who administered the vaccine. This value set is provided as a suggestive example.

Immunization Program Eligibility

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the patient’s eligibility for a vaccination program. This value set is provided as a suggestive example.

Immunization Recommendation Status Codes

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the status of the patient towards perceived immunity against a vaccine preventable disease. This value set is provided as a suggestive example.

Immunization Subpotent Reason

The value set to instantiate this attribute should be drawn from a terminologically robust code system that consists of or contains concepts to support describing the reason why a dose is considered to be subpotent. This value set is provided as a suggestive example.

Implant Status

A set codes that define the functional status of an implanted device.

Industry CDC Census 2010

2010 Industry coding system used by CDC (NIOSH and NCHS) for coding industry text. Industry describes an economic/business sector comprised of businesses/ enterprises concerned with the output of a specified category of products or services.

Insurance plan type

This example value set defines a set of codes that can be used to indicate a type of insurance plan.

IntegrityCheckAlgorithm

** MISSING DESCRIPTION **

Intelligent Medical Objects

IMO is a clinical interface terminology, which helps to map diagnostic, procedure and other terminologies to medical concepts and codes.

International Civil Aviation Organization Sex

ICAO is funded and directed by 193 national governments to support their diplomacy and cooperation in air transport as signatory states to the Chicago Convention (1944) Its core function is to maintain an administrative and expert bureaucracy (the ICAO Secretariat supporting these diplomatic interactions, and to research new air transport policy and standardization innovations as directed and endorsed by governments through the ICAO Assembly, or by the ICAO Council which the assembly elects. ICAO has developed a technical specification (sample version form 2021 here ) to “allow compatibility and global interchange using both visual (eye readable) and machine readable means. The specifications lay down standards for visas which can, where issued by a State and accepted by a receiving State, be used for travel purposes. The MRV[Machine Readable Visa] shall, as a minimum, contain the data specified herein in a form that is legible both visually and by optical character recognition methods..” Further, defining that “Sex of MRV-A[Format A - Machine Readable Visa] holder, when included, is to be specified by use of the single initial commonly used in the language of the State of issue. If translation into English, French or Spanish is necessary, followed by an oblique and the capital letter F for female, M for male, or X for unspecified.” Sex of MRV-B[Format B - Machine Readable Visa] holder, when included, is to be specified by use of the single initial commonly used in the language of the State of issue. If translation into English, French or Spanish is necessary, followed by an oblique and the capital letter F for female, M for male, or X for unspecified.

International Classification for Nursing Practice

ICNP(r) is a combinatorial terminology, using a multi-axial structure. ICNP(r) provides standardized terms and codes for terms in two classifications that can be used to compose or create pre-coordinated concepts to represent observations and procedures, specifically, patient problems/nursing diagnoses, nursing interventions including those focused on assessment and actual or expected (goal) outcomes. The ICNP(r) Classification for Nursing Phenomena is used to compose concepts or statements to represent observations (nursing diagnoses, patient problems, patient status, patient outcomes). The ICNP(r) Nursing Actions Classification is used to compose concepts or statements to represent procedures (nursing interventions)

International Classification of Diseases for Oncology

International Classification of Diseases for Oncology)

International Classification of Diseases for Oncology, version 3.

International Classification of Diseases for Oncology, version 3. For more information see http://www.who.int/classifications/icd/adaptations/oncology/en/.

International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)

The International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM), describes the classification of morbidity and mortality information for statistical purposes and for the indexing of healthcare records by diseases. The ICD-10-CM codes can be used as the value of the Act.cd attribute.

International Classification of Diseases, 11th Revision Mortality and Morbidity Statistics (MMS)

The International Classification of Diseases, 11th Revision Mortality and Morbidity Statistics (MMS) is one of the ICD11 linearizations. Information about the ICD Foundation Component and the ICD11 Linearizations can be found in the complete reference guide here: https://icd.who.int/icd11refguide/en/index.htmlThe ICD11 Linearizations (Tabular lists) A linearization is a subset of the foundation component, that is:

  1. fit for a particular purpose: reporting mortality, morbidity, primary care or other uses;
  2. composed of entities that are Mutually Exclusive of each other;
  3. each entity is given a single parent. Linearization is similar to the classical print versions of ICD Tabular List (e.g. volume I of ICD-10 or other previous editions). The main linearization of ICD-11 is Mortality and Morbidity Statistics (MMS). Various linearizations could be built at different granularity, use case or other purposes such as for Primary Care, Clinical Care or Research. The linkage from the foundation component to a particular linearization will ensure consistent use of the ICD.” ICD-11 for Mortality and Morbidity (ICD-11 MMS) can be downloaded in either print or electronic (spreadsheet) format from the browser in the Info tab located here
International Classification of Functioning, Disability and Health

“The International Classification of Functioning, Disability and Health, known more commonly as ICF, is a classification of health and health-related domains. As the functioning and disability of an individual occurs in a context, ICF also includes a list of environmental factors. ICF is the WHO framework for measuring health and disability at both individual and population levels. ICF was officially endorsed by all 191 WHO Member States in the Fifty-fourth World Health Assembly on 22 May 2001(resolution WHA 54.21 ) as the international standard to describe and measure health and disability. ICF is based on the same foundation as ICD and ICHI and share the same set of extension codes that enable documentation at a higher level of detail.” Official updates to the ICF are available as annual lists of changes. These updates are approved annually at the October meeting of the WHO Family of International Classifications (WHO-FIC) Network. To license ICF, the same rules apply for ICF as for ICD. See http://icd.who.int/. For more information, see https://www.who.int/standards/classifications/international-classification-of-functioning-disability-and-health.

International Classification of Functioning, Disability and Health, Dutch Translation

“The International Classification of Functioning, Disability and Health, known more commonly as ICF, is a classification of health and health-related domains. As the functioning and disability of an individual occurs in a context, ICF also includes a list of environmental factors. ICF is the WHO framework for measuring health and disability at both individual and population levels. ICF was officially endorsed by all 191 WHO Member States in the Fifty-fourth World Health Assembly on 22 May 2001(resolution WHA 54.21 ) as the international standard to describe and measure health and disability. ICF is based on the same foundation as ICD and ICHI and share the same set of extension codes that enable documentation at a higher level of detail.” “The Dutch translation of the ICF is published in book form by BSL. The ICF can also be consulted online in the Classification Browser. The ICF team of the WHO-FIC Collaborating Center combines expertise in the field of the ICF for the Dutch language area and currently consists of delegations from the Netherlands Paramedical Institute, the University Medical Center Groningen, Maastricht University, the Big Move Institute, Stichting Scientific Research Road Safety, University of Ghent, Vilans, and Rehabilitation Center de Hoogstraat.” Official updates to the ICF are available as annual lists of changes. These updates are approved annually at the October meeting of the WHO Family of International Classifications (WHO-FIC) Network. To license ICF, the same rules apply for ICF as for ICD. See http://icd.who.int/. For more information, see https://www.whofic.nl/familie-van-internationale-classificaties/referentie-classificaties/icf.

International Classification of Primary Care 1993 (English)

The International Classification of Primary Care (ICPC). Swedish Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Basque

The International Classification of Primary Care (ICPC). Basque Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Danish

The International Classification of Primary Care (ICPC). Danish Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Dutch

The International Classification of Primary Care (ICPC). Dutch Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Finnish

The International Classification of Primary Care (ICPC). Finnish Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 French

The International Classification of Primary Care (ICPC). French Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 German

The International Classification of Primary Care (ICPC). German Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Hebrew

The International Classification of Primary Care (ICPC). Hebrew Translation, Denmark: World Organisation of Family Doctors, 1993

International Classification of Primary Care 1993 Hungarian

The International Classification of Primary Care (ICPC). Hungarian Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Italian

The International Classification of Primary Care (ICPC). Italian Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Norwegian

The International Classification of Primary Care (ICPC). Norwegian Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Portuguese

The International Classification of Primary Care (ICPC). Portuguese Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Spanish

The International Classification of Primary Care (ICPC). Spanish Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care 1993 Swedish

The International Classification of Primary Care (ICPC). Swedish Translation. Denmark: World Organisation of Family Doctors, 1993.

International Classification of Primary Care, 1993 edition

The International Classification of Primary Care (ICPC). Denmark: World Organisation of Family Doctors, 1993. Various language translations are identified beneath this OID.

International Classification of Primary Care, second edition (1998)

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

International Classification of Primary Care, second edition, English

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

International Classification of Sleep Disorders

International Classification of Sleep Disorders

International Statistical Classification of Diseases and Related Health Problems, 10th Revision, Canada

ICD-10-CA (International Statistical Classification of Diseases and Related Health Problems, 10th Revision, Canada) was developed by the World Health Organization (WHO) and enhanced by CIHI to meet Canadian morbidity data needs. ICD-10-CA classifies diseases, injuries and causes of death, as well as external causes of injury and poisoning. It also includes conditions and situations that are not diseases but represent risk factors to health, such as occupational and environmental factors, lifestyle and psychosocial circumstances.

International System for Human Cytogenomic Nomenclature (ISCN)

The International System for Human Cytogenetic Nomenclature (ISCN) was created by the International Standing committee on Human Cytogenetic Nomenclature to represent the outcome of cytogenetic tests. ISCN specifies the nomenclature to describe karyotypes, chromosome abnormalities, in situ hybridization, etc. ISCN provides a list of symbols and abbreviated terms in adjunction with a set of rules, which can be used in the description of chromosomes and chromosome abnormalities, such as p for short arm of chromosome, q for long arm of chromosome, cen for centromere, del for deletion, ish for in situ hybridization, and plus sign (+) for gain, etc. A LOINC code is created to represent “chromosome analysis results in ISCN expression”. In HL7 v2 messages, this LOINC code is used in OBX-3 with a coded result (CWE data type) that will be sent in OBX-5. The value of the coded result is an ISCN expression, and ISCN will be the code system for the coded result.

Japanese Chemistry

Japanese Chemistry

LanguageAbilityMode

A value representing the method of expression of the language. Example:Expressed spoken, expressed written, expressed signed, received spoken, received written, received signed. OpenIssue: Description copied from Concept Domain of same name. Must be verified.

LanguageAbilityProficiency

A value representing the level of proficiency in a language. Example:Excellent, good, fair, poor. OpenIssue: Description copied from Concept Domain of same name. Must be verified.

LibraryType

The type of knowledge asset this library contains.

List Empty Reasons

General reasons for a list to be empty. Reasons are either related to a summary list (i.e. problem or medication list) or to a workflow related list (i.e. consultation list).

List Order Codes

Base values for the order of the items in a list resource.

LivingArrangement

A code depicting the living arrangements of a person

LocalMarkupIgnore

Tells a receiver to ignore just the local markup tags (local_markup, local_header, local_attr) when value=”markup”, or to ignore the local markup tags and all contained content when value=”all”

LocalRemoteControlState

A value representing the current state of control associated with the device. Examples: A device can either work autonomously (localRemoteControlStateCode=”Local”) or it can be controlled by another system (localRemoteControlStateCode=”Remote”). Rationale: The control status of a device must be communicated between devices prior to remote commands being transmitted. If the device is not in “Remote” status then external commands will be ignored.

Location type

This example value set defines a set of codes that can be used to indicate the physical form of the Location. This includes several ‘non physical’ codes which are still considered a location.

Locus Reference Genomic Sequences (LRG)

In collaboration with NCBI, the European Bioinformatics Institute (EBI) is developing the Locus Reference Genomic Sequences (LRG) database, which is a database of reference sequences. LRG is a system for providing a genomic DNA sequence representation of a single gene that is idealized, has a permanent ID (with no versioning), and core content that never changes. LRG is not a nomenclature system. More than one LRG could be created for a region of interest, should that need arise. Additional annotations will be present that may change with time (each item carrying its own date stamp), so that the latest ancillary knowledge about a gene is directly available. In other words, an LRG sequence and its core annotation are not meant to represent current biology knowledge, but to provide a standard for reporting variation in a stable coordinate system. The combination of the LRG plus the updatable-annotation layer will be used to support the biological interpretation of variants. LRG identifiers can be used with the HL7 coded data type (code data type that accepts expression data, or a coded expression data type). This coded data type will be gene symbols can be used with the HL7 coded data type. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model, LRG identifiers can be used to as the observation values for Genomic Reference Sequence Identifier (LOINC code: 48013-7). LRG is a database that can be used freely by the public.

Logical Observation Identifiers, Names and Codes (LOINC)

LOINC provides a set of universal names and ID codes for identifying laboratory and clinical test results.1,2 LOINC facilitates the exchange and pooling of results, such as blood hemoglobin, serum potassium, or vital signs, for clinical care, outcomes management, and research. LOINC’s universal identifiers (names and codes) can be used in the context of order and observation exchanges between information systems that use syntax standards such as HL73, CEN TC251, ISO TC215, ASTM4, and DICOM. Specifically, the identifier can be used as the coded value for an observation in any other standard that uses the observation/observation value paradigm, whether messages, documents, application programming interface (API), etc. For example, LOINC codes are used widely in the OBX segment Observation Identifier field (OBX-3) of an ORU HL7 (HL7 version 2.x or ASTM 1238-9410) message that may be sent between a Clinical Laboratory Information Management Systems (LIMS) and Electronic Health Record Systems (EHR).5, 6 In this way, LOINC codes provide universal identifiers that allow the exchange of clinical data between heterogeneous computing environments.

MDDID

Medispan Drug Descriptor ID Entry autogenerated to support Sources from the UMLS. Full metadata set still incomplete.

MDFAttributeType

Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

MDFSubjectAreaPrefix

The standard prefixes used in Rose for RIM subject areas that determine the role or function of each subject area. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

MDNS

MDNS

MEDCIN

MEDCIN contains more than 175,000 clinical data elements arranged in a hierarchy, with each item having weighted links to relevant diagnoses. The clinical data elements are organized into six basic termtypes designed to accommodate information relevant to a clinical encounter. The basic termtypes in MEDCIN’s terminological hierarchy are as follows: Symptoms History Physical Examination Tests Diagnoses Therapy Within this basic structure, MEDCIN terms are further organized in a ten level terminological hierarchy, supplemented by an optional, multi-hierarchical diagnostic index. For example, the symptom of “difficulty breathing” is placed in the terminological hierarchy as a subsidiary (or “child”) finding of “pulmonary symptoms,” although the presence (or absence) of difficulty breathing can related to conditions as diverse as myocardial infarction, bronchitis, pharyngeal foreign bodies, asthma, pulmonary embolism, etc. MEDCIN’s diagnostic index provides more than 800 such links for difficulty breathing.

METABOLIC SYNDROME

A collection of metabolic risk factors in one individual. The root causes of metabolic syndrome are overweight / obesity, physical inactivity, and genetic factors. Various risk factors have been included in metabolic syndrome. Factors generally accepted as being characteristic of this syndrome include abdominal obesity, atherogenic dyslipidemia, raised blood pressure, insulin resistence with or without glucose intolerance, prothrombotic state, and proinflammatory state.

MIME

IETF MIME media types

MTH MedDRA Spanish

Metathesaurus Forms of Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, Spanish Edition. Bethesda, MD: National Library of Medicine, March 2004.

ManagedParticipationStatus

Codes representing the defined possible states of a Managed Participation, as defined by the Managed Participation class state machine.

ManufacturerModelNameExample

This code system serves to capture the ManufacturerModelName concept domain used to convey a coded name for a device.

Manufacturers of Vaccines (MVX)

“The CDC’s National Center for Immunization and Respiratory Diseases (NCIRD) developed and maintains HL7 Table 0227, Manufacturers of Vaccines (MVX). It includes both active and inactive manufacturers of vaccines in the US. Inactive MVX codes allow transmission of historical immunization records. When MVX code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated. MVX is the underlying Master Code System for V2 table 0227 (Manufacturers Of Vaccines (code=MVX)). The machine readable name for MVX in PHIN VADS is PH_VaccinesAdministeredCVX_CDC_NIP. Status indicates if the manufacturer is currently making vaccine for distribution in the United States. Last Updated indicates the last time this particular manufacturer code was updated in this table. Questions regarding MVX should be directed to the IIS Technical Assistance Team(or use mailing address).” For more information, please see here.

MapRelationship

The closeness or quality of the mapping between the HL7 concept (as represented by the HL7 concept identifier) and the source coding system. The values are patterned after the similar relationships used in the UMLS Metathesaurus. Because the HL7 coding sy

MaritalStatus

* * * No description supplied * * * Open Issue: The specific meanings of these codes can vary somewhat by jurisdiction and implementation so caution should be used when determining equivalency. Open Issue: fixing and completion of the hierarchy and proper good definitions of all the concepts is badly needed.

MatchGrade

A Master Patient Index (MPI) assessment of whether a candidate patient record is a match or not.

MaterialForm

A value representing the state (solid, liquid, gas) and nature of the material. Open Issue: There exist no codes in the repository for this coding system; should it be removed?

MaterialType

Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used. This is outside the hierarchy and there’s already an equivalent domain MaterialEntityClass in the right hierarchy. The corresponding code system is empty.

MaxOccurs

Flags an element as having unlimited repetitions.

MdfHmdMetSourceType

Code to identify the source of a Message Element Type represented in the ‘of MET’ column of an HMD. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

MdfHmdRowType

The row type codes for the tabular representation of a Hierarchical Message Description. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

MdfRmimRowType

The row types for the tabular representation of an R-MIM. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

Measure Aggregate Method

Aggregation method for a measure (e.g. sum, average, median, minimum, maximum, count)

MeasureDataUsage

The intended usage for supplemental data elements in the measure.

MeasureImprovementNotation

Observation values that indicate what change in a measurement value or score is indicative of an improvement in the measured item or scored issue.

MeasurePopulationType

The type of population.

MeasureScoring

The scoring type of the measure.

MeasureSupplementalData

Identifier supplemental data in a population for measuring purposes.

MeasureType

The type of measure (includes codes from 2.16.840.1.113883.1.11.20368).

MedDRA Am Engl

Medical Dictionary for Regulatory Activities Terminology (MedDRA), American English Equivalents, Version 7.0. Bethesda, MD: National Library of Medicine, March 1, 2004 This is the English language version as encapsulated in the UMLS..

MedDRA Am Engl expanded

Medical Dictionary for Regulatory Activities Terminology (MedDRA), American English Equivalents with expanded abbreviations, Version 7.0. Bethesda, MD: National Library of Medicine, March 1, 2004.

MedDRA Dutch

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, Dutch Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004 This is the Dutch language version as encapsulated in the UMLS..

MedDRA French

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, French Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004 This is the French language version as encapsulated in the UMLS..

MedDRA German

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, German Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004 This is the German language version as encapsulated in the UMLS..

MedDRA Portuguese

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, Portuguese Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004. This is the Portuguese language version as encapsulated in the UMLS..

MedDRA Spanish

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, Spanish Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004. This is the Spanish language version as encapsulated in the UMLS..

MedDRA expanded

Medical Dictionary for Regulatory Activities Terminology (MedDRA), with expanded abbreviations, Version 7.0. Bethesda, MD: National Library of Medicine, March 1, 2004.

Media Type

Internet Assigned Numbers Authority (IANA) Mime Media Types. Identifies the type of the encapsulated data and identifies a method to interpret or render the data. The IANA defined domain of media types is established by the Internet standard RFC 2045 [http://www.ietf.org/rfc/rfc2045.txt] and 2046 [http://www.ietf.org/rfc/rfc2046.txt]. RFC 2046 defines the media type to consist of two parts:

  1. top level media type, and
  2. media subtype However, this HL7 datatypes specification treats the entire media type as one atomic code symbol in the form defined by IANA, i.e., top level type followed by a slash “/” followed by media subtype. Currently defined media types are registered in a database [http://www.iana.org/assignments/media-types/index.html] maintained by IANA. Currently several hundred different MIME media types are defined, with the list growing rapidly. In general, all those types defined by the IANA MAY be used.
Medical Dictionary for Regulatory Activities

MedDRA is a multilingual standardised international medical terminology which can be used for regulatory communication and evaluation of data pertaining to medicinal products for human use. MedDRA is designed for use in the registration, documentation and safety monitoring of medicinal products through all phases of the development cycle (i.e., from clinical trials to post-marketing surveillance).#13; MedDRA is structured as a five level hierarchy. System Organ Classes (SOCs) are the broadest terms (e.g., Cardiac disorders, Investigations). The lowest level of the terminology is the Lowest Level Term (LLT) level.

Medical Economics Diagnostic Codes

Medical Economics Diagnostic Codes

Medical Economics Drug Codes

Medical Economics Drug Codes

Medical Subject Headings

The Medical Subject Headings (MeSH) thesaurus is a controlled and hierarchically-organized vocabulary produced by the National Library of Medicine. It is used for indexing, cataloging, and searching of biomedical and health-related information. MeSH includes the subject headings appearing in MEDLINE/PubMed, the NLM Catalog, and other NLM databases. MeSH can be downloaded from https://www.nlm.nih.gov/databases/download/mesh.html MeSH can be browsed here: https://meshb.nlm.nih.gov/search

Medicare Severity Diagnosis Related Groups (MS-DRGs)

Section 1886(d) of the Act specifies that the Secretary shall establish a classification system (referred to as DRGs) for inpatient discharges and adjust payments under the IPPS based on appropriate weighting factors assigned to each DRG. Therefore, under the IPPS, we[CMS] pay for inpatient hospital services on a rate per discharge basis that varies according to the DRG to which a beneficiary’s stay is assigned. The formula used to calculate payment for a specific case multiplies an individual hospital’s payment rate per case by the weight of the DRG to which the case is assigned. Each DRG weight represents the average resources required to care for cases in that particular DRG, relative to the average resources used to treat cases in all DRGs. Congress recognized that it would be necessary to recalculate the DRG relative weights periodically to account for changes in resource consumption. Accordingly, section 1886(d)(4)(C) of the Act requires that the Secretary adjust the DRG classifications and relative weights at least annually. These adjustments are made to reflect changes in treatment patterns, technology, and any other factors that may change the relative use of hospital resources. Currently, cases are classified into Medicare Severity Diagnosis Related Groups (MS-DRGs) for payment under the IPPS based on the following information reported by the hospital: the principal diagnosis, up to 25 additional diagnoses, and up to 25 procedures performed during the stay. In a small number of MS-DRGs, classification is also based on the age, sex, and discharge status of the patient. Effective October 1, 2015, the diagnosis and procedure information is reported by the hospital using codes from the International Classification of Diseases, Tenth Revision, Clinical Modification (ICD-10-CM) and the International Classification of Diseases, Tenth Revision, Procedure Coding System (ICD-10-PCS). Content can be obtained on the CMS hosted page located at https://www.cms.gov/Medicare/Medicare-Fee-for-Service-Payment/AcuteInpatientPPS/MS-DRG-Classifications-and-Software The DRGs are released annually with errata published infrequently. The fiscal year and release version should be noted (e.g., 2021.38.R1). Requests for annual MS-DRG classification changes and any MS-DRG related inquiries should be sent to the MSDRGClassificationChange@cms.hhs.gov mailbox. For additional information on the MS-DRG system, including yearly reviews and changes to the MS-DRGs, please view prior Inpatient Prospective Payment System (IPPS) proposed and final rules located in the left navigational area of https://www.cms.gov/Medicare/Medicare-Fee-for-Service-Payment/AcuteInpatientPPS/MS-DRG-Classifications-and-Software

Medication Reference Terminology (MED-RT)

Medication Reference Terminology (MED-RT) is the evolutionary successor to the Veterans Health Administration National Drug File – Reference Terminology (VHA NDF-RT). Both are formal ontology representations of medication terminology, pharmacologic classifications, and asserted authoritative relationships between them. The MED-RT code system includes relationships between MED-RT concepts and concepts in external code systems, as well as relationships between concepts only in the external code systems. The external code systems that MED-RT references include RxNorm, MeSH, and SNOMED CT US Edition. MED-RT can be downloaded from https://evs.nci.nih.gov/ftp1/MED-RT/ For more information, please see https://ncit.nci.nih.gov/ncitbrowser/pages/vocabulary.jsf?dictionary=MED-RT

Medication request administration location codes

MedicationRequest Administration Location Codes

MedicationAdministration Location Codes

MedicationAdministration Location Codes

MedicationAdministration Performer Function Codes

MedicationAdministration Performer Function Codes

MedicationDispense Performer Function Codes

MedicationDispense Performer Function Codes

MedicationKnowledge Characteristic Codes

MedicationKnowledge Characteristic Codes

MedicationKnowledge Package Type Codes

MedicationKnowledge Package Type Codes

MedicationKnowledge Status Codes

MedicationKnowledge Status Codes

MedicationRequest Category Codes

MedicationRequest Category Codes

MedicationRequest Course of Therapy Codes

MedicationRequest Course of Therapy Codes

MedicationRequest Status Reason Codes

MedicationRequest Status Reason Codes

MedicationUsage Administration Location Codes

MedicationUsage Administration Location Codes

Medispan Diagnostic Codes

Medispan Diagnostic Codes

Medispan GPI

Medispan GPI

MessageCondition

Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.This isn’t referenced in the RIM and is a copy of old v2 codes. It’s superseded by AcknowledgementDetailCode

MessageWaitingPriority

Indicates that the receiver has messages for the sender OpenIssue: Description does not make sense relative to name of coding system. Must be reviewed and improved.

Missing Tooth Reason Codes

This value set includes sample Missing Tooth Reason codes.

Modifier type Codes

This value set includes sample Modifier type codes.

ModifyIndicator

Indicates whether the subscription to a query is new or is being modified.

Mondo Disease Ontology

The Mondo Disease Ontology is a semi-automatically constructed ontology that merges in multiple disease resources to yield a coherent merged ontology that contains cross-species disease terminology. Numerous sources for disease definitions and data models currently exist, which include HPO, OMIM, SNOMED CT, ICD, PhenoDB, MedDRA, MedGen, ORDO, DO, GARD, etc; however, these sources partially overlap and sometimes conflict, making it difficult to know definitively how they relate to each other. This has resulted in a proliferation of mappings between disease entries in different resources; however mappings are problematic: collectively, they are expensive to create and maintain. Most importantly, the mappings lack completeness, accuracy, and precision; as a result, mapping calls are often inconsistent between resources. The UMLS provides intermediate concepts through which other resources can be mapped, but these mappings suffer from the same challenges: they are not guaranteed to be one-to-one, especially in areas with evolving disease concepts such as rare disease. In order to address the lack of a unified disease terminology that provides precise equivalences between disease concepts, we created Mondo, which provides a logic-based structure for unifying multiple disease resources. Mondo’s development is coordinated with the Human Phenotype Ontology (HPO), which describes the individual phenotypic features that constitute a disease. Like the HPO, Mondo provides a hierarchical structure which can be used for classification or “rolling up” diseases to higher level groupings. It provides mappings to other disease resources, but in contrast to other mappings between ontologies, we precisely annotate each mapping using strict semantics, so that we know when two disease names or identifiers are equivalent or one-to-one, in contrast to simply being closely related. For more information, see https://mondo.monarchinitiative.org/

Multum Lexicon

Broadly, the fields and values in the Multum Lexicon and the VantageRx Database are intended to be available for use in any HL7 message that includes a reference to non-veterinary drug products or active ingredients that are either approved for sale by the FDA or readily available in the United States. The following inter-related definitions recently circulated by us to the HL7 Vocabulary Technical Committee explain the scope of what we mean by “drug product” and “active ingredient”. (A definition for “drug ingredient” is also provided here because the definition of “active ingredient” is reliant on this term.) Drug Product A drug product is a manufactured or extemporaneously-compounded physiologically-active material intended by the preparer to achieve therapeutic, diagnostic, or preventative effects via biochemical mechanisms when applied to an epithelial surface or placed in an internal body space of a targeted organism. Drug Ingredient A drug ingredient is a chemical compound or biologic agent that occurs in a drug product. Active Ingredient An active ingredient is a drug ingredient that mediates one or more of the intended therapeutic, diagnostic, or preventative effects of a drug product and is present in sufficient quantities to achieve such effects according to the allopathic tradition of healthcare practice.

NAACCR

NAACCR Cancer Registry

NANDA International

The NANDA-I classification is a set of nursing diagnoses developed by the NANDA International. This purpose of the terminology is to provide nursing diagnoses used to describe patients’ responses to actual or potential health problems and life processes responses to diseases rather than classifying the conditions of diseases and disorders.

NCI Thesaurus

NCI Thesaurus NCI Thesaurus is a biomedical thesaurus created specifically to meet the needs of the cancer research community, especially those engaged in translational research NCI Thesaurus is produced by the NCI Enterprise Vocabulary Services project. The NCI Thesaurus is provided under an open content license.

NCI Version of NDF-RT

The National Drug File RT (NDF-RT) is published by the US Veterans’ Administration (VA). NDF-RT covers clinical drugs used at the VA. The NCI version of NDF-RT is used by NCI to provide automated terminology access to the Food and Drug Administration (FDA) Structured Product Label (SPL) initiative. NCI makes its version of NDF-RT available publicly thru the Web, download via FTP and via open APIs for Java, SOAP and HTTP.

NCPDP Brand Generic Indicator

Denotes brand or generic drug dispensed.

NCPDP Compound Code

Code indicating whether or not the prescription is a compound.

NCPDP Dispense As Written (DAW)/Product Selection Code

Code indicating whether or not the prescriber’s instructions regarding generic substitution were followed.

NCPDP Pharmacy Type

Type of pharmacy.

NCPDP Prescription Origin Code

Code indicating the origin of the prescription. Indicates whether the prescription was transmitted as an electronic prescription, by phone, by fax, or as a written paper copy.

NCPDP Provider Identification Number

A NCPDP assigned number that provides pharmacies with a unique, 7-digit national identifying number that assists pharmacies in their interactions with federal agencies and third party providers. The NCPDP Provider Identification Number was formerly known as the NABP (National Board of Pharmacy) number. NCPDP also enumerates licensed dispensing sites in the United States as part of its Alternate Site Enumeration Program Numbering System (ASEP). The purpose of this system is to enable a site to identify itself to all third party processors by one standard number, in order to adjudicate claims and receive reimbursement from prescription card programs.

NCPDP Reject Code

Code indicating the error encountered. Contains exception definitions for use when transaction processing cannot be completed.

NHSN BSI Risk Factors

NHSN Blood Stream Infection Risk Factors

NHSN HAI Vocabulary

NHSN HAI Vocabulary used for Single Value bindingsto Observation Identifier

NHSN Healthcare Facility Patient Care Location

A classification of patient care locations within healthcare facilities for public health purposes.

NHSN Hip Replacement

NHSN Hip Replacement

NHSN Infection Type

NHSN Infection Type

NHSN KneeR eplacement

NHSN Knee Replacement

NHSN LCBI Pathways

NHSN Laboratory Confirmed Bloodstream Infection Pathways

NHSN Occasion Of Detection

NHSN Occasion Of Detection

NHSN Procedure Category

NHSN Procedure Category

NHSN SSI Anatomic Site

NHSN Surgical Site Infection Anatomic Site

NHSN SSI Location Type

NHSN SSI LocationType

NHSN Spinal Fusion Approach

NHSN Spinal Fusion Approach

NHSN Spinal Fusion Level

NHSN Spinal Fusion Level

NHSN Summary Data

NHSN Summary Data

NHSN Surveillance System Codes

A set of healthcare surveillance vocabulary concepts and associated identifiers intended solely for data submissions to the National Healthcare Safety Network (NHSN). Other uses are not recommended. The CDCNHSN code system is highly specialized to meet the needs of NHSN surveillance reporting, is undergoing changes, and is not recommended for creating value sets to be used outside of NHSN.

NOC

NOC - Nursing Outcome Codes

NUCC Health Care Provider Taxonomy

The Provider Taxonomy Code List is published (released) twice a year on July 1st and January 1st. The July publication is effective for use on October 1st and the January publication is effective for use on April 1st. The time between the publication release and the effective date is considered an implementation period to allow providers, payers and vendors an opportunity to incorporate any changes into their systems. This listing includes Active codes approved for use effective April 1st, 2003, version 3.0; and codes that are New and approved for use effective October 1st, 2003, version 3.1. It was identified that there is an IP licensure issue with the republishing of the content for this code system by HL7, so the content was removed as of the July 2016 Harmonization cycle release. This external code system content may be accessed from the web page located at http://www.nucc.org/index.php/code-sets-mainmenu-41/provider-taxonomy-mainmenu-40. Multiple formats and means of accessing the content are available from this page. Note this code system stub has been retired; it is missing the copyright information, and has been superceded.

National Center for Health Statistics

The International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM), Volumes I, II (diagnoses) and III (procedures) describes the classification of morbidity and mortality information for statistical purposes and for the indexing of healthcare records by diseases and procedures. The ICD-9-CM codes can be used as the value of the Act.cd attribute.

National Center for Health Statistics

The International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM), Volumes I, II (diagnoses) and III (procedures) describes the classification of morbidity and mortality information for statistical purposes and for the indexing of healthcare records by diseases and procedures. The ICD-9-CM codes can be used as the value of the Act.cd attribute.

National Drug Data File

National Drug Data File Plus Source Vocabulary 2004. San Bruno, CA: First DataBank, March 11, 2004. This entry was generated to support the Sources in the UMLS. Additional metadata is still missing.

National Drug File Reference Terminology (NDF-RT)

NDF-RT is a concept-oriented terminology, a collection of concepts, each of which represents a single, unique meaning. Every concept has one fully-specified name and an arbitrary number of other names, all of which are intended to mean the same thing and are therefore synonymous terms. Synonymous terms from external vocabulary sources may have associated unique identifiers. Publication of NDF-RT has ended. The Medication Reference Terminology (MED-RT) is the evolutionary successor to the NDF-RT.

National Uniform Billing Council, UB 92

National Uniform Billing Council, UB 92

National drug codes

National drug codes

Need

The frequency with which the target must be validated

Network Type Codes

This value set includes a smattering of Network type codes.

North American Industry Classification System

North American Industry Classification System(NAICS) for the United States, a new economic classification system that replaces the 1987 Standard Industrial Classification (SIC) for statistical purposes. NAICS is a system for classifying establishments by type of economic activity. Its purposes are: (1) to facilitate the collection, tabulation, presentation, and analysis of data relating to establishments, and (2) to promote uniformity and comparability in the presentation of statistical data describing the economy. NAICS will be used by Federal statistical agencies that collect or publish data by industry.

NullFlavor

A collection of codes specifying why a valid value is not present.

Nursing Intervention Classification

NIC provides names and values for procedures/orders/service intent related to the treatment activities of nurses and other providers who may perform the same treatment activities. Names, definitions, and associated codes are attached for 486 interventions. Defining activities (anywhere from ten to several dozen) are listed for each of the interventions in the NIC classification book but are not attached to this document.

Nursing Management Minimum Data Set

The NMMDS is the minimum set of items of information with uniform definitions and categories concerning the specific dimension of the context of patient care delivery. It represents the minimum data used to support the management and administration of patient/nursing care delivery across all types of settings. The NMMDS is composed of seventeen (17) data elements organized into three categories: environment, nurse resources, and financial resources. See Tables 1-3 for the elements and related definitions organized by each categories. The NMMDS most appropriately focuses at the first level of accountability for patient/client/family/community nursing care: this may be the delivery unit, service, or center of excellence level. The NMMDS supports numerous constructed variables as well as aggregation of data at the unit, institution, network, and system, etc levels. This minimum data set provides the structure for the collection of uniform information that influences quality of patient care, directly and indirectly.

Nursing Minimum Data Set

The NMDS is the minimum set of items of information with uniform definitions and categories concerning the specific dimension of the context of patient care delivery. It represents the minimum data used to support the management and administration of patient/nursing care delivery across all types of settings.

Nutrition intake category codes

NutritionIntake Category Codes

OHDSI Standardized Vocabularies

Standardized Vocabularies are an integral part of the OMOP CDM. The Standardized Vocabularies contain all of the code sets, terminologies, vocabularies, nomenclatures, lexicons, thesauri, ontologies, taxonomies, classifications, abstractions, and other such data that are needed for:

  • Generation of the transformed (i.e., standardized) data from the raw source dataset into the OMOP CDM,
  • Searching, querying and extraction of the transformed data, and browsing and navigating the hierarchies of classes and abstractions inherent in the transformed data, and
  • Interpreting the meanings of the data. This asset is available for free to anyone and can be downloaded from the Atena download page in a delimited file format. To manage the change of content, but to allow users to use and refer to a defined set of vocabularies, the whole resource is issued in releases. Major changes to the OMOP Vocabulary is released twice yearly in February and August. Instead of a major / minor version scheme, the releases of the Standardized Vocabularies component of the OMOP Vocabulary are tagged with the release date. Version label is based on the version of the CDM its aligned-to, plus a suffix appended incremented based on release date, for example: “v5.0 31-MAY-23.” At this time prior versions of the OMOP Vocabulary are not publicly available. Each release is accompanied by a standard release note, containing information about:
  • Domain changes
  • Newly added concepts grouped by vocabulary_id and domain
  • Standard concept changes
  • Newly added concepts and their standard concept status
  • Changes of concept mapping status grouped by target domain Additional details about the OMOP Vocabulary release notes can be found here
OMAHA Tangram Medical Terminology

OMAHA Tangram Medical Terminology is an ontology-based medical terminological resource developed by Chinese language. It helps to standardize the expression of Chinese medical terms, and improve the semantic interoperability between different systems. The terminology can be used in electronic health records, decision support systems and digital health researches, providing the functions of mapping, data capture, data mining, data registries, statistical analysis and reasoning etc. Tangram Medical Terminology is released quarterly using the file name format as Tangram_Medical_Terminology _YYYYMMDD (Example: Tangram _Medical_Terminology _20200120). For more information, please visit http://wiki.omaha.org.cn/pages/viewpage.action?pageId=31425763 For more information, see https://term.omaha.org.cn/.

Observation Category Codes

Observation Category codes.

Observation Reference Range Meaning Codes

This value set defines a set of codes that can be used to indicate the meaning/use of a reference range for a particular target population.

ObservationCategory

High level observation categories for the general type of observation being made. URL: http://hl7-fhir.github.io/valueset-observation-category.html This is an inline code system http://hl7.org/fhir/observation-category.

ObservationInterpretation

One or more codes providing a rough qualitative interpretation of the observation, such as “normal” / “abnormal”, “low” / “high”, “better” / “worse”, “resistant” / “susceptible”, “expected” / “not expected”. The value set is intended to be for ANY use where coded representation of an interpretation is needed.

ObservationMethod

A code that provides additional detail about the means or technique used to ascertain the observation. Examples: Blood pressure measurement method: arterial puncture vs. sphygmomanometer (Riva-Rocci), sitting vs. supine position, etc. OpenIssue: Description copied from Concept Domain of same name. Must be verified. Note that the Domain has a full discussion about use of the attribute and constraining that is not appropriate for the code system description. Needs to be improved.

ObservationValue

This code system covers all concepts of HL7-defined values for the Observation value element, when it has a coded datatype.

Occupation CDC Census 2010

2010 Occupation coding system used by CDC (NIOSH and NCHS) for coding occupation text. Occupation describes a set of activities or tasks that individuals are paid to perform or, if unpaid, define a person’s contribution to a household/family business/community.

Occupational Data for Health (ODH)

The concepts representing the values supporting Occupational Data for Health, including Job Supervisory Level or Pay Grade (ODH) code system consists of data elements that describe a person’s work information, structured to facilitate individual, population, and public health use; not intended to support billing.).

Omaha System

The Omaha System provides standardized terms, definitions, and codes for observations and procedures, specifically for client problems, multidisciplinary interventions including those focusing on assessment and care, and problem-specific client outcomes.

Online Product Identification Number Index of Nova Scotia

Codes to identify products and services that do not have DIN’s and which need to be billed. http://www.atlanticpharmaceutical.ca/default.asp?mn=5.23

Open Eligibility Taxonomy

“The Open Eligibility Project is a collaborative for a series of standards for the human services sector. The Open Eligibility taxonomy is a simple way to categorize human services and human situations. With these common categories, we, as service providers, navigators, and people in need, can find human services quickly and easily.” “The Open Eligibility taxonomy consists of two important concepts: Human Services and Human Situations. Human Services are services offered by government or charitable organizations, and include things such as housing, food pantries or counseling services. Human Situations are ways of describing attributes of a person that could help them find programs they are looking for, including examples like: veterans, physical disability or seniors.” For more information, see https://support.findhelp.com/hc/en-us/articles/4404055283227-The-Open-Eligibility-Project

Operation Outcome Codes

Operation Outcome codes used by FHIR test servers (see Implementation file translations.xml)

Oral Site Codes

This value set includes a smattering of FDI oral site codes.

Orderable Drug Form

OpenIssue: Missing description.

Organization type

This example value set defines a set of codes that can be used to indicate a type of organization.

OrganizationNameType

Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used. All of these are maintained under EntityNameType. This was created in error and should never be used.

PH_RaceAndEthnicity_CDC

Code system of concepts specifying the patient’s race. Used in HL7 Version 2.x messages in the PID segment. This code system includes codes used decades ago are are maintained here for historical purposes such as searching in past history records. These codes were formally deprecated in V2.9 and retired in THO in 2021. Please reference http://build.fhir.org/ig/HL7/UTG/CodeSystem-CDCREC for the current CDC Race and Ethnicity code system.

POS Codes

POS Codes

ParameterizedDataType

Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

Participant type

This value set defines a set of codes that can be used to indicate how an individual participates in an encounter.

ParticipationFunction

This code is used to specify the exact function an actor had in a service in all necessary detail. This domain may include local extensions (CWE).

ParticipationMode

A set of codes specifying the modality by which the Entity playing the Role is participating in the Act. Examples: Physically present, over the telephone, written communication. Rationale: Particularly for author (originator) participants this is used to specify whether the information represented by the act was initially provided verbally, (hand-)written, or electronically. Open Issue: There needs to be a reexamination of the hierarchies as there seems to be some muddling between ELECTRONIC and other concepts that involve electronic communication that are in other hierarchies.

ParticipationSignature

A set of codes specifying whether and how the participant has attested his participation through a signature and or whether such a signature is needed. Examples: A surgical Procedure act object (representing a procedure report) requires a signature of the performing and responsible surgeon, and possibly other participants. (See also: Participation.signatureText.)

ParticipationType

A code specifying the meaning and purpose of every Participation instance. Each of its values implies specific constraints on the Roles undertaking the participation.

PatientImportance

Patient VIP code

Payee Type Codes

Codes indicating the type of party to be reimbursed for cost of products and services.

PayeeResourceType

The type of payee Resource.

Payment Adjustment Reason Codes

This value set includes smattering of Payment Adjustment Reason codes.

Payment Status Codes

This value set includes a sample set of Payment Status codes.

Payment Type Codes

This value set includes sample Payment Type codes.

PaymentTerms

Describes payment terms for a financial transaction, used in an invoice. This is typically expressed as a responsibility of the acceptor or payor of an invoice.

PeriodicIntervalOfTimeAbbreviation

** MISSING DESCRIPTION **

Perioperative Nursing Data Set

The PNDS provides standardized terms and codes for patient problems/nursing diagnoses, nursing interventions including actual or expected (goal) outcomes. The PNDS provides standardized terms and codes for nursing diagnoses (a subset of NANDA), nursing interventions and outcomes. The outcomes and interventions are in a relational database. The PNDS intervention and outcome statements are attached in an Access Database. The NANDA diagnoses in the PNDS have already been registered by HL7.

PersonDisabilityType

A code identifying a person’s disability.

PlanDefinitionType

The type of PlanDefinition.

Possible Concept Code Relationships

Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used.

PostalAddressUse

Deprecation Comment: This code system was deprecated as of the November 2007 harmonization meeting. The content was folded into AddressUse (2.16.840.1.113883.5.1119), which replaces this code system.

Practitioner role

This example value set defines a set of codes that can be used to indicate the role of a Practitioner.

Primary-source-type

Type of the validation primary source

ProbabilityDistributionType

** MISSING DESCRIPTION **

Process Priority Codes

This value set includes the financial processing priority codes.

ProcessingID

Codes used to specify whether a message is part of a production, training, or debugging system.

ProcessingMode

This attribute defines whether the message is being sent in current processing, archive mode, initial load mode, restore from archive mode, etc.

Program

This value set defines an example set of codes that could be can be used to classify groupings of service-types/specialties.

Provenance participant type

The type of participation a provenance participant.

Push-type-available

Type of alerts/updates the primary source can send

QualityOfEvidenceRating

A rating system that describes the quality of evidence such as the GRADE, DynaMed, or Oxford CEBM systems.

Quantity Units

HL7-defined code system of concepts specifying the adjustment quantity.

QueryParameterValue

The domain of coded values used as parameters within QueryByParameter queries.

QueryPriority

Identifies the time frame in which the response is expected.

QueryQuantityUnit

Values in this domain specify the units of a query quantity limited request. Deprecation Comment: Deprecated as per 11/2008 Harmonization cleanup; internal and obsolete HL7 usage, no longer used. This is a holdover. It is not referenced. It is superseded by QueryRequestLimit.

QueryRequestLimit

Definition: Defines the units associated with the magnitude of the maximum size limit of a query response that can be accepted by the requesting application.

QueryResponse

A code classifying the general nature of the response to a given query. Includes whether or not data was found, or whether an error occurred.

QueryStatusCode

A code specifying the state of the Query.

QuestionnaireItemUsageMode

Identifies the modes of usage of a questionnaire that should enable a particular questionnaire item.

Race

Deprecation Information: Deprecated per UP-263. This code system is NOT the acknowledged source of truth for Race concepts and codes. It should no longer be used. https://terminology.hl7.org/CodeSystem-CDCREC.html should be used in its place. In the United States, federal standards for classifying data on race determine the categories used by federal agencies and exert a strong influence on categorization by state and local agencies and private sector organizations. The federal standards do not conceptually define race, and they recognize the absence of an anthropological or scientific basis for racial classification. Instead, the federal standards acknowledge that race is a social-political construct in which an individual’s own identification with one more race categories is preferred to observer identification. The standards use a variety of features to define five minimum race categories. Among these features are descent from “the original peoples” of a specified region or nation. The minimum race categories are American Indian or Alaska Native, Asian, Black or African American, Native Hawaiian or Other Pacific Islander, and White. The federal standards stipulate that race data need not be limited to the five minimum categories, but any expansion must be collapsible to those categories.

RadLex radiology lexicon

RadLex is a comprehensive set of radiology terms for use in radiology reporting, decision support, data mining, data registries, education and research. RadLex Playbook is a project of the Radiological Society of North America (RSNA), and constitutes a portion of the RadLex ontology. Playbook aims to provide a standard system for naming radiology procedures, based on the elements which define an imaging exam such as modality and body part. By providing standard names and codes for radiologic studies, Playbook is intended to facilitate a variety of operational and quality improvement efforts, including workflow optimization, chargemaster management, radiation dose tracking, enterprise integration and image exchange. As of RadLex Playbook version 2.5, a four-year project to harmonize RadLex Playbook with the radiology portion of the LOINC standard has been concluded, leading to the LOINC-RSNA Radiology Playbook which is jointly managed by the Regenstrief Institute (publisher of LOINC) and RSNA. This harmonized Playbook defines a new information model for describing imaging procedures, and identifies correspondences between RadLex Playbook codes and LOINC codes. (See https://loinc.org/download/loinc-users-guide and http://pubs.rsna.org/doi/pdf/10.1148/rg.2017160188 for details.) Note that RadLex Playbook codes start with “RPID” followed by a numerical value. LOINC codes consist of a numerical code, followed by a hyphen and a single additional digit (called the check digit). Note that in the future, new codes will be created in the LOINC format only, not the RPID format. New adopters are encouraged to use LOINC-format codes. LOINC-format codes may be accessed at http://search.loinc.org. New code requests may be submitted to the joint Regenstrief-RSNA governance committee at https://loinc.org/submissions/. From the RSNA website: “We (RSNA) recognize the benefits that come from radiologists using common language to communicate diagnostic results. For this reason, RSNA produced RadLex®, a comprehensive set of radiology terms for use in radiology reporting, decision support, data mining, data registries, education and research. RadLex provides the foundation for vital data resources used in radiology:

  • The LOINC/RSNA Radiology Playbook (http://playbook.radlex.org/playbook/SearchRadlexAction)
  • RadElement Common Data Elements (http://www.radelement.org/)
  • RadReport Radiology Reporting Templates (http://radreport.org/) The development of RadLex has been supported by the National Institute of Biomedical Imaging and Bioengineering (NIBIB) and the cancer Biomedical Informatics Grid (caBIG) project.;”
Read Classification

Clinical Terms Version 3 contains over 200,000 coded concepts arranged in a sub-type hierarchical structure. Top level hierarchy sections: Disorders Findings Morphology Surgical procedures Regimes & therapies Investigations Stages & scales Occupations Organisms Units Drugs Appliances & equipment

Reason Medication Given Codes

This value set is provided as an example. The value set to instantiate this attribute should be drawn from a robust terminology code system that consists of or contains concepts to support the medication process.

ReferralMethod

The methods of referral can be used when referring to a specific HealthCareService resource.

RejectionCriterion

Criterion for rejection of the specimen by laboratory.

RelationalOperator

Identifies common relational operators used in selection criteria.

RelationshipConjunction

A code specifying the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exclusive-or.) Constraints: All AND criteria must be true. If OR and AND criteria occur together, one criterion out of the OR-group must be true and all AND criteria must be true also. If XOR criteria occur together with OR and AND criteria, exactly one of the XOR criteria must be true, and at least one of the OR criteria and all AND criteria must be true. In other words, the sets of AND, OR, and XOR criteria are in turn combined by a logical AND operator (all AND criteria and at least one OR criterion and exactly one XOR criterion.) To overcome this ordering, Act criteria can be nested in any way necessary.

Religious Affiliation

Assigment of spiritual faith affiliation

ResearchStudyObjectiveType

Codes for the kind of study objective.

ResearchStudyPhase

Codes for the stage in the progression of a therapy from initial experimental use in humans in clinical trials to post-market evaluation.

ResearchStudyPrimaryPurposeType

Codes for the main intent of the study.

ResearchStudyReasonStopped

Codes for why the study ended prematurely.

ResearchSubjectMilestone

Indicates the progression of a study subject through the study milestones.

ResearchSubjectState

Indicates the progression of a study subject through a study.

ResearchSubjectStateType

Identifies the kind of state being refered to.

ResourceSecurityCategory

Provides general guidance around the kind of access Control to Read, Search, Create, Update, or Delete a resource.

ResponseLevel

Specifies whether a response is expected from the addressee of this interaction and what level of detail that response should include

ResponseModality

Defines the timing and grouping of the response instances. OpenIssue: Description copied from Concept Domain of same name. Must be verified.

ResponseMode

Specifies the mode, immediate versus deferred or queued, by which a receiver should communicate its receiver responsibilities.

Risk Probability

Codes representing the likelihood of a particular outcome in a risk assessment.

RoleClass

Codes for the Role class hierarchy. The values in this hierarchy, represent a Role which is an association or relationship between two entities - the entity that plays the role and the entity that scopes the role. Roles names are derived from the name of the playing entity in that role. The role hierarchy stems from three core concepts, or abstract domains:

  • RoleClassOntological is an abstract domain that collects roles in which the playing entity is defined or specified by the scoping entity.
  • RoleClassPartitive collects roles in which the playing entity is in some sense a “part” of the scoping entity.
  • RoleClassAssociative collects all of the remaining forms of association between the playing entity and the scoping entity. This set of roles is further partitioned between:
    • RoleClassPassive which are roles in which the playing entity is used, known, treated, handled, built, or destroyed, etc. under the auspices of the scoping entity. The playing entity is passive in these roles in that the role exists without an agreement from the playing entity.
    • RoleClassMutualRelationship which are relationships based on mutual behavior of the two entities. The basis of these relationship may be formal agreements or they may be de facto behavior. Thus, this sub-domain is further divided into:
      • RoleClassRelationshipFormal in which the relationship is formally defined, frequently by a contract or agreement.
      • Personal relationship which inks two people in a personal relationship. The hierarchy discussed above is represented In the current vocabulary tables as a set of abstract domains, with the exception of the “Personal relationship” which is a leaf concept. OpenIssue: Description copied from Concept Domain of same name. Must be verified.
RoleCode

A set of codes further specifying the kind of Role; specific classification codes for further qualifying RoleClass codes.

RoleLinkStatus

Description:Codes representing possible states of a RoleLink, as defined by the RoleLink class state machine.

RoleLinkType

A code specifying the meaning and purpose of every RoleLink instance. Each of its values implies specific constraints to what kinds of Role objects can be related and in which way.

RoleStatus

Codes representing the defined possible states of an Role, as defined by the Role class state machine.

RouteOfAdministration

The path the administered medication takes to get into the body or into contact with the body.

RxNorm

RxNorm provides normalized names for clinical drugs and links its names to many of the drug vocabularies commonly used in pharmacy management and drug interaction software, including those of First Databank, Micromedex, and Gold Standard Drug Database. By providing links between these vocabularies, RxNorm can mediate messages between systems not using the same software and vocabulary. RxNorm now includes the United States Pharmacopeia (USP) Compendial Nomenclature from the United States Pharmacopeial Convention. USP is a cumulative data set of all Active Pharmaceutical Ingredients (API).

SCDHEC GIS Spatial Accuracy Tiers

Description: The South Carolina Department of Health and Environmental Control GIS Spatial Data Accuracy Tiers have been derived from the National Standard for Spatial Data Accuracy as a means to categorize the accuracy of spatial data assignment utilizing a variety of tools for capturing coordinates including digitizers, geocoding software and global positioning system devices.

SNOMED International

SNOMED International

SNOMED topology codes (anatomic sites)

SNOMED topology codes (anatomic sites)

SNOMED-DICOM Microglossary

SNOMED-DICOM Microglossary

SNOMED CT International Edition

SNOMED CT is a core clinical healthcare terminology that contains concepts with unique meanings and formal logic based definitions organized into hierarchies.

Security Role Type

This CodeSystem contains Additional FHIR-defined Security Role types not defined elsewhere

Sequence Ontology

“The Sequence Ontology is a set of terms and relationships used to describe the features and attributes of biological sequence. SO includes different kinds of features which can be located on the sequence. Biological features are those which are defined by their disposition to be involved in a biological process.” “The Sequence Ontologies are provided as a resource to the biological community. They have the following obvious uses:

  • To provide for a structured controlled vocabulary for the description of primary annotations of nucleic acid sequence, e.g. the annotations shared by a DAS server (BioDAS, Biosapiens DAS), or annotations encoded by GFF3.”
  • To provide for a structured representation of these annotations within databases. Were genes within model organism databases to be annotated with these terms then it would be possible to query all these databases for, for example, all genes whose transcripts are edited, or trans-spliced, or are bound by a particular protein. One such genomic database is Chado.
  • To provide a structured controlled vocabulary for the description of mutations at both the sequence and more gross level in the context of genomic databases.” “The Sequence Ontology is part of OBO. It has close links to other ontology projects such as the RNAO consortium, and the Biosapiens polypeptide features.” The content can be browsed here The content can be downloaded here For information on contributing, please see here To request a term or register feedback, see here
Sequencing

Specifies sequence of sort order.

Service category

This value set defines an example set of codes that can be used to classify groupings of service-types/specialties.

Service type

This value set defines an example set of codes of service-types.

ServiceProvisionConditions

The code(s) that detail the conditions under which the healthcare service is available/offered.

SetOperator

** MISSING DESCRIPTION **

Sex Parameter For Clinical Use

A summary parameter that provides guidance on how a receiver should apply settings or reference ranges that are derived from observable information such as an organ inventory, recent hormone lab tests, genetic testing, menstrual status, obstetric history, etc..

SmartCapabilities

Codes that define what the server is capable of.

Software System Type Codes

Types of software systems that support knowledge artifact authoring and evaluation (authoring, testing, tooling, evaluation)

SoftwareNameExample

This code system serves to capture the SoftwareName concept domain used to convey a coded name for the software used to author content.

Source of Payment Typology

The Source of Payment Typology is a standardized Payer Type classification system. It is a mechanism for consistent reporting of payer data to state health data organizations and supports data comparisons by payer type across states, various provider types, and to national benchmarks. Developed by the Public Health Data Standards Consortium (PHDSC) Payer Typology Subcommittee, the typology includes broad hierarchial payer type categories with more specific subcategories. The audience for Source of Payment Typology includes researchers, public health advocates, and healthcare analysts.

Special arrangements

This value set defines a set of codes that can be used to indicate the kinds of special arrangements in place for a patients visit.

SpecialValues

A set of generally useful codes defined so they can be included in value sets.

SpecimenType

** MISSING DESCRIPTION **

Standard Billing Unit

NCPDP standard product billing codes of NCPDP field Unit of Measure (600-28). This billing code is assigned per product, placed in the Structured Product Label, and used in the pharmacy billing processing for consistent billing unit.

Standard Occupation Code

The Standard Occupational Classification (SOC) system is used by Federal statistical agencies to classify workers into occupational categories for the purpose of collecting, calculating, or disseminating data. All workers are classified into one of over 820 occupations according to their occupational definition. To facilitate classification, occupations are combined to form 23 major groups, 96 minor groups, and 449 broad occupations. Each broad occupation includes detailed occupation(s) requiring similar job duties, skills, education, or experience. This code system replaced the older FIPSPUB92, which was withdrawn in February 2005.

StandardsStatus

HL7 Ballot/Standards status of artifact.

StateChangeReason

Indicates why the state of the subject changed.

StatisticAttribute Estimate Type

Method of reporting variability of estimates, such as confidence intervals, interquartile range or standard deviation.

StatisticCertaintyRating

The relative quality of the statistic.

StatisticCertaintySubcomponentRating

The quality rating of the subcomponent of a quality of evidence rating.

StatisticCertaintySubcomponentType

The subcomponent classification of quality of evidence rating systems.

StatisticStatisticType

The type of a specific statistic.

StatisticStudyType

The type of study a statistic was derived from.

StatisticSynthesisType

Types of combining results from a body of evidence (eg. summary data meta-analysis).

StatisticsCode

The statistical operation parameter -“statistic” codes.

StrengthOfRecommendationRating

A rating system that describes the strength of the recommendation, such as the GRADE, DynaMed, or HGPS systems.

Structure Definition Use Codes / Keywords

Structure Definition Use Codes / Keywords

Style Type

<ns1:p>The style code is used within the CDA/SPL narrative block to give the instance author some control over various aspects of style</ns1:p>

SubscriberPolicyholder Relationship Codes

This value set includes codes for the relationship between the Subscriber and the Beneficiary (insured/covered party/patient).

Subscription Error Codes

Codes to represent subscription error details

SubscriptionChannel Type Codes

The type of method used to execute a subscription

SubscriptionStatusAtEvent

A status code for the state of the Subscription.

SubscriptionTag

Tags to put on a resource after subscriptions have been sent.

Substance Admin Substitution

Identifies what sort of change is permitted or has occurred between the therapy that was ordered and the therapy that was/will be provided.

Substance Category Codes

Substance category codes

SubstitutionCondition

Identifies what sort of change is permitted or has occurred between the item that was ordered/requested and the one that was/will be provided.

Supply Item Type

This value sets refers to a specific supply item.

Supply Type

This value sets refers to a Category of supply.

SupplyRequestReason

The reason why the supply item was requested.

Surface Codes

This value set includes a smattering of FDI tooth surface codes.

Systematized Nomenclature of Dentistry (SNODENT)

Systematized Nomenclature of Dentistry (SNODENT) is owned, maintained and distributed by the American Dental Association (ADA). SNODENT is a vocabulary designed for use in the electronic environment - for electronic health and dental records. The intended purpose is to:

  • Provide standardized terms for describing dental disease
  • Capture clinical detail and patient characteristics
  • Permit analysis of patient care services and outcomes
  • To be interoperable with Electronic Health Records (EHR) and Electronic Dental Records (EDR) SNODENT licensing information can be found at: http://www.ada.org/8466.aspx URL for Official Source: http://www.ada.org/snodent.aspx
Systemized Nomenclature of Medicine (SNOMED)

Systemized Nomenclature in Medicine (SNOMED)

TNM Staging System

The TNM Staging System was developed and is maintained by the AJCC and the Union for International Cancer Control (UICC). It is the most commonly used staging system by medical professionals around the world. The TNM classification system was developed as a tool for doctors to stage different types of cancer based on certain, standardized criteria. The TNM Staging System is based on the extent of the tumor (T), the extent of spread to the lymph nodes (N), and the presence of metastasis (M). HTA Note: Most content of TNM (V6) is in the SNOMED international release but not content from the most recent (V9). In Europe many countries use TNM codes, taken from the book and referenced using an OID.

TableCellHorizontalAlign

These values are defined within the XHTML 4.0 Table Model

TableCellScope

These values are defined within the XHTML 4.0 Table Model

TableCellVerticalAlign

These values are defined within the XHTML 4.0 Table Model

TableFrame

These values are defined within the XHTML 4.0 Table Model

TableRules

These values are defined within the XHTML 4.0 Table Model

Tags for the Identification of Languages

Older value from OID registry. Superceded; see recommendations in BCP-47.

TargetAwareness

A code specifying the extent to which the Entity playing the participating Role (usually as a target Participation) is aware of the associated Act. Examples: For diagnostic observations, is the patient, family member or other participant aware of his terminal illness? Discussion: If the awareness, denial, unconsciousness, etc. is the subject of medical considerations (e.g., part of the problem list), one should use explicit observations in these matters as well, and should not solely rely on this simple attribute in the Participation.

TelecommunicationAddressUse

Deprecation Comment: This code system was deprecated as of the November 2007 harmonization meeting. The content was folded into AddressUse (2.16.840.1.113883.5.1119), which replaces this code system.

TelecommunicationCapabilities

Description: Concepts that define the telecommunication capabilities of a particular device. Used to identify the expected capabilities to be found at a particular telecommunication address.

Test script operation code

This value set defines a set of codes that are used to indicate the supported operations of a testing engine or tool.

Test script profile destination type

This value set defines a set of codes that are used to indicate the profile type of a test system when acting as the destination within a TestScript.

Test script profile origin type

This value set defines a set of codes that are used to indicate the profile type of a test system when acting as the origin within a TestScript.

The Health Care Payment Learning and Action Network (HCPLAN) Alternative Payment Model (APM) Framework Categories

“The Health Care Payment Learning and Action Network (HCPLAN or LAN) https://hcp-lan.org/ is a public-private partnership established in 2015 by the US Department of Health and Human Services (HHS) to accelerate the transition to value-based payment models in the US healthcare system.” “The Framework represents payments from public and private payers to provider organizations (including payments between the payment and delivery arms of highly integrated health systems). It is designed to accommodate payments in multiple categories that are made by a single payer, as well as single provider organizations that receive payments in different categories—potentially from the same payer.” “Since the original APM Framework White Paper was released in January 2016, it has become the foundation for implementing APMs and evaluating progress toward health care payment reform. Payers, providers, and purchasers have all used the APM Framework to better understand the payment reform landscape and to set goals for participation in APMs, and health care stakeholders have used the APM Framework to identify common goals for transforming the nation’s health care system. Overall, the APM Framework’s classification system has been adopted by the health care ecosystem.” “The LAN APM Framework represents a continuum of payment approaches across four Categories.” Initial version of the APM Framework White Paper was published in 2016. The updated version of the White Paper was published in 2017. For more information, please see https://hcp-lan.org/workproducts/apm-refresh-whitepaper-final.pdf

The Read Codes Four Byte Set:

The Read Codes Four Byte Set consists of 4 alphanumeric characters. This version contains approximately 40,000 codes arranged in a hierarchical structure. Top level hierarchy sections: Disorders Findings Surgical procedures Investigations Occupations Drugs

The Read Codes Version 2

The Read Codes Version 2 contains over 70,000 coded concepts arranged in a hierarchical structure. Top level hierarchy sections: Disorders Findings Surgical procedures Investigations Occupations Drugs

TimingEvent

** MISSING DESCRIPTION **

TransmissionRelationshipTypeCode

Description:A code specifying the meaning and purpose of every TransmissionRelationship instance. Each of its values implies specific constraints to what kinds of Transmission objects can be related and in which way.

TribalEntityUS

INDIAN ENTITIES RECOGNIZED AND ELIGIBLE TO RECEIVE SERVICES FROM THE UNITED STATES BUREAU OF INDIAN AFFAIRS

Trigger Event ID

Description: This code system contains all HL7 artifacts of type TE (Trigger Event) that are created by HL7 or its affiliates or their designates using the realm namespacing rules approved by HL7. Local implementations who create trigger events outside of these namespacing rules, (e.g. using the ZZ realm code) must register their own code system. The specific list of legal codes can be found by consulting the HL7 publications (editions, ballots, implementation guides, etc.) published by HL7 Inc. and by the various HL7 affiliates and their designates. Codes shall be expressed in upper case, with separator as shown in HL7 publications with no version id. E.g. PORX_TE123456UV.

UCDS

UCDS

URL

Universal Resource Locator (URL) schemes Currently there is no single authority for URL schemes. The authority for URL scheme assignments clearly lies within IANA or W3C and it is likely that a formal URL/URI assigning authority will be formed soon.

US Census Bureau

The Standard Industrial Classification Codes that appear in a company’s disseminated EDGAR filings indicate the company’s type of business. These codes are also used in the Division of Corporation Finance as a basis for assigning review responsibility for the company’s filings. For example, a company whose business was Metal Mining (SIC 1000) would have its filings reviewed by staffers in A/D Office 4. Note that this code system is published both by the US Bureau of Labor Statistics (BLS) at http://www.sec.gov/info/edgar/siccodes.htm, and by the US Occupational & Safety Health Administration (OSHA) at http://www.osha.gov/pls/imis/sic_manual.html.

US Census Occupation Code

Coding system of United States Census Occupation Codes, published by the US Governmetn Bureau of the Census. Doucmentation and Crosswalk mapping between the COC and the SOC and NAICS code systems available at http://www.census.gov/hhes/www/ioindex/view.html

US Department of Veterans Affairs

VHA Enterprise Reference Terminology is based on CHI standard terminologies (e.g., SNOMED-CT, LOINC, HL7, NDF-RT, etc.) when available and on VHA own code sets when necessary (e.g., allergens). All concepts used within the VHA clinical environment receive a VHA Unique IDentifier or VUID. VHA Enterprise Reference Terminology complies with the semantics of the HL7 message structure

US EPA Substance Registry System

The United States Environmental Protection Agency’s (US EPA) Substance Registry System (SRS) provides information on substances and how they are represented in US environmental statutes, in US EPA information systems, and in information systems owned by other organizations. The SRS provides standardized identification for each substance to improve data quality in US EPA systems and elsewhere.

USCLS Codes

This value set includes a smattering of USCLS codes.

UTG Specific Concept Properties

A set of concept properties used by UTG to maintain legacy terminology distribution systems

Unified Code for Units of Measure (UCUM)

The Unified Code for Units of Measure (UCUM) is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans. A typical application of The Unified Code for Units of Measure are electronic data interchange (EDI) protocols, but there is nothing that prevents it from being used in other types of machine communication.

Unified Medical Language

Unified Medical Language

Unified Medical Language System

UMLS codes as CUIs making up the values in a coding system. More information may be found at http://www.nlm.nih.gov/research/umls/

Unique Ingredient Identifier (UNII)

A UNII is a non-proprietary, free, unique, unambiguous, nonsemantic, alphanumeric identifier based on a substance’s molecular structure and/or descriptive information. UNII identifiers are generated based on scientific identity characteristics using ISO 11238 data elements. UNII availability does not imply any regulatory review or approval. Synonyms and mappings are based on the best public information available at the time of publication.

Unit Type Codes

This value set includes a smattering of Unit type codes.

United States Postal Service

Coding system of defined postal zip codes for the United States of America.

Universal Product Code

Universal Product Code

Universal Resource Locator Scheme

A Universal Resource Locator (URL) is a type of telecommunications address specified as Internet standard RFC 1738 [http://www.isi.edu/in-notes/rfc1738.txt]. The URL specifies the protocol and the contact point defined by that protocol for the resource.

UsageContextType

A code that specifies a type of context being specified by a usage context.

V2 Table List

Master List of V2 Tables

Vaccine Administered Code Set (CVX)

The CDC’s National Center of Immunization and Respiratory Diseases (NCIRD - see https://www.cdc.gov/ncird/) developed and maintains the CVX (vaccine administered) code set. It includes both active and inactive vaccines available in the US. CVX codes for inactive vaccines allow transmission of historical immunization records. When a MVX (manufacturer) code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated. These codes should be used for immunization messages using either HL7 Version 2.3.1 or HL7 Version 2.5.1. CVX is the underlying Master Code System for V2 table 0292 (Vaccines Administered). The machine readable name for CVX in PHIN VADS is PH_VaccinesAdministeredCVX_CDC_NIP. The version of the CVX code set for certification can be found on the archive page:https://www2a.cdc.gov/vaccines/iis/iisstandards/mu3versioned_codes.asp The Status column indicates if the vaccine is currently available in the United States.

  • Active: A currently available administrable vaccine
  • Inactive: An administrable vaccine formulation that is no longer available for patient administration, but can be found in historical patient records OR A historical record of a vaccine administered where the exact formulation is unknown
  • Pending: A vaccine that is expected to become active in the future
  • Non-US: A vaccine that available outside the US only
  • Never Active: A vaccine that was never available and is not in the pipeline of new vaccines The Last Updated column indicates the last time this particular vaccine code was updated in this table. Questions regarding this table should be directed to the IIS Technical Assistance Team via iisinfo@cdc.gov (or use mailing address via https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx#addr) HL7 Implementers should note that ‘Status’ IS NOT CONCEPT STATUS as all codes are ACTIVE in this code system. The current code system is available via https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx
VaccineManufacturer

The manufacturer of a vaccine.

VaccineType

The kind of vaccine.

Validation-process

The primary process by which the target is validated

Validation-status

Status of the validation of the target against the primary source

Validation-type

What the target is validated against

VerificationResult Communication Method

Attested information may be validated by process that are manual or automated. For automated processes it may accomplished by the system of record reaching out through another system’s API or information may be sent to the system of record. This value set defines a set of codes to describing the process, the how, a resource or data element is validated.

VocabularyDomainQualifier

Vocabulary domain qualifiers are concepts that are used in domain constraints to specify behavior of the new domain. Code system retired.

W3C Decentralized Identifier (DID)

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Each DID document can express cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Services enable trusted interactions associated with the DID subject. A DID might provide the means to return the DID subject itself, if the DID subject is an information resource such as a data model.” For more information, see https://www.w3.org/TR/did-core/

WHO ATC

WHO ATC

WHO Adverse Reaction Terms

WHO Adverse Reaction Terms

WHO Adverse Reaction Terms French

WHO Adverse Drug Reaction Terminology (WHOART). French Translation. Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. For more information, see http://www.umc-products.com/graphics/3149.pdf

WHO Adverse Reaction Terms German

WHO Adverse Drug Reaction Terminology (WHOART). German Translation. Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. For more information, see http://www.umc-products.com/graphics/3149.pdf

WHO Adverse Reaction Terms Portuguese

WHO Adverse Drug Reaction Terminology (WHOART). Portuguese Translation. Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. For more information, see http://www.umc-products.com/graphics/3149.pdf

WHO Adverse Reaction Terms Spanish

WHO Adverse Drug Reaction Terminology (WHOART). Spanish Translation. Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. For more information, see http://www.umc-products.com/graphics/3149.pdf

WHO Adverse Reaction Terms foreign language translations

WHO Adverse Drug Reaction Terminology (WHOART). Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. This branch node OID contains identifiers for the different foreign language versions of this terminology. For more information, see http://www.umc-products.com/graphics/3149.pdf

WHO rec# code with ASTM extension

WHO rec# code with ASTM extension

WHO rec# drug codes

WHO rec# drug codes

Work Classification (Occupational Data for Health)

Code system of concepts representing a person’s job type as defined by compensation and sector (e.g. paid vs. unpaid, self-employed vs. not self-employed, government vs. private, etc.).

X12 Claim Adjustment Reason Codes

“X12, chartered by the American National Standards Institute for more than 40 years, develops and maintains EDI standards and XML schemas which drive business processes globally. X12’s diverse membership includes technologists and business process experts in health care, insurance, transportation, finance, government, supply chain and other industries.” The X12 Claim Adjustment Reason Codes describe why a claim or service line was paid differently than it was billed. These codes are listed within an X12 implementation guide (TR3) and maintained by X12. External code lists maintained by X12 and external code lists maintained by others and distributed by WPC on behalf of the maintainer can be found here: here Click on the name of any external code list to access more information about the code list, view the codes, or submit a maintenance request. These external code lists were previously published on either www.wpc-edi.com/reference or www.x12.org/codes

X12 Remittance Advice Remark Codes

X12, chartered by the American National Standards Institute for more than 40 years, develops and maintains EDI standards and XML schemas which drive business processes globally. X12’s diverse membership includes technologists and business process experts in health care, insurance, transportation, finance, government, supply chain and other industries. Remittance Advice Remark Codes (RARCs) are used to provide additional explanation for an adjustment already described by a Claim Adjustment Reason Code (CARC) or to convey information about remittance processing. Each RARC identifies a specific message as shown in the Remittance Advice Remark Code List. There are two types of RARCs, supplemental and informational. The majority of the RARCs are supplemental; these are generally referred to as RARCs without further distinction. Supplemental RARCs provide additional explanation for an adjustment already described by a CARC. The second type of RARC is informational; these RARCs are all prefaced with Alert: and are often referred to as Alerts. Alerts are used to convey information about remittance processing and are never related to a specific adjustment or CARC.

X12 Service Type Codes

“X12, chartered by the American National Standards Institute for more than 40 years, develops and maintains EDI standards and XML schemas which drive business processes globally. X12’s diverse membership includes technologists and business process experts in health care, insurance, transportation, finance, government, supply chain and other industries.” The X12 Service Type Codes identify business groupings for health care services or benefits. These codes are listed within an X12 implementation guide (TR3) and maintained by X12. External code lists maintained by X12 and external code lists maintained by others and distributed by WPC on behalf of the maintainer can be found here: https://x12.org/codes Click on the name of any external code list to access more information about the code list, view the codes, or submit a maintenance request. These external code lists were previously published on either http://www.wpc-edi.com/reference or http://www.x12.org/codes. If you have questions about these lists, submit them on the X12 Feedback form. “All X12 products are subject to this IP policy, including published and draft works. X12 is the only organization authorized to grant permission for use of X12 products. Users of all X12 products should make sure that they understand the permissible uses, as well as the limitations on such usage, as outlined below.” Additional IP information can be found here: https://x12.org/products/ip-use “Send an email to ip@x12.org to request permission to reproduce X12 IP. Include your name, organization, title, address, city, state, zip, email, a detailed description of the Submitted Artifact, including the underlying or cited X12 Product, and a detailed description of the intended audience and planned distribution method for the Artifact.” Additional information on X12 licensing program can be found here: https://x12.org/products/licensing-program To purchase code list subscriptions call (425) 562-2245 or email admin@wpc-edi.com.

X12.3 Data Elementary Dictionary

X12.3 Data Elementary Dictionary This is the root OID for vocabulary defined internally by X12N. OIDS for each vocabulary will be assigned underneath this oid by appending the X12N data element id to the root OID. Data Element 1336 is Insurance Type Code, so the OID for the X12N Insurance Type Code vocabulary will be 2.16.840.1.113883.6.255.1336

accept-applicationAcknowledgmentConditions

HL7-defined code system of concepts which identify conditions under which accept acknowledgments are required to be returned in response to a message, and required for enhanced acknowledgment mode. Used in HL7 Versions 2 messaging in the MSH segment.

accessRestrictionValue

Code system of concepts specifying the information to which access is restricted. Used in HL7 Version 2.x messaging in the ARV segment. Note that these new codes as of November 2018 have been temporarily loaded into this V2 code system pending availability of the currently unavailable new tooling, at which time this code systrem will be retired and a value set of codes from the HL7 V3 ActCode code system will be used instead for this table.

acknowledgmentCodes

HL7-defined code system of concepts specifying acknowledgment codes. For details of usage, see message processing rules in the published Standard. Used in HL7 Version 2.x messaging in the MSA segment.

actionCodes

HL7-defined code system ofstatus codes of record operation. Used in Version 2 messaging, these are used in the RXA segment in the vaccine messages, where a method of correcting vaccination information transmitted with incorrect patient identifying information is needed. As of version 2.6, this table was replaced with table 0206, whose values are defined by code system xxxx.

actionTakenInResponseToTheEvent

HL7-defined code system of concepts used to define the action taken as a result of an event related to a product issue. Used in HL7 Version 2.x messaging in the PCR segment.

active-inactive

HL7-defined code system of concepts specifying whether a person is currently a valid staff member. Used in HL7 Version 2.x messaging in the STF segment.

actpriority

HL7-defined code system of concepts specifying the priority for the shipment. Used in HL7 Version 2.x messaging in the SHP segment.

additivePreservative

HL7-defined code system of concepts specifying any additive introduced to the specimen before or at the time of collection. These additives may be introduced in order to preserve, maintain or enhance the particular nature or component of the specimen. Used in HL7 Version 2.x messaging in the SPM and SAC segments.

addressExpirationReason

Code system of concepts specifying the reason this address was marked as “ended”. Used in HL7 Version 2.x messaging in the XAD segment.

addressType

HL7-defined code system of concepts specifying types or kinds of addresses. Used in HL7 Version 2.x messaging in the XAD segment.

addressUsage

HL7-defined code system of concepts specifying how an address is intended to be used. Used in HL7 Version 2.x messaging in the XAD segment.

adjustmentAction

Code system of concepts used to specify the action requested of the party that receives an adjustment. Used in the Adjustment (ADJ) segment in HL7 Version 2.x messaging.

adjustmentCategory

Code system of concepts used to specify the category of adjustment and is used to assist in determining which table is used for Adjustment Reason. Used in the Adjustment (ADJ) segment in HL7 Version 2.x messaging.

administrationDevice

Code system of concepts which specify the mechanical device used to aid in the administration of the drug or other treatment. Common examples are IV-sets of different types. Used in HL7 Version 2.x messaging in the RXR segment.

administrationMethod

Code system of concepts which specify the specific method requested for the administration of the drug or treatment to the patient. Used in HL7 Version 2.x messaging in the RXR segment.

administrativeSex

Code system of concepts specifying a patient’s sex for administrative purposes. Used in HL7 Version 2.x messages in the PID segment.

admissionLevelOfCare

Code system of concepts specifying the acuity level assigned to the patient at the time of admission. Used in HL7 Version 2.x messaging in the PV2 segment.

admissionType

Code system of concepts specifying the circumstances under which the patient was or will be admitted. Used in HL7 Version 2.x messaging in the PV1 segment.

advanceDirective

Code system of concepts specifying the patient’s instructions to the healthcare facility. Used in HL7 Version 2.x messaging in the PV2 and PD1 segments.

advancedBeneficiaryNotice

Code system of concepts specifying the status of the patient’s or the patient’s representative’s consent for responsibility to pay for potentially uninsured services. This element was introduced to satisfy CMS Medical Necessity requirements for outpatient services in the United States. Includes concepts such as (a) whether the associated diagnosis codes for the service are subject to medical necessity procedures, (b) whether, for this type of service, the patient has been informed that they may be responsible for payment for the service, and (c) whether the patient agrees to be billed for this service. Used in HL7 Version 2.x messaging in the ORC and FT1 segments.

alertDevice

Code system of concepts specifying any type of allergy alert device the patient may be carrying or wearing. Used in HL7 Version 2.x messaging in the IAM segment.

alertLevel

HL7-defined code system of concepts that identify the highest level of the alert state (e.g.,highest alert severity) that is associated with the indicated equipment (e.g. processing event, inventory event, QC event). Used in the Equipment Detail (EQU) and Notification Detail (NDS) segments in HL7 Version 2.x messaging.

allergenType

Code system of concepts speciying a classification of general allergy categories (drug, food, pollen, etc.). Used in HL7 Version 2.x messaging in the AL1 segment.

allergyClinicalStatus

Code system of concepts specifying the verification status for the allergy. Used in HL7 Version 2.x messaging in the IAM segment.

allergySeverity

Code system of concepts which specify the general severity of an allergy. Used in HL7 Version 2.x messaging in the AL1 segment.

allowSubstitution

HL7-defined code system of concepts which specify whether substitutions are allowed and, if so, the type of substitutions allowed. Used in HL7 Version 2.x messaging in the RXO segment.

allowSubstitution

Code system of concepts used to indicate whether the appointment resource may be substituted for another by the entity assigned to fulfill the appointment. Used in HL7 Version 2.x messaging in the AIS and AIG segments.

alternateCharacterSetHandlingScheme

HL7-defined code system of concept that specify the scheme used when any alternative character sets are specified in the second or later iterations of MSH-18 Character Set, and if any special handling scheme is needed. Used in HL7 Version 2.x messaging in the MSH segment.

alternateCharacterSets

HL7-defined code system of concepts used to specify the character set(s) in use. Includes both single-byte and double-byte characters sets, and used in Version 2.x messaging in the MSH segment.

ambulatoryPaymentClassification

Code system of concepts specifying the derived Ambulatory Payment Classification (APC) code. Used in HL7 Version 2.x messaging in the GP2 segment.

ambulatoryStatus

Code system of concepts specifying permanent or transient handicapped conditions of a person. Used in HL7 Version 2.x messaging in the PV1 segment.

amountClass

Code system of concepts specifying the amount quantity class. Used in HL7 Version 2.x messaging in the PTA segment.

amountType

Code system of concepts which specify amount quantity type. Used in HL7 Version 2.x messaging in the RMC segment.

analyteRepeatStatus

HL7-defined code system of concepts identifying the repeat status for the analyte/result (e.g. original, rerun, repeat, reflex). The following are assumptions regarding the table values: Repeated without dilution — performed usually to confirm correctness of results (e.g., in case of results flagged as “Panic” or mechanical failures). Repeated with dilution — performed usually in the case the original result exceeded the measurement range (technical limits). Reflex test — this test is performed as the consequence of rules triggered based on other test result(s). Used in HL7 Version 2.x messaging in the Test Code Detail (TCD) segment.

annotations

Code system of concepts specifying the coded entry associated with a given point in time during the waveform recording. Used in HL7 Version 2.x messaging in the Observation Result (OBX) Another Observation (ANO) segments.

applicationChangeType

HL7-defined code system of concepts which specify the type of change being requested (if NMR query) or announced (if NMD unsolicited update) during application status changes. It is assumed that a “new” version starts up with no loss or duplication of data as the “old” one is shutting down (if possible). Used in HL7 Version 2 Messaging in the NSC segment.

appointmentReason

Code system of concepts used to describe the kind of appointment or the reason why an appointment has been scheduled. Used in HL7 Version 2.x messaging in the ARQ segment.

appointmentType

Code system of concepts used in an appointment request to describe the kind of appointment. Used in HL7 Version 2.x messaging in the ARQ segment.

approvingRegulatoryAgency

Code system of concepts specifying the regulatory agency by which the item has been approved, such as the FDA or AMA. Used in HL7 Version 2.x messaging in the ITM segment.

armStick

HL7-defined code system of concepts specifying the arm(s) receiving the stick. Used in HL7 Version 2.x messaging in the DON segment.

arrivalMode

Code system of concepts specifying how the patient was brought to the healthcare facility. Used in HL7 Version 2.x messaging in the PV2 segment.

artificialBlood

Code system of concepts that identify the artificial blood identifier associated with the specimen. Used in the Interaction Specimen Container Detail (SAC) segment in HL7 Version 2.x messaging.

assignmentOfBenefits

Code system of concepts which indicate whether an insured person agreed to assign the insurance benefits to the healthcare provider. If so, the insurance will pay the provider directly. Used in HL7 Version 2.x messaging in the IN1 segment.

authorizationMode

HL7-defined code system of concepts of forms of authorization a recorder may receive from the responsible practitioner to create or change an order. Used in HL7 Version 2.x messaging in the ORC segment.

auto-DilutionType

Code system of vendor-defined codes that specify the pre‑configured dilution to be applied on the instrument, which can be used instead of a numeric declaration. Used in Version 2 messaging in the TCD segment.

bedStatus

Code system of concepts which specify the state of a bed in an inpatient setting, and is used to determine if a patient may be assigned to it or not. Used in HL7 Version 2.x messaging in the DLD and PV1 segments.

benefitGroup

Code system of concepts used to specify the benefit group. Used in the Invoice (IVC) segment in HL7 Version 2.x messaging.

bloodProduct

HL7-defined code system of concepts which specify a type of blood product. Used in HL7 Version 2 messaging in the BLC segment.

bloodProductDispenseStatus

HL7-defined code system of concepts used to specify the current status of the specified blood product as indicated by the filler or placer. For example, the first status change of a product that may trigger a Blood Product Dispense Status Message occurs when it first becomes linked to a patient and is ready to dispense. The placer system may use the Blood Product Dispense Status Message to request the transfusion service to dispense the product. When the blood product is delivered or issued to a patient, the status of the blood product would be changed to indicate that it has now been “dispensed”. Used in the Blood Product Dispense Status (BPX) segment in HL7 Version 2.x messaging.

bloodProductProcessingRequirements

Code system of concepts used to specify additional information about the blood component class associated with the Universal Service ID. The placer of the order can specify any required processing of the blood product that must be completed prior to transfusion to the intended recipient. Used in the Blood Product Order (BPO) segment in HL7 Version 2.x messaging.

bloodProductTransfusion-dispositionStatus

HL7-defined code system of concepts used to specify the current status of the specified blood product as indicated by the placer. For example, the placer may return the blood product to the transfusion service unused because an IV could not be started. The blood component may have been entered, but the line was clogged and could not be used, in which case the component must be wasted. A final status would indicate that the product has actually been “transfused.” Used in the Blood Product Transfusion/Disposition (BTX) segment in HL7 Version 2.x messaging.

bloodUnitType

HL7-defined code system of concepts used to specify the type of blood unit. Used in the Blood Unit Information (BUI) segment in HL7 Version 2.x messaging.

bodyParts

HL7-defined code system of concepts specifying the part of the body. Used in HL7 Version 2 messaging in the RXR segment.

bodySite

HL7-defined code system of concepts that specify a body site from which a specimen is obtained. Used in HL7 Version 2.x messaging in the OBX and CH7 segments.

bodySiteModifier

HL7-defined code system of concepts specifying the modifier for the body site. Used in HL7 Version 2.x messaging in the RXR segment.

bolusType

HL7-defined code system of concepts specifying the type of bolus. Used in HL7 Version 2.x messaging in the RXV segment.

bpObservationStatusCodesInterpretation

HL7-defined code system of concepts used to specify the interpretation for the blood product observation status codes. A status is considered preliminary until a blood product has reached a final disposition for the patient. For example, when the product is first cross-matched and a status message is sent, it would be considered preliminary. When the product is dispensed to the patient, that status would also be considered preliminary. However, once the product is transfused, the status would be considered final. Used in the Blood Product Dispense Status (BPX) and Blood Product Transfusion/Disposition (BTX) segments in HL7 Version 2.x messaging.

calendarAlignment

HL7-defined code system of concepts used to specify an alignment of the repetition to a calendar (e.g., to distinguish every 30 days from “the 5th of every month”). Used in HL7 Version 2 messaging in the RPT segment.

caseCategory

HL7-defined code system of concepts which specify reasons that a non-urgent patient presents to the Emergency Room for treatment instead of a clinic or physician office. Used in HL7 Version 2 messaging in the ABS segment.

causalityObservations

HL7-defined code system of concepts used to record event observations regarding what may have caused a product related event. Used in HL7 Version 2.x messaging in the PCR segment.

cclValue

Code system of concepts specifying the clinical complexity level (CCL) value for the determined diagnosis related group (DRG) for this diagnosis. US Realm. Used in HL7 Version 2.x messaging in the DG1 segment.

certificateStatus

Code system of concepts specifying the status of the certificate held by the health professional. Used in HL7 Version 2 messaging in the CER segment.

certificationCategory

Code system of concepts specifying the code for the certification category. Used in HL7 Version 2.x messaging in the IN3 segment.

certificationPatientType

Code system of concepts which specify the category or type of patient for which this certification is requested. Used in HL7 Version 2.x messaging in the ICD segment.

certificationStatus

HL7-defined code system of concepts used to specify the status of the practitioner’s speciality certification. Used in HL7 Version 2.x messaging in the Specialty Description (SPD) value and Practitioner Detail (PRA) segment.

certificationType

Code system of concepts specifying the code for the certification type. Used in HL7 Version 2.x messaging in the IN3 segment.

chargeOnIndicator

Code system of concepts used to define the event upon which a charge should be generated. Used in HL7 Version 2.x messaging in the PRC segment.

chargeType

HL7-defined code system of concepts which specify someone or something other than the patient to be billed for a service. Used in HL7 Version 2.x messaging in the BLG segment.

chargeTypeReason

Code system of concepts specifying the choice of, and providing the clinical rationale for, a selected charge type. Used in HL7 Version 2.x messaging in the BLG segment.

checkDigitScheme

HL7-defined code system of concepts specifying the check digit scheme employed. Used in HL7 Version 2.x messaging in PPN, XCN and XON segments.

chromosome-human

Chromosome number for human.

clergyNotificationType

Code system of concepts specifying whether the clergy should be notified. Used in HL7 Version 2 messaging in the PV2 segment.

codingSystem

HL7-defined code system of concepts specifying the coding system. This table is maintained outside of the published Version 2 standards, and may be found at http://www.hl7.org/Special/committees/vocab/table_0396/index.cfm. Used in HL7 Version 2.x messaging in the CWE segment.

collectionEvent

HL7-defined code system of concepts specifying the limit for the collection event or process step. Used in HL7 Version 2.x messaging in the OMC segment.

commandResponse

Code system of concepts identifying the response of the previously issued command. Used in HL7 Version 2.x messaging in the Equipment Command Response (ECR) and Interaction Status Detail (ISD) segments.

commentType

Code system of concepts that identify the type of comment text being sent in the specific comment record. Used in the Notes and Comments (NTE) segment in HL7 Version 2.x messaging.

communicationLocation

HL7-defined code system of concepts specifying the communication location. Used in HL7 Version 2.x messaging in the OMC segment.

completionStatus

HL7-defined code system of concepts specifying the status of the treatment administration event segment. Used in HL7 Version 2.x messaging in the Pharmacy Order Administration (RXA) segment.

computationType

HL7-defined code system of concepts used to specify if the change is computed as a percent change or as an absolute change. Used in the Delta (DLT) segment in HL7 Version 2.x messaging.

confidentiality

HL7-defined code system of concepts specifying the confidentiality for the shipment. Used in HL7 Version 2.x messaging in the SHP segment.

confidentialityCodes

Code system of concepts specifying the degree to which special confidentiality protection should be applied to the observation. Used in HL7 Version 2.x messaging in the OM1 and ORC segments.

consentBypassReason

Code system of concepts specifying the reason the subject’s consent was not sought. Used in HL7 Version 2.x messaging in the CON segment.

consentDisclosureLevel

HL7-defined code system of concepts specifying how much information was disclosed to the subject as part of the informed consent process. Used in HL7 Version 2.x messaging in the CON segment.

consentMode

HL7-defined code system of concepts specifying the method in which a subject provides consent. Used in HL7 Version 2.x messaging in the TXA and CON segments.

consentNon-disclosureReason

Code system of concepts used to specify a reason the subject did not receive full disclosure. Used in the Consent (CON) segment in HL7 Version 2.x messaging.

consentStatus

HL7-code system of concepts specifying whether the consent has been sought and granted. Used in HL7 Version 2.x messaging in the TXA and CON segments.

consentType

Code system of concepts specifying to what the subject is consenting, i.e. what type of service, surgical procedure, information access/release or other event. Used in HL7 Version 2.x messaging in the TXA and CON segments.

contactRole2

Code system of concepts which specify a relationship role that the next of kin/associated parties plays with regard to the patient. Also used in referrals, for example, it may be necessary to identify the contact representative at the clinic that sent a referral. Used in HL7 Version 2 messaging in the NK1 and CTD segments after 2.5, when it replace 2.16.840.1.113883.18.57.

containerCondition

HL7-defined code system of concepts used to specify at each receipt the status of the container in which the specimen is shipped in chain of custody cases where specimens are moved from lab to lab. If the container is compromised in any way (seal broken, container cracked or leaking, etc.), then this status needs to be recorded for legal reasons. Used in the Specimen (SPM), Shipment (SHP) and Shipment Package (PAC) segments in HL7 Version 2.x messaging.

containerStatus

HL7-defined code system of concepts that identify the status of the unique container in which the specimen resides at the time the transaction was initiated. Used in the Interaction Specimen Container Detail (SAC) segment in HL7 Version 2.x messaging.

continuationStyle

HL7-defined code system of concepts identifying whether it is a fragmented message or part of an interactive continuation message. Used in HL7 Version 2.x messaging in the Continuation Pointer (DSC) segment.

controlledSubstanceSchedule

Code system of concepts specifying the class of the drug or other substance if its usage is controlled by legislation. In the USA, such legislation includes the federal Controlled Substance Act (CSA) or a State Uniform Controlled Substance Act. Other countries should create their own versions of this table. Used in HL7 Version 2.x messaging in the RXE segment. The name of the table is taken from the Pharmacy Law Digest July 1988.

coordinationOfBenefits

Code system of concepts specifying whether this insurance works in conjunction with other insurance plans or if it provides independent coverage and payment of benefits regardless of other insurance that might be available to the patient. Used in HL7 Version 2.x messaging in the IN1 segment.

coverageType

Code system of concepts specifying the type of insurance coverage or what types of services are covered for the purposes of a billing system. For example, a physician billing system will only want to receive insurance information for plans that cover physician/professional charges. Used in HL7 Version 2.x messaging in the Insurance (IN1) segment.

cpRangeType

HL7-defined code system of concepts used to define a type of range used in composite pricing in financial transacxtions. Used in HL7 Version 2 messaging in the CP datatype.

cumulativeDosageLimitUom

Code system of concepts specifying the unit of measure (UoM) for the cumulative dosage limit. Used in HL7 Version 2.x messaging in the CDO segment.

cweStatuses

HL7-defined code system of comcepts that represent an exception identifier code; that is, a code that is not defined in the value set (either model or site-extended). These are occationsally referred to a ‘flavors of null’ although this set of concepts is specific to the CWE datatype used in HL7 Version 2.x messaging, and the codes may be used in the ‘identifier’ component of the ‘triplets’ in that datatype.

cycleType

Code system of concepts specifying the type of cycle that is being executed. A cycle type is a specific sterilization method used for a specific type of supply item. Used in HL7 Version 2.x messaging in the SCD segment.

cyclicEntryExitIndicator

HL7-defined code system of concepts used to specify if this service request is the first or last service request in a cyclic series of service requests. Used in the Timing/Quantity Relationship (TQ2) segment in HL7 Version 2.x messaging.

dataTypes

HL7-defined code system of concepts specifying the format of the observation value in the Observation Result (OBX). Used in HL7 Version 2.x messaging in the OBX, OM1, OM3 and OMC segments.

date-timeSelectionQualifier

HL7-defined code system of conceptss that allow the specification of certain types of values within the date/time range. Used in HL7 Vesion 2 messaging in the QRF segment.

dateFormat

Code system of concepts that identify the date format for a decontamination/sterilization instance. Used in HL7 Version 2.x messaging in the SCP segment.

dayType

Code system of concepts which specify whether the days are denied, pending or approved. Used in HL7 Version 2.x messaging in the DTN segment.

daysOfTheWeek

HL7-defined code system of concepts used to identify the day(s) of the week when a location may be scheduled for appointments. Used in HL7 Version 2.x messaging in the UVC and LDP segments.

deferredResponseType

HL7-defined code system of concepts which specify which type of deferred query resonse is desired, as specified with the query parameters. Used in HL7 Version 2 messaging in the QRD segment.

degreeLicenseCertificate

Code system of concepts specifying an educational degree (e.g., MD). Used in the CNN datatype (names and identifiers of clinicians) in Version 2 messaging. Used in HL7 Version 2.x messaging in the CNN segment; note that in releases of HL7 prior to 2.3.1, was also used in person names (XPN), but this use was deprecated, then withdrawn in 2.7.

delayedAcknowledgmentType

HL7-defined code system of concepts which specify a response type used in deferred processing two phase reply for delayed acknowldgement mode of the original acknowledgement mechanism defined in HL7 Version 2.x messaging and used in the MSH segment.

derivedSpecimen

HL7-defined code system of concepts which specify the parents and children for diagnostic studies, especially in microbiology, where the initial specimen (e.g., blood) is processed to produce results (e.g., the identity of the bacteria grown out of the culture). The process also produces new “specimens” (e.g., pure culture of staphylococcus, and E. coli), and these are studied by a second order process (bacterial sensitivities). The parents (e.g., blood culture) and children (e.g., penicillin MIC) are identified in such cases. Used in HL7 Version 2.x messaging in the OM4 segment.

deviceDataState

Code system of concepts that define the state of the data as provided from a device. Used in HL7 Version 2.x messaging in the SDD segment.

deviceStatus

Code system of concepts that communicate the state of a device. Used in HL7 Version 2.x messaging in the SCD segment.

deviceType

Code system of concepts that idenfity the kind of device as defined by the manufacturer. Used in HL7 Version 2.x messaging in the SCP segment.

diagnosisClassification

Code system of concepts used to classify whether a patient visit can be related to a diagnosis. Used in HL7 Version 2.x messaging in the DG1 segment.

diagnosisPriority

Code system of concepts that identify the significance or priority of the diagnosis code. Note that the codes are numeric, and the number of the code represents the ordinal priority of the associated diagnosis. Used in the DG1 segment in HL7 Version 2.x messaging. The predefined codes are the most common, and just a starter set, as the codes are an unbounded list; additional ranked procedures may be signified by incrementing the code value as needed.

diagnosisType

Code system of concepts specifying a type of diagnosis being sent. Used in HL7 Version 2.x messaging in the DG1 segment..

diagnosticServiceSectionId

HL7-defined code system of concepts which specify a section of a diagnostic service where the observation may be performed. Used in HL7 Version 2.x messaging in the OBR and OM4 segments.

dietCodeSpecificationType

HL7-defined code system of concepts which specify whether the type of diet. Used in HL7 Version 2.x messaging in the ODS segment.

disabilityInformationRelationship

Code system of concepts used to specify to which person the disability information relates in the message. For example, if the value is PT, the disability information relates to the patient. Used in HL7 Version 2.x messaging in the Disability (DB1) segment.

dispenseMethod

HL7-definde code system of concepts specifying the method by which treatment is dispensed. Used in HL7 Version 2.x messaging in the Pharmacy/Treatment Encoded order (RXE) and Pharmacy/Treatment dispense (RXD) segments.

dispenseType

Code system of concepts specifying the type of dispensing event that occurred. Used in HL7 Version 2.x messaging in the RXD segment.

documentAvailabilityStatus

HL7-defined code system of concepts used to define whether a patient document is appropriate or available for use in patient care. Used in HL7 Version 2.x messaging in the TXA segment.

documentCompletionStatus

HL7-defined code system of concepts used to record the state of a document in a workflow. Used in HL7 Version 2.x messaging in the TXA segment.

documentConfidentialityStatus2

HL7-defined code system of concetps used to identify the degree to which special confidentiality protection should be applied to this information. Used in HL7 Version 2.x messaging in the TXA segment.

documentStorageStatus

HL7-defined code system of concepts used to describe the availability of a document in relation to the type of storage. Used in HL7 Version 2.x messaging in the TXA segment.

documentType

Code system of concepts used to identify the kind of patient document. Used in HL7 Version 2.x messaging in the TXA segment.

drgDiagnosisDeterminationStatus

HL7-defined cCode system of concepts specifying the status of a diagnosis for a diagnosis related group (DRG) determination. US Realm. Used in HL7 Version 2.x messaging in the DG1 segment.

drgGroupingStatus

Code system of concepts specifying the status of the use of the gender information for diagnosis related group (DRG) determination. US Realm. Used in HL7 Version 2.x messaging in the DRG segment.

drgProcedureDeterminationStatus

Code system of concepts specifying the status of the use of this particular procedure for the diagnosis related group (DRG) determination. US Realm. Used in HL7 Version 2.x messaging in the PR1 segment.

drgProcedureRelevance

Code system of concepts specifying the relevance of this particular procedure for the diagnosis related group (DRG) determination. US Realm. Used in HL7 Version 2.x messaging in the PR1 segment.

drgStatusFinancialCalculation

Code system of concepts specifying the status of the diagnosis related group (DRG) calculation regarding the financial aspects. US Realm. Used in HL7 Version 2.x messaging in the DRG segment.

drgStatusPatient

Code system of concepts specifying whether the length of stay is normal or respectively shorter or longer than normal. Used in HL7 Version 2.x messaging in the DRG segment.

drgStatusRespirationMinutes

Code system of concepts specifying the status of the use of the respiration minutes information for diagnosis related group (DRG) determination. US Realm. Used in HL7 Version 2.x messaging in the DRG segment.

drgTransferType

HL7-defined code system of concepts which specify a type of hospital receiving a transfer patient, which affects how a facility is reimbursed under diagnosis related group (DRG’s), for example, exempt or non-exempt. Used in HL7 Version 2 messaging in the DRG segment.

drgstatusAdmission

Code system of concepts specifying the admission status for the diagnosis related group (DRG) determination. US Realm. Used in HL7 Version 2.x messaging in the DRG segment.

drgstatusWeightAtBirth

Code system of concepts specifying the status of the use of the weight at birth for diagnosis related group (DRG) determination. US Realm. Used in HL7 Version 2.x messaging in the DRG segment.

durationCategories

Code system of concepts used to classify an observation definition as intended to measure a patient’s state at a point in time. Used in HL7 Version 2.x messaging in the OM1 segment.

eligibilitySource

Code system of concepts which specify the source of information about the insured’s eligibility for benefits. Used in HL7 Version 2.x messaging in the IN2 segment.

employmentStatus

HL7-defined code system of concepts which specify an employment status of a person. Used in HL7 Version 2 messaging in the GT1 segment.

encoding

HL7-defined code system of concept identifying the type of encoding used to represent successive octets of binary data as displayable ASCII characters. These are defined by IETF; more information may be found at https://www.ietf.org/rfc/rfc1521.txt. Used in HL7 Version 2.x messaging in the ED datatypes.

environmentalFactors

Code system of concepts that identify the other environmental factors associated with the specimen in a specific container, e.g., atmospheric exposure. Used in the Interaction Specimen Container Detail (SAC) segment in HL7 Version 2.x messaging.

equipmentState

HL7-defined code system of concepts that identify the status the equipment was in at the time the transaction was initiated. Used in HL7 Version 2.x messaging in the EQU segment.

equipmentStateIndicator

HL7-defined code sytem of cocepts that specify the type of measurement of the state of an automated laboratory instrument. Used in HL7 Version 2.x messaging in the INV segment.

errorSeverity

HL7-defined code system of concepts specifying the severity of an application error as reported during acknowledgment of messages. Knowing if something is Error, Warning or Information is intrinsic to how an application handles the content and the information flow. Used in HL7 Version 2.x messaging acknowledgment in the ERR segment.

escortRequired

HL7-defined code system of concepts defining whether patient transportation preparations are in place. Used in HL7 Version 2.x messaging in the OBR segment.

ethnicGroup

Code system of concepts further defining a patient’s ancestry. In the US, a current use is to use these codes to report ethnicity in line with US federal standards for Hispanic origin. Used for HL7 Version 2 messaging in the PID segment.

eventConsequence

HL7-defined code system of concepts used to describe the impact of an event on a patient. Used in HL7 Version 2.x messaging in the PEO segment.

eventExpected

HL7-defined code system of concepts used to communicate whether an event has been judged to be expected or unexpected. Used in HL7 Version 2.x messaging in the PEO segment.

eventQualification

HL7-defined code system of concepts used to qualify an event related to a product experience. Used in HL7 Version 2.x messaging in the PEO segment.

eventReason

Code system of concepts which specify the reason for an event. Used in HL7 Version 2.x messaging in the EVN segment.

eventRelatedPeriod

HL7-defined code system of concepts specifying a common (periodical) activity of daily living. Used in HL7 Version 2 messaging in the RPT segment.

eventReportedTo

HL7-defined code system of concepts used to identify the type of entity to which the even has been reported. Used in HL7 Version 2.x messaging in the PES segment.

eventSeriousness

HL7-defined code system of concepts used by a sender to designate an event as serious or significant. Used in HL7 Version 2.x messaging in the PEO segment.

eventType

HL7-defined code system of concepts specifying the trigger event for Version 2.x interface messages. Used in HL7 Version 2.x messaging in the MSH segment.

eventType

HL7-defined code system of concepts specifying the type of event of the message. Used in HL7 Version 2.x messaging in the EQP segment.

exclusiveTest

HL7-defined code system of concepts that define if a test should be a specific event with no other tests to be performed with this test, or not, or other special circumstances. Used in HL7 Version 2.x messaging in Master Files (OM1 segment) to characterize observations in a master of such orderables.

expandedYes-NoIndicator

HL7-defined code system of concepts used to specify an expansion on the original Yes/No indicator table by including “flavors of null”. It is intended to be applied to fields where the response is not limited to “yes” or “no”. Used in numerous locations in HL7 Version 2.x messaging.

extendedPriorityCodes

Code system of concepts describing the urgency of a request carried in an order. Used in HL7 Version 2.x messaging in timing/quantity; in older versions of the Standard was used in the TQ datatype, but in later versions it is used in the TQ1 segment (which replaced the TQ datatype which has been withdrawn).

facilityType

HL7-defined code system of concepts used to specify the type of facility. Used in HL7 Version 2.x messaging in the Facility (FAC) segment.

file-levelEvent

HL7-defined code system of concepts specifying file-level events for master files. Used in HL7 Version 2 messaging in the MFI segment.

fillerStatus

Code system of concepts used to describe an appointment status from the perspective of the entity assigned to fulfill the appointment. Used in HL7 Version 2.x messaging in the SCH segment.

formularyStatus

Code system of concepts specifying whether or not the service (pharmaceutical) is in the formulary. Used in HL7 Version 2.x messaging in the OM7 segment.

formularyStatus

HL7-defined code system of concepts specifying whether or not the pharmaceutical substance is part of the local formulary. Used in HL7 Version 2.x messaging in the RXE segment.

gestationCategory

HL7-defined code system of concepts which specify the status of a birth in relation to the gestation. Used in HL7 Version 2 messaging in the ABS segment.

governmentReimbursementProgram

Code system of concepts which specify codes that indicate an agency that the practitioner is authorized to bill for medical services. Existing codes only for use in the United States. Used in HL7 Version 2.x messaging in the PRA segment.

grouperStatus

Code system of concepts specifying the status of a grouper in general. US Realm. Used in HL7 Version 2.x messaging in the DRG segment.

hospitalService

Code system of concepts specifying the treatment or type of surgery the patient is scheduled to receive. Used in HL7 Version 2.x messaging in the PV1 segment.

identifierType

HL7-defined code system of concepts specifying type of identifier. Used in HL7 Version 2.x messaging data types CX, PLN, PPN, XCN and XON.

identityMayBeDivulged

HL7-defined code system of concepts used to define whether the primary observer has given permission for their identification information to be provided to a product manufacturer. Used in HL7 Version 2.x messaging in the PEO segment.

identityReliability

Code system of concepts specifying the reliability of patient/person identifying data transmitted via a transaction. Used in HL7 Version 2.x messaging in the PID segment.

immunizationRegistryStatus

Code system of concepts specifying the immunization registry status of the patient. Used in HL7 Version 2.x messaging in the PD1 segment.

inactiveReason

Code system of concepts specifying the reason the staff member is inactive. Used in HL7 Version 2 messaging in the STF segment.

incidentType

HL7-defined code system of concepts which specify a classification of types of incidents. Used in HL7 Version 2 messaging in the RMI segment.

indirectExposureMechanism

HL7-defined code system of concepts used to identify the mechanism of product transmission when the product has not been directly applied to the patient. Used in HL7 Version 2.x messaging in the PCR segment.

informInstructions

Code system of concepts specifying who (if anyone) should or should not be informed of an error. Used in the Error (ERR) segment in HL7 Version 2.x messaging.

institutionRelationshipType

Code system of concepts specifying the relationship the staff person has with the institution for whom he/she provides services. Used in HL7 Version 2 messaging in the STF segment.

insuranceCompanyContactReason

Code system of concepts used to describe why an insurance company has been contacted. Used in HL7 Version 2.x messaging in the IN2 segment.

intendedProcedureType

HL7-defined code system of concepts specifying the type of intended procedure. Used in HL7 Version 2.x messaging in the DON segment.

invocationEvent

HL7-defined code system of concepts which specify codes for an event precipitating/triggering a charge activity. Used in HL7 Version 2.x messaging in the CCD and BLG segments.

invoiceControl

Code system of concepts used to specify what action is being performed by this message. Used in the Invoice (IVC) segment in HL7 Version 2.x messaging.

invoiceProcessingResultsStatus

Code system of concepts used to specify the processing status for an Invoice Processing Result. Used in the Invoice Processing Result (IPR) segment in HL7 Version 2.x messaging.

invoiceReason

Code system of concepts used to specify the reason for this invoice. Used in the Invoice (IVC) segment in HL7 Version 2.x messaging.

invoiceType

Code system of concepts used to specify the type of invoice. Used in the Invoice (IVC) segment in HL7 Version 2.x messaging.

itemImportance

Code system of concepts that denote a level or importance of an inventory item within the context of an inventory location. Used in HL7 Version 2.x messaging in the IVT segment.

itemStatus

Code system of concepts that identify the state of an inventory item within the context of an inventory location. Used in HL7 Version 2.x messaging in the IVT segment.

itemStatus

Code system of concepts specifying the status (useful for reporting and item usage purposes) that applies to an item. Used in HL7 Version 2.x messaging in the ITM segment.

itemType

Code system of concepts specifying a classification of material items into like groups as defined and utilized within an operating room setting for charting procedures. Used in HL7 Version 2.x messaging in the ITM segment.

jobStatus

HL7-defined code system of concepts specifying the next of kin/associated party’s job status. Used in HL7 Version 2.x messaging in the Next of Kin/Associated Parties (NK1) segment.

jurisdictionalBreadth

Code system of concepts specifying the breadth/extent of the jurisdiction where the qualification is valid. Used in HL7 Version 2 messaging in the CER segment.

kindOfQuantity

HL7 published code system of concepts that describe categories of an underlying kind of property represented by an observation. These are intended to distinguish concentrations from total amounts, molar concentrations from mass concentrations, partial pressures from colors, and so forth. These are discussed more fully in the LOINC Users’ Manual. These defined categories are derived from the approach described in 1995 edition of the IUPAC Silver Book. These distinctions are used in IUPAC and LOINC standard codes. Needs review by OO and HTA to determined if this is a value set built on LOINC part codes or some other external vocabulary.

laborCalculationType

Code system of concepts that identify the method used to calculate employee labor and measure employee productivity. Used in HL7 Version 2.x messaging in the SCP segment.

languageAbility

Code system of concepts which specify codes that indicate the ability that a Staff Member possesses with respect to the language. Used in HL7 Version 2.x messaging in the LAN segment.

languageProficiency

HL7-defined code system of concepts which specify a level of knowledge that a Staff Member possesses with respect to their language ability. Used in HL7 Version 2 messaging in the LAN segment.

levelOfCare

Code system of concepts used to identify the level of care a patient may be afforded when assigned to this location definition. Used in HL7 Version 2.x messaging in the LCH segment.

limitationTypeCode

HL7-defined code system of concepts specifying the type of limitation. Used in HL7 Version 2.x messaging in the DPS segment.

livingArrangement

Code system of concepts characterizing the situation that patient-associated parties live in at their residential address. Used in HL7 Version 2.x messaging in the NK1 and PD1 segments.

livingDependency2

HL7-defined code system of concepts that identify specific living conditions (e.g., spouse dependent on patient, walk-up) that are relevant to an evaluation of the patient’s healthcare needs. This information can be used for discharge planning. Examples might include Spouse Dependent, Medical Supervision Required, Small Children Dependent. Used in Version 2.s messaging in the NK1 segment.

livingWillCodes

Code system of concepts specifying whether or not the patient has a living will and, if so, whether a copy fo the living will is on file at the healthcare facility. If the patient does not have a living will, the value of this field indicates whether the patient was provided information on living wills. Used in HL7 Version 2.x messaging in the Patient Visit - Additional Information ( PV2) and Patient Additional Demographic (PD1) segments.

loadStatus

Code system of concepts used to define the status of the information provided in a device sterilization or decontamination cycle. Used in HL7 Version 2.x messaging in the SDD segment.

local-remoteControlState

HL7-defined code system of concepts that identify the current state of control associated with the equipment. Equipment can either work autonomously (‘Local’ control state) or it can be controlled by another system, e.g., LAS computer (‘Remote’ control state). Used in the Equipment Detail (EQU) segment in HL7 Version 2.x messaging.

locationCharacteristic

Code system of concepts specifying an identifier code to show which characteristic is being communicated with the segment. Used in HL7 Version 2.x messaging in the Location Characteristic (LCH) segment.

locationEquipment

Code system of concepts used to identify the equipment available in a location definition identified as a room or bed. Used in HL7 Version 2.x messaging in the LOC segment.

locationRelationship

Code system of concepts specifying an identifier code to show which relationship is being communicated with the segment. Used in HL7 Version 2.x messaging in the Location Relationship (LRL) segment.

locationServiceType

Code system of concepts specifying the types of services provided by the location. Used in HL7 Version 2.x messaging in the LOC segment.

lotControl

Code system of concepts that define whether the sterilization load for a device is built in the sub-sterile area adjacent to an Operating Room or the Central Processing Department. Used in HL7 Version 2.x messaging in the SCP segment.

mailClaimParty

Code system of concepts which specify a party to which a claim should be mailed when claims are sent by mail. Used in HL7 Version 2.x messaging in the IN2 segment.

maritalStatus

Code system of concepts specifying a person’s marital (civil/legal) status. Used in HL7 Version 2.x messages in the PID segment.

marketingBasis

HL7-defined code system of concepts used to specify the basis for marketing approval. Used in HL7 Version 2.x messaging in the Product Detail Country (PDC) segment.

masterFileIdentifierCodes

HL7-defined code system of concepts which are represented by codes identifying HL7 Versions 2.x Master Files. Used in HL7 Version 2.x messaging in the MFI segment.

masterfileActionCode

HL7-defined code system of concepts specifying an action for a master file record. Used in HL7 Version 2.x messaging in the MFE segment.

matchAlgorithms

Code system of concepts identifying the name or identity of the specific search algorithm to which the RCP-5 Search Confidence Threshold and the QRI-1 Candidate Confidence refer. Used in HL7 Version 2.x messaging in the Query Response Instance (QRI) segment.

matchReason

Code system of concepts identifying what search components (e.g., name, birthdate, social security number) of the record returned matched the original query where the responding system does not assign numeric match weights or confidence levels. It provides a method for passing a descriptive indication of the reason a particular record was found. Used in HL7 Version 2.x messaging in the Query Response Instance (QRI) segment.

medicalRoleExecutingPhysician

Code system of concepts specifying the role of the physician (“self-employed” or “employed”). Used in HL7 Version 2.x messaging in the PSL segment.

messageErrorCondition

HL7-defined code system of concepts specifying the HL7 (communications) error code. Used in the ERR segment in HL7 Version 2.x messaging.

messageStructure

HL7-defined code system of abstract message structure codes. Each code identifies a specific message structure abstract syntax as published in the HL7 Version 2 standard. Used in HL7 Version 2.x messaging in the MSH segment.

messageType

HL7-defined code system of concepts which specify message types. Used in HL7 Version 2.x messaging in the MSH segment.

messageWaitingPriority

HL7-defined code system of concepts which specify the disposition of the patient at time of discharge (i.e., discharged to home, expired, etc.). Used in HL7 Version 2.x messaging in the MSA segment.

mfnRecord-levelErrorReturn

Code system of concepts specifying the status of the requested update. Site-defined table, specific to each master file being updated via this transaction. Used in HL7 Version 2.x messaging in the MFA segment.

militaryService

Code system of concepts which specify the military branch. This field is defined by CMS or other regulatory agencies. Used in HL7 Version 2.x messaging in the PD1 segment.

militaryStatus

Code system of concepts which specify the military status of the patient. This field is defined by CMS or other regulatory agencies. Used in HL7 Version 2.x messaging in the PD1 segment.

mimeBase64EncodingCharacters

HL7-defined code system of concepts specifying the characters used in the MIME Base 64 encoding mechanism. These are for reference only, as they are not carried as explicit code values in any HL7 coded field. This table was published only in releases 2.3, 2.3.1, and 2.4 of the Standard, and was removed thereafter.

mimeTypes

Code system of concepts specifying the general type of data. Used in HL7 Version 2.x messaging in the RP and ED datatypes.

modifyIndicator

HL7-defined code system of concepts identifying whether the subscription is new or is being modified. Used in HL7 Version 2.x messaging in the Response Control Parameter (RCP) segment.

moneyOrPercentageIndicator

HL7-defined code system of concepts which specify whether the amount is currency or a percentage. Used in HL7 Version 2.x messaging in the MOP segment.

name-addressRepresentation

HL7-defined code system of concepts specifying an indication of the representation provided by the data item. Used in HL7 Version 2.x messaging in the PPN, XAD, XCN and XON segments.

name-addressRepresentation

HL7-defined cdoe system of concepts that provide an indication of the kind of representation provided by a name or address, but does not necessarily specify the character sets used for the data. It is used to provides hints for a receiver, so it can make choices regarding what it has been sent and what it is capable of displaying.

nameAssemblyOrder

Code system of concepts specifying the preferred display order of the components of this person name. Used in HL7 Version 2.x messaging in the PPN, XCN and XPN segments.

nameType2

HL7-defined code system of concepts for types of names for persons. Used in HL7 Version 2.x messaging in the XPN, PPN, XCN, PID and MRG segments.

natureOfAbnormalTesting

HL7-defined code system of concepts specifying the nature of an abnormal test. Used in HL7 Version 2.x messaging in the OBX segment.

natureOfChallenge

HL7-defined code system of concepts used to further describe an observation definition that is characterized as a challenge observation. Used in HL7 Version 2.x messaging in the OM1 segment.

natureOfServiceTestObservation

Code system of concepts specifying an identification of a test battery, an entire functional procedure or study, a single test value (observation), multiple test batteries or functional procedures as an orderable unit (profile), or a single test value (observation) calculated from other independent observations, typically used as an indicator for Master Files. Used in HL7 Version 2.x messaging in the OM1 segment.

newbornType

HL7-defined code system of concepts which specify whether the baby was born in or out of a specified facility. Used in HL7 Version 2 messaging in the ABS segment.

non-subjectConsenterReason

HL7-defined code system of concepts used to specify a reason consent was granted by a person other than the subject of the consent. Used in the Consent (CON) segment in HL7 Version 2.x messaging.

nubc-OccurrenceCode-cs

National Uniform Billing Committee (NUBC) UB-04 Data Specifications Manual, UB form locator 31 - 34, Occurrence Codes and Amounts - code and associated date defining asignificant event relating to the bill that may affect payer processing the claim. The UB-04 Data Specifications Manual with the codes is available by subscription from NUBC at http://www.nubc.org/become.html. Used in HL7 Version 2.x messaging in the OCD segment. Updated by NUBC annually; see the coding instructions for more detail. Note that this content was previously published in HL7 artifacts in violaton of IP restrictions; the content has been removed in version 2.2.0 pending finalization of a republication permission request to AHA/NUBC.

nubc-OccurrenceSpan-cs

HL7-defined code system of concepts specifying a National Uniform Billing Committee (NUBC) code that identifies an event that relates to the payment of a claim. The UB-04 Data Specifications Manual with the codes is available by subscription from NUBC at http://www.nubc.org/become.html. Used in HL7 Version 2.x messaging in the Occurrence Span Code and Date (OSP) value. Updated by NUBC annually; see the coding instructions for more detail. Note that this content was previously published in HL7 artifacts in violaton of IP restrictions; the content has been removed in version 2.2.0 pending finalization of a republication permission request to AHA/NUBC.

nubc-PresentOnAdmission-cs

National Uniform Billing Committee (NUBC) UB-04 Data Specifications Manual, UB form locator 67, Present on Admission (POA) Indicator. Code identifying a diagnosis that was present at the time the order for inpatient admission occurs. POA indicator is assigned to all diagnoses as defined in Appendix I of the “ICD-9-CM Official Guidelines for Coding and Reporting” or “ICD-10-CM Official Guidelines for Coding and Reporting (appropriate to the ICD revision used). The UB-04 Data Specifications Manual with the codes is available by subscription from NUBC at http://www.nubc.org/become.html. Used in HL7 Version 2.x messaging in the DG1 segment. Note that this content was previously published in HL7 artifacts in violaton of IP restrictions; the content has been removed in version 2.2.0 pending finalization of a republication permission request to AHA/NUBC.

nubc-ServiceLineRevenue-cs

Code system of concepts specifying a revenue code as specified in the National Uniform Billing Committee (NUBC) UB-04 manual, UB form locator 42, the service line revenue code. These are claim codes indicating the identifying number for the product or service provided. The UB-04 Data Specifications Manual with the codes is available by subscription from NUBC at http://www.nubc.org/become.html. Used in HL7 Version 2.x messaging in the Revenue Code (GP1) value. Updated by NUBC annually; see the coding instructions for more detail. Note that this content was previously published in HL7 artifacts in violaton of IP restrictions; the content has been removed in version 2.2.0 pending finalization of a republication permission request to AHA/NUBC.

observationResultHandling

Code system of concepts regarding the handling of a result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Used in HL7 Version 2.x messaging in the OBR segment.

observationResultStatusCodesInterpretation

HL7-defined code system of concepts which specify observation result status. These codes reflect the current completion status of the results for one Observation Identifier. Used in HL7 Version 2.x messaging in the OBX segment.

observationSubtype

HL7-defined code system of concepts specifying the observation sub-type. Used in HL7 Version 2.x messaging in the OBX segment.

observationType

HL7-defined code system of concepts specifying types of observations to enable systems to distinguish between observations sent along with an order, versus observations sent as the result to an order. Used in HL7 Version 2.x messaging in the OBX segment.

onlineVerificationResult

Code values used to indicate the result of an online verification of insurance data.

onlineVerificationResultErrorCodes

Code values representing a type of error from a failed operation to perform online verification of insurance data.

orderControlCodeReason

HL7-defined code system of concepts that describe reasons for the chosen order control codes. Used in HL7 Version 2 messaging in the ORC segment.

orderControlCodes

HL7-defined code system of concepts which are used to determine the function of the order segment. Depending on the message, the action specified by one of these control codes may refer to an order or an individual service. Used in Version 2.x messaging of orders in the ORC segment.

orderStatus

HL7-defined code system of concepts specifying the status of an order. The purpose of these values are to report the status of an order either upon request (solicited), or when the status changes (unsolicited). The values are not intended to initiate action. It is assumed that the order status value always reflects the status as it is known to the sending application at the time that a message is sent. Only the filler can originate these values. Used in HL7 Version 2.x messaging in the ORC segment.

orderStatusModifier

HL7-defined code system of concepts used to further define the status identified in ORC-5. Used in HL7 Version 2 messaging in the ORC segment.

orderType

HL7-defined code system of concepts specifying whether the order is to be executed in an inpatient setting or an outpatient setting. Used in HL7 Version 2.x messaging in the ORC segment.

organDonorCodes

Code system of concepts specifying whether the patient wants to donate his/her organs and whether an organ donor card or similar documentation is on file with the healthcare organization. Used in HL7 Version 2.x messaging in the Patient Visit - Additional Information ( PV2) and Patient Additional Demographic (PD1) segments.

organization-Agency-Department

Code system of concepts used to specify the agency or department that assigned the identifier in component 1. Used in the Performing Person Time Stamp (PPN), Extended Composite ID Number and Name for Persons (XCN) and Extended Composite ID with Check Digit (CX) segments in HL7 Version 2.x messaging.

organizationUnitType

HL7-defined code system of concepts which identify an environment in which a provider acts in a specified role. The provider environment is not the specialty for the provider. This is intended to allow communication of this information when the provider information may not have been communicated previously in a master file, and is used to support international requirements. Used in HL7 Version 2 messaging in the PRT and ROL segments.

organizationUnitType

Code system of concepts specifying the classification of the organization unit. Used in HL7 Version 2.x messaging in the ORG segment.

organizationalNameType

Code system of concepts used to specify the type of name for an organization i.e., legal name, display name. Used in HL7 Version 2.x messaging in the XON and PD1 segments.

outlierType

HL7-defined code system of concepts specifying the type of outlier (i.e. period of care beyond DRG-standard stay in facility) that has been paid. Used in HL7 Vesrion 2.x messaghing in the DRG segment.

overallClaimDisposition

Code system of concepts specifying the final status of the claim. Used in HL7 Version 2.x messaging in the GP1 segment.

override

Code system of concepts used to define whether a Charge Description Master description may be overridden or if it must be overridden. Used in HL7 Version 2.x messaging in the CDM and PRC segments.

overrideType

Code system of concepts used to specify what type of override can be used to override the specific error identified. Used in HL7 Version 2 messaging in the ERR and OVR segments.

package

Code system of concepts specifying the packaging unit in which this inventory supply item can be ordered or issued when purchased from the vendor in the related vendor segment. Used in HL7 Version 2.x messaging in the PKG segment.

packagingStatus

Code system of concepts specifying the packaging status of the service. Used in HL7 Version 2.x messaging in the GP2 segment.

pan-Canadian LOINC Observation Code Database

The pan Canadian LOINC Observation Code Database (pCLOCD) is the Canadian version of the LOINC(tm) database. It was created using the LOINC(tm) records and attributes that were constrained for Canadian use and supplemented to specifically meet Canadian requirements. It contains the core LOINC(tm) attributes as required by Regenstrief copyright rules. The LOINC(tm) Component has been customized to meet Canadian requirements and is displayed as the pan Canadian Component Name. This component name is the basis for the pan Canadian Display Name. Core attributes are include both English and Canadian French. This code system contains supplemental “X” codes defined in the pCLOCD that do not yet exist in the LOINC code system.

pan-Canadian Provider Qualification Types

SCPQUAL is used to encode the degree or educational rank of a healthcare provider credential as defined by the various Royal Canadian Professional Medical Collages. It is also supports the encoding “Expertise type” in the pan-Canadian version 3 messages

pan-Canadian Provider Types

This code system contains the list of provider types used in the pan-Canadian specifications.

pan-Canadian Temporary Codes

These pan-Canadian codes are maintained in circumstances where the desired code is not yet available in another code system (HL7 code systems, LOINC, SNOMED, etc.) In general, the codes will be deprecated once an equivalent code is available in the preferred code system.

participation

HL7-defined code system of concepts that represent functional involvement of a caregiver or member of a care team with an activity being transmitted (e.g., Case Manager, Evaluator, Transcriber, Nurse Care Practitioner, Midwife, Physician Assistant, etc.). Used in HL7 Version 2.x messaging in the PRT segment.

patientClass

Code system of concepts used by systems to categorize patients by site in HL7 Version 2.x interfaces in the PV1 segment.

patientCondition

Code system of concepts specifying the patient’s current medical condition for the purpose of communicating to non-medical outside parties, e.g. family, employer, religious minister, media, etc. Used in HL7 Version 2.x messaging in the PV2 segment.

patientLocationType

Code system of concepts used to identify the kind of location described in the location definition. Used in HL7 Version 2.x messaging in the LOC segment.

patientOutcome

HL7-defined code system of concepts used to describe the overall state of a patient as a result of patient care. Used in HL7 Version 2.x messaging in the PEO segment.

patientResultsReleaseCategorizationScheme

HL7-defined code system of concepts specifying the scheme for the patient results release categorization. Used in HL7 Version 2.x messaging in the OBX segment.

patientStatus

Code system of concepts used to define the state of a care episode for a patient. Used in HL7 Version 2.x messaging in the PV2 segment.

patientsRelationshipToInsured

Code system of concepts used to specify the relationship of the patient to the insured, as defined by CMS or other regulatory agencies. Used in HL7 Version 2.x messaging in the Insurance Additional Information (IN2) segment.

payeeRelationshipToInvoice

Code system of concepts used to specify the relationship to the invoice for Person Payee Types. Used in the Payee Information (PYE) segment in HL7 Version 2.x messaging.

payeeType

Code system of concepts used to specify the type of payee (e.g., organization, person). Used in the Payee Information (PYE) segment in HL7 Version 2.x messaging.

paymentAdjustmentInformation

Code system of concepts specifying any payment adjustment due to drugs or medical devices. Used in HL7 Version 2.x messaging in the GP2 segment.

paymentMethod

Code system of concepts used to specify the method for the movement of payment. Used in the Payment Information (PMT) segment in HL7 Version 2.x messaging.

pcaType

HL7-defined code system of concepts specifying the type of PCA. Used in HL7 Version 2.x messaging in the RXV segment.

personLocationType

Code system of concepts specifying the categorization of the person’s location. Used in HL7 Version 2.x messaging datatypes that contain location identifiers such as Person Location (PL), Location with address variation (LA) and Name with date and location (NDL).

pharmacyOrderTypes

HL7-defined code system of concepts specifying the general category of pharmacy order which may be used to determine the processing path the order will take. Used in HL7 Version 2.x messaging in the RXO, RXE, RXD, RXG and RXA segments.

phlebotomyIssue

HL7-defined code system of concepts specifying the phlebotomy issue. Used in HL7 Version 2.x messaging in the DON segment.

phlebotomyStatus

HL7-defined code system of concepts specifying the status of the phlebotomy. Used in HL7 Version 2.x messaging in the DON segment.

policyType

Code system of concepts which specify the policy type. Used in HL7 Version 2.x messaging in the PTA segment.

precaution

Code system of concepts specifying non-clincal precautions that need to be taken with the patient. Used in HL7 Version 2.x messaging in the PV2 segment.

precision

HL7-defined code system of concepts specifying the degree of precision of the time stamp (Y = year, L = month, D = day, H = hour, M = minute, S = second). Used in HL7 Version 2 messaging in the TS datatype. Note deprecated in 2.5.1 and retained only for backward compatibility, as the datatypes and architecture for the degree of precision for timestamps was changed.

preferredMethodOfContact

HL7-defined code system of concepts specifying which of a group of multiple phone numbers is the preferred method of contact for this person. Used in HL7 Version 2.x messaging in the STF, PRD, and CTD segments.

preferredSpecimen-AttributeStatus

HL7-defined code system of concepts that indicate whether a Specimen/Attribute is Preferred or Alternate for collection of a particular specimen. Used in HL7 Version 2.x messaging in Master Files (OM4 segment) to characterize information about specimens that are associated with certain observations.

priceType

HL7-defined code system of concepts used to identify the intent for the dollar amount on a pricing transaction. Used in HL7 Version 2.x messaging in the CP datatype.

primaryKeyValueType

HL7-defined code system of concepts used to specify the type for the master file record identifier. Used in HL7 Version 2.x messaging in the Master File Entry (MFE) segment.

primaryObserverQualification

HL7-defined code system of concepts used to provide a general description of the kind of health care professional who provided the primary observation. Used in HL7 Version 2.x messaging in the PEO and PCR segments.

priority

HL7-defined code system of concepts specifying the allowed priorities for obtaining the specimen. Used in HL7 Version 2.x messaging in the OM4 segment.

privacyLevel

Code system of concepts used to identify the level of privacy a patient will be afforded when assigned to this location definition. Used in HL7 Version 2.x messaging in the LCH segment.

problem-goalAction

HL7-defined code system of concepts used in Patient Care for the intent of a problem or goal. Used in HL7 Version 2.x messaging in the GOL, ROL, PRB and PTH segments.

procedureDrgType

HL7-defined code system of concepts which specify a procedure’s priority ranking relative to its DRG. Used in HL7 Version 2 messaging in the PR1 segment.

procedureFunctionalType

Code system of concepts used to classify a procedure. Used in HL7 Version 2.x messaging in the PR1 segment.

procedurePractitionerIdentifierCodeType

HL7-defined table of concepts which specify the different types of practitioners associated with this procedure. This set of codes is known to be incomplete. Note that as of v2.6, this table and the field(s) it was used in was replaced by table 443 used in the ROL segment. Used in Version 2.x messaging in the PR1 segment, but was discontinued as of 2.6; usage replaced with code system 2.16.840.1.113883.18.283 providerRole.

procedurePriority

HL7-defined code system of concepts which specify the significance or priority of a procedure code. Used in HL7 Version 2 messaging in the PR1 segment. Note that this is a post-coordinated code system, where additional ordinal priorities are created by incrementing the numericinteger code value as needed. Only the first 2 ordinal values are predefined in the code system.

processInterruption

HL7-defined code system of concepts specifying whether the process was interrrupted and whether the needle had been inserted in the donor’s arm prior to the interruption. Used in HL7 Version 2.x messaging in the DON segment.

processInterruptionReason

HL7-defined code system of concepts specifying the reason for the process interruption. Used in HL7 Version 2.x messaging in the DON segment.

processingConsideration

Code system of concepts used to specify special processing requested of Payer for this Product/Service Line Item (e.g., hold until paper supporting documentation is received by Payer). Used in the Product/Service Line Item (PSL) segment in HL7 Version 2.x messaging.

processingId

HL7-defined code system of concepts which specify whether the message is part of a production, training or debugging system. Used in HL7 Version 2.x messaging in the PT datatype.

processingMode

HL7-defined code system of concepts that indicate an archival process or an initial load process. Used in HL7 Version 2.x messaging in the PT datatype.

processingPriority

HL7-defined code system of concepts which specify one or more available priorities for performing the observation or test. Used in HL7 Version 2.x messaging in the OM1 segment.

processingType

HL7-defined code system of concepts identifying the processing type that applies to the test code. If this attribute is omitted, then regular production is the default. Used in HL7 Version 2.x messaging in the Test Code Configuration (TCC) segment.

product-serviceStatus

Code system of concepts used to specify the processing status for the Product/Service Code. Used in the Product/Service Line Item (PSL) segment in HL7 Version 2.x messaging.

product-servicesClarification

Code system of concepts used to specify the Product/Service Code. Used in the Product/Service Line Item (PSL) segment in HL7 Version 2.x messaging.

productSource

HL7-defined code system of concepts used to describe the evaluation state of a product identified in an incident. Used in HL7 Version 2.x messaging in the PCR segment.

productionClass

Code system of concepts specifying the code and/or text indicating the primary use for which the living subject was bred or grown. Used in HL7 Version 2.x messaging in the PID segment.

protection

Code system of concepts specifying that an address needs to be treated with special care or sensitivity. Used in HL7 Version 2.x messaging in the XAD and XTN segments.

providerAdjustmentReason

Code system of concepts used to specify the reason for this adjustment. Used in the Adjustment (ADJ) segment in HL7 Version 2.x messaging.

providerBilling

HL7-defined code system of concepts specifying how provider services are billed. Used in HL7 Version 2.x messaging in the PRA segment.

providerRole

Code system of concepts used to define the relationship between a referral recipient and a patient or between a referral initiator and a patient. Used in HL7 Version 2.x messaging in the PRD segment.

providerRole

Code system of concepts specifying the functional involvement with the activity being transmitted (e.g., Case Manager, Evaluator, Transcriber, Nurse Care Practitioner, Midwife, Physician Assistant, etc.). Used in HL7 Version 2.x messaging in the ROL segment.

publicity

Code system of concepts specifying a level of publicity of information about a patient for a specific visit. Used in HL7 Version 2.x messaging in the PV2 and PD1 segments.

purgeStatus

Code system of concepts used to define the state of a visit relative to its place in a purge workflow. Used in HL7 Version 2.x messaging in the PV2 segment.

quantityLimitedRequest

HL7-defined code system of concepts which specify the maximum length of a query response that can be accepted by a requesting system, and are expressed as units of mesaure of query response objects. Used in HL7 Version 2.x messaging in the RCP segment.

quantityMethod

HL7-defined code system of concepts used to specify the method by which the quantity distributed is measured. Used in HL7 Version 2.x messaging in the Product Summary Header (PSH) segment.

queryPriority

HL7-defined code system of concepts which specify a time frame in which a querry response is expected. Used in HL7 Verson 2.x messaging in the RCP segment.

queryResponseFormat

HL7-defined code system of concepts which specify which of several types of formats for data to be returned in response to a query. Used in HL7 Version 2 messaging in the EQL segment.

queryResponseStatus

HL7-defined code system of concepts defining precise response status concepts in support of HL7 Version 2 query messaging. It is commonly used to indicate no data is found that matches the query parameters, but no error. Used in HL7 Version 2.x messaging in the QAK segment.

queryResultsLevel

HL7-defined code system of concepts which are used to control level of detail in query results. Used in HL7 Version 2 messaging in the URD segment.

re-admissionIndicator

Code system of concepts which are used to specify that a patient is being re admitted to a healthcare facilityin from which they were discharged, and indicates the circumstances around such re-admission. Used in HL7 Version 2.x messagine in the PV1 segment.

reasonForStudy

HL7-defined code system of concepts that provide additional information to the universal service identifier on why a test, study or review was ordered. Initial values are to support the IHE LCC LAB-7 transaction.

recreationalDrugType

Code system of concepts specifying what recreational drugs the patient uses. Used in HL7 Version 2.x messaging in the PV2 segment.

referralCategory

Code system of concepts used to describe the patient care setting where a referral should take place. Used in HL7 Version 2.x messaging in the RF1 segment.

referralDisposition

Code system of concepts used to identify the expected response from the healthcare professional receiving a referral. Used in HL7 Version 2.x messaging in the RF1 segment.

referralPriority

Code system of concepts used to designate the urgency of a referral. Used in HL7 Version 2.x messaging in the RF1 segment.

referralReason

Code system of concepts used to specify the reason for which the referral will take place. Used in HL7 Version 2.x messaging in the Referral Information (RF1) segment.

referralStatus

Code system of concepts used to define the state of a referral. Used in HL7 Version 2.x messaging in the RF1 segment.

referralType

Code system of concepts used to identify the general category of healthcare professional desired to satisfy a referral. Used in HL7 Version 2.x messaging in the RF1 segment.

reimbursementType

Code system of concepts specifying the fee schedule reimbursement type applied to the line item. Used in HL7 Version 2.x messaging in the GP2 segment.

relatednessAssessment

HL7-defined code system of concepts used to provide an estimate of whether an issue with a product was the cause of an event. Used in HL7 Version 2.x messaging in the PCR segment.

relationalConjunction

HL7-defined code system of concepts used with relationalOperator values to group more than one segment field name. Used in HL7 Version 2.x messaging in the QSC segment.

relationalOperator

HL7-defined code system of concepts used to define the relationship between HL7 segment field names identified in a query construct. Used in HL7 Version 2.x messaging in the QSC segment.

relationship

HL7-defined code system of concepts specifying an actual personal relationship that the next of kin/associated party has to a patient. Used in HL7 Version 2.x messaging in the NK1 and IN1 segments.

relationshipModifier

HL7-defined code system of concepts used in an observation definition to describe the subject of an observation in relation to a patient. Used in HL7 Version 2.x messaging in the OM1 segment.

relevantClincialInformation

Code system of concepts specifying additional clinical information about the patient or specimen to report the supporting and/or suspected diagnosis and clinical findings on requests for interpreted diagnostic studies. Used in HL7 Version 2.x messaging in the OBR segment.

religion2

Code system of concepts specifying a person’s religion. Used in HL7 Version 2.x messaging in the PID segment.

remoteControlCommand

Code system of concepts that identify the comment the component is to initiate. Used in the Equipment Command (ECD) and Interaction Status Detail (ISD) segments in HL7 Version 2.x messaging.

reorderTheory

Code system of concepts that identify the calculation method used to determine the resupply schedule. Used in HL7 Version 2.x messaging in the IVT segment.

repeatPattern

Code system of concepts used to specify the interval between repeated services. Used in HL7 Version 2.x messaging in the RI datatype and RPT segment.

reportPriority

HL7-defined code system of concepts which specify the priority associated with a report or update run using a query. Used in HL7 Version 2 messaging in the URD segment.

reportSource

HL7-defined code system of concepts used to identify where a report sender learned about an event. Used in HL7 Version 2.x messaging in the PES segment.

reportTiming

HL7-defined code system of concepts used to identify the time span of a report or the reason for a report sent to a regulatory agency. Used in HL7 Version 2.x messaging in the PES segment.

reportingPriority

HL7-defined code system of concepts which specify the available priorities reporting the test results when the user is asked to specify the reporting priority independent of the processing priority. Used in HL7 Version 2.x messaging in the OM1 segment.

responseFlag

HL7-defined code system of concepts allowing the placer (sending) application to determine the amount of information to be returned from the filler. Used in HL7 Version 2.x messaging in the ORC segment.

responseLevel

HL7-defined code system of concepts specifying application response levels defined for a given Master File Message at the MFE segment level, and used for MFN-Master File Notification message. Specifies additional detail (beyond MSH-15 - Accept Acknowledgment Type and MSH-16 - Application Acknowledgment Type) for application-level acknowledgment paradigms for Master Files transactions. Used in HL7 Version 2.x messaging in the MFI segment.

responseModality

HL7-defined code system of concepts identifying the timing and grouping of the response message(s). Used in HL7 Version 2.x messaging in the Response Control Parameter (RCP) segment.

resultStatus

HL7-defined code system of concepts which specify a status of results for an order. Used in HL7 Version 2.x messaging in the OBR segment.

riskManagementIncident

HL7-defined code system of concepts which specify a type of incident that occurs during a patient’s stay. Used in HL7 Version 2 messaging in the RMI segment.

risks

Code system of concepts specifying any known or suspected specimen hazards, e.g., exceptionally infectious agent or blood from a hepatitis patient. Used in HL7 Version 2.x messaging in the SPM and PAC segments.

roleExecutingPhysician

Code system of concepts specifying the account role of the physician, for example, only billing for the professional part, the technical part or both. Used in HL7 Version 2.x messaging in the PSL segment.

roomType

Code system of concepts which specify the room type. Used in HL7 Version 2.x messaging in the RMC segment.

rootCause

Code system of concepts specifying the root cause. Used in HL7 Version 2.x messaging in the OBX segment.

route

HL7-defined code system of concepts that indicate a means of administrating a medication dose. Used in HL7 Version 2 messaging in the RX1 segment (which was withdrawn after version 2.2). As of HL7 version 2.3, it was replaced by 2.16.840.1.113883.18.80 routeOfAdministration and 2.16.840.1.113883.18.83 administrationMethod. Used in the RX1 segment.

routeOfAdministration

Code system of concepts which specify the route of administration. Used in HL7 Version 2.x messaging in the RXR segment.

rulingAct

Code system of concepts specifying an act containing a rule that the item is legally required to be included in notification reporting. Used in HL7 Version 2.x messaging in the ITM segment.

rxComponentType

HL7-defined code system of concepts which specify the RX component type. Used in HL7 Version 2.x messaging in the RXC segment.

schoolType

Code system of concepts which specify a categorization of an academic institution that grants a degree to a Staff Member. Used in HL7 Version 2.x messaging in the EDU segment.

securityCheckScheme

HL7-defined code system of concepts specifying the scheme for the security check. Used in HL7 Version 2.x messaging in the CX datatypes and PPN and XCN segments.

segmentAction

HL7-defined code system of concepts specifying actions to be applied for segments when an HL7 version 2 interface is operating in “action code mode” (a kind of update mode in the Standard). Used in HL7 Version 2.x messaging in the RXA, RXV, LCH, IAM, ARV, IN1 and OH1 segments.

segmentGroup

HL7-defined code system of concepts specifying the optional segment groups which are to be included in the response. This is a repeating field, to accommodate inclusion of multiple segment groups. The default for this field, not present, means that all relevant groups are included. Used in HL7 Version 2.x messaging in the Response Control Parameter (RCP) segment.

sensitivityToCausativeAgent

Code system of concepts specifying the reason the patient should not be exposed to a substance. Used in HL7 Version 2.x messaging in the IAM segment.

sequenceCondition

HL7-defined code system of concepts used to specify the relationship between the start/end of the related service request(s) (from TQ2-3, TQ2-4 or TQ2-5) and the current service request from ORC-2, 3 or 4. Used in HL7 Version 2.x messaging in the TQ2 segment.

sequenceCondition

HL7-defined code system of concepts that identify whether sequence conditions or a repeating cycle of orders is defined. This is part of the Order Sequence Definition used in HL7 Version 2.x messaaging in the OSD datatype.

sequenceResultsFlag

HL7-defined code system of concepts used to specify the sequencing relationship between the current service request and the related service request(s) specified in this TQ2 segment. Used in the Timing/Quantity Relationship (TQ2) segment in HL7 Version 2.x messaging.

sequenceStatus

Codes providing the status of the variant test result.

sequencing

HL7-defined code system of concepts identifying how the field or parameter will be sorted and, if sorted, whether the sort will be case sensitive (the default) or not. Used in HL7 Version 2.x messaging in the Sort Order (SRT) value.

serviceRequestRelationship

HL7-defined code system of concepts used to specify an additional or alternate relationship between this service request and other service requests. Used in the Timing/Quantity Relationship (TQ2) segment in HL7 Version 2.x messaging.

severityOfIllness

HL7-defined code system of concepts which specify the ranking of a patient’s illness. Used in HL7 Version 2 messaging in the ABS segment.

shipmentStatus

HL7-defined code system of concepts specifying the status of the shipment. Used in HL7 Version 2.x messaging in the SHP segment.

sideOfBody

Code system of concepts specifying the side of the body (“left” or “right”). Used in HL7 Version 2.x messaging in the PSL segment.

signatorysRelationshipToSubject

Code system of concepts specifying the relationship of the consenter to the subject. Used in HL7 Version 2 messaging in the CON segment.

signatureType

Code system of concepts that indicate how a patient/subscriber authorization signature is obtained and how it is being retained by a provider. Used in HL7 Version 2.x messaging in the IN1 segment.

siteAdministered

HL7-defined code system of concepts used for medication administration sites. Used only in HL7 releases 2.1 and 2.2; as of 2.3 the model for this was changed and the field using this code system was removed from the Standard.

sourceOfComment

HL7-defined code system of concepts which are used to specify the source of a comment. Used in HL7 Version 2.x messaging in the NTE segment.

sourceType

HL7-defined code system of concepts used to specify the type of facility. Used in HL7 Version 2.x messaging in the Facility (FAC) segment.

specialHandling

Code system of concepts describing how a specimen and/or container needs to be handled from the time of collection through the initiation of testing. Used in HL7 Version 2.x messaging in the SPM, SAC, PAC and OM4 segments.

specialProgram

Code system of concepts used to record a health insurance program required for healthcare visit reimbursement. Used in HL7 Version 2.x messaging in the PV2 segment.

specialtyType

Code system of concepts used to identify the specialty of the care professional who is supported when using this location definition. Used in HL7 Version 2.x messaging in the LDP segment.

specimenAction

HL7-defined code system of concepts which specify actions to be taken with respect to the specimens that accompany or precede an order. The purpose of these are to further qualify (when appropriate) the general action indicated by the order control code (code system xxxx). Used in HL7 Version 2.x messaging in the OBR segment.

specimenAppropriateness

Code system of concepts specifying the suitability of the specimen for the particular planned use as determined by the filler. Used in HL7 Version 2.x messaging in the SPM segment.

specimenChildRole

HL7-defined code system of concepts specifying for child specimens the relationship between this specimen and the parent specimen. Used in HL7 Version 2.x messaging in the SPM segment.

specimenCollectionMethod

HL7-defined code system of concepts specifying the specimen collection method. Used in HL7 Version 2.x messaging in the SPM segment.

specimenComponent

Code system of concepts that identify the specimen component, e.g., supernatant, sediment, etc. Used in the Interaction Specimen Container Detail (SAC) segment in HL7 Version 2.x messaging.

specimenCondition

Code system of concepts specifying a mode or state of being that describes the nature of the specimen. Used in HL7 Version 2.x messaging in the SPM segment.

specimenQuality

Code system of concepts specifying the degree or grade of excellence of the specimen at receipt. Used in HL7 Version 2.x messaging in the SPM segment.

specimenRejectReason

HL7-defined code system of reasons a specimen may be rejected for a specified observation/result/analysis. Used in HL7 Version 2.x messaging in the SPM segment.

specimenRole

HL7-defined code system of concepts that identify the role of a sample. Used in HL7 Version 2.x messaging in the Specimen (SPM) and Observation Request (OBR) segments.

specimenSourceCodes

HL7-defined code system of concepts which specify sources for speciments for clinical testing. These concepts are used in HL7 Version 2.x messaging in the OBR segment prior to version 2.7, and was replaced by the concepts in code system 2.16.840.1.133883.18.311 specimenType and code system 2.16.840.1.133883.18.312 specimenCollectionMethod as of version 2.5 and thereafter.

specimenType

HL7-defined code system of concepts that describe the precise nature of an entity that may be used as the source material for an observation. This is one of two code systems that are used instead of table 0070 (code system 2.16.840.1.113883.18.28) which conflated specimen types and specimen collection methods. Used in HL7 Version 2.x messaging in the SPM segment.

statusOfEvaluation

HL7-defined code system of concepts that describes the status of product evaluation. Used in HL7 Version 2.x messaging in the PCR segment.

sterilizationType

Code system of concepts specifying the type of sterilization used for sterilizing the inventory supply item in the ITM segment. Used in HL7 Version 2.x messaging in the STZ segment.

stockLocation

Code system of concepts specifying a stock location for older Version 2 messaging systems; not used after version 2.2 of the Standard.

studentStatus

Code system of concepts used to designate whether a guarantor is a full or part time student. Used in HL7 Version 2.x messaging in the GT1, NK1 and PD1 segments.

substanceStatus

HL7-defined code system of concepts identifying the status of the inventoried item. The status indicates the current status of the substance. Used in HL7 Version 2.x messaging in the Inventory Detail (INV) segment.

substanceType

HL7-defined code system of concepts identifying the type of substance. Used in HL7 Version 2.x messaging in the Inventory Detail (INV) segment.

substitutionStatus

HL7-defined code system of concepts which specify the substitution status. Used in HL7 Version 2.x messaging in the RXE, RXD, and RXG segments.

subtypeOfReferencedData

Code system of a subset of the media subtypes of binary data that are encoded in an ascii structure or stream. Used in Version 2 messaging ED and RP datatypes, but only in standard 2.5.1 and earlier; after that, it was recommended that the IANA media types be used instead of this short list of HL7-defined codes. More information on the standard media types and subtypes may be found at http://www.iana.org/assignments/media-types/media-types.xhtml.

supplierType

Code system that Identifies the type of supplier that will distribute the supply items associated to a contract number. Used in HL7 Version 2.x messaging in the CTR segment.

supplyRisk

Code system of concepts specifying any known or suspected hazard associated with this material item. Used in HL7 Version 2.x messaging in the ITM segment.

systemInducedContaminants

Code system of concepts that identify the specimen contaminant identifier associated with the specimen in the container. Used in the Interaction Specimen Container Detail (SAC) segment in HL7 Version 2.x messaging.

taxStatus

Code system of concepts used to specify the tax status of the provider. Used in the Invoice (IVC) segment in HL7 Version 2.x messaging.

telecommunicationEquipmentType

HL7-defined code system of concepts for specifying a type of telecommunication equipment. Best practice is to use this concept whenever a telecommunication number or access string for particular equipment is specified. Used in HL7 Version 2.x messaging in the XTN segment.

telecommunicationExpirationReason

Code system of concepts specifying the reason this contact number/email was marked as “ended”. Used in HL7 Version 2.x messaging in the XTN segment.

telecommunicationUse

HL7-defined code system of concepts for specifying a specific use of a telecommunication number. Best practice is to use this concept whenever a telecommunication number or access string is specified. Used in HL7 Version 2.x messaging in the XTN segment.

timeDelayPostChallenge

HL7-defined code system of concepts used to classify an observation definition as being a component of a challenge test. Used in HL7 Version 2.x messaging in the OM1 segment.

timeSelectionCriteriaParameterClass

Code system of concepts used to describe acceptable start and end times, as well as days of the week, for appointment or resource scheduling. Used in HL7 Version 2.x messaging in the SCV and APR segments.

tissueType

HL7-defined code system of concepts which specify a type of tissue removed from a patient during a procedure. Used in HL7 Version 2 messaging in the PR1 segment.

tqConjunctionId

HL7-defined code system of concepts specifying that a second timing specification is to follow using the repeat delimiter. Used in HL7 Version 2.x messaging in the TQ1 segment.

transactionType

Code system of concepts specifying a type of financial transaction. Used in HL7 Version 2.x messaging in the FT1 segment.

transfusionAdverseReaction

Code system of concepts used to specify the type of adverse reaction that the recipient of the blood product experienced. Used in the Blood Product Transfusion/Disposition (BTX) segment in HL7 Version 2.x messaging.

transportArranged

HL7-defined code system of concepts defining whether patient transportation preparations are in place. Used in HL7 Version 2.x messaging in the OBR segment.

transportationMode

HL7-defined code system of concepts which specify how (or whether) to transport a patient, when applicable, for an ordered service. Used in HL7 Version 2.x messaging in the OBR segment.

trayType

HL7-defined code system of concepts which specify whether the type of diet. Used in HL7 Version 2.x messaging in the ODT segment.

treatment

Code system of concepts that identify the specimen treatment performed during lab processing. Used in the Interaction Specimen Container Detail (SAC) segment in HL7 Version 2.x messaging.

triageType

HL7-defined code system of concepts which specify a patient’s prioritization within the context of a transmitted abstract. Used in HL7 Version 2 messaging in the ABS segment.

typeOfAgreement

Code system of concepts which specify codes to further identify an insurance plan. Used in HL7 Version 2.x messaging in the IN1 segment.

typeOfReferencedData

HL7-defined code system of concepts declaring the general type of media data that is encoded. Used in v2.5.1 interfaces and earlier, and replaced with the full set of IANA media types as a standard coding system for this after HL7 version 2.6 (see value set 2.16.840.1.113883.21.425 hl7VS-mimeTypes for HL7 table 0834 built on MIME types). More information may be found at http://www.iana.org/assignments/media-types/media-types.xhtml

universalIdType

HL7-defined code system of types of UID (Universal Identifiers). Used in HL7 Version 2.x messaging HD and EI datatypes.

userAuthenticationCredentialType

HL7-defined code system of concepts specifying a type of user authentication credential. Used in HL7 Version 2.x messaging in the UAC segment.

v2CS-relationshipType

HL7-defined code system of concepts that identify the type of relationship identified by Relationship Instance Identifier (REL-3) that is established between the Source Information Instance (REL-4) and the Target Information Instance (REL-5).

versionId

HL7-defined code system of concepts which are used to identify an HL7 version in the Version 2.x family of published standards. Used in HL7 Version 2.x messaging in the VID segment.

visitIndicator

Code system of concepts specifying the level on which data are being sent. It is the indicator used to send data at two levels, visit and account. HL7 recommends sending an “A” or no value when the data in the message are at the account level or “V” to indicate that the data sent in the message are at the visit level. Used in HL7 Version 2.x messaging in the Patient Visit (PV1) segment.

visitPriority

Code system of concepts used to define a relative level of urgency applied to a patient visit. Used in HL7 Version 2.x messaging in the PV2 segment.

visitUserCodes

Code system of concepts which specify categories of a patient’s visit with respect to an individual institution’s needs, and is expected to be different on a site-specific basis. Used in HL7 Version 2.x messaging in the PV2 segment.

whatSubjectFilter

HL7-defined code system of concepts which specify the kind of information that is required to satisfy a query request. The values define the type of transaction inquiry. Used in HL7 Version 2 messaging in the URD segment.

whichDate-timeQualifier

HL7-defined code system of concepts that specify a type of date referred to in query specifications. Used in HL7 Version 2 messaging in the QRF segment.

whichDate-timeStatusQualifier

HL7-defined code system of concepts that specify the status type of objects selected in a date range. Used in HL7 Vesion 2 messaging in the QRF segment.

Terminology: Naming Systems

These define identifier and/or code system identities used by systems conforming to this implementation guide.

NamingSystem/ACR

American College of Radiology finding codes

NamingSystem/ADAAreaOralCavitySystem

The Area of Oral Cavity System is accepted and approved by the ADA and is the most commonly used system used by dental professionals in America. Area of the oral cavity is designated by a two-digit code. The Area of Oral Cavity System can be found in the ADA Comprehensive ADA Dental Claim Form Completion Instructions (see https://www.ada.org/-/media/project/ada-organization/ada/ada-org/files/publications/cdt/v2019adadentalclaimcompletioninstructions_v3_2022feb.pdf). For more information see here: https://www.ada.org/publications/cdt/ada-dental-claim-form. A Statement of Understanding (SOU) between ADA and HL7 exists here: http://www.hl7.org/documentcenter/public/mou/ADA%20HL7%20SOU%202021_signed.pdf

NamingSystem/ADAUniversalToothDesignationSystem

The American Dental Association (ADA) accepted the Universal/National Tooth Designation System and the ISO/ANSI/ADA Specification No. 3950 for Designation System for Teeth and Areas of the Oral Cavity as the human tooth and oral cavity enumeration schemas in 1994. The universal tooth designation or numbering system is accepted and approved by the ADA and is the most commonly used system used by dental professionals in America. Teeth are numbered 1-32, starting with the third molar (1) on the right side of the upper arch, following around the arch to the third molar (16) on the left side, and descending to the lower third molar (17) on the left side, and following that arch to the terminus of the lower jaw, the lower right third molar (32). Supernumerary teeth are identified by the numbers 51 through 82, beginning with the area of the upper right third molar, following around the upper arch and continuing on the lower arch to the area of the lower right third molar (e.g., supernumerary #51 is adjacent to the upper right molar #1; supernumerary #82 is adjacent to the lower right third molar #32). The Universal Numbering System can be found in the ADA Dental Claim Form. For more information see here: https://www.ada.org/publications/cdt/ada-dental-claim-form. A Statement of Understanding (SOU) between ADA and HL7 exists here: http://www.hl7.org/documentcenter/public/mou/ADA%20HL7%20SOU%202021_signed.pdf

NamingSystem/AHANUBCPatientDischargeStatus

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 17 - Patient Discharge Status These codes are used to convey the patient discharge status and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

NamingSystem/AHANUBCPointOfOriginNewborn

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 15 - Point of Origin for Admission or Visit for Newborn These codes are used to convey the patient point of origin for an admission or visit and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

NamingSystem/AHANUBCPointOfOriginNonnewborn

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 15 - Point of Origin for Admission or Visit for Non-newborn These codes are used to convey the patient point of origin for an admission or visit and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

NamingSystem/AHANUBCPriorityTypeOfAdmitOrVisit

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 14 - Priority (Type) of Admission or Visit These codes are used to convey the priority of an admission or visit and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

NamingSystem/AHANUBCRevenueCodes

“The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified.” This code system consists of the following: * FL 42 - Revenue Codes These codes are used to convey the revenue code and are the property of the American Hospital Association. To obtain the underlying code systems, please see information here Statement of Understanding between AHA and HL7 can be found here. In particular see sections 4.1d and 4.2. “The UB-04 Manual has a 12-month subscription period from June 30 through July 1.” For frequently asked questions, see here here

NamingSystem/AHANUBCTypeOfBill

The UB-04 Data File contains the complete set of NUBC codes. Every code in the range of possible codes is accounted for sequentially. There are no gaps because all used and unused codes are identified. This code system consists of the following: * FL 04 - Type of Bill Facility Codes * FL 04 - Type of Bill Frequency Codes A code indicating the specific Type of Bill (TOB), e.g., hospital inpatient, outpatient, replacements, voids, etc. The first digit is a leading zero*. The fourth digit defines the frequency of the bill for the institutional and electronic professional claim. Note that with the advent of UB-04, the matrix methodology of constructing the first component of TOB codes according to digit position was abandoned in favor of specifying valid discrete codes. As a result, the first three digits in TOB have no underlying meaning. To obtain the underlying code systems, please see information here The UB-04 Manual has a 12-month subscription period from June 30 through July 1.

NamingSystem/APRDRG

3M APR DRGs have become the standard across the U.S. for classifying hospital inpatients in non-Medicare populations. As of January 2019, 27 state Medicaid programs use 3M APR DRGs to pay hospitals, as do approximately a dozen commercial payers and Medicaid managed care organizations. Over 2,400 hospitals have licensed 3M APR DRGs to verify payment and analyze their internal operations. The 3M APR DRG methodology classifies hospital inpatients according to their reason for admission, severity of illness and risk of mortality. Each year 3M calculates and releases a set of statistics for each 3M APR DRG based on our analysis of large national data sets. These statistics include a relative weight for each 3M APR DRG. The relative weight reflects the average hospital resource use for a patient in that 3M APR DRG relative to the average hospital resource use of all inpatients. Please note that payers and other users of the 3M APR DRG methodology are responsible for ensuring that they use relative weights that are appropriate for their particular populations. The 3M APR DRG statistics also include data for each 3M APR DRG on relative frequency, average length of stay, average charges and incidence of mortality. 3M APR DRGs can be rolled up into broader categories. The 326 base DRGs roll up into 25 major diagnostic categories (MDCs) plus a pre-MDC category. An example is MDC 04, Diseases and Disorders of the Respiratory System. As well, each 3M APR DRG is assigned to a service line that is consistent with the outpatient service lines that are defined by the 3M™ Enhanced Ambulatory Patient Groups (EAPGs).

NamingSystem/AS4

ASTM E1238/ E1467 Universal

NamingSystem/AS4E

AS4 Neurophysiology Codes

NamingSystem/AlabamaDLN

Alabama Motor Vehicle Bureau

NamingSystem/AlaskaDLN

Alaska Motor Vehicle Bureau

NamingSystem/ArizonaDLN

Arizona Motor Vehicle Bureau

NamingSystem/ArkansasDLN

Arkansas Motor Vehicle Bureau

NamingSystem/C5

CPT-5

NamingSystem/CAPeCC

“The College of American Pathologists (CAP) eCC (electronic Cancer Checklists) enables pathologists to use the CAP Cancer Protocols directly within their laboratory information system (LIS) workflow and to ensure that each report is completed with the necessary required elements. Most anatomic pathology (AP)-LIS vendors offer a CAP eCC synoptic module for reporting on surgical cancer resections and selected biopsies.” “The CAP eCC is based on the CAP Cancer Protocols and is produced under the guidance of the CAP Pathology Electronic Reporting (PERT) Committee along with close interaction and advisement of the Cancer Committee. The eCC is developed in collaboration with and partially underwritten by the Centers for Disease Control and Prevention (CDC). Additional collaborators include the American Joint Committee on Cancer (AJCC), Cancer Care Ontario (CCO), and the North American Association of Central Cancer Registries (NAACCR). The CAP currently is working with the California Cancer Registry (CCR) to offer the benefits of the eCC to California laboratories. CCR and the CAP are seeking out laboratories interested in participating in an ongoing project using the eCC to directly transfer cancer data to the central registry.” “The CAP releases eCC templates on a rolling basis, coordinating as much as possible with the posting of new and revised Cancer Protocols and Cancer Biomarker Reporting Templates. A few weeks prior to each Major or Agile release, email notifications are sent out to all licensed CAP eCC users.” For more information, see page here

NamingSystem/CAS

Chemical abstract codes

NamingSystem/CCC

Clinical Care Classification System (formerly Home Health Care Classification system) codes. The Clinical Care Classification (CCC) consists of two taxonomies: CCC of Nursing Diagnoses and CCC of Nursing Interventions both of which are classified by 21 Care Components. Each of these are classified by Care Components which provide a standardized framework for documenting patient care in hospitals, home health agencies, ambulatory care clinics, and other health care settings.

NamingSystem/CCDD

The Canadian Clinical Drug Data Set provides codes for identification and a consistent approach to naming of medications and some medical devices in Canada. It has been designed and developed to reflect current clinical practice and safety advice and is freely available for use in digital health solutions and design applications. CCDD is available in English and Canadian French, and published on Terminology Gateway by Canada Health Infoway. To request content changes, send an email to clinicaldrug@infoway-inforoute.ca

NamingSystem/CCN

Per CMS Transmittal 29 dated OCTOBER 12, 2007: “The National Provider Identifier (NPI) will replace the Medicare/Medicaid Provider Number on Medicare claims. The NPI will assume the Medicare/Medicaid Provider Number’s role as a primary identifier. However, the Medicare/Medicaid Provider Number will continue to be issued to providers and used to verify Medicare/Medicaid certification on all survey and certification, and resident/patient assessment transactions. In order to avoid confusion with the NPI, the Medicare/Medicaid Provider Number (also known as the OSCAR Provider Number, Medicare Identification Number or Provider Number) has been renamed the CMS Certification Number (CCN). The CCN continues to serve a critical role in verifying that a provider has been Medicare certified and for what type of services.” See https://www.cms.gov/regulations-and-guidance/guidance/transmittals/downloads/r29soma.pdf

NamingSystem/CD2

American Dental Association’s Current Dental Terminology 2 (CDT-2) codes.

NamingSystem/CDARUS

Coding system intended for use in the Russian clinical documents

NamingSystem/CDCA

CDC Analyte Codes

NamingSystem/CDCLocal

“CDC Public Health Information Network local coding system used for creating the concepts that are not available in the Standard Development Organization (SDO) Vocabulary like SNOMED CT, LOINC, ICD-9, etc.” Versioning numbered according to PHIN VADS convention. For more information, see https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.114222.4.5.274.

NamingSystem/CDCM

CDC Methods/Instruments Codes

NamingSystem/CDCNHSN

A set of healthcare surveillance vocabulary concepts and associated identifiers intended solely for data submissions to the National Healthcare Safety Network (NHSN). Other uses are not recommended. The CDCNHSN code system is highly specialized to meet the needs of NHSN surveillance reporting, is undergoing changes, and is not recommended for creating value sets to be used outside of NHSN.

NamingSystem/CDCREC

The U.S. Centers for Disease Control and Prevention (CDC) has prepared a code set for use in coding race and ethnicity data. This code set is based on current federal standards for classifying data on race and ethnicity, specifically the minimum race and ethnicity categories defined by the U.S. Office of Management and Budget (OMB) and a more detailed set of race and ethnicity categories maintained by the U.S. Bureau of the Census (BC). The main purpose of the code set is to facilitate use of federal standards for classifying data on race and ethnicity when these data are exchanged, stored, retrieved, or analyzed in electronic form. At the same time, the code set can be applied to paper-based record systems to the extent that these systems are used to collect, maintain, and report data on race and ethnicity in accordance with current federal standards. The content is available at https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238#.

NamingSystem/CDPS

“The Chronic Illness and Disability Payment System (CDPS) is a diagnostic-based risk adjustment model that is widely used to adjust capitated payments for health plans that enroll Medicaid beneficiaries. CDPS uses International Classification of Disease (ICD) codes to assign CDPS Categories that indicate illness burden related to major body systems (e.g. cardiovascular) or types of chronic disease (e.g. diabetes). Within each major category is a hierarchy reflecting both the clinical severity of the condition and its expected effect on future costs. Each of the hierarchical CDPS Categories is assigned a CDPS weight. CDPS weights are additive across major categories.” “The CDPS model was developed in 2000 using data from seven Fee-for-Service (FFS) Medicaid programs. The model received major updates in 2009 (using national FFS Medicaid data from 2002-2005) and in 2014 (using additional national FFS Medicaid data from 2011). CDPS has also received regular annual updates to include the most recent ICD and NDC codes.” For more information, please visit https://hwsph.ucsd.edu/research/programs-groups/cdps.html.

NamingSystem/CDS

CDC Surveillance

NamingSystem/CDT

The purpose of the CDT Code is to achieve uniformity, consistency and specificity in accurately documenting dental treatment. One use of the CDT Code is to provide for the efficient processing of dental claims, and another is to populate an Electronic Health Record.

NamingSystem/CE

CEN ECG diagnostic codes

NamingSystem/CLIA

“The Centers for Medicare & Medicaid Services (CMS) regulates all laboratory testing (except research) performed on humans in the U.S. through the Clinical Laboratory Improvement Amendments (CLIA). In total, CLIA covers approximately 330,000 laboratory entities. The Division of Clinical Laboratory Improvement & Quality, within the Quality, Safety & Oversight Group, under the Center for Clinical Standards and Quality (CCSQ) has the responsibility for implementing the CLIA Program. The objective of the CLIA program is to ensure quality laboratory testing. Although all clinical laboratories must be properly certified to receive Medicare or Medicaid payments, CLIA has no direct Medicare or Medicaid program responsibilities.” CMS CLIA certified laboratories will be assigned a10-digit alphanumeric CLIA identification number, with the “D” in the third position identifying the provider/supplier as a laboratory certified under CLIA.” CLIA is maintained by CMS. It is in the public domain and free to use without restriction. See http://cms.gov/regulations-and-guidance/legislation/clia.

NamingSystem/CLP

CLIP

NamingSystem/CMSPlaceofServiceCodes

Place of Service Codes are two-digit codes placed on health care professional claims to indicate the setting in which a service was provided. The Centers for Medicare & Medicaid Services (CMS) maintain POS codes used throughout the health care industry. This code set is required for use in the implementation guide adopted as the national standard for electronic transmission of professional health care claims under the provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA). HIPAA directed the Secretary of HHS to adopt national standards for electronic transactions. These standard transactions require all health plans and providers to use standard code sets to populate data elements in each transaction. The Transaction and Code Set Rule adopted the ASC X12N-837 Health Care Claim: Professional, volumes 1 and 2, as the standard for electronic submission of professional claims. This standard names the POS code set currently maintained by CMS as the code set to be used for describing sites of service in such claims. POS information is often needed to determine the acceptability of direct billing of Medicare, Medicaid and private insurance services provided by a given provider.

NamingSystem/CMSRxHCC

Starting in 2006, with the implementation of the Part D program, CMS introduced a second major HCC-based risk adjustment model. Created with the passage of the Medicare Modernization Act (MMA) of 2003, the Medicare Part D Prescription Drug benefit became the second major Medicare capitated payment system. CMS developed the Part D RxHCC risk adjustment model to apply to monthly capitated payments to both Medicare Advantage (MA-PDs) and standalone prescription drug plans (PDPs). The Part D RxHCC risk adjustment model implemented in 2006 was developed using a structure similar to the CMS-HCC model, in that it included demographic and diagnosis information clustered into hierarchical condition categories. CMS obtains diagnoses for all Medicare beneficiaries from either fee-for-service claims or Medicare Advantage reporting. In 2011, CMS implemented an updated Part D RxHCC risk adjustment model, incorporating program data derived from prescription drug event (PDE) data. The data used to calibrate this updated model was more recent cost and utilization data, resulting in a model that reflects more recent drug cost and utilization patterns. For more information, see: https://www.cms.gov/Medicare/Health-Plans/MedicareAdvtgSpecRateStats/Risk-Adjustors The CMS RxHCCs are in the public domain and are free to use without restriction.

NamingSystem/CPT

The Current Procedural Terminology (CPT) code set, created and maintained by the American Medical Association, is the language of medicine today and the code to its future. This system of terminology is the most widely accepted medical nomenclature used to report medical procedures and services under public and private health insurance programs. CPT coding is also used for administrative management purposes such as claims processing and developing guidelines for medical care review. Each year, via a rigorous, evidence-based and transparent process, the independent CPT Editorial Panel revises, creates or deletes hundreds of codes in order to reflect current medical practice. Designated by the U.S. Department of Health and Human Services under the Health Insurance Portability and Accountability Act (HIPAA) as a national coding set for physician and other health care professional services and procedures, CPT’s evidence-based codes accurately encompass the full range of health care services. All CPT codes are five-digits and can be either numeric or alphanumeric, depending on the category. CPT code descriptors are clinically focused and utilize common standards so that a diverse set of users can have common understanding across the clinical health care paradigm. There are various types of CPT codes: Category I: These codes have descriptors that correspond to a procedure or service. Codes range from 00100–99499 and are generally ordered into sub-categories based on procedure/service type and anatomy. Category II: These alphanumeric tracking codes are supplemental codes used for performance measurement. Using them is optional and not required for correct coding. Category III: These are temporary alphanumeric codes for new and developing technology, procedures and services. They were created for data collection, assessment and in some instances, payment of new services and procedures that currently don’t meet the criteria for a Category I code. Proprietary Laboratory Analyses (PLA) codes: These codes describe proprietary clinical laboratory analyses and can be either provided by a single (“solesource”) laboratory or licensed or marketed to multiple providing laboratories that are cleared or approved by the Food and Drug Administration (FDA)). This category includes but is not limited to Advanced Diagnostic Laboratory Tests (ADLTs) and Clinical Diagnostic Laboratory Tests (CDLTs), as defined under the Protecting Access to Medicare Act of 2014 (PAMA).

NamingSystem/CST

COSTART

NamingSystem/CVX

The CDC’s National Center of Immunization and Respiratory Diseases (NCIRD - see https://www.cdc.gov/ncird/) developed and maintains the CVX (vaccine administered) code set. It includes both active and inactive vaccines available in the US. CVX codes for inactive vaccines allow transmission of historical immunization records. When a MVX (manufacturer) code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated. These codes should be used for immunization messages using either HL7 Version 2.3.1 or HL7 Version 2.5.1. CVX is the underlying Master Code System for V2 table 0292 (Vaccines Administered). The machine readable name for CVX in PHIN VADS is PH_VaccinesAdministeredCVX_CDC_NIP. The version of the CVX code set for certification can be found on the archive page:https://www2a.cdc.gov/vaccines/iis/iisstandards/mu3versioned_codes.asp The Status column indicates if the vaccine is currently available in the United States.

  • Active: A currently available administrable vaccine
  • Inactive: An administrable vaccine formulation that is no longer available for patient administration, but can be found in historical patient records OR A historical record of a vaccine administered where the exact formulation is unknown
  • Pending: A vaccine that is expected to become active in the future
  • Non-US: A vaccine that available outside the US only
  • Never Active: A vaccine that was never available and is not in the pipeline of new vaccines The Last Updated column indicates the last time this particular vaccine code was updated in this table. Questions regarding this table should be directed to the IIS Technical Assistance Team via iisinfo@cdc.gov (or use mailing address via https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx#addr) HL7 Implementers should note that ‘Status’ IS NOT CONCEPT STATUS as all codes are ACTIVE in this code system. The current code system is available via https://www2a.cdc.gov/vaccines/iis/iisstandards/vaccines.asp?rpt=cvx
NamingSystem/CaliforniaDLN

California Motor Vehicle Bureau

NamingSystem/ClinVarV

ClinVar is a freely accessible, public archive of reports of the relationships among human variations and phenotypes, with supporting evidence. ClinVar thus facilitates access to and communication about the relationships asserted between human variation and observed health status, and the history of that interpretation. ClinVar processes submissions reporting variants found in patient samples, assertions made regarding their clinical significance, information about the submitter, and other supporting data. The alleles described in submissions are mapped to reference sequences, and reported according to the HGVS standard. ClinVar then presents the data for interactive users as well as those wishing to use ClinVar in daily workflows and other local applications. ClinVar works in collaboration with interested organizations to meet the needs of the medical genetics community as efficiently and effectively as possible. Read more about using ClinVar. ClinVar supports submissions of differing levels of complexity. The submission may be as simple as a representation of an allele and its interpretation (sometimes termed a variant-level submission), or as detailed as providing multiple types of structured observational (case-level) or experimental evidence about the effect of the variation on phenotype. A major goal is to support computational (re)evaluation, both of genotypes and assertions, and to enable the ongoing evolution and development of knowledge regarding variations and associated phenotypes. ClinVar is an active partner of the ClinGen project, providing data for evaluation and archiving the results of interpretation by recognized expert panels and providers of practice guidelines (see https://www.ncbi.nlm.nih.gov/clinvar/docs/review_guidelines/). ClinVar archives and versions submissions which means that when submitters update their records, the previous version is retained for review. Read more about submitting data to ClinVar at https://www.ncbi.nlm.nih.gov/clinvar/docs/submit. The level of confidence in the accuracy of variation calls and assertions of clinical significance depends in large part on the supporting evidence, so this information, when available, is collected and visible to users. Because the availability of supporting evidence may vary, particularly in regard to retrospective data aggregated from published literature, the archive accepts submissions from multiple groups, and aggregates related information, to reflect transparently both consensus and conflicting assertions of clinical significance. A review status is also assigned to any assertion, to support communication about the trustworthiness of any assertion. Domain experts are encouraged to apply for recognition as an expert panel (more info at https://www.ncbi.nlm.nih.gov/clinvar/docs/review_guidelines/). Accessions, with the format SCV000000000.0, are assigned to each submitted record. If there are multiple submitted records about the same variation/condition pair, they are aggregated within ClinVar’s data flow and reported as a reference accession with the format RCV000000000.0. Because of this model, one variant will be included in multiple RCV accessions whenever different conditions are reported for that variant. Submitted records for the same variation are also aggregated and reported as an accession with the format VCV000000000.0. This aggregation lets a user review all submitted data for a variant, regardless of the condition for which it was interpreted. ClinVar archives submitted information, and adds identifiers and other data that may be available about a variant or condition from other public resources. However ClinVar neither curates content nor modifies interpretations independent of an explicit submission. If you have data that differs from what is currently represented in ClinVar, we encourage you to submit your data and the evidence supporting your interpretation. There is a submission wizard to guide you through that process. See https://www.ncbi.nlm.nih.gov/variation/clinvar_single_wizard/. If you are submitting variants that were interpreted as part of work funded by the NIH, please consult your program officer about expectations for submissions to ClinVar.

NamingSystem/ColoradoDLN

Colorado Motor Vehicle Bureau

NamingSystem/ConnecticutDLN

Connecticut Motor Vehicle Bureau

NamingSystem/DCDLN

DC Motor Vehicle Bureau

NamingSystem/DCL

DICOM Class Label

NamingSystem/DEEDS

root for the DEEDS code sets

NamingSystem/DEEDS210

Code for ED Practitioner Role

NamingSystem/DEEDS402

Mode of transport to ED

NamingSystem/DEEDS405

ED Source of Referral

NamingSystem/DEEDS407

Code for Initial Healthcare Encounter for Chief Complaint

NamingSystem/DEEDS408

Code for Acuity Assessment

NamingSystem/DEEDS412

ED Responsiveness Assessment

NamingSystem/DEEDS414

Glasgow eye opening assessment

NamingSystem/DEEDS415

Glasgow verbal component assessment

NamingSystem/DEEDS416

Glasgow motor component assessment

NamingSystem/DEEDS418

Systolic blood pressure special situation

NamingSystem/DEEDS422

Heart rate method

NamingSystem/DEEDS424

Respiratory rate special circumstances codes

NamingSystem/DEEDS427

Patient temperature route

NamingSystem/DEEDS506

Injury Activity

NamingSystem/DEEDS508

Safety Equipment Use

NamingSystem/DEEDS519

Clinical Finding Data Source

NamingSystem/DelawareDLN

Delaware Motor Vehicle Bureau

NamingSystem/E5

Euclides quantity codes

NamingSystem/E6

Euclides Lab method codes

NamingSystem/E7

Euclides Lab equipment codes

NamingSystem/ENZC

Enzyme Codes

NamingSystem/EPSG-GeodeticParameterDataset

Description: The EPSG (European Petroleum Survey Group) dataset represents all Datums, coordinate references (projected and 2D geographic) and coordinate systems (including Cartesian coordinate systems) used in surveying worldwide. Each record includes a 4-8 digit unique identifier. The current version is available from http://www.epsg.org/. The database contains over 4000 records covering spatial data applications worldwide. Deprecation Comment: This has been superceded by the two code systems EPSG-CRS and EPSG-CA

NamingSystem/FDBHICCode

The FDB Hierarchical Ingredient Code is a six character identifier that represents an active ingredient and its specific therapeutic classification.

NamingSystem/FDDC

First DataBank Drug Codes

NamingSystem/FDDX

First DataBank Diagnostic Codes

NamingSystem/FloridaDLN

Florida Motor Vehicle Bureau

NamingSystem/GCDF

GCDF Dosage Form Code (2-character) a two-character alphanumeric column that represents a dosage form. The dosage form of a generic drug formulation describes the physical presentation of a drug, such as tablet, capsule, or liquid. It may also incorporate the delivery and release mechanism of the drug. A GCDF is associated to each GCN_SEQNO to identify that component of the generic drug formulation.

NamingSystem/GCRT

GCRT Route of Administration Code (1-character) a one-character alphanumeric column that provides the normal site or method by which a drug is administered, such as oral, injection, or topical. A GCRT is associated to each GCN_SEQNO to identify that component of the generic drug formulation.

NamingSystem/GLN

Global Location Number (GLN) can be used by companies to identify their locations, giving them complete flexibility to identify any type or level of location required. For more information as to how GLNs are used in healthcare, see a GS1 provided guide located here https://www.gs1.org/docs/healthcare/GLN_Healthcare_Imp_Guide.pdf For additional information regarding the GLN standard refer to the GS1 General Specifications (https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications) and for assignment refer to the GS1 GLN Allocation Rules (https://www.gs1.org/1/glnrules/en/). GS1 local offices handle all enquiries related to GS1 standards. Please see the list of GS1 offices (https://www.gs1.org/contact/overview) for more information. In relation to the “Healthcare GLN Implementation Guideline”: “GS1®, under its IP Policy, seeks to avoid uncertainty regarding intellectual property claims by requiring the participants in the Work Group that developed this Healthcare GLN Implementation Guideline to agree to grant to GS1 members a royalty-free licence or a RAND licence to Necessary Claims, as that term is defined in the GS1 IP Policy. Furthermore, attention is drawn to the possibility that an implementation of one or more features of this Specification may be the subject of a patent or other intellectual property right that does not involve a Necessary Claim. Any such patent or other intellectual property right is not subject to the licensing obligations of GS1. Moreover, the agreement to grant licences provided under the GS1 IP Policy does not include IP rights and any claims of third parties who were not participants in the Work Group. Accordingly, GS1 recommends that any organisation developing an implementation designed to be in conformance with this Specification should determine whether there are any patents that may encompass a specific implementation that the organisation is developing in compliance with the Specification and whether a licence under a patent or other intellectual property right is needed. Such a determination of a need for licencing should be made in view of the details of the specific system designed by the organisation in consultation with their own patent counsel.” “GS1 disclaims all liability for any damages arising from use or misuse of this document, whether special, indirect, consequential, or compensatory damages, and including liability for infringement of any intellectual property rights, relating to use of information in or reliance upon this document.” GS1 and the GS1 logo are registered trademarks of GS1 AISBL.

NamingSystem/GMDN

http://www.gmdnagency.com/

NamingSystem/GTR

The Genetic Testing Registry (GTR) provides a central location for voluntary submission of genetic test information by providers. The scope includes the test’s purpose, methodology, validity, evidence of the test’s usefulness, and laboratory contacts and credentials. The overarching goal of the GTR is to advance the public health and research into the genetic basis of health and disease. Each Test is a specific, orderable test from a particular laboratory, and is assigned a unique GTR accession number. The format is GTR00000001.1, with a leading prefix “GTR” followed by 8 digits, a period, then 1 or more digits representing the version. When a laboratory updates a registered test, a new version number is assigned. To find all laboratories in GTR and all registered tests, see here https://www.ncbi.nlm.nih.gov/gtr/all/tests/?term=all%5Bsb%5D

NamingSystem/GeorgiaDLN

Georgia Motor Vehicle Bureau

NamingSystem/HCPCS-all-codes

The Level II HCPCS codes, which are established by CMS’s Alpha-Numeric Editorial Panel, primarily represent items and supplies and non-physician services not covered by the American Medical Association’s Current Procedural Terminology-4 (CPT-4) codes; Medicare, Medicaid, and private health insurers use HCPCS procedure and modifier codes for claims processing. Level II alphanumeric procedure and modifier codes comprise the A to V range.

NamingSystem/HGNCGeneGroup

The HGNC is responsible for approving unique symbols and names for human loci, including protein coding genes, ncRNA genes and pseudogenes, to allow unambiguous scientific communication. For each known human gene we approve a gene name and symbol (short-form abbreviation). All approved symbols are stored in the HGNC database,www.genenames.org, a curated online repository of HGNC-approved gene nomenclature, gene groups and associated resources including links to genomic, proteomic and phenotypic information. Each symbol is unique and we ensure that each gene is only given one approved gene symbol. It is necessary to provide a unique symbol for each gene so that we and others can talk about them, and this also facilitates electronic data retrieval from publications and databases. Please see https://www.genenames.org/ for more info.

NamingSystem/HIPPS

“Health Insurance Prospective Payment System (HIPPS) rate codes represent specific sets of patient characteristics (or case-mix groups) health insurers use to make payment determinations under several prospective payment systems. Case-mix groups are developed based on research into utilization patterns among various provider types. For the payment systems that use HIPPS codes, clinical assessment data is the basic input. A standard patient assessment instrument is interpreted by case-mix grouping software algorithms, which assign the case mix group. For payment purposes, at least one HIPPS code is defined to represent each case-mix group. These HIPPS codes are reported on claims to insurers. Institutional providers use HIPPS codes on claims in association with special revenue codes. One revenue code is defined for each prospective payment system that requires HIPPS codes. HIPPS codes are placed in data element SV202 on the electronic 837 institutional claims transaction, using an HP qualifier, or in Form Locator (FL) 44 (“HCPCS/rate”) on a paper UB-04 claims form. The associated revenue code is placed in data element SV201 or in FL 42. In certain circumstances, multiple HIPPS codes may appear on separate lines of a single claim.” “HIPPS codes are alpha-numeric codes of five digits. Each code contains intelligence, with certain positions of the code indicating the case mix group itself, and other positions providing additional information. The additional information varies among HIPPS codes pertaining to different payment systems, but often provides information about the clinical assessment used to arrive at the code. Which positions of the code carry the case mix group information may also vary by payment systems.” “Under the Health Insurance Portability and Accountability Act (HIPAA) rules for transactions and code sets, HIPPS codes are defined as a non-medical code set. Therefore, these codes are effective by transaction date. Effective From Dates: HIPPS codes are valid under HIPAA on transactions on or after this date. Since all HIPPS codes to date have been initially created for Original Medicare payment systems, this is also date of service the codes begin to be payable by Medicare. While it is valid under HIPAA rules that a claim for dates of service before this date could be submitted on a transaction after this date, CMS is not aware of a business need for a provider to do so. The code would not be payable by any insurer and no Grouper software would be available to produce a code for those dates. Effective Through Dates: HIPPS codes are no longer valid under HIPAA on transactions on or after this date. This date may vary from the date a code ceases to be payable by Medicare, since other payers may continue to use older HIPPS codes after Medicare transitions to a new payment system. Since CMS, as the HIPPS code set maintainer, may not have complete information about other payers’ uses of these codes, codes may remain effective under HIPAA long after they cease to be payable on Medicare claims. To reflect this, a separate column on the HIPPS Code Master List indicates the Medicare Payment Though Date.”

NamingSystem/HPO

“The Human Phenotype Ontology (HPO) provides a standardized vocabulary of phenotypic abnormalities encountered in human disease. Each term in the HPO describes a phenotypic abnormality, such as Atrial septal defect. The HPO is currently being developed using the medical literature, Orphanet, DECIPHER, and OMIM. HPO currently contains over 13,000 terms and over 156,000 annotations to hereditary diseases. The HPO project and others have developed software for phenotype-driven differential diagnostics, genomic diagnostics, and translational research. The HPO is a flagship product of the Monarch Initiative, an NIH-supported international consortium dedicated to semantic integration of biomedical and model organism data with the ultimate goal of improving biomedical research. The HPO, as a part of the Monarch Initiative, is a central component of one of the 13 driver projects in the Global Alliance for Genomics and Health (GA4GH) strategic roadmap.” Please see https://hpo.jax.org/app/download/ontology. Releases, produced approximately every 2 months, can be found here.

NamingSystem/HawaiiDLN

Hawaii Motor Vehicle Bureau

NamingSystem/IC2

ICHPPC-2

NamingSystem/ICD-10DualCoding

ICD-10 allows dual coding. Refer to Section 3.1.3 of the ICD-10 Instruction Manual (2nd Edition, http://www.who.int/entity/classifications/icd/ICD-10_2nd_ed_volume2.pdf). This OID identifies the code system that describes how to encode Dual Coding in a CD compatible expression (for Datatypes R2 CD only). An ICD-10 dual code expression SHALL consist of two ICD-10 codes separated by space. This code system SHALL NOT be used for single ICD-10 codes; the normal ICD-10 code system oid which is 2.16.840.1.113883.6.3 should be used in this case. Dual code expressions SHALL only be used per the rules described in the ICD-10 instruction manual. An example CD:<br></br> <example code=”J21.8 B95.6” codeSystem=”2.16.840.1.113883.6.260”><br></br> <originalText value=”Staph aureus bronchiolitis”/><br></br> </example><br></br><br></br> Where:<br></br> J21.8 is: Acute bronchiolitis due to other specified organisms<br></br> B95.6 is: Staphylococcus aureus as the cause of diseases classified to other chapters

NamingSystem/ICD-9CM-diagnosiscodes

The International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM), Volumes I, II (diagnoses) and III (procedures) describes the classification of morbidity and mortality information for statistical purposes and for the indexing of healthcare records by diseases and procedures. The ICD-9-CM codes can be used as the value of the Act.cd attribute.

NamingSystem/ICD-9CM-procedurecodes

The International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM), Volumes I, II (diagnoses) and III (procedures) describes the classification of morbidity and mortality information for statistical purposes and for the indexing of healthcare records by diseases and procedures. The ICD-9-CM codes can be used as the value of the Act.cd attribute.

NamingSystem/ICD-9DualCoding

ICD-9 Dual Coding Expression Syntax”, description: ICD-9 allows dual coding. Refer to Section ?? of the ICD-9 Instruction Manual (ref?). This OID identifies the code system that describes how to encode Dual Coding in a CD compatible expression (for Datatypes R2 CD only). An ICD-9 dual code expression SHALL consist of two ICD-9 codes separated by space. This code system SHALL NOT be used for single ICD-9 codes; the normal ICD-9 code system oid which is 2.16.840.1.113883.6.3 should be used in this case. DisplayName SHALL not be used. Dual code expressions SHALL only be used per the rules described in the ICD-9 instruction manual. An example CD:<br></br><example code=”989.5 E905.9” codeSystem=”2.16.840.1.113883.6.261”><br></br><originalText value=”ANAPHYLAXIS DUE TO BITE OR STING”/><br></br></example><br></br>Where 989.5 is: “Toxic effect of venom” and E905.9 is: “Bite or sting”

NamingSystem/ICD10dut

Hirs, W., H.W. Becker, C. van Boven, S.K. Oskam, I.M. Okkes, H. Lamberts. ICD-10, Dutch Translation, 200403. Amsterdam: Department of General Practice, Academic Medical Center/University of Amsterdam, Dutch College of General Practitioners (NHG), March 20

NamingSystem/ICD11MMS

The International Classification of Diseases, 11th Revision Mortality and Morbidity Statistics (MMS) is one of the ICD11 linearizations. Information about the ICD Foundation Component and the ICD11 Linearizations can be found in the complete reference guide here: https://icd.who.int/icd11refguide/en/index.htmlThe ICD11 Linearizations (Tabular lists) A linearization is a subset of the foundation component, that is:

  1. fit for a particular purpose: reporting mortality, morbidity, primary care or other uses;
  2. composed of entities that are Mutually Exclusive of each other;
  3. each entity is given a single parent. Linearization is similar to the classical print versions of ICD Tabular List (e.g. volume I of ICD-10 or other previous editions). The main linearization of ICD-11 is Mortality and Morbidity Statistics (MMS). Various linearizations could be built at different granularity, use case or other purposes such as for Primary Care, Clinical Care or Research. The linkage from the foundation component to a particular linearization will ensure consistent use of the ICD.” ICD-11 for Mortality and Morbidity (ICD-11 MMS) can be downloaded in either print or electronic (spreadsheet) format from the browser in the Info tab located here
NamingSystem/ICF

“The International Classification of Functioning, Disability and Health, known more commonly as ICF, is a classification of health and health-related domains. As the functioning and disability of an individual occurs in a context, ICF also includes a list of environmental factors. ICF is the WHO framework for measuring health and disability at both individual and population levels. ICF was officially endorsed by all 191 WHO Member States in the Fifty-fourth World Health Assembly on 22 May 2001(resolution WHA 54.21 ) as the international standard to describe and measure health and disability. ICF is based on the same foundation as ICD and ICHI and share the same set of extension codes that enable documentation at a higher level of detail.” Official updates to the ICF are available as annual lists of changes. These updates are approved annually at the October meeting of the WHO Family of International Classifications (WHO-FIC) Network. To license ICF, the same rules apply for ICF as for ICD. See http://icd.who.int/. For more information, see https://www.who.int/standards/classifications/international-classification-of-functioning-disability-and-health.

NamingSystem/ICFDut

“The International Classification of Functioning, Disability and Health, known more commonly as ICF, is a classification of health and health-related domains. As the functioning and disability of an individual occurs in a context, ICF also includes a list of environmental factors. ICF is the WHO framework for measuring health and disability at both individual and population levels. ICF was officially endorsed by all 191 WHO Member States in the Fifty-fourth World Health Assembly on 22 May 2001(resolution WHA 54.21 ) as the international standard to describe and measure health and disability. ICF is based on the same foundation as ICD and ICHI and share the same set of extension codes that enable documentation at a higher level of detail.” “The Dutch translation of the ICF is published in book form by BSL. The ICF can also be consulted online in the Classification Browser. The ICF team of the WHO-FIC Collaborating Center combines expertise in the field of the ICF for the Dutch language area and currently consists of delegations from the Netherlands Paramedical Institute, the University Medical Center Groningen, Maastricht University, the Big Move Institute, Stichting Scientific Research Road Safety, University of Ghent, Vilans, and Rehabilitation Center de Hoogstraat.” Official updates to the ICF are available as annual lists of changes. These updates are approved annually at the October meeting of the WHO Family of International Classifications (WHO-FIC) Network. To license ICF, the same rules apply for ICF as for ICD. See http://icd.who.int/. For more information, see https://www.whofic.nl/familie-van-internationale-classificaties/referentie-classificaties/icf.

NamingSystem/ICSD

International Classification of Sleep Disorders

NamingSystem/IECColourManagement

IEC 61966-2-1:1999 is the official specification of sRGB. It provides viewing environment, encoding, and colorimetric details. For more information, please see https://webstore.iec.ch/publication/6168

NamingSystem/IETF1766

Codes representing languages for which a person has some level of proficiency for written or spoken communication. Examples: Spanish, Italian, German, English, American Sign, etc.

NamingSystem/IMO

IMO is a clinical interface terminology, which helps to map diagnostic, procedure and other terminologies to medical concepts and codes.

NamingSystem/ISCN

The International System for Human Cytogenetic Nomenclature (ISCN) was created by the International Standing committee on Human Cytogenetic Nomenclature to represent the outcome of cytogenetic tests. ISCN specifies the nomenclature to describe karyotypes, chromosome abnormalities, in situ hybridization, etc. ISCN provides a list of symbols and abbreviated terms in adjunction with a set of rules, which can be used in the description of chromosomes and chromosome abnormalities, such as p for short arm of chromosome, q for long arm of chromosome, cen for centromere, del for deletion, ish for in situ hybridization, and plus sign (+) for gain, etc. A LOINC code is created to represent “chromosome analysis results in ISCN expression”. In HL7 v2 messages, this LOINC code is used in OBX-3 with a coded result (CWE data type) that will be sent in OBX-5. The value of the coded result is an ISCN expression, and ISCN will be the code system for the coded result.

NamingSystem/ISO3166Part1

ISO 3166-1 establishes codes that represent the current names of countries, dependencies, and other areas of particular geopolitical interest, on the basis of country names obtained from the United Nations.

NamingSystem/ISO3166Part2

ISO 3166-2 establishes a code that represents the names of the principal administrative divisions, or similar areas, of the countries and entities included in ISO 3166-1.

NamingSystem/ISO3166Part3

ISO 3166-3 establishes a code that represents non-current country names, i.e. the country names deleted from ISO 3166 since its first publication in 1974.

NamingSystem/IUPC

IUPAC/IFCC Component Codes

NamingSystem/IUPP

IUPAC/IFCC Property Codes

NamingSystem/IdahoDLN

Idaho Motor Vehicle Bureau

NamingSystem/IllinoisDLN

Illinois Motor Vehicle Bureau

NamingSystem/IndianaDLN

Indiana Motor Vehicle Bureau

NamingSystem/IowaDLN

Iowa Motor Vehicle Bureau

NamingSystem/JC8

Japanese Chemistry

NamingSystem/KansasDLN

Kansas Motor Vehicle Bureau

NamingSystem/KentuckyDLN

Kentucky Motor Vehicle Bureau

NamingSystem/LouisianaDLN

Louisiana Motor Vehicle Bureau

NamingSystem/MDDX

Medispan Diagnostic Codes

NamingSystem/MDRAE

Medical Dictionary for Regulatory Activities Terminology (MedDRA), American English Equivalents, Version 7.0. Bethesda, MD: National Library of Medicine, March 1, 2004 This is the English language version as encapsulated in the UMLS..

NamingSystem/MDRDUT

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, Dutch Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004 This is the Dutch language version as encapsulated in the UMLS..

NamingSystem/MDREA

Medical Dictionary for Regulatory Activities Terminology (MedDRA), American English Equivalents with expanded abbreviations, Version 7.0. Bethesda, MD: National Library of Medicine, March 1, 2004.

NamingSystem/MDREX

Medical Dictionary for Regulatory Activities Terminology (MedDRA), with expanded abbreviations, Version 7.0. Bethesda, MD: National Library of Medicine, March 1, 2004.

NamingSystem/MDRFRE

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, French Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004 This is the French language version as encapsulated in the UMLS..

NamingSystem/MDRGER

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, German Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004 This is the German language version as encapsulated in the UMLS..

NamingSystem/MDRPOR

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, Portuguese Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004. This is the Portuguese language version as encapsulated in the UMLS..

NamingSystem/MDRSPA

Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, Spanish Edition. International conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use (ICH). Reston, VA: MedDRA MSSO, March 1, 2004. This is the Spanish language version as encapsulated in the UMLS..

NamingSystem/MEDC

Medical Economics Drug Codes

NamingSystem/MEDRT

Medication Reference Terminology (MED-RT) is the evolutionary successor to the Veterans Health Administration National Drug File – Reference Terminology (VHA NDF-RT). Both are formal ontology representations of medication terminology, pharmacologic classifications, and asserted authoritative relationships between them. The MED-RT code system includes relationships between MED-RT concepts and concepts in external code systems, as well as relationships between concepts only in the external code systems. The external code systems that MED-RT references include RxNorm, MeSH, and SNOMED CT US Edition. MED-RT can be downloaded from https://evs.nci.nih.gov/ftp1/MED-RT/ For more information, please see https://ncit.nci.nih.gov/ncitbrowser/pages/vocabulary.jsf?dictionary=MED-RT

NamingSystem/MEDX

Medical Economics Diagnostic Codes

NamingSystem/MGPI

Medispan GPI

NamingSystem/MONDO

The Mondo Disease Ontology is a semi-automatically constructed ontology that merges in multiple disease resources to yield a coherent merged ontology that contains cross-species disease terminology. Numerous sources for disease definitions and data models currently exist, which include HPO, OMIM, SNOMED CT, ICD, PhenoDB, MedDRA, MedGen, ORDO, DO, GARD, etc; however, these sources partially overlap and sometimes conflict, making it difficult to know definitively how they relate to each other. This has resulted in a proliferation of mappings between disease entries in different resources; however mappings are problematic: collectively, they are expensive to create and maintain. Most importantly, the mappings lack completeness, accuracy, and precision; as a result, mapping calls are often inconsistent between resources. The UMLS provides intermediate concepts through which other resources can be mapped, but these mappings suffer from the same challenges: they are not guaranteed to be one-to-one, especially in areas with evolving disease concepts such as rare disease. In order to address the lack of a unified disease terminology that provides precise equivalences between disease concepts, we created Mondo, which provides a logic-based structure for unifying multiple disease resources. Mondo’s development is coordinated with the Human Phenotype Ontology (HPO), which describes the individual phenotypic features that constitute a disease. Like the HPO, Mondo provides a hierarchical structure which can be used for classification or “rolling up” diseases to higher level groupings. It provides mappings to other disease resources, but in contrast to other mappings between ontologies, we precisely annotate each mapping using strict semantics, so that we know when two disease names or identifiers are equivalent or one-to-one, in contrast to simply being closely related. For more information, see https://mondo.monarchinitiative.org/

NamingSystem/MSDRG

Section 1886(d) of the Act specifies that the Secretary shall establish a classification system (referred to as DRGs) for inpatient discharges and adjust payments under the IPPS based on appropriate weighting factors assigned to each DRG. Therefore, under the IPPS, we[CMS] pay for inpatient hospital services on a rate per discharge basis that varies according to the DRG to which a beneficiary’s stay is assigned. The formula used to calculate payment for a specific case multiplies an individual hospital’s payment rate per case by the weight of the DRG to which the case is assigned. Each DRG weight represents the average resources required to care for cases in that particular DRG, relative to the average resources used to treat cases in all DRGs. Congress recognized that it would be necessary to recalculate the DRG relative weights periodically to account for changes in resource consumption. Accordingly, section 1886(d)(4)(C) of the Act requires that the Secretary adjust the DRG classifications and relative weights at least annually. These adjustments are made to reflect changes in treatment patterns, technology, and any other factors that may change the relative use of hospital resources. Currently, cases are classified into Medicare Severity Diagnosis Related Groups (MS-DRGs) for payment under the IPPS based on the following information reported by the hospital: the principal diagnosis, up to 25 additional diagnoses, and up to 25 procedures performed during the stay. In a small number of MS-DRGs, classification is also based on the age, sex, and discharge status of the patient. Effective October 1, 2015, the diagnosis and procedure information is reported by the hospital using codes from the International Classification of Diseases, Tenth Revision, Clinical Modification (ICD-10-CM) and the International Classification of Diseases, Tenth Revision, Procedure Coding System (ICD-10-PCS). Content can be obtained on the CMS hosted page located at https://www.cms.gov/Medicare/Medicare-Fee-for-Service-Payment/AcuteInpatientPPS/MS-DRG-Classifications-and-Software The DRGs are released annually with errata published infrequently. The fiscal year and release version should be noted (e.g., 2021.38.R1). Requests for annual MS-DRG classification changes and any MS-DRG related inquiries should be sent to the MSDRGClassificationChange@cms.hhs.gov mailbox. For additional information on the MS-DRG system, including yearly reviews and changes to the MS-DRGs, please view prior Inpatient Prospective Payment System (IPPS) proposed and final rules located in the left navigational area of https://www.cms.gov/Medicare/Medicare-Fee-for-Service-Payment/AcuteInpatientPPS/MS-DRG-Classifications-and-Software

NamingSystem/MTHMDRSPA

Metathesaurus Forms of Medical Dictionary for Regulatory Activities Terminology (MedDRA) Version 7.0, Spanish Edition. Bethesda, MD: National Library of Medicine, March 2004.

NamingSystem/MVX

“The CDC’s National Center for Immunization and Respiratory Diseases (NCIRD) developed and maintains HL7 Table 0227, Manufacturers of Vaccines (MVX). It includes both active and inactive manufacturers of vaccines in the US. Inactive MVX codes allow transmission of historical immunization records. When MVX code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated. MVX is the underlying Master Code System for V2 table 0227 (Manufacturers Of Vaccines (code=MVX)). The machine readable name for MVX in PHIN VADS is PH_VaccinesAdministeredCVX_CDC_NIP. Status indicates if the manufacturer is currently making vaccine for distribution in the United States. Last Updated indicates the last time this particular manufacturer code was updated in this table. Questions regarding MVX should be directed to the IIS Technical Assistance Team(or use mailing address).” For more information, please see here.

NamingSystem/MaineDLN

Maine Motor Vehicle Bureau

NamingSystem/MarylandDLN

Maryland Motor Vehicle Bureau

NamingSystem/MassachusettsDLN

Massachusetts Motor Vehicle Bureau

NamingSystem/MeSH

The Medical Subject Headings (MeSH) thesaurus is a controlled and hierarchically-organized vocabulary produced by the National Library of Medicine. It is used for indexing, cataloging, and searching of biomedical and health-related information. MeSH includes the subject headings appearing in MEDLINE/PubMed, the NLM Catalog, and other NLM databases. MeSH can be downloaded from https://www.nlm.nih.gov/databases/download/mesh.html MeSH can be browsed here: https://meshb.nlm.nih.gov/search

NamingSystem/MichiganDLN

Michigan Motor Vehicle Bureau

NamingSystem/MinnesotaDLN

Minnesota Motor Vehicle Bureau

NamingSystem/MississippiDLN

Mississippi Motor Vehicle Bureau

NamingSystem/MissouriDLN

Missouri Motor Vehicle Bureau

NamingSystem/MontanaDLN

Montana Motor Vehicle Bureau

NamingSystem/NCPDPBrandGenericIndicator

Denotes brand or generic drug dispensed.

NamingSystem/NCPDPCompoundCode

Code indicating whether or not the prescription is a compound.

NamingSystem/NCPDPDispensedAsWrittenOrProductSelectionCode

Code indicating whether or not the prescriber’s instructions regarding generic substitution were followed.

NamingSystem/NCPDPPharmacyType

Type of pharmacy.

NamingSystem/NCPDPPrescriptionOriginCode

Code indicating the origin of the prescription. Indicates whether the prescription was transmitted as an electronic prescription, by phone, by fax, or as a written paper copy.

NamingSystem/NCPDPProviderIdentificationNumber

A NCPDP assigned number that provides pharmacies with a unique, 7-digit national identifying number that assists pharmacies in their interactions with federal agencies and third party providers. The NCPDP Provider Identification Number was formerly known as the NABP (National Board of Pharmacy) number. NCPDP also enumerates licensed dispensing sites in the United States as part of its Alternate Site Enumeration Program Numbering System (ASEP). The purpose of this system is to enable a site to identify itself to all third party processors by one standard number, in order to adjudicate claims and receive reimbursement from prescription card programs.

NamingSystem/NCPDPRejectCode

Code indicating the error encountered. Contains exception definitions for use when transaction processing cannot be completed.

NamingSystem/NDFRT

NDF-RT is a concept-oriented terminology, a collection of concepts, each of which represents a single, unique meaning. Every concept has one fully-specified name and an arbitrary number of other names, all of which are intended to mean the same thing and are therefore synonymous terms. Synonymous terms from external vocabulary sources may have associated unique identifiers. Publication of NDF-RT has ended. The Medication Reference Terminology (MED-RT) is the evolutionary successor to the NDF-RT.

NamingSystem/NHSNBSIRiskFactors

NHSN Blood Stream Infection Risk Factors

NamingSystem/NHSNHipReplacement

NHSN Hip Replacement

NamingSystem/NHSNInfectionType

NHSN Infection Type

NamingSystem/NHSNKneeReplacement

NHSN Knee Replacement

NamingSystem/NHSNLCBIPathways

NHSN Laboratory Confirmed Bloodstream Infection Pathways

NamingSystem/NHSNOccasionOfDetection

NHSN Occasion Of Detection

NamingSystem/NHSNProcedureCategory

NHSN Procedure Category

NamingSystem/NHSNSSIAnatomicSite

NHSN Surgical Site Infection Anatomic Site

NamingSystem/NHSNSSILocationType

NHSN SSI LocationType

NamingSystem/NHSNSpinalFusionApproach

NHSN Spinal Fusion Approach

NamingSystem/NHSNSpinalFusionLevel

NHSN Spinal Fusion Level

NamingSystem/NHSNSummaryData

NHSN Summary Data

NamingSystem/NHSNVocabulary

NHSN HAI Vocabulary used for Single Value bindingsto Observation Identifier

NamingSystem/NebraskaDLN

Nebraska Motor Vehicle Bureau

NamingSystem/NevadaDLN

Nevada Motor Vehicle Bureau

NamingSystem/NewHampshireDLN

New Hampshire Motor Vehicle Bureau

NamingSystem/NewJerseyDLN

New Jersey Motor Vehicle Bureau

NamingSystem/NewMexicoDLN

New Mexico Motor Vehicle Bureau

NamingSystem/NewYorkDLN

New York Motor Vehicle Bureau

NamingSystem/NorthCarolinaDLN

North Carolina Motor Vehicle Bureau

NamingSystem/NorthDakotaDLN

North Dakota Motor Vehicle Bureau

NamingSystem/OMOP

Standardized Vocabularies are an integral part of the OMOP CDM. The Standardized Vocabularies contain all of the code sets, terminologies, vocabularies, nomenclatures, lexicons, thesauri, ontologies, taxonomies, classifications, abstractions, and other such data that are needed for:

  • Generation of the transformed (i.e., standardized) data from the raw source dataset into the OMOP CDM,
  • Searching, querying and extraction of the transformed data, and browsing and navigating the hierarchies of classes and abstractions inherent in the transformed data, and
  • Interpreting the meanings of the data. This asset is available for free to anyone and can be downloaded from the Atena download page in a delimited file format. To manage the change of content, but to allow users to use and refer to a defined set of vocabularies, the whole resource is issued in releases. Major changes to the OMOP Vocabulary is released twice yearly in February and August. Instead of a major / minor version scheme, the releases of the Standardized Vocabularies component of the OMOP Vocabulary are tagged with the release date. Version label is based on the version of the CDM its aligned-to, plus a suffix appended incremented based on release date, for example: “v5.0 31-MAY-23.” At this time prior versions of the OMOP Vocabulary are not publicly available. Each release is accompanied by a standard release note, containing information about:
  • Domain changes
  • Newly added concepts grouped by vocabulary_id and domain
  • Standard concept changes
  • Newly added concepts and their standard concept status
  • Changes of concept mapping status grouped by target domain Additional details about the OMOP Vocabulary release notes can be found here
NamingSystem/OhioDLN

Ohio Motor Vehicle Bureau

NamingSystem/OklahomaDLN

Oklahoma Motor Vehicle Bureau

NamingSystem/OpenEligibilityTaxonomy

“The Open Eligibility Project is a collaborative for a series of standards for the human services sector. The Open Eligibility taxonomy is a simple way to categorize human services and human situations. With these common categories, we, as service providers, navigators, and people in need, can find human services quickly and easily.” “The Open Eligibility taxonomy consists of two important concepts: Human Services and Human Situations. Human Services are services offered by government or charitable organizations, and include things such as housing, food pantries or counseling services. Human Situations are ways of describing attributes of a person that could help them find programs they are looking for, including examples like: veterans, physical disability or seniors.” For more information, see https://support.findhelp.com/hc/en-us/articles/4404055283227-The-Open-Eligibility-Project

NamingSystem/OregonDLN

Oregon Motor Vehicle Bureau

NamingSystem/PHIndustryCDCCensus2010

2010 Industry coding system used by CDC (NIOSH and NCHS) for coding industry text. Industry describes an economic/business sector comprised of businesses/ enterprises concerned with the output of a specified category of products or services.

NamingSystem/PHOccupationCDCCensus2010

2010 Occupation coding system used by CDC (NIOSH and NCHS) for coding occupation text. Occupation describes a set of activities or tasks that individuals are paid to perform or, if unpaid, define a person’s contribution to a household/family business/community.

NamingSystem/PHOccupationalDataForHealthODH

The concepts representing the values supporting Occupational Data for Health, including Job Supervisory Level or Pay Grade (ODH) code system consists of data elements that describe a person’s work information, structured to facilitate individual, population, and public health use; not intended to support billing.).

NamingSystem/POS

POS Codes

NamingSystem/PennsylvaniaDLN

Pennsylvania Motor Vehicle Bureau

NamingSystem/RARC

X12, chartered by the American National Standards Institute for more than 40 years, develops and maintains EDI standards and XML schemas which drive business processes globally. X12’s diverse membership includes technologists and business process experts in health care, insurance, transportation, finance, government, supply chain and other industries. Remittance Advice Remark Codes (RARCs) are used to provide additional explanation for an adjustment already described by a Claim Adjustment Reason Code (CARC) or to convey information about remittance processing. Each RARC identifies a specific message as shown in the Remittance Advice Remark Code List. There are two types of RARCs, supplemental and informational. The majority of the RARCs are supplemental; these are generally referred to as RARCs without further distinction. Supplemental RARCs provide additional explanation for an adjustment already described by a CARC. The second type of RARC is informational; these RARCs are all prefaced with Alert: and are often referred to as Alerts. Alerts are used to convey information about remittance processing and are never related to a specific adjustment or CARC.

NamingSystem/RadLex

RadLex is a comprehensive set of radiology terms for use in radiology reporting, decision support, data mining, data registries, education and research. RadLex Playbook is a project of the Radiological Society of North America (RSNA), and constitutes a portion of the RadLex ontology. Playbook aims to provide a standard system for naming radiology procedures, based on the elements which define an imaging exam such as modality and body part. By providing standard names and codes for radiologic studies, Playbook is intended to facilitate a variety of operational and quality improvement efforts, including workflow optimization, chargemaster management, radiation dose tracking, enterprise integration and image exchange. As of RadLex Playbook version 2.5, a four-year project to harmonize RadLex Playbook with the radiology portion of the LOINC standard has been concluded, leading to the LOINC-RSNA Radiology Playbook which is jointly managed by the Regenstrief Institute (publisher of LOINC) and RSNA. This harmonized Playbook defines a new information model for describing imaging procedures, and identifies correspondences between RadLex Playbook codes and LOINC codes. (See https://loinc.org/download/loinc-users-guide and http://pubs.rsna.org/doi/pdf/10.1148/rg.2017160188 for details.) Note that RadLex Playbook codes start with “RPID” followed by a numerical value. LOINC codes consist of a numerical code, followed by a hyphen and a single additional digit (called the check digit). Note that in the future, new codes will be created in the LOINC format only, not the RPID format. New adopters are encouraged to use LOINC-format codes. LOINC-format codes may be accessed at http://search.loinc.org. New code requests may be submitted to the joint Regenstrief-RSNA governance committee at https://loinc.org/submissions/. From the RSNA website: “We (RSNA) recognize the benefits that come from radiologists using common language to communicate diagnostic results. For this reason, RSNA produced RadLex®, a comprehensive set of radiology terms for use in radiology reporting, decision support, data mining, data registries, education and research. RadLex provides the foundation for vital data resources used in radiology:

  • The LOINC/RSNA Radiology Playbook (http://playbook.radlex.org/playbook/SearchRadlexAction)
  • RadElement Common Data Elements (http://www.radelement.org/)
  • RadReport Radiology Reporting Templates (http://radreport.org/) The development of RadLex has been supported by the National Institute of Biomedical Imaging and Bioengineering (NIBIB) and the cancer Biomedical Informatics Grid (caBIG) project.;”
NamingSystem/RhodeIslandDLN

Rhode Island Motor Vehicle Bureau

NamingSystem/SCDHEC-GISSpatialAccuracyTiers

Description: The South Carolina Department of Health and Environmental Control GIS Spatial Data Accuracy Tiers have been derived from the National Standard for Spatial Data Accuracy as a means to categorize the accuracy of spatial data assignment utilizing a variety of tools for capturing coordinates including digitizers, geocoding software and global positioning system devices.

NamingSystem/SDM

SNOMED-DICOM Microglossary

NamingSystem/SNM3

SNOMED International

NamingSystem/SNT

SNOMED topology codes (anatomic sites)

NamingSystem/SO

“The Sequence Ontology is a set of terms and relationships used to describe the features and attributes of biological sequence. SO includes different kinds of features which can be located on the sequence. Biological features are those which are defined by their disposition to be involved in a biological process.” “The Sequence Ontologies are provided as a resource to the biological community. They have the following obvious uses:

  • To provide for a structured controlled vocabulary for the description of primary annotations of nucleic acid sequence, e.g. the annotations shared by a DAS server (BioDAS, Biosapiens DAS), or annotations encoded by GFF3.”
  • To provide for a structured representation of these annotations within databases. Were genes within model organism databases to be annotated with these terms then it would be possible to query all these databases for, for example, all genes whose transcripts are edited, or trans-spliced, or are bound by a particular protein. One such genomic database is Chado.
  • To provide a structured controlled vocabulary for the description of mutations at both the sequence and more gross level in the context of genomic databases.” “The Sequence Ontology is part of OBO. It has close links to other ontology projects such as the RNAO consortium, and the Biosapiens polypeptide features.” The content can be browsed here The content can be downloaded here For information on contributing, please see here To request a term or register feedback, see here
NamingSystem/SOPT

The Source of Payment Typology is a standardized Payer Type classification system. It is a mechanism for consistent reporting of payer data to state health data organizations and supports data comparisons by payer type across states, various provider types, and to national benchmarks. Developed by the Public Health Data Standards Consortium (PHDSC) Payer Typology Subcommittee, the typology includes broad hierarchial payer type categories with more specific subcategories. The audience for Source of Payment Typology includes researchers, public health advocates, and healthcare analysts.

NamingSystem/SouthCarolinaDLN

South Carolina Motor Vehicle Bureau

NamingSystem/SouthDakotaDLN

South Dakota Motor Vehicle Bureau

NamingSystem/TNM

The TNM Staging System was developed and is maintained by the AJCC and the Union for International Cancer Control (UICC). It is the most commonly used staging system by medical professionals around the world. The TNM classification system was developed as a tool for doctors to stage different types of cancer based on certain, standardized criteria. The TNM Staging System is based on the extent of the tumor (T), the extent of spread to the lymph nodes (N), and the presence of metastasis (M). HTA Note: Most content of TNM (V6) is in the SNOMED international release but not content from the most recent (V9). In Europe many countries use TNM codes, taken from the book and referenced using an OID.

NamingSystem/TangramMedicalTerminology

OMAHA Tangram Medical Terminology is an ontology-based medical terminological resource developed by Chinese language. It helps to standardize the expression of Chinese medical terms, and improve the semantic interoperability between different systems. The terminology can be used in electronic health records, decision support systems and digital health researches, providing the functions of mapping, data capture, data mining, data registries, statistical analysis and reasoning etc. Tangram Medical Terminology is released quarterly using the file name format as Tangram_Medical_Terminology _YYYYMMDD (Example: Tangram _Medical_Terminology _20200120). For more information, please visit http://wiki.omaha.org.cn/pages/viewpage.action?pageId=31425763 For more information, see https://term.omaha.org.cn/.

NamingSystem/TennesseeDLN

Tennessee Motor Vehicle Bureau

NamingSystem/TexasDLN

Texas Motor Vehicle Bureau

NamingSystem/UC

UCDS

NamingSystem/UMD

MDNS

NamingSystem/UML

Unified Medical Language

NamingSystem/UNII

A UNII is a non-proprietary, free, unique, unambiguous, nonsemantic, alphanumeric identifier based on a substance’s molecular structure and/or descriptive information. UNII identifiers are generated based on scientific identity characteristics using ISO 11238 data elements. UNII availability does not imply any regulatory review or approval. Synonyms and mappings are based on the best public information available at the time of publication.

NamingSystem/UPC

Universal Product Code

NamingSystem/USCOC

Coding system of United States Census Occupation Codes, published by the US Governmetn Bureau of the Census. Doucmentation and Crosswalk mapping between the COC and the SOC and NAICS code systems available at http://www.census.gov/hhes/www/ioindex/view.html

NamingSystem/USEIN

An Employer Identification Number (EIN) is also known as a Federal Tax Identification Number, and is used to identify a business entity.

NamingSystem/USZIPCODES

Coding system of defined postal zip codes for the United States of America.

NamingSystem/UtahDLN

Utah Motor Vehicle Bureau

NamingSystem/VHA

VHA Enterprise Reference Terminology is based on CHI standard terminologies (e.g., SNOMED-CT, LOINC, HL7, NDF-RT, etc.) when available and on VHA own code sets when necessary (e.g., allergens). All concepts used within the VHA clinical environment receive a VHA Unique IDentifier or VUID. VHA Enterprise Reference Terminology complies with the semantics of the HL7 message structure

NamingSystem/VermontDLN

Vermont Motor Vehicle Bureau

NamingSystem/VirginiaDLN

Virginia Motor Vehicle Bureau

NamingSystem/W1-W2

WHO rec# drug codes

NamingSystem/W3CDID

Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject. Each DID document can express cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Services enable trusted interactions associated with the DID subject. A DID might provide the means to return the DID subject itself, if the DID subject is an information resource such as a data model.” For more information, see https://www.w3.org/TR/did-core/

NamingSystem/W4

WHO rec# code with ASTM extension

NamingSystem/WashingtonDLN

Washington Motor Vehicle Bureau

NamingSystem/WestVirginiaDLN

West Virginia Motor Vehicle Bureau

NamingSystem/WisconsinDLN

Wisconsin Motor Vehicle Bureau

NamingSystem/WyomingDLN

Wyoming Motor Vehicle Bureau

NamingSystem/X12.3

X12.3 Data Elementary Dictionary This is the root OID for vocabulary defined internally by X12N. OIDS for each vocabulary will be assigned underneath this oid by appending the X12N data element id to the root OID. Data Element 1336 is Insurance Type Code, so the OID for the X12N Insurance Type Code vocabulary will be 2.16.840.1.113883.6.255.1336

NamingSystem/X12ClaimAdjustmentReasonCodes

“X12, chartered by the American National Standards Institute for more than 40 years, develops and maintains EDI standards and XML schemas which drive business processes globally. X12’s diverse membership includes technologists and business process experts in health care, insurance, transportation, finance, government, supply chain and other industries.” The X12 Claim Adjustment Reason Codes describe why a claim or service line was paid differently than it was billed. These codes are listed within an X12 implementation guide (TR3) and maintained by X12. External code lists maintained by X12 and external code lists maintained by others and distributed by WPC on behalf of the maintainer can be found here: here Click on the name of any external code list to access more information about the code list, view the codes, or submit a maintenance request. These external code lists were previously published on either www.wpc-edi.com/reference or www.x12.org/codes

NamingSystem/X12ServiceTypeCodes

“X12, chartered by the American National Standards Institute for more than 40 years, develops and maintains EDI standards and XML schemas which drive business processes globally. X12’s diverse membership includes technologists and business process experts in health care, insurance, transportation, finance, government, supply chain and other industries.” The X12 Service Type Codes identify business groupings for health care services or benefits. These codes are listed within an X12 implementation guide (TR3) and maintained by X12. External code lists maintained by X12 and external code lists maintained by others and distributed by WPC on behalf of the maintainer can be found here: https://x12.org/codes Click on the name of any external code list to access more information about the code list, view the codes, or submit a maintenance request. These external code lists were previously published on either http://www.wpc-edi.com/reference or http://www.x12.org/codes. If you have questions about these lists, submit them on the X12 Feedback form. “All X12 products are subject to this IP policy, including published and draft works. X12 is the only organization authorized to grant permission for use of X12 products. Users of all X12 products should make sure that they understand the permissible uses, as well as the limitations on such usage, as outlined below.” Additional IP information can be found here: https://x12.org/products/ip-use “Send an email to ip@x12.org to request permission to reproduce X12 IP. Include your name, organization, title, address, city, state, zip, email, a detailed description of the Submitted Artifact, including the underlying or cited X12 Product, and a detailed description of the intended audience and planned distribution method for the Artifact.” Additional information on X12 licensing program can be found here: https://x12.org/products/licensing-program To purchase code list subscriptions call (425) 562-2245 or email admin@wpc-edi.com.

NamingSystem/abcCodes

Five character alphabetic codes fit into current claims processing software or onto standard paper claim forms. ABC Codes give business parity to licensed CAM and nurse providers who file claims to insurance companies. .

NamingSystem/ahfs

Description: The AHFS Pharmacologic-Therapeutic Classification has been in use in hospitals in the United States since its inception in 1959. An integral part of the American Hospital Formulary Service, the AHFS classification allows the grouping of drugs with similar pharmacologic, therapeutic, and/or chemical characteristics. Today, the AHFS classification is used by many people outside of hospitals.

NamingSystem/apdrg

In 1987, the state of New York passed legislation instituting a DRG-based prospective payment system for all non-Medicare patients. The legislation included a requirement that the New York State Department of Health (NYDH) evaluate the applicability of the DRGs to a non-Medicare population. In particular, the legislation required that the DRGs be evaluated with respect to neonates and patients with Human Immunodeficiency Virus (HIV) infections. NYDH entered into an agreement with 3M HIS to assist with the evaluation of the need for DRG modifications as well as to make the necessary changes in the DRG definitions and software. The DRG definitions developed by NYDH and 3M HIS are referred to as the All Patient DRGs (AP DRGs).

NamingSystem/art

WHO Adverse Reaction Terms

NamingSystem/bluetooth-address-identifier

The Bluetooth Device Address (sometimes referred to as a Bluetooth MAC address) is a unique 48-bit identifier assigned to each Bluetooth device by the manufacturer. Bluetooth Addresses are usually displayed as 6 bytes written in hexadecimal and separated by colons (example - 00:11:22:33:FF:EE). They are an essential part of Bluetooth-based protocols. The upper half of a Bluetooth Address (most-significant 24 bits) is the so-called Organizationally Unique Identifier (OUI). It can be used to determine the manufacturer of a device (Bluetooth MAC Address Lookup form). OUI prefixes are assigned by the Institute of Electrical and Electronics Engineers (IEEE). An EUI (Extended Unique Identifier) is generally made from an OUI and thus a Bluetooth Address is also an EUI-48. A device that has a Bluetooth address can also have it own Ethernet MAC address.

NamingSystem/ca-hc-din

A Drug Identification Number (DIN) is a computer-generated eight digit number assigned by Health Canada to a drug product prior to being marketed in Canada. It uniquely identifies all drug products sold in a dosage form in Canada and is located on the label of prescription and over-the-counter drug products that have been evaluated and authorized for sale in Canada. A DIN uniquely identifies the following product characteristics:

  • manufacturer
  • product name
  • active ingredient(s)
  • strength(s) of active ingredient(s)
  • pharmaceutical form, and
  • route of administration. Note: The number has a leading zero. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/drug-products/applications-submissions/guidance-documents/regulatory-requirements-drug-identification-numbers/document.html
NamingSystem/camncvs

CAM & Nursing Coding Vocabulary Set

NamingSystem/cmsMBI

Medicare Beneficiary Identifier (MBI) number is a unique identifier of a beneficiary used for Medicare entitlement and billing purposes. Medicare Beneficiary Identifiers are represented without any spaces or dashes.

NamingSystem/cmshcc

The CMS-HCC model uses more than 9,000 ICD-10-CM codes, which are mapped to condition categories that predict costs well. The condition categories are based on diagnoses clinically related to one another and with similar predicted cost implications. Hierarchies are imposed on the condition categories to capture the most costly diagnoses. Hierarchy logic is imposed on certain condition categories to account for different hierarchical costs, thus, the term Hierarchical Condition Category, or HCC. For more information, see https://www.cms.gov/Medicare/Health-Plans/MedicareAdvtgSpecRateStats/Risk-Adjustors. The CMS HCCs are in the public domain and are free to use without restriction.

NamingSystem/cpnum

Gold Standard’s Clinical Pharmacology Monograph Number

NamingSystem/csaid

** Inactvie since 2015. Nature of injury (NOI) codes, which are part of the Work Injury or Disease Information coding system (CAN/CSA-Z795-96 - R2003). The CSA code set includes 3 parts: Nature of injury (NOI), body part (BP), side of body (SB). For example:

  • NOI - Cut or laceration Injury = 03400
  • BP - Upper Arm body part = 31100
  • SOB - Left Side of Body = L The Body Part codes are qualified by the Side of Body codes code system, to be more precise in specifying the location of the injury being coded. Code set is maintained by the Canadian Standards Association (CSA). set is maintained by the Canadian Standards Association (CSA). The Canadian Standards Association 5060 Spectrum Way Mississauga, Ontario Canada L4W 5N6 Phone: (416) 747-4000 1-800-463-6727 Fax: (416) 747-2473
NamingSystem/deeds-old

retired root for DEEDs from earlier work. Superceded.

NamingSystem/dicomMDLTY

DICOM modality codes

NamingSystem/dicomqry

DICOM Query Label

NamingSystem/dmdICD10

Internationale Klassifikation der Krankheiten 10 [German translation of ICD10]. Germany: Deutsches Institut fuer Medizinische Dokumentation und Information, 1998.

NamingSystem/dui

An OID issued under DICOM OID rules. DICOM OIDs are represented as plain OIDs, with a prefix of “urn:oid:”. See https://www.dicomstandard.org/

NamingSystem/epsg-ca

Description:The set of values found in the Coord Axis Code column of the Coordinate Axis table as maintained in the EPSG geodetic parameter dataset. These define the axis for coordinate systems for geographic coordinates.

NamingSystem/epsg-crs

Description: The set of values found in the Coord Axis Code column of the Coordinate Axis table as maintained in the EPSG geodetic parameter dataset. These define the axis for coordinate systems for geographic coordinates.

NamingSystem/ethernet-address-identifier

The Ethernet MAC (media access control) address is a unique identifier assigned to a network interface controller (NIC) for use as a network address in communications within a network segment. This use is common in most IEEE 802 networking technologies. The address typically includes a manufacturer’s organizationally unique identifier (OUI). MAC addresses are formed according to the principles of two numbering spaces based on Extended Unique Identifiers (EUI) managed by the Institute of Electrical and Electronics Engineers (IEEE): EUI-48. A device that has an Ethernet MAC address can also have it own Bluetooth MAC address.

NamingSystem/euclides

EUCLIDES

NamingSystem/externalCodeSystems

External coding systems registered in HL7 with an HL7 OID

NamingSystem/fdk

FDA K10

NamingSystem/fipspub92

FIPSPUB92 - GUIDELINE FOR STANDARD OCCUPATIONAL CLASSIFICATION (SOC) CODES, version 1983 February 24. This entry is now obsolete, as FIPS92 was withdrawn from use in February 2005 by the US Government. It has been replaced by 2.16.840.1.113883.6.243; please use that OID instead.

NamingSystem/gtin

The GS1 GTIN is a globally unique identifier of trade items. A trade item is any item (product or service) upon which there is a need to retrieve pre-defined information and that may be priced, or ordered, or invoiced at any point in any supply chain. Note: GTINs may be used in both Codes (http://build.fhir.org/datatypes.html#Coding) and Identifiers (http://build.fhir.org/datatypes.html#Identifier).

NamingSystem/hcp-lan-apm-framework

“The Health Care Payment Learning and Action Network (HCPLAN or LAN) https://hcp-lan.org/ is a public-private partnership established in 2015 by the US Department of Health and Human Services (HHS) to accelerate the transition to value-based payment models in the US healthcare system.” “The Framework represents payments from public and private payers to provider organizations (including payments between the payment and delivery arms of highly integrated health systems). It is designed to accommodate payments in multiple categories that are made by a single payer, as well as single provider organizations that receive payments in different categories—potentially from the same payer.” “Since the original APM Framework White Paper was released in January 2016, it has become the foundation for implementing APMs and evaluating progress toward health care payment reform. Payers, providers, and purchasers have all used the APM Framework to better understand the payment reform landscape and to set goals for participation in APMs, and health care stakeholders have used the APM Framework to identify common goals for transforming the nation’s health care system. Overall, the APM Framework’s classification system has been adopted by the health care ecosystem.” “The LAN APM Framework represents a continuum of payment approaches across four Categories.” Initial version of the APM Framework White Paper was published in 2016. The updated version of the White Paper was published in 2017. For more information, please see https://hcp-lan.org/workproducts/apm-refresh-whitepaper-final.pdf

NamingSystem/hcpcs-Level-II

The Level II HCPCS codes, which are established by CMS’s Alpha-Numeric Editorial Panel, primarily represent items and supplies and non-physician services not covered by the American Medical Association’s Current Procedural Terminology-4 (CPT-4) codes; Medicare, Medicaid, and private health insurers use HCPCS procedure and modifier codes for claims processing. Level II alphanumeric procedure and modifier codes comprise the A to V range.

NamingSystem/hhcc

HHCC - Home Health Codes

NamingSystem/hi

Health Outcomes

NamingSystem/hibccHIN

HIBCC

NamingSystem/hsloc

A classification of patient care locations within healthcare facilities for public health purposes.

NamingSystem/ib

ISBT 128 is a coding system for blood components, hematopoietic progenitor cells and other tissues. It is comprised of an overall Application Specification, and labeling and coding documents for the separate sections: blood components, hematopoietic progenitor cells (draft), source plasma (draft) and tissues (draft). The documentation is supported by databases: Country/Collection Facility, Product Code (blood components), Product Code (hematopoietic progenitor sells), Product Code (source plasma), Product Code (tissues) and Special Testing. ISBT 128 is designed as a series of data structures that are designed to be technology-independent and can be used for bar coding, radio frequency tag encoding and electronic data interchange. The HL7 Blood Bank SIG is currently designing example messages that incorporate ISBT 128 coding. No changes of any kind will be needed to use ISBT 128 in HL7 messages.

NamingSystem/icaosex

ICAO is funded and directed by 193 national governments to support their diplomacy and cooperation in air transport as signatory states to the Chicago Convention (1944) Its core function is to maintain an administrative and expert bureaucracy (the ICAO Secretariat supporting these diplomatic interactions, and to research new air transport policy and standardization innovations as directed and endorsed by governments through the ICAO Assembly, or by the ICAO Council which the assembly elects. ICAO has developed a technical specification (sample version form 2021 here ) to “allow compatibility and global interchange using both visual (eye readable) and machine readable means. The specifications lay down standards for visas which can, where issued by a State and accepted by a receiving State, be used for travel purposes. The MRV[Machine Readable Visa] shall, as a minimum, contain the data specified herein in a form that is legible both visually and by optical character recognition methods..” Further, defining that “Sex of MRV-A[Format A - Machine Readable Visa] holder, when included, is to be specified by use of the single initial commonly used in the language of the State of issue. If translation into English, French or Spanish is necessary, followed by an oblique and the capital letter F for female, M for male, or X for unspecified.” Sex of MRV-B[Format B - Machine Readable Visa] holder, when included, is to be specified by use of the single initial commonly used in the language of the State of issue. If translation into English, French or Spanish is necessary, followed by an oblique and the capital letter F for female, M for male, or X for unspecified.

NamingSystem/icd-o

International Classification of Diseases for Oncology)

NamingSystem/icd-o-3

International Classification of Diseases for Oncology, version 3. For more information see http://www.who.int/classifications/icd/adaptations/oncology/en/.

NamingSystem/icd10

International Classification of Diseases revision 10 (ICD 10)

NamingSystem/icd10-CA

ICD-10-CA (International Statistical Classification of Diseases and Related Health Problems, 10th Revision, Canada) was developed by the World Health Organization (WHO) and enhanced by CIHI to meet Canadian morbidity data needs. ICD-10-CA classifies diseases, injuries and causes of death, as well as external causes of injury and poisoning. It also includes conditions and situations that are not diseases but represent risk factors to health, such as occupational and environmental factors, lifestyle and psychosocial circumstances.

NamingSystem/icd10CM

The International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM), describes the classification of morbidity and mortality information for statistical purposes and for the indexing of healthcare records by diseases. The ICD-10-CM codes can be used as the value of the Act.cd attribute.

NamingSystem/icd10PCS

ICD Procedure Coding System (ICD 10 PCS)

NamingSystem/icd10ae

International Statistical Classification of Diseases and Related Health Problems (ICD-10): Americanized Version. 10th rev. Geneva (Switzerland): World Health Organization, 1998.

NamingSystem/icd9

ICD9

NamingSystem/icd9cm

International Classification of Diseases revision 9, with Clinical Modifications (ICD 9 CM)

NamingSystem/icnp

ICNP(r) is a combinatorial terminology, using a multi-axial structure. ICNP(r) provides standardized terms and codes for terms in two classifications that can be used to compose or create pre-coordinated concepts to represent observations and procedures, specifically, patient problems/nursing diagnoses, nursing interventions including those focused on assessment and actual or expected (goal) outcomes. The ICNP(r) Classification for Nursing Phenomena is used to compose concepts or statements to represent observations (nursing diagnoses, patient problems, patient status, patient outcomes). The ICNP(r) Nursing Actions Classification is used to compose concepts or statements to represent procedures (nursing interventions)

NamingSystem/icpc

The International Classification of Primary Care (ICPC). Denmark: World Organisation of Family Doctors, 1993. Various language translations are identified beneath this OID.

NamingSystem/icpc-BAQ

The International Classification of Primary Care (ICPC). Basque Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-DAN

The International Classification of Primary Care (ICPC). Danish Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-DUT

The International Classification of Primary Care (ICPC). Dutch Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-ENG

The International Classification of Primary Care (ICPC). Swedish Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-FIN

The International Classification of Primary Care (ICPC). Finnish Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-FRE

The International Classification of Primary Care (ICPC). French Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-GER

The International Classification of Primary Care (ICPC). German Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-HEB

The International Classification of Primary Care (ICPC). Hebrew Translation, Denmark: World Organisation of Family Doctors, 1993

NamingSystem/icpc-HUN

The International Classification of Primary Care (ICPC). Hungarian Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-ITA

The International Classification of Primary Care (ICPC). Italian Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-NOR

The International Classification of Primary Care (ICPC). Norwegian Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-POR

The International Classification of Primary Care (ICPC). Portuguese Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-SPA

The International Classification of Primary Care (ICPC). Spanish Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc-SWE

The International Classification of Primary Care (ICPC). Swedish Translation. Denmark: World Organisation of Family Doctors, 1993.

NamingSystem/icpc2-icd10-DUT

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

NamingSystem/icpc2-icd10-ENG

Becker, H.W., C. van Boven, S.K. Oskam, I.M. Okkes, W. Hirs, H. Lamberts. ICPC2 - ICD10 Thesaurus, Version March, 2004. Amsterdam: Project “Adaptation ICPC, integration and implementation of ICPC2 and ICD10(-CM).” Department of General Practice, Academic

NamingSystem/icpc2-icd10-THSRS

A diagnostic Terminology for semi-automatic Double Coding in Electronic Patient Records The thesaurus is a part of the CD Rom: “ICPC in the Amsterdam Transition Project. Extended Version. IM Okkes, SK Oskam, H. Lamberts. Amsterdam: Academic Medical Center/University of Amsterdam. Department of Family Medicine”, see also the web site http://www.transitieproject.nl for this application of the thesaurus. This bilingual (English/Dutch) ICPC2-ICD10 thesaurus is derived from an extended version of the CD-Rom ICPC in the Amsterdam Transition Project, that was published as a companion to ICPC-2-R by Oxford University Press (2005). As was the case with the former thesaurus (published in Dutch in 2003), the content of this new thesaurus may be copied for academic purposes, and be used for teaching and research under the usual referencing conditions. Any other and/or commercial use requires prior permission from the authors, represented by Dr. Inge Okkes (see below). It is strongly recommended that you first go through the ICPC Tutorial, the Manual and the Glossary, and consider printing them. Becker, H.W., C. van Boven, S.K. Oskam, I.M. Okkes, W. Hirs, H. Lamberts. ICPC2 - ICD10 Thesaurus, Version March, 2004. Amsterdam: Project “Adaptation ICPC, integration and implementation of ICPC2 and ICD10(-CM).” Department of General Practice, Academic

NamingSystem/icpc2E-DUT

Hirs, W., H.W. Becker, C. van Boven, S.K. Oskam, I.M. Okkes, H. Lamberts. International Classification of Primary Care 2E: 2nd ed. electronic. Dutch Translation. Amsterdam: Department of General Practice, Academic Medical Center/University of Amsterdam, D

NamingSystem/icpc2E-ENG

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

NamingSystem/icpc2E-P

International Classification of Primary Care, Version 2-Plus. Produced by NLM. Bethesda (MD): National Library of Medicine, UMLS project. This node has the various modifications and translations produced under it.

NamingSystem/icpc2E-P-AE

International Classification of Primary Care, Version 2-Plus, Australian Modification. Americanized English Equivalents, January, 2000. Produced by NLM. Bethesda (MD): National Library of Medicine, UMLS project

NamingSystem/icpc2E-P-AUS

International Classification of Primary Care, Version 2-Plus, Australian Modification. January, 2000

NamingSystem/ics

ICCS

NamingSystem/ietf3066

from OID registry

NamingSystem/imei-identifier

The International Mobile Equipment Identity (IMEI) is a number, usually unique, to identify 3GPP and iDEN mobile phones, as well as some satellite phones. The IMEI consists of 15 decimal digits: 14 digits plus a check digit while the IMEISV consists of 16 decimal digits: 14 digits plus two software version digits. These numbers includes information on the origin, model, and serial number of the device. The structure of the IMEI/SV is specified in 3GPP TS 23.003. The model and origin comprise the initial 8-digit portion of the IMEI/SV, known as the Type Allocation Code (TAC). The remainder of the IMEI is manufacturer-defined, with a Luhn check digit at the end.

NamingSystem/iri

As defined by RFC 3987 (http://www.ietf.org/rfc/rfc3987.txt). Internationalized Resource Identifiers (IRIs) are the internationalized version of URIs (which are also defined as a NamingSystem as https://terminology.hl7.org/4.0.0/NamingSystem-uri.html) that allow Unicode characters to be used in the identifier with some restrictions, which was defined by the Internet Engineering Task Force (IETF) in 2005. An IRI such as ‘https://hi.wikipedia.org/wiki/हृदय’ can be percent-encoded into the URI ‘https://hi.wikipedia.org/wiki/%E0%A4%B9%E0%A5%83%E0%A4%A6%E0%A4%AF’ to be used as a URL, but the IRI is easier to read, particularly for readers of non-Latin languages, and is natively supported by many tools, including many browsers, HTTP libraries, and in the Resource Description Framework (RDF).

NamingSystem/iso21000-6-2004E-RDD

ISO/IEC 21000-6:2004 describes a Rights Data Dictionary which comprises a set of clear, consistent, structured, integrated and uniquely identified terms to support the MPEG-21 Rights Expression Language (REL), ISO/IEC 21000-5. Annex A specifies the methodology for and structure of the RDD Dictionary, and specifies how further Terms may be defined under the governance of a Registration Authority, requirements for which are described in Annex C. Taken together, these specifications and the RDD Dictionary and Database make up the RDD System. Use of the RDD System will facilitate the accurate exchange and processing of information between interested parties involved in the administration of rights in, and use of, Digital Items, and in particular it is intended to support ISO/IEC 21000-5 (REL). Clause 6 describes how ISO/IEC 21000-6:2004 relates to ISO/IEC 21000-5. As well as providing definitions of terms for use in ISO/IEC 21000-5, the RDD System is designed to support the mapping of terms from different namespaces. Such mapping will enable the transformation of metadata from the terminology of one namespace (or Authority) into that of another namespace. Mapping, to ensure minimum ambiguity or loss of semantic integrity, will be the responsibility of the Registration Authority. Provision of automated trm look-up is also a requirement. The RDD Dictionary is a prescriptive dctionary, in the sense that it defines a single meaning for a trm represented by a particular RddAuthorized TermName, but it is also inclusive in that it can recognize the prescription of other Headwords and definitions by other Authorities and incorporates them through mappings. The RDD Dictionary also supports the circumstance that the same name may have different meanings under different Authorities. ISO/IEC 21000-6:2004describes audit provisions so that additions, amendments and deletions to Terms and their attributes can be tracked. ISO/IEC 21000-6:2004 recognizes legal definitions as and only as Terms from other Authorities that can be mapped into the RDD Dictionary. Therefore Terms that are directly authorized by the RDD Registration Authority neither define nor prescribe intellectual property rights or other legal entities.

NamingSystem/iso3166-1edition2

This OID identifies the coding system published in the ISO 3166-1 Standard for Country codes. It contains 3 sets of synonyms for the country codes: 2-character alphabetic, 3-character alphabetic, and numeric. Note that this is the 2nd edition of the standard.

NamingSystem/iso3166-1edition2alpha2

Identifies the coding system published in the ISO 3166-1 Standard for Country codes, 2nd edition, 2-character alphabetic codes.

NamingSystem/iso3166-1edition2alpha3

Identifies the coding system published in the ISO 3166-1 Standard for Country codes, 2nd edition, 3-character alphabetic codes.

NamingSystem/iso3166-1edition2numeric

Identifies the coding system published in the ISO 3166-1 Standard for Country codes, 2nd edition, numeric codes.

NamingSystem/iso3166-2

Identifies the coding system published in the ISO 3166-2 Standard for Country Subdivision codes. This standard is released periodically, and a new OID will be assigned by ISO for new editions.

NamingSystem/iso4217

ISO 4217 currency codes.

NamingSystem/iso639-1

Description: Codes for the Representation of Names of Languages Part 1: Alpha-2 Code. Used as part of the IETF 3066 specification for languages throughout the HL7 specification. This part of ISO 639 provides a code consisting of language code elements comprising two-letter language identifiers for the representation of names of languages. The language identifiers according to this part of ISO 639 were devised originally for use in terminology, lexicography and linguistics, but may be adopted for any application requiring the expression of language in two- letter coded form, especially in computerized systems. The alpha-2 code was devised for practical use for most of the major languages of the world that are not only most frequently represented in the total body of the world’s literature, but which also comprise a considerable volume of specialized languages and terminologies. Additional language identifiers are created when it becomes apparent that a significant body of documentation written in specialized languages and terminologies exists. Languages designed exclusively for machine use, such as computer-programming languages, are not included in this code. The code set is available from http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm? csnumber=22109&ICS1=1&ICS2=140&ICS3=20

NamingSystem/iso639-1ret

Codes for the Representation of Names of Languages Part 1: Alpha-2 Code. Used as part of the IETF 3066 specification for languages throughout the HL7 specification. DeprecationComment: This code system is being deprecated, as the OID identifying it has been replaced with the correct ISO OID of 1.0.639.1

NamingSystem/iso639-2

Description: Codes for the representation of names of languages, 3 character alphabetic codes. This has been superceded by ISO 639-3 for many purposes. ISO 639-2 was released in 1998. The code set is available from http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=4767

NamingSystem/iso639-2ret

Codes for the Representation of Names of Languages Part 2: Alpha-3 Code. Used as part of the IETF 3066 specification for languages throughout the HL7 specification. DeprecationComment: This code system is being deprecated, as the OID identifying it has been replaced with the correct ISO OID of 1.0.639.2

NamingSystem/iso639-3

Description: ISO 639-3 is a code that aims to define three-letter identifiers for all known human languages. At the core of ISO 639-3 are the individual languages already accounted for in ISO 639-2. The large number of living languages in the initial inventory of ISO 639-3 beyond those already included in ISO 639-2 was derived primarily from Ethnologue (15th edition). Additional extinct, ancient, historic, and constructed languages have been obtained from Linguist List. SIL International has been designated as the ISO 639-3/RA for the purpose of processing requests for alpha-3 language codes comprising the International Standard, Codes for the representation of names of languages - Part 3: Alpha-3 code for comprehensive coverage of languages. The ISO 639-3/RA receives and reviews applications for requesting new language codes and for the change of existing ones according to criteria indicated in the standard. It maintains an accurate list of information associated with registered language codes which can be viewed on or downloaded from this website, and processes updates of registered language codes. Notification of pending and adopted updates are also distributed on a regular basis to subscribers and other parties.

NamingSystem/mddid

Medispan Drug Descriptor ID Entry autogenerated to support Sources from the UMLS. Full metadata set still incomplete.

NamingSystem/mdr

MedDRA is a multilingual standardised international medical terminology which can be used for regulatory communication and evaluation of data pertaining to medicinal products for human use. MedDRA is designed for use in the registration, documentation and safety monitoring of medicinal products through all phases of the development cycle (i.e., from clinical trials to post-marketing surveillance).#13; MedDRA is structured as a five level hierarchy. System Organ Classes (SOCs) are the broadest terms (e.g., Cardiac disorders, Investigations). The lowest level of the terminology is the Lowest Level Term (LLT) level.

NamingSystem/medcin

MEDCIN contains more than 175,000 clinical data elements arranged in a hierarchy, with each item having weighted links to relevant diagnoses. The clinical data elements are organized into six basic termtypes designed to accommodate information relevant to a clinical encounter. The basic termtypes in MEDCIN’s terminological hierarchy are as follows: Symptoms History Physical Examination Tests Diagnoses Therapy Within this basic structure, MEDCIN terms are further organized in a ten level terminological hierarchy, supplemented by an optional, multi-hierarchical diagnostic index. For example, the symptom of “difficulty breathing” is placed in the terminological hierarchy as a subsidiary (or “child”) finding of “pulmonary symptoms,” although the presence (or absence) of difficulty breathing can related to conditions as diverse as myocardial infarction, bronchitis, pharyngeal foreign bodies, asthma, pulmonary embolism, etc. MEDCIN’s diagnostic index provides more than 800 such links for difficulty breathing.

NamingSystem/medicareHIC

Medicare Health Insurance Claim # (HIC) is a unique identifier of a beneficiary used for Medicare entitlement and billing purposes. Medicare Numbers (HIC or HICN) are represented without any spaces or dashes.

NamingSystem/metabolicSyndrome

A collection of metabolic risk factors in one individual. The root causes of metabolic syndrome are overweight / obesity, physical inactivity, and genetic factors. Various risk factors have been included in metabolic syndrome. Factors generally accepted as being characteristic of this syndrome include abdominal obesity, atherogenic dyslipidemia, raised blood pressure, insulin resistence with or without glucose intolerance, prothrombotic state, and proinflammatory state.

NamingSystem/mth-icpc2-icd10-7B

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

NamingSystem/mth-icpc2-icd10-AE

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

NamingSystem/mthicpc2E-AE

Henk Lamberts and Inge Hofmans-Okkes. International Classification of Primary Care 2nd Edition, Electronic, 2E, American English Equivalents. Amsterdam: International Classification of Primary Care / prepared by the Classification Committee of the World Health Organization. Entry derived from the UMLS Metathesaurus.

NamingSystem/multum

Broadly, the fields and values in the Multum Lexicon and the VantageRx Database are intended to be available for use in any HL7 message that includes a reference to non-veterinary drug products or active ingredients that are either approved for sale by the FDA or readily available in the United States. The following inter-related definitions recently circulated by us to the HL7 Vocabulary Technical Committee explain the scope of what we mean by “drug product” and “active ingredient”. (A definition for “drug ingredient” is also provided here because the definition of “active ingredient” is reliant on this term.) Drug Product A drug product is a manufactured or extemporaneously-compounded physiologically-active material intended by the preparer to achieve therapeutic, diagnostic, or preventative effects via biochemical mechanisms when applied to an epithelial surface or placed in an internal body space of a targeted organism. Drug Ingredient A drug ingredient is a chemical compound or biologic agent that occurs in a drug product. Active Ingredient An active ingredient is a drug ingredient that mediates one or more of the intended therapeutic, diagnostic, or preventative effects of a drug product and is present in sufficient quantities to achieve such effects according to the allopathic tradition of healthcare practice.

NamingSystem/naaccrCodes

NAACCR Cancer Registry

NamingSystem/naics

North American Industry Classification System(NAICS) for the United States, a new economic classification system that replaces the 1987 Standard Industrial Classification (SIC) for statistical purposes. NAICS is a system for classifying establishments by type of economic activity. Its purposes are: (1) to facilitate the collection, tabulation, presentation, and analysis of data relating to establishments, and (2) to promote uniformity and comparability in the presentation of statistical data describing the economy. NAICS will be used by Federal statistical agencies that collect or publish data by industry.

NamingSystem/nanda-i

The terminology consists of standardized terms and codes for patient problems or life processes expressed as nursing diagnoses. These data elements would be classified by HL7 as “observations”. The taxonomy is multi-axial. It consists of 12 domains and 36 classes. All domains and classes are defined. There are 7 axes with definitions for each. Each nursing diagnosis consists of: a concept label or term expressed as a noun or a noun phrase; a definition of the term; a set of defining characteristics (signs and symptoms) of the diagnostic term; an approved list of modifiers of the term; a set of risk factors with definitions; and a set of related factors (or etiologies) for the term. The system preserves semantics by having robust review procedures and policies to ensure against semantic drift in the meanings of the encoded terms over time. NANDA as an organization is committed to updating the terminology on a regular biannual basis. NANDA has been in existence since 1973 and is thus the oldest developer of standardized language in nursing. Most other nursing language systems use many of the older NANDA terms in their vocabularies. The express purpose of the organization is to develop a comprehensive standardized nursing language that captures the conclusions that nurses make based on observations - in effect, the nursing diagnoses. The work is a continuing effort and diagnoses are revised, retired or added bi-annually. The codes are simple integers and are not linked to each other. If a diagnostic term is retired, the code is also retired. If a new diagnosis is added a new code is given to that term. If a diagnostic term is revised, the code is kept intact but the date of the revision is published alongside the term. Domains and classes are not coded.

NamingSystem/nciVersionOfNDF-RT

The National Drug File RT (NDF-RT) is published by the US Veterans’ Administration (VA). NDF-RT covers clinical drugs used at the VA. The NCI version of NDF-RT is used by NCI to provide automated terminology access to the Food and Drug Administration (FDA) Structured Product Label (SPL) initiative. NCI makes its version of NDF-RT available publicly thru the Web, download via FTP and via open APIs for Java, SOAP and HTTP.

NamingSystem/nddf

National Drug Data File Plus Source Vocabulary 2004. San Bruno, CA: First DataBank, March 11, 2004. This entry was generated to support the Sources in the UMLS. Additional metadata is still missing.

NamingSystem/nic

The Nursing Interventions Classification (NIC) is a standardized classification developed by a research team at the University of Iowa. The purpose of NIC is to define interventions that nurses do on behalf of patients in all care domains. An intervention is defined as ‘any treatment, based upon clinical judgment and knowledge, a nurse performs to enhance patient/client outcomes.’ NIC is updated a five-year cycle.

NamingSystem/nmds

The NMDS is the minimum set of items of information with uniform definitions and categories concerning the specific dimension of the context of patient care delivery. It represents the minimum data used to support the management and administration of patient/nursing care delivery across all types of settings.

NamingSystem/nmmds

The NMMDS is the minimum set of items of information with uniform definitions and categories concerning the specific dimension of the context of patient care delivery. It represents the minimum data used to support the management and administration of patient/nursing care delivery across all types of settings. The NMMDS is composed of seventeen (17) data elements organized into three categories: environment, nurse resources, and financial resources. See Tables 1-3 for the elements and related definitions organized by each categories. The NMMDS most appropriately focuses at the first level of accountability for patient/client/family/community nursing care: this may be the delivery unit, service, or center of excellence level. The NMMDS supports numerous constructed variables as well as aggregation of data at the unit, institution, network, and system, etc levels. This minimum data set provides the structure for the collection of uniform information that influences quality of patient care, directly and indirectly.

NamingSystem/noc

NOC - Nursing Outcome Codes

NamingSystem/npi

National Provider Identifier

NamingSystem/nubc-UB92

National Uniform Billing Council, UB 92

NamingSystem/oms

The Omaha System provides standardized terms, definitions, and codes for observations and procedures, specifically for client problems, multidisciplinary interventions including those focusing on assessment and care, and problem-specific client outcomes.

NamingSystem/opinions

Description: Codes to identify products and services that do not have DIN’s and which need to be billed. http://www.atlanticpharmaceutical.ca/default.asp?mn=5.23

NamingSystem/passportNumNS-ABW

Identifier of the namespace for Passport Numbers issued by the country of ARUBA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-AFG

Identifier of the namespace for Passport Numbers issued by the country of AFGHANISTAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-AGO

Identifier of the namespace for Passport Numbers issued by the country of ANGOLA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-AIA

Identifier of the namespace for Passport Numbers issued by the country of ANGUILLA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ALA

Identifier of the namespace for Passport Numbers issued by the country of ALAND ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ALB

Identifier of the namespace for Passport Numbers issued by the country of ALBANIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-AND

Identifier of the namespace for Passport Numbers issued by the country of ANDORRA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ANT

Identifier of the namespace for Passport Numbers issued by the country of NETHERLANDS ANTILLES. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ARE

Identifier of the namespace for Passport Numbers issued by the country of UNITED ARAB EMIRATES. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ARG

Identifier of the namespace for Passport Numbers issued by the country of ARGENTINA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ARM

Identifier of the namespace for Passport Numbers issued by the country of ARMENIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ASM

Identifier of the namespace for Passport Numbers issued by the country of AMERICAN SAMOA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ATA

Identifier of the namespace for Passport Numbers issued by the country of ANTARCTICA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ATF

Identifier of the namespace for Passport Numbers issued by the country of FRENCH SOUTHERN TERRITORIES. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ATG

Identifier of the namespace for Passport Numbers issued by the country of ANTIGUA AND BARBUDA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-AUS

Identifier of the namespace for Passport Numbers issued by the country of AUSTRALIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-AUT

Identifier of the namespace for Passport Numbers issued by the country of AUSTRIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-AZE

Identifier of the namespace for Passport Numbers issued by the country of AZERBAIJAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BDI

Identifier of the namespace for Passport Numbers issued by the country of BURUNDI. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BEL

Identifier of the namespace for Passport Numbers issued by the country of BELGIUM. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BEN

Identifier of the namespace for Passport Numbers issued by the country of BENIN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BFA

Identifier of the namespace for Passport Numbers issued by the country of BURKINA FASO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BGD

Identifier of the namespace for Passport Numbers issued by the country of BANGLADESH. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BGR

Identifier of the namespace for Passport Numbers issued by the country of BULGARIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BHR

Identifier of the namespace for Passport Numbers issued by the country of BAHRAIN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BHS

Identifier of the namespace for Passport Numbers issued by the country of BAHAMAS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BIH

Identifier of the namespace for Passport Numbers issued by the country of BOSNIA AND HERZEGOVINA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BLM

Identifier of the namespace for Passport Numbers issued by the country of SAINT BARTHELEMY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BLR

Identifier of the namespace for Passport Numbers issued by the country of BELARUS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BLZ

Identifier of the namespace for Passport Numbers issued by the country of BELIZE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BMU

Identifier of the namespace for Passport Numbers issued by the country of BERMUDA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BOL

Identifier of the namespace for Passport Numbers issued by the country of BOLIVIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BRA

Identifier of the namespace for Passport Numbers issued by the country of BRAZIL. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BRB

Identifier of the namespace for Passport Numbers issued by the country of BARBADOS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BRN

Identifier of the namespace for Passport Numbers issued by the country of BRUNEI DARUSSALAM. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BTN

Identifier of the namespace for Passport Numbers issued by the country of BHUTAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BVT

Identifier of the namespace for Passport Numbers issued by the country of BOUVET ISLAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-BWA

Identifier of the namespace for Passport Numbers issued by the country of BOTSWANA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CAF

Identifier of the namespace for Passport Numbers issued by the country of CENTRAL AFRICAN REPUBLIC. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CAN

Identifier of the namespace for Passport Numbers issued by the country of CANADA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CCK

Identifier of the namespace for Passport Numbers issued by the country of COCOS (KEELING) ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CHE

Identifier of the namespace for Passport Numbers issued by the country of SWITZERLAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CHL

Identifier of the namespace for Passport Numbers issued by the country of CHILE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CHN

Identifier of the namespace for Passport Numbers issued by the country of CHINA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CIV

Identifier of the namespace for Passport Numbers issued by the country of COTE D’IVOIRE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CMR

Identifier of the namespace for Passport Numbers issued by the country of CAMEROON. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-COD

Identifier of the namespace for Passport Numbers issued by the country of CONGO, THE DEMOCRATIC REPUBLIC OF THE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-COG

Identifier of the namespace for Passport Numbers issued by the country of CONGO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-COK

Identifier of the namespace for Passport Numbers issued by the country of COOK ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-COL

Identifier of the namespace for Passport Numbers issued by the country of COLOMBIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-COM

Identifier of the namespace for Passport Numbers issued by the country of COMOROS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CPV

Identifier of the namespace for Passport Numbers issued by the country of CAPE VERDE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CRI

Identifier of the namespace for Passport Numbers issued by the country of COSTA RICA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CUB

Identifier of the namespace for Passport Numbers issued by the country of CUBA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CXR

Identifier of the namespace for Passport Numbers issued by the country of CHRISTMAS ISLAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CYM

Identifier of the namespace for Passport Numbers issued by the country of CAYMAN ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CYP

Identifier of the namespace for Passport Numbers issued by the country of CYPRUS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-CZE

Identifier of the namespace for Passport Numbers issued by the country of CZECH REPUBLIC. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-DEU

Identifier of the namespace for Passport Numbers issued by the country of GERMANY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-DJI

Identifier of the namespace for Passport Numbers issued by the country of DJIBOUTI. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-DMA

Identifier of the namespace for Passport Numbers issued by the country of DOMINICA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-DNK

Identifier of the namespace for Passport Numbers issued by the country of DENMARK. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-DOM

Identifier of the namespace for Passport Numbers issued by the country of DOMINICAN REPUBLIC. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-DZA

Identifier of the namespace for Passport Numbers issued by the country of ALGERIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ECU

Identifier of the namespace for Passport Numbers issued by the country of ECUADOR. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-EGY

Identifier of the namespace for Passport Numbers issued by the country of EGYPT. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ERI

Identifier of the namespace for Passport Numbers issued by the country of ERITREA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ESH

Identifier of the namespace for Passport Numbers issued by the country of WESTERN SAHARA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ESP

Identifier of the namespace for Passport Numbers issued by the country of SPAIN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-EST

Identifier of the namespace for Passport Numbers issued by the country of ESTONIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ETH

Identifier of the namespace for Passport Numbers issued by the country of ETHIOPIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-FIN

Identifier of the namespace for Passport Numbers issued by the country of FINLAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-FJI

Identifier of the namespace for Passport Numbers issued by the country of FIJI. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-FLK

Identifier of the namespace for Passport Numbers issued by the country of FALKLAND ISLANDS (MALVINAS). Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-FRA

Identifier of the namespace for Passport Numbers issued by the country of FRANCE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-FRO

Identifier of the namespace for Passport Numbers issued by the country of FAROE ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-FSM

Identifier of the namespace for Passport Numbers issued by the country of MICRONESIA, FEDERATED STATES OF. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GAB

Identifier of the namespace for Passport Numbers issued by the country of GABON. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GBR

Identifier of the namespace for Passport Numbers issued by the country of UNITED KINGDOM. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GEO

Identifier of the namespace for Passport Numbers issued by the country of GEORGIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GGY

Identifier of the namespace for Passport Numbers issued by the country of GUERNSEY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GHA

Identifier of the namespace for Passport Numbers issued by the country of GHANA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GIB

Identifier of the namespace for Passport Numbers issued by the country of GIBRALTAR. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GIN

Identifier of the namespace for Passport Numbers issued by the country of GUINEA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GLP

Identifier of the namespace for Passport Numbers issued by the country of GUADELOUPE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GMB

Identifier of the namespace for Passport Numbers issued by the country of GAMBIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GNB

Identifier of the namespace for Passport Numbers issued by the country of GUINEA-BISSAU. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GNQ

Identifier of the namespace for Passport Numbers issued by the country of EQUATORIAL GUINEA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GRC

Identifier of the namespace for Passport Numbers issued by the country of GREECE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GRD

Identifier of the namespace for Passport Numbers issued by the country of GRENADA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GRL

Identifier of the namespace for Passport Numbers issued by the country of GREENLAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GTM

Identifier of the namespace for Passport Numbers issued by the country of GUATEMALA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GUF

Identifier of the namespace for Passport Numbers issued by the country of FRENCH GUIANA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GUM

Identifier of the namespace for Passport Numbers issued by the country of GUAM. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-GUY

Identifier of the namespace for Passport Numbers issued by the country of GUYANA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-HKG

Identifier of the namespace for Passport Numbers issued by the country of HONG KONG. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-HMD

Identifier of the namespace for Passport Numbers issued by the country of HEARD ISLAND AND MCDONALD ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-HND

Identifier of the namespace for Passport Numbers issued by the country of HONDURAS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-HRV

Identifier of the namespace for Passport Numbers issued by the country of CROATIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-HTI

Identifier of the namespace for Passport Numbers issued by the country of HAITI. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-HUN

Identifier of the namespace for Passport Numbers issued by the country of HUNGARY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-IDN

Identifier of the namespace for Passport Numbers issued by the country of INDONESIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-IMM

Identifier of the namespace for Passport Numbers issued by the country of ISLE OF MAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-IND

Identifier of the namespace for Passport Numbers issued by the country of INDIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-IOT

Identifier of the namespace for Passport Numbers issued by the country of BRITISH INDIAN OCEAN TERRITORY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-IRL

Identifier of the namespace for Passport Numbers issued by the country of IRELAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-IRN

Identifier of the namespace for Passport Numbers issued by the country of IRAN (ISLAMIC REPUBLIC OF). Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-IRQ

Identifier of the namespace for Passport Numbers issued by the country of IRAQ. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ISL

Identifier of the namespace for Passport Numbers issued by the country of ICELAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ISR

Identifier of the namespace for Passport Numbers issued by the country of ISRAEL. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ITA

Identifier of the namespace for Passport Numbers issued by the country of ITALY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-JAM

Identifier of the namespace for Passport Numbers issued by the country of JAMAICA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-JEY

Identifier of the namespace for Passport Numbers issued by the country of JERSEY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-JOR

Identifier of the namespace for Passport Numbers issued by the country of JORDAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-JPN

Identifier of the namespace for Passport Numbers issued by the country of JAPAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-KAZ

Identifier of the namespace for Passport Numbers issued by the country of KAZAKHSTAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-KEN

Identifier of the namespace for Passport Numbers issued by the country of KENYA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-KGZ

Identifier of the namespace for Passport Numbers issued by the country of KYRGYZSTAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-KHM

Identifier of the namespace for Passport Numbers issued by the country of CAMBODIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-KIR

Identifier of the namespace for Passport Numbers issued by the country of KIRIBATI. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-KNA

Identifier of the namespace for Passport Numbers issued by the country of SAINT KITTS AND NEVIS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-KOR

Identifier of the namespace for Passport Numbers issued by the country of KOREA, REPUBLIC OF. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-KWT

Identifier of the namespace for Passport Numbers issued by the country of KUWAIT. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LAO

Identifier of the namespace for Passport Numbers issued by the country of LAO PEOPLE’S DEMOCRATIC REPUBLIC. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LBN

Identifier of the namespace for Passport Numbers issued by the country of LEBANON. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LBR

Identifier of the namespace for Passport Numbers issued by the country of LIBERIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LBY

Identifier of the namespace for Passport Numbers issued by the country of LIBYAN ARAB JAMAHIRIYA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LCA

Identifier of the namespace for Passport Numbers issued by the country of SAINT LUCIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LIE

Identifier of the namespace for Passport Numbers issued by the country of LIECHTENSTEIN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LKA

Identifier of the namespace for Passport Numbers issued by the country of SRI LANKA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LSO

Identifier of the namespace for Passport Numbers issued by the country of LESOTHO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LTU

Identifier of the namespace for Passport Numbers issued by the country of LITHUANIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LUX

Identifier of the namespace for Passport Numbers issued by the country of LUXEMBOURG. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-LVA

Identifier of the namespace for Passport Numbers issued by the country of LATVIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MAC

Identifier of the namespace for Passport Numbers issued by the country of MACAO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MAF

Identifier of the namespace for Passport Numbers issued by the country of SAINT MARTIN (FRENCH PART). Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MAR

Identifier of the namespace for Passport Numbers issued by the country of MOROCCO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MCO

Identifier of the namespace for Passport Numbers issued by the country of MONACO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MDA

Identifier of the namespace for Passport Numbers issued by the country of MOLDOVA, REPUBLIC OF. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MDG

Identifier of the namespace for Passport Numbers issued by the country of MADAGASCAR. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MDV

Identifier of the namespace for Passport Numbers issued by the country of MALDIVES. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MEX

Identifier of the namespace for Passport Numbers issued by the country of MEXICO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MHL

Identifier of the namespace for Passport Numbers issued by the country of MARSHALL ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MKD

Identifier of the namespace for Passport Numbers issued by the country of MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MLI

Identifier of the namespace for Passport Numbers issued by the country of MALI. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MLT

Identifier of the namespace for Passport Numbers issued by the country of MALTA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MMR

Identifier of the namespace for Passport Numbers issued by the country of MYANMAR. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MNE

Identifier of the namespace for Passport Numbers issued by the country of MONTENEGRO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MNG

Identifier of the namespace for Passport Numbers issued by the country of MONGOLIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MNP

Identifier of the namespace for Passport Numbers issued by the country of NORTHERN MARIANA ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MOZ

Identifier of the namespace for Passport Numbers issued by the country of MOZAMBIQUE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MRT

Identifier of the namespace for Passport Numbers issued by the country of MAURITANIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MSR

Identifier of the namespace for Passport Numbers issued by the country of MONTSERRAT. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MTQ

Identifier of the namespace for Passport Numbers issued by the country of MARTINIQUE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MUS

Identifier of the namespace for Passport Numbers issued by the country of MAURITIUS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MWI

Identifier of the namespace for Passport Numbers issued by the country of MALAWI. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MYS

Identifier of the namespace for Passport Numbers issued by the country of MALAYSIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-MYT

Identifier of the namespace for Passport Numbers issued by the country of MAYOTTE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NAM

Identifier of the namespace for Passport Numbers issued by the country of NAMIBIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NCL

Identifier of the namespace for Passport Numbers issued by the country of NEW CALEDONIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NER

Identifier of the namespace for Passport Numbers issued by the country of NIGER. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NFK

Identifier of the namespace for Passport Numbers issued by the country of NORFOLK ISLAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NGA

Identifier of the namespace for Passport Numbers issued by the country of NIGERIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NIC

Identifier of the namespace for Passport Numbers issued by the country of NICARAGUA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NIU

Identifier of the namespace for Passport Numbers issued by the country of NIUE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NLD

Identifier of the namespace for Passport Numbers issued by the country of NETHERLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NOR

Identifier of the namespace for Passport Numbers issued by the country of NORWAY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NPL

Identifier of the namespace for Passport Numbers issued by the country of NEPAL. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NRU

Identifier of the namespace for Passport Numbers issued by the country of NAURU. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-NZL

Identifier of the namespace for Passport Numbers issued by the country of NEW ZEALAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-OMN

Identifier of the namespace for Passport Numbers issued by the country of OMAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PAK

Identifier of the namespace for Passport Numbers issued by the country of PAKISTAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PAN

Identifier of the namespace for Passport Numbers issued by the country of PANAMA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PCN

Identifier of the namespace for Passport Numbers issued by the country of PITCAIRN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PER

Identifier of the namespace for Passport Numbers issued by the country of PERU. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PHL

Identifier of the namespace for Passport Numbers issued by the country of PHILIPPINES. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PLW

Identifier of the namespace for Passport Numbers issued by the country of PALAU. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PNG

Identifier of the namespace for Passport Numbers issued by the country of PAPUA NEW GUINEA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-POL

Identifier of the namespace for Passport Numbers issued by the country of POLAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PRI

Identifier of the namespace for Passport Numbers issued by the country of PUERTO RICO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PRK

Identifier of the namespace for Passport Numbers issued by the country of KOREA, DEMOCRATIC PEOPLE’S REPUBLIC OF. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PRT

Identifier of the namespace for Passport Numbers issued by the country of PORTUGAL. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PRY

Identifier of the namespace for Passport Numbers issued by the country of PARAGUAY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PSE

Identifier of the namespace for Passport Numbers issued by the country of PALESTINIAN TERRITORY, OCCUPIED. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-PYF

Identifier of the namespace for Passport Numbers issued by the country of FRENCH POLYNESIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-QAT

Identifier of the namespace for Passport Numbers issued by the country of QATAR. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-REU

Identifier of the namespace for Passport Numbers issued by the country of REUNION. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ROU

Identifier of the namespace for Passport Numbers issued by the country of ROMANIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-RUS

Identifier of the namespace for Passport Numbers issued by the country of RUSSIAN FEDERATION. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-RWA

Identifier of the namespace for Passport Numbers issued by the country of RWANDA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SAU

Identifier of the namespace for Passport Numbers issued by the country of SAUDI ARABIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SDN

Identifier of the namespace for Passport Numbers issued by the country of SUDAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SEN

Identifier of the namespace for Passport Numbers issued by the country of SENEGAL. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SGP

Identifier of the namespace for Passport Numbers issued by the country of SINGAPORE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SGS

Identifier of the namespace for Passport Numbers issued by the country of SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SHN

Identifier of the namespace for Passport Numbers issued by the country of SAINT HELENA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SJM

Identifier of the namespace for Passport Numbers issued by the country of SVALBARD AND JAN MAYEN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SLB

Identifier of the namespace for Passport Numbers issued by the country of SOLOMON ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SLE

Identifier of the namespace for Passport Numbers issued by the country of SIERRA LEONE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SLV

Identifier of the namespace for Passport Numbers issued by the country of EL SALVADOR. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SMR

Identifier of the namespace for Passport Numbers issued by the country of SAN MARINO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SOM

Identifier of the namespace for Passport Numbers issued by the country of SOMALIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SPM

Identifier of the namespace for Passport Numbers issued by the country of SAINT PIERRE AND MIQUELON. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SRB

Identifier of the namespace for Passport Numbers issued by the country of SERBIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-STP

Identifier of the namespace for Passport Numbers issued by the country of SAO TOME AND PRINCIPE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SUR

Identifier of the namespace for Passport Numbers issued by the country of SURINAME. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SVK

Identifier of the namespace for Passport Numbers issued by the country of SLOVAKIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SVN

Identifier of the namespace for Passport Numbers issued by the country of SLOVENIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SWE

Identifier of the namespace for Passport Numbers issued by the country of SWEDEN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SWZ

Identifier of the namespace for Passport Numbers issued by the country of SWAZILAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SYC

Identifier of the namespace for Passport Numbers issued by the country of SEYCHELLES. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-SYR

Identifier of the namespace for Passport Numbers issued by the country of SYRIAN ARAB REPUBLIC. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TCA

Identifier of the namespace for Passport Numbers issued by the country of TURKS AND CAICOS ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TCD

Identifier of the namespace for Passport Numbers issued by the country of CHAD. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TGO

Identifier of the namespace for Passport Numbers issued by the country of TOGO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-THA

Identifier of the namespace for Passport Numbers issued by the country of THAILAND. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TJK

Identifier of the namespace for Passport Numbers issued by the country of TAJIKISTAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TKL

Identifier of the namespace for Passport Numbers issued by the country of TOKELAU. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TKM

Identifier of the namespace for Passport Numbers issued by the country of TURKMENISTAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TLS

Identifier of the namespace for Passport Numbers issued by the country of TIMOR-LESTE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TON

Identifier of the namespace for Passport Numbers issued by the country of TONGA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TTO

Identifier of the namespace for Passport Numbers issued by the country of TRINIDAD AND TOBAGO. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TUN

Identifier of the namespace for Passport Numbers issued by the country of TUNISIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TUR

Identifier of the namespace for Passport Numbers issued by the country of TURKEY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TUV

Identifier of the namespace for Passport Numbers issued by the country of TUVALU. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TWN

Identifier of the namespace for Passport Numbers issued by the country of TAIWAN, PROVINCE OF CHINA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-TZA

Identifier of the namespace for Passport Numbers issued by the country of TANZANIA, UNITED REPUBLIC OF. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-UGA

Identifier of the namespace for Passport Numbers issued by the country of UGANDA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-UKR

Identifier of the namespace for Passport Numbers issued by the country of UKRAINE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-UMI

Identifier of the namespace for Passport Numbers issued by the country of UNITED STATES MINOR OUTLYING ISLANDS. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-URY

Identifier of the namespace for Passport Numbers issued by the country of URUGUAY. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-USA

Identifier of the namespace for Passport Numbers issued by the country of UNITED STATES. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-UZB

Identifier of the namespace for Passport Numbers issued by the country of UZBEKISTAN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-VAT

Identifier of the namespace for Passport Numbers issued by the country of HOLY SEE (VATICAN CITY STATE). Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-VCT

Identifier of the namespace for Passport Numbers issued by the country of SAINT VINCENT AND THE GRENADINES. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-VEN

Identifier of the namespace for Passport Numbers issued by the country of VENEZUELA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-VGB

Identifier of the namespace for Passport Numbers issued by the country of VIRGIN ISLANDS (BRITISH). Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-VIR

Identifier of the namespace for Passport Numbers issued by the country of VIRGIN ISLANDS (U.S.). Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-VNM

Identifier of the namespace for Passport Numbers issued by the country of VIET NAM. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-VUT

Identifier of the namespace for Passport Numbers issued by the country of VANUATU. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-WLF

Identifier of the namespace for Passport Numbers issued by the country of WALLIS AND FUTUNA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-WSM

Identifier of the namespace for Passport Numbers issued by the country of SAMOA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-YEM

Identifier of the namespace for Passport Numbers issued by the country of YEMEN. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-YUG

Identifier of the namespace for Passport Numbers issued by the country of YUGOSLAVIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ZAF

Identifier of the namespace for Passport Numbers issued by the country of SOUTH AFRICA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ZMB

Identifier of the namespace for Passport Numbers issued by the country of ZAMBIA. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/passportNumNS-ZWE

Identifier of the namespace for Passport Numbers issued by the country of ZIMBABWE. Used for the HL7 v3 data type II.root and FHIR Identifer.system values for Passport Numbers

NamingSystem/pclocd

The pan Canadian LOINC Observation Code Database (pCLOCD) is the Canadian version of the LOINC(tm) database. It was created using the LOINC(tm) records and attributes that were constrained for Canadian use and supplemented to specifically meet Canadian requirements. It contains the core LOINC(tm) attributes as required by Regenstrief copyright rules. The LOINC(tm) Component has been customized to meet Canadian requirements and is displayed as the pan Canadian Component Name. This component name is the basis for the pan Canadian Display Name. Core attributes are include both English and Canadian French. This code system contains supplemental “X” codes defined in the pCLOCD that do not yet exist in the LOINC code system.

NamingSystem/pnds

The PNDS provides standardized terms and codes for patient problems/nursing diagnoses, nursing interventions including actual or expected (goal) outcomes. The PNDS provides standardized terms and codes for nursing diagnoses (a subset of NANDA), nursing interventions and outcomes. The outcomes and interventions are in a relational database. The PNDS intervention and outcome statements are attached in an Access Database. The NANDA diagnoses in the PNDS have already been registered by HL7.

NamingSystem/presentOnAdmission

This code system consists of Present on Admission (POA) indicators which are assigned to the principal and secondary diagnoses (as defined in Section II of the Official Guidelines for Coding and Reporting) and the external cause of injury codes to indicate the presence or absence of the diagnosis at the time of inpatient admission.

NamingSystem/rcFB

The Read Codes Four Byte Set consists of 4 alphanumeric characters. This version contains approximately 40,000 codes arranged in a hierarchical structure. Top level hierarchy sections: Disorders Findings Surgical procedures Investigations Occupations Drugs

NamingSystem/rcV2

The Read Codes Version 2 contains over 70,000 coded concepts arranged in a hierarchical structure. Top level hierarchy sections: Disorders Findings Surgical procedures Investigations Occupations Drugs

NamingSystem/read-Codes

Clinical Terms Version 3 contains over 200,000 coded concepts arranged in a sub-type hierarchical structure. Top level hierarchy sections: Disorders Findings Morphology Surgical procedures Regimes & therapies Investigations Stages & scales Occupations Organisms Units Drugs Appliances & equipment

NamingSystem/sic

The Standard Industrial Classification Codes that appear in a company’s disseminated EDGAR filings indicate the company’s type of business. These codes are also used in the Division of Corporation Finance as a basis for assigning review responsibility for the company’s filings. For example, a company whose business was Metal Mining (SIC 1000) would have its filings reviewed by staffers in A/D Office 4. Note that this code system is published both by the US Bureau of Labor Statistics (BLS) at http://www.sec.gov/info/edgar/siccodes.htm, and by the US Occupational & Safety Health Administration (OSHA) at http://www.osha.gov/pls/imis/sic_manual.html.

NamingSystem/snm

Systemized Nomenclature in Medicine (SNOMED)

NamingSystem/soc

The Standard Occupational Classification (SOC) system is used by Federal statistical agencies to classify workers into occupational categories for the purpose of collecting, calculating, or disseminating data. All workers are classified into one of over 820 occupations according to their occupational definition. To facilitate classification, occupations are combined to form 23 major groups, 96 minor groups, and 449 broad occupations. Each broad occupation includes detailed occupation(s) requiring similar job duties, skills, education, or experience. This code system replaced the older FIPSPUB92, which was withdrawn in February 2005.

NamingSystem/ssn

United States Social Security Number (SSN). Assigned by the U.S. Social Security Administration. Note: IRS assigned ITINs are often used as drop-ins for social security numbers. The SSN is represented in resources with dashes removed. See http://www.ssa.gov/.

NamingSystem/standardBillingUnit

NCPDP standard product billing codes of NCPDP field Unit of Measure (600-28). This billing code is assigned per product, placed in the Structured Product Label, and used in the pharmacy billing processing for consistent billing unit.

NamingSystem/umls

UMLS codes as CUIs making up the values in a coding system. More information may be found at http://www.nlm.nih.gov/research/umls/

NamingSystem/uri

As defined by RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt)(with many schemes defined in many RFCs). For OIDs and UUIDs, use the URN form (urn:oid:(note: lowercase) and urn:uuid:). See http://www.ietf.org/rfc/rfc3001.txt and http://www.ietf.org/rfc/rfc4122.txt This oid is used as an identifier II.root to indicate the the extension is an absolute URI (technically, an IRI). Typically, this is used for OIDs and GUIDs. Note that when this OID is used with OIDs and GUIDs, the II.extension should start with urn:oid or urn:uuid: Note that this OID is created to aid with interconversion between CDA and FHIR - FHIR uses urn:ietf:rfc:3986 as equivalent to this OID. URIs as identifiers appear more commonly in FHIR. This OID may also be used in CD.codeSystem.

NamingSystem/url

Universal Resource Locator (URL) schemes Currently there is no single authority for URL schemes. The authority for URL scheme assignments clearly lies within IANA or W3C and it is likely that a formal URL/URI assigning authority will be formed soon.

NamingSystem/usEPAsrs

The United States Environmental Protection Agency’s (US EPA) Substance Registry System (SRS) provides information on substances and how they are represented in US environmental statutes, in US EPA information systems, and in information systems owned by other organizations. The SRS provides standardized identification for each substance to improve data quality in US EPA systems and elsewhere.

NamingSystem/usb-address-identifier

A USB device that is plugged in identifies itself by its VID/PID combination. A VID is a 16-bit vendor number (Vendor ID). A PID is a 16-bit product number (Product ID). A host uses the VID/PID combination to find the drivers (if any) that are to be used for the USB device. For this to work, the VID/PID combination must be unique, in the sense that each USB device with the same VID/PID will use the same driver. So, whenever you need a specific driver for your USB product, you will need a unique VID/PID for that product. In that sense, the VID/PID combination does not really serve as a truly unique identifier of a single device instance. It is, however, useful to know for medical devices that communicate using USB.

NamingSystem/v3-DCM

Coded concepts defined in PS 3.16 Digital Imaging and Communications in Medicine (DICOM): Part 16: Content Mapping Resource, Annex D: DICOM Controlled Terminology Definition

NamingSystem/v3-HealthcareProviderTaxonomyHIPAA

This HL7 Version 3 code system stub was created many years ago for the convenience of the HL7 community using the RIM; it has been determined that there is licensure issue with the republishing of the content for this code system by HL7, as well as erroneous and incomplete content. Content should be accessed using the links at nucc.org

NamingSystem/v3-PeriodicIntervalOfTimeAbbreviation
NamingSystem/v3-ProcedureMethod

Identifies the technique used to perform a procedure.

NamingSystem/v3-SpecialArrangement

A code indicating the type of special arrangements provided for a patient encounter (e.g., wheelchair, stretcher, interpreter, attendant, seeing eye dog). For encounters in intention moods, this information can be used to identify special arrangements that will need to be made for the incoming patient.

NamingSystem/v3-UnitOfMeasurePrefix

Decimal multipliers for units of measure Deprecation Comment: This code system was created in error. Implementations should use the code system UCUM with OID 2.16.840.1.113883.6.8 Note that due to some tooling issues, some of the synonym codes that differed only in case (upper/lower) were not being assembled into MIF correctly, therefore they have been removed as a workaround for these tooling issues. This should have limited effect as this system has been deprecated for 8 years, and retired for 4 years, and will be removed soon.

NamingSystem/v3-WC

WHO ATC

NamingSystem/v3-brazilianProcedureCodesSUS

Brazilian Procedure Codes used in the National Health System

NamingSystem/v3-cci

CCI (Canadian Classification of Health Interventions) was developed by CIHI to accompany ICD-10-CA. It was designed to be service-provider and service-setting neutral and can be used comprehensively throughout Canada’s health systems. CCI classifies a broad range of interventions including therapeutic and diagnostic interventions and other health care interventions, such as assistance with activities of daily living, environmental assessments and counselling.

NamingSystem/v3-dbSNP

In collaboration with the National Human Genome Research Institute, The National Center for Biotechnology Information has established the dbSNP database to serve as a central repository for both single base nucleotide substitutions and short deletion and insertion polymorphisms. The entries in the dbSNP database can be used with the HL7 coded data type. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model, dbSNP entries can be used to as the observation values for DNA sequence variation identifiers. For example, OBX|1|CWE|48004-6^DNA Sequence Variation Identifier^LN||rs55538123^^dbSNP Versioning is identified by the build id. A new build is released approximately every six months or every year. The latest build id is 130, and the dbSNP web query for built 130 was available on Apr 30, 2009. dbSNP is a database that can be used freely by the public. More information may be fouond at: http://www.ncbi.nlm.nih.gov/projects/SNP/

NamingSystem/v3-fda-FCE

Entered erroneously - do not use. The correct OID for this identifier system is 2.16.840.1.113883.4.345.

NamingSystem/v3-fda-FFRN

Entered in error originally - do not use. Correct OID for this item is 2.16.840.1.113883.4.344.

NamingSystem/v3-hc-aic

Foreign key for the Active Ingredient Table that relates active ingredients to specific products. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/drug-products/drug-product-database/read-file-drug-product-database-data-extract.htmll

NamingSystem/v3-hc-aigc

Part of the active ingredient code number starting at position 3 and ending at position 7. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/drug-products/drug-product-database/terminology.html

NamingSystem/v3-hc-aign

The AIG number is a 10 digit number that identifies products that have the same active ingredient(s) and ingredient strength(s). The AIG is comprised of three portions:

  • the first portion (2 digits) identifies the number of active ingredients
  • the second portion(5 digits) identifies the unique groups of active ingredients(s);
  • the last portion (3 digits) identifies the active ingredient group strength. The strength group has a tolerance of -2% to +10%. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/drug-products/drug-product-database/terminology.html
NamingSystem/v3-hc-npn

Natural Product Number (NPN) is an eight (8) digit numerical code assigned to each natural health product approved to be marketed under the Natural Health Products Regulations. A Homeopathic Medicine Number (DIN-HM) is an eight (8) digit numerical code assigned to each homeopathic medicine approved to be marketed under the Natural Health Products Regulations. Further information about this Code System can be found at https://www.canada.ca/en/health-canada/services/drugs-health-products/natural-non-prescription/applications-submissions/product-licensing/licensed-natural-health-products-database.html

NamingSystem/v3-hgnc

The HGNC is responsible for approving unique symbols and names for human loci, including protein coding genes, ncRNA genes and pseudogenes, to allow unambiguous scientific communication. For each known human gene we approve a gene name and symbol (short-form abbreviation). All approved symbols are stored in the HGNC database,www.genenames.org, a curated online repository of HGNC-approved gene nomenclature, gene groups and associated resources including links to genomic, proteomic and phenotypic information. Each symbol is unique and we ensure that each gene is only given one approved gene symbol. It is necessary to provide a unique symbol for each gene so that we and others can talk about them, and this also facilitates electronic data retrieval from publications and databases. HGNC gene symbols can be used with the HL7 coded data type. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model Implementation Guide, HGNC gene symbols can be used to as the observation values for gene identifiers. For example, OBX|1|CWE|48018-6^Gene identifier^||BRCA1^HGNC| Versioning Information: The version of the HGNC database is reported using the last updated date and timestamp. The last updated date and timestamp is posted on the main HGNC Search screen in the format like “Monday March 30 23:00:56 2009”. HGNC is updated daily. HGNC is a free database for the public. Please see https://www.genenames.org/ for more info.

NamingSystem/v3-hgvs

HGVS nomenclatures are the guidelines for mutation nomenclature made by the Human Genome Variation Society. HGVS nomenclature can be used with the HL7 coded data type (code data type that accepts expression data, or a coded expression data type). This coded data type should be able to distinguish expressions in HGVS nomenclature from coded concepts. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model, HGVS nomenclature can be used to as the observation values for DNA sequence variations. For example, OBX|1|CWE|48004-6^DNA Sequence Variation^LN||c.1129C>T^^HGVS| Versioning information: The HGVS nomenclature for the description of sequence variants was last modified Feb 20, 2008. The HGVS nomenclature for the description of protein sequence variants was last modified May 12, 2007. The HGVS nomenclature for the description of DNA sequence variants was last modified June 15, 2007 The HGVS nomenclature for the description of RNA sequence variants was last modified May 12, 2007 HGVS nomenclatures can be used freely by the public.

NamingSystem/v3-icpc2E

International Classification of Primary Care / prepared by the Classification Committee of the World Organization of National Colleges, Academies and Academic Associations of General Practitioners/Family Physicians (WONCA), known more briefly as the World

NamingSystem/v3-iso3166-1

Identifies the coding system published in the ISO 3166-1 Standard for Country codes. This standard is released periodically, and a new OID will be assigned by ISO for new editions.

NamingSystem/v3-loinc

LOINC provides a set of universal names and ID codes for identifying laboratory and clinical test results.1,2 LOINC facilitates the exchange and pooling of results, such as blood hemoglobin, serum potassium, or vital signs, for clinical care, outcomes management, and research. LOINC’s universal identifiers (names and codes) can be used in the context of order and observation exchanges between information systems that use syntax standards such as HL73, CEN TC251, ISO TC215, ASTM4, and DICOM. Specifically, the identifier can be used as the coded value for an observation in any other standard that uses the observation/observation value paradigm, whether messages, documents, application programming interface (API), etc. For example, LOINC codes are used widely in the OBX segment Observation Identifier field (OBX-3) of an ORU HL7 (HL7 version 2.x or ASTM 1238-9410) message that may be sent between a Clinical Laboratory Information Management Systems (LIMS) and Electronic Health Record Systems (EHR).5, 6 In this way, LOINC codes provide universal identifiers that allow the exchange of clinical data between heterogeneous computing environments.

NamingSystem/v3-lrg

In collaboration with NCBI, the European Bioinformatics Institute (EBI) is developing the Locus Reference Genomic Sequences (LRG) database, which is a database of reference sequences. LRG is a system for providing a genomic DNA sequence representation of a single gene that is idealized, has a permanent ID (with no versioning), and core content that never changes. LRG is not a nomenclature system. More than one LRG could be created for a region of interest, should that need arise. Additional annotations will be present that may change with time (each item carrying its own date stamp), so that the latest ancillary knowledge about a gene is directly available. In other words, an LRG sequence and its core annotation are not meant to represent current biology knowledge, but to provide a standard for reporting variation in a stable coordinate system. The combination of the LRG plus the updatable-annotation layer will be used to support the biological interpretation of variants. LRG identifiers can be used with the HL7 coded data type (code data type that accepts expression data, or a coded expression data type). This coded data type will be gene symbols can be used with the HL7 coded data type. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model, LRG identifiers can be used to as the observation values for Genomic Reference Sequence Identifier (LOINC code: 48013-7). LRG is a database that can be used freely by the public.

NamingSystem/v3-mdc

The nomenclature relates primarily to vital signs monitoring, but also includes semantics of other medical devices that are commonly used in acute care settings. There are multiple coding partitions each of which has a systematic name consisting of a set of base concepts and differentiating criteria.

NamingSystem/v3-mime

IETF MIME media types

NamingSystem/v3-nciThesaurus

NCI Thesaurus NCI Thesaurus is a biomedical thesaurus created specifically to meet the needs of the cancer research community, especially those engaged in translational research NCI Thesaurus is produced by the NCI Enterprise Vocabulary Services project. The NCI Thesaurus is provided under an open content license.

NamingSystem/v3-ndc

National drug codes

NamingSystem/v3-nuccProviderCodes

The Provider Taxonomy Code List is published (released) twice a year on July 1st and January 1st. The July publication is effective for use on October 1st and the January publication is effective for use on April 1st. The time between the publication release and the effective date is considered an implementation period to allow providers, payers and vendors an opportunity to incorporate any changes into their systems. This listing includes Active codes approved for use effective April 1st, 2003, version 3.0; and codes that are New and approved for use effective October 1st, 2003, version 3.1. It was identified that there is an IP licensure issue with the republishing of the content for this code system by HL7, so the content was removed as of the July 2016 Harmonization cycle release. This external code system content may be accessed from the web page located at http://www.nucc.org/index.php/code-sets-mainmenu-41/provider-taxonomy-mainmenu-40. Multiple formats and means of accessing the content are available from this page.

NamingSystem/v3-policyHolderRole

This vocabulary is defined by Implementation Guide for CDA Release 2 - Level 1 - Care Record Summary (US realm). It describes roles recognized through the issuance of an insurance policy to a policyholder who a relationship with the covered party, such as spouse, child, etc. This vocabulary is essentially an inversion of the role relations of the HL7 CoverageRoleType vocabulary. It provides more detailed roles with respect to the underwriter (the scoping organization) for those participants in the policyholder role for a patient. Open Issue: The code values for this coding system must be extracted from the CDA documentation and brought forward through Harmonization for instantiation in this repository.

NamingSystem/v3-refSeq

The Reference Sequence (RefSeq) is one of the NCBI projects, the RefSeq collection aims to provide a comprehensive, integrated, non-redundant, well-annotated set of sequences, including genomic DNA, transcripts, and proteins. ReqSeq is accessible via BLAST, Entrez, and the NCBI FTP site. Information is also available in Entrez Genomes and Entrez Gene, and for some genomes additional information is available in the Map Viewer. RefSeq entries can be used with the HL7 coded data type. For example, in the HL7 messages specified according to the HL7 V2 Clinical Genomics Fully LOINC-Qualified Genetic Variation Model, RefSeq entries can be used to as the observation values for genomic reference sequence identifiers (LOINC #: 48013-7). More information may be found at: http://www.ncbi.nlm.nih.gov/RefSeq Versioning informaiton: The latest release of RefSeq was released on May 13, 2009 with the release number of 35. RefSeq generates new releases roughly every two months. The dates of the three previous releases were: Release 34, March 12, 2009 Release 33, January 20, 2009 Release 32, November 17, 2008 RefSeq is a free database for the public.

NamingSystem/v3-rxNorm

RxNorm provides normalized names for clinical drugs and links its names to many of the drug vocabularies commonly used in pharmacy management and drug interaction software, including those of First Databank, Micromedex, and Gold Standard Drug Database. By providing links between these vocabularies, RxNorm can mediate messages between systems not using the same software and vocabulary. RxNorm now includes the United States Pharmacopeia (USP) Compendial Nomenclature from the United States Pharmacopeial Convention. USP is a cumulative data set of all Active Pharmaceutical Ingredients (API).

NamingSystem/v3-scpqual

SCPQUAL is used to encode the degree or educational rank of a healthcare provider credential as defined by the various Royal Canadian Professional Medical Collages. It is also supports the encoding “Expertise type” in the pan-Canadian version 3 messages

NamingSystem/v3-scptype

SCPTYPE is used to encode and categorize an entity that delivers health care in an expected and professional manner to an entity in need of health care services. Examples: Registered Nurse, Chiropractor, Physician, Custodial Care Clinic. Allows for the implementation of role-based access to clinical functions and data. Provisioning of clinical services is based on the role that a provider may play in the health system.

NamingSystem/v3-sctemp

These pan-Canadian codes are maintained in circumstances where the desired code is not yet available in another code system (HL7 code systems, LOINC, SNOMED, etc.) In general, the codes will be deprecated once an equivalent code is available in the preferred code system. The SCTEMP is a transitional or temporary CodeSystem supported and maintained by Canada Health Infoway. It houses the code(s) required and accepted by Canadian implementers if the implementation cannot wait for the code to be harmonized with the international terminology authority. The SCTEMP CodeSystem also served as a source for tracking submissions that need to be made to the various terminology authorities. The SCTEMP CodeSystem applies to HL7, non-SNOMED CT and non-LOINC /pCLOCD used within pan-Canadian specifications. The SCTEMP is not used for the Unified Code for Units of Measure (UCUM).

NamingSystem/v3-snomed-CT

SNOMED CT is a core clinical healthcare terminology that contains concepts with unique meanings and formal logic based definitions organized into hierarchies.

NamingSystem/v3-ucum

The Unified Code for Units of Measure (UCUM) is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans. A typical application of The Unified Code for Units of Measure are electronic data interchange (EDI) protocols, but there is nothing that prevents it from being used in other types of machine communication.

NamingSystem/whoARTfl

WHO Adverse Drug Reaction Terminology (WHOART). Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. This branch node OID contains identifiers for the different foreign language versions of this terminology. For more information, see http://www.umc-products.com/graphics/3149.pdf

NamingSystem/whoFRE

WHO Adverse Drug Reaction Terminology (WHOART). French Translation. Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. For more information, see http://www.umc-products.com/graphics/3149.pdf

NamingSystem/whoGER

WHO Adverse Drug Reaction Terminology (WHOART). German Translation. Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. For more information, see http://www.umc-products.com/graphics/3149.pdf

NamingSystem/whoPOR

WHO Adverse Drug Reaction Terminology (WHOART). Portuguese Translation. Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. For more information, see http://www.umc-products.com/graphics/3149.pdf

NamingSystem/whoSPA

WHO Adverse Drug Reaction Terminology (WHOART). Spanish Translation. Uppsala (Sweden): WHO Collaborating Centre for International Drug Monitoring, 1997. For more information, see http://www.umc-products.com/graphics/3149.pdf

NamingSystem/zigbee-address-identifier

The ZigBee Address is a unique 64-bit identifier assigned to each ZigBee device by the manufacturer. ZigBee Addresses are usually displayed as 8 bytes written in hexadecimal and separated by colons (example - DF:3B:00:11:22:33:FF:EE). They are an essential part of ZigBee-based protocols. The most-significant 24 bits of the ZigBee address is the so-called Organizationally Unique Identifier (OUI). It can be used to determine the manufacturer of a device. OUI prefixes are assigned by the Institute of Electrical and Electronics Engineers (IEEE). An EUI (Extended Unique Identifier) is generally made from an OUI and thus a ZigBee Address is also an EUI-64. When a ZigBee device joins a network it is assigned an additional 16-bit address sometimes referred to as its network address. This address is different from the 64-bit ZigBee address and is dynamic.

Other

These are resources that are used within this implementation guide that do not fit into one of the other categories.

CDA Rendering Manifest
Code System Identification Records Manifest
Deprecated Code Systems Rendering Manifest
External Code System Metadata Records Manifest
Externals With Complete Content Manifest
Externals With Content Manifest
FHIR Normative Manifest
FHIR Rendering Manifest
Identifier Systems Manifest
Retired Code System Fragments Manifest
Retired Code System Identification Records Manifest
Retired Code System Metadata Records Manifest
Retired Manifest
Retired Manifest
Unified Rendering Manifest
V2 Publishing Manifest
V2 Rendering Manifest
V3 Publishing Manifest
V3 Rendering Manifest