001package org.hl7.fhir.dstu3.model.codesystems; 002 003/* 004 Copyright (c) 2011+, HL7, Inc. 005 All rights reserved. 006 007 Redistribution and use in source and binary forms, with or without modification, 008 are permitted provided that the following conditions are met: 009 010 * Redistributions of source code must retain the above copyright notice, this 011 list of conditions and the following disclaimer. 012 * Redistributions in binary form must reproduce the above copyright notice, 013 this list of conditions and the following disclaimer in the documentation 014 and/or other materials provided with the distribution. 015 * Neither the name of HL7 nor the names of its contributors may be used to 016 endorse or promote products derived from this software without specific 017 prior written permission. 018 019 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND 020 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 021 WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 022 IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, 023 INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 024 NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR 025 PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 026 WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 027 ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 028 POSSIBILITY OF SUCH DAMAGE. 029 030*/ 031 032// Generated on Mon, Apr 17, 2017 17:38-0400 for FHIR v3.0.1 033 034 035import org.hl7.fhir.exceptions.FHIRException; 036 037public enum V3ObservationValue { 038 039 /** 040 * 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. 041 */ 042 _ACTCOVERAGEASSESSMENTOBSERVATIONVALUE, 043 /** 044 * 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. 045 */ 046 _ACTFINANCIALSTATUSOBSERVATIONVALUE, 047 /** 048 * Codes specifying asset indicators used to assess or establish eligibility for coverage under a policy or program. 049 */ 050 ASSET, 051 /** 052 * Indicator of annuity ownership or status as beneficiary. 053 */ 054 ANNUITY, 055 /** 056 * Indicator of real property ownership, e.g., deed or real estate contract. 057 */ 058 PROP, 059 /** 060 * Indicator of retirement investment account ownership. 061 */ 062 RETACCT, 063 /** 064 * Indicator of status as trust beneficiary. 065 */ 066 TRUST, 067 /** 068 * Code specifying income indicators used to assess or establish eligibility for coverage under a policy or program; e.g., pay or pension check, child support payments received or provided, and taxes paid. 069 */ 070 INCOME, 071 /** 072 * Indicator of child support payments received or provided. 073 */ 074 CHILD, 075 /** 076 * Indicator of disability income replacement payment. 077 */ 078 DISABL, 079 /** 080 * Indicator of investment income, e.g., dividend check, annuity payment; real estate rent, investment divestiture proceeds; trust or endowment check. 081 */ 082 INVEST, 083 /** 084 * Indicator of paid employment, e.g., letter of hire, contract, employer letter; copy of pay check or pay stub. 085 */ 086 PAY, 087 /** 088 * Indicator of retirement payment, e.g., pension check. 089 */ 090 RETIRE, 091 /** 092 * Indicator of spousal or partner support payments received or provided; e.g., alimony payment; support stipulations in a divorce settlement. 093 */ 094 SPOUSAL, 095 /** 096 * Indicator of income supplement, e.g., gifting, parental income support; stipend, or grant. 097 */ 098 SUPPLE, 099 /** 100 * Indicator of tax obligation or payment, e.g., statement of taxable income. 101 */ 102 TAX, 103 /** 104 * Codes specifying living expense indicators used to assess or establish eligibility for coverage under a policy or program. 105 */ 106 LIVEXP, 107 /** 108 * Indicator of clothing expenses. 109 */ 110 CLOTH, 111 /** 112 * Indicator of transportation expenses. 113 */ 114 FOOD, 115 /** 116 * Indicator of health expenses; including medication costs, health service costs, financial participations, and health coverage premiums. 117 */ 118 HEALTH, 119 /** 120 * Indicator of housing expense, e.g., household appliances, fixtures, furnishings, and maintenance and repairs. 121 */ 122 HOUSE, 123 /** 124 * Indicator of legal expenses. 125 */ 126 LEGAL, 127 /** 128 * Indicator of mortgage amount, interest, and payments. 129 */ 130 MORTG, 131 /** 132 * Indicator of rental or lease payments. 133 */ 134 RENT, 135 /** 136 * Indicator of transportation expenses. 137 */ 138 SUNDRY, 139 /** 140 * Indicator of transportation expenses, e.g., vehicle payments, vehicle insurance, vehicle fuel, and vehicle maintenance and repairs. 141 */ 142 TRANS, 143 /** 144 * Indicator of transportation expenses. 145 */ 146 UTIL, 147 /** 148 * 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. 149 */ 150 ELSTAT, 151 /** 152 * Indicator of adoption. 153 */ 154 ADOPT, 155 /** 156 * Indicator of birth. 157 */ 158 BTHCERT, 159 /** 160 * Indicator of creditable coverage. 161 */ 162 CCOC, 163 /** 164 * Indicator of driving status. 165 */ 166 DRLIC, 167 /** 168 * Indicator of foster child status. 169 */ 170 FOSTER, 171 /** 172 * Indicator of status as covered member under a policy or program, e.g., member id card or coverage document. 173 */ 174 MEMBER, 175 /** 176 * Indicator of military status. 177 */ 178 MIL, 179 /** 180 * Indicator of marriage status. 181 */ 182 MRGCERT, 183 /** 184 * Indicator of citizenship. 185 */ 186 PASSPORT, 187 /** 188 * Indicator of student status. 189 */ 190 STUDENRL, 191 /** 192 * 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. 193 */ 194 HLSTAT, 195 /** 196 * Indication of disability. 197 */ 198 DISABLE, 199 /** 200 * Indication of drug use. 201 */ 202 DRUG, 203 /** 204 * Indication of IV drug use . 205 */ 206 IVDRG, 207 /** 208 * Non-clinical report of pregnancy. 209 */ 210 PGNT, 211 /** 212 * Code specifying observations related to living dependency, such as dependent upon spouse for activities of daily living. 213 */ 214 LIVDEP, 215 /** 216 * Continued living in private residence requires functional and health care assistance from one or more relatives. 217 */ 218 RELDEP, 219 /** 220 * Continued living in private residence requires functional and health care assistance from spouse or life partner. 221 */ 222 SPSDEP, 223 /** 224 * Continued living in private residence requires functional and health care assistance from one or more unrelated persons. 225 */ 226 URELDEP, 227 /** 228 * Code specifying observations related to living situation for a person in a private residence. 229 */ 230 LIVSIT, 231 /** 232 * Living alone. Maps to PD1-2 Living arrangement (IS) 00742 [A] 233 */ 234 ALONE, 235 /** 236 * Living with one or more dependent children requiring moderate supervision. 237 */ 238 DEPCHD, 239 /** 240 * Living with disabled spouse requiring functional and health care assistance 241 */ 242 DEPSPS, 243 /** 244 * Living with one or more dependent children requiring intensive supervision 245 */ 246 DEPYGCHD, 247 /** 248 * Living with family. Maps to PD1-2 Living arrangement (IS) 00742 [F] 249 */ 250 FAM, 251 /** 252 * Living with one or more relatives. Maps to PD1-2 Living arrangement (IS) 00742 [R] 253 */ 254 RELAT, 255 /** 256 * Living only with spouse or life partner. Maps to PD1-2 Living arrangement (IS) 00742 [S] 257 */ 258 SPS, 259 /** 260 * Living with one or more unrelated persons. 261 */ 262 UNREL, 263 /** 264 * 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. 265 */ 266 SOECSTAT, 267 /** 268 * Indication of abuse victim. 269 */ 270 ABUSE, 271 /** 272 * Indication of status as homeless. 273 */ 274 HMLESS, 275 /** 276 * Indication of status as illegal immigrant. 277 */ 278 ILGIM, 279 /** 280 * Indication of status as incarcerated. 281 */ 282 INCAR, 283 /** 284 * Indication of probation status. 285 */ 286 PROB, 287 /** 288 * Indication of refugee status. 289 */ 290 REFUG, 291 /** 292 * Indication of unemployed status. 293 */ 294 UNEMPL, 295 /** 296 * Indicates the result of a particular allergy test. E.g. Negative, Mild, Moderate, Severe 297 */ 298 _ALLERGYTESTVALUE, 299 /** 300 * Description:Patient exhibits no reaction to the challenge agent. 301 */ 302 A0, 303 /** 304 * Description:Patient exhibits a minimal reaction to the challenge agent. 305 */ 306 A1, 307 /** 308 * Description:Patient exhibits a mild reaction to the challenge agent. 309 */ 310 A2, 311 /** 312 * Description:Patient exhibits moderate reaction to the challenge agent. 313 */ 314 A3, 315 /** 316 * Description:Patient exhibits a severe reaction to the challenge agent. 317 */ 318 A4, 319 /** 320 * Observation values that communicate the method used in a quality measure to combine the component measure results included in an composite measure. 321 */ 322 _COMPOSITEMEASURESCORING, 323 /** 324 * Code specifying that the measure uses all-or-nothing scoring. All-or-nothing scoring places an individual in the numerator of the composite measure if and only if they are in the numerator of all component measures in which they are in the denominator. 325 */ 326 ALLORNONESCR, 327 /** 328 * Code specifying that the measure uses linear scoring. Linear scoring computes the fraction of component measures in which the individual appears in the numerator, giving equal weight to each component measure. 329 */ 330 LINEARSCR, 331 /** 332 * Code specifying that the measure uses opportunity-based scoring. In opportunity-based scoring the measure score is determined by combining the denominator and numerator of each component measure to determine an overall composite score. 333 */ 334 OPPORSCR, 335 /** 336 * Code specifying that the measure uses weighted scoring. Weighted scoring assigns a factor to each component measure to weight that measure's contribution to the overall score. 337 */ 338 WEIGHTSCR, 339 /** 340 * Description:Coded observation values for coverage limitations, for e.g., types of claims or types of parties covered under a policy or program. 341 */ 342 _COVERAGELIMITOBSERVATIONVALUE, 343 /** 344 * Description:Coded observation values for types of covered parties under a policy or program based on their personal relationships or employment status. 345 */ 346 _COVERAGELEVELOBSERVATIONVALUE, 347 /** 348 * Description:Child over an age as specified by coverage policy or program, e.g., student, differently abled, and income dependent. 349 */ 350 ADC, 351 /** 352 * Description:Dependent biological, adopted, foster child as specified by coverage policy or program. 353 */ 354 CHD, 355 /** 356 * Description:Person requiring functional and/or financial assistance from another person as specified by coverage policy or program. 357 */ 358 DEP, 359 /** 360 * Description:Persons registered as a family unit in a domestic partner registry as specified by law and by coverage policy or program. 361 */ 362 DP, 363 /** 364 * Description:An individual employed by an employer who receive remuneration in wages, salary, commission, tips, piece-rates, or pay-in-kind through the employeraTMs payment system (i.e., not a contractor) as specified by coverage policy or program. 365 */ 366 ECH, 367 /** 368 * Description:As specified by coverage policy or program. 369 */ 370 FLY, 371 /** 372 * Description:Person as specified by coverage policy or program. 373 */ 374 IND, 375 /** 376 * Description:A pair of people of the same gender who live together as a family as specified by coverage policy or program, e.g., Naomi and Ruth from the Book of Ruth; Socrates and Alcibiades 377 */ 378 SSP, 379 /** 380 * A clinical judgment as to the worst case result of a future exposure (including substance administration). When the worst case result is assessed to have a life-threatening or organ system threatening potential, it is considered to be of high criticality. 381 */ 382 _CRITICALITYOBSERVATIONVALUE, 383 /** 384 * Worst case result of a future exposure is assessed to be life-threatening or having high potential for organ system failure. 385 */ 386 CRITH, 387 /** 388 * Worst case result of a future exposure is not assessed to be life-threatening or having high potential for organ system failure. 389 */ 390 CRITL, 391 /** 392 * Unable to assess the worst case result of a future exposure. 393 */ 394 CRITU, 395 /** 396 * Description: The domain contains genetic analysis specific observation values, e.g. Homozygote, Heterozygote, etc. 397 */ 398 _GENETICOBSERVATIONVALUE, 399 /** 400 * Description: An individual having different alleles at one or more loci regarding a specific character 401 */ 402 HOMOZYGOTE, 403 /** 404 * Observation values used to indicate the type of scoring (e.g. proportion, ratio) used by a health quality measure. 405 */ 406 _OBSERVATIONMEASURESCORING, 407 /** 408 * A measure in which either short-term cross-section or long-term longitudinal analysis is performed over a group of subjects defined by a set of common properties or defining characteristics (e.g., Male smokers between the ages of 40 and 50 years, exposure to treatment, exposure duration). 409 */ 410 COHORT, 411 /** 412 * A measure score in which each individual value for the measure can fall anywhere along a continuous scale (e.g., mean time to thrombolytics which aggregates the time in minutes from a case presenting with chest pain to the time of administration of thrombolytics). 413 */ 414 CONTVAR, 415 /** 416 * A score derived by dividing the number of cases that meet a criterion for quality (the numerator) by the number of eligible cases within a given time frame (the denominator) where the numerator cases are a subset of the denominator cases (e.g., percentage of eligible women with a mammogram performed in the last year). 417 */ 418 PROPOR, 419 /** 420 * A score that may have a value of zero or greater that is derived by dividing a count of one type of data by a count of another type of data (e.g., the number of patients with central lines who develop infection divided by the number of central line days). 421 */ 422 RATIO, 423 /** 424 * Observation values used to indicate what kind of health quality measure is used. 425 */ 426 _OBSERVATIONMEASURETYPE, 427 /** 428 * A measure that is composed from one or more other measures and indicates an overall summary of those measures. 429 */ 430 COMPOSITE, 431 /** 432 * A measure related to the efficiency of medical treatment. 433 */ 434 EFFICIENCY, 435 /** 436 * A measure related to the level of patient engagement or patient experience of care. 437 */ 438 EXPERIENCE, 439 /** 440 * A measure that indicates the result of the performance (or non-performance) of a function or process. 441 */ 442 OUTCOME, 443 /** 444 * A measure which focuses on a process which leads to a certain outcome, meaning that a scientific basis exists for believing that the process, when executed well, will increase the probability of achieving a desired outcome. 445 */ 446 PROCESS, 447 /** 448 * A measure related to the extent of use of clinical resources or cost of care. 449 */ 450 RESOURCE, 451 /** 452 * A measure related to the structure of patient care. 453 */ 454 STRUCTURE, 455 /** 456 * Observation values used to assert various populations that a subject falls into. 457 */ 458 _OBSERVATIONPOPULATIONINCLUSION, 459 /** 460 * Patients who should be removed from the eMeasure population and denominator before determining if numerator criteria are met. Denominator exclusions are used in proportion and ratio measures to help narrow the denominator. 461 */ 462 DENEX, 463 /** 464 * Denominator exceptions are those conditions that should remove a patient, procedure or unit of measurement from the denominator only if the numerator criteria are not met. Denominator exceptions allow for adjustment of the calculated score for those providers with higher risk populations. Denominator exceptions are used only in proportion eMeasures. They are not appropriate for ratio or continuous variable eMeasures. Denominator exceptions allow for the exercise of clinical judgment and should be specifically defined where capturing the information in a structured manner fits the clinical workflow. Generic denominator exception reasons used in proportion eMeasures fall into three general categories: 465 466 467 Medical reasons 468 Patient reasons 469 System reasons 470 */ 471 DENEXCEP, 472 /** 473 * It can be the same as the initial patient population or a subset of the initial patient population to further constrain the population for the purpose of the eMeasure. Different measures within an eMeasure set may have different Denominators. Continuous Variable eMeasures do not have a Denominator, but instead define a Measure Population. 474 */ 475 DENOM, 476 /** 477 * The initial population refers to all entities to be evaluated by a specific quality measure who share a common set of specified characteristics within a specific measurement set to which a given measure belongs. 478 */ 479 IP, 480 /** 481 * The initial patient population refers to all patients to be evaluated by a specific quality measure who share a common set of specified characteristics within a specific measurement set to which a given measure belongs. Details often include information based upon specific age groups, diagnoses, diagnostic and procedure codes, and enrollment periods. 482 */ 483 IPP, 484 /** 485 * Measure population is used only in continuous variable eMeasures. It is a narrative description of the eMeasure population. 486(e.g., all patients seen in the Emergency Department during the measurement period). 487 */ 488 MSRPOPL, 489 /** 490 * Numerators are used in proportion and ratio eMeasures. In proportion measures the numerator criteria are the processes or outcomes expected for each patient, procedure, or other unit of measurement defined in the denominator. In ratio measures the numerator is related, but not directly derived from the denominator (e.g., a numerator listing the number of central line blood stream infections and a denominator indicating the days per thousand of central line usage in a specific time period). 491 */ 492 NUMER, 493 /** 494 * Numerator Exclusions are used only in ratio eMeasures to define instances that should not be included in the numerator data. (e.g., if the number of central line blood stream infections per 1000 catheter days were to exclude infections with a specific bacterium, that bacterium would be listed as a numerator exclusion.) 495 */ 496 NUMEX, 497 /** 498 * PartialCompletionScale 499 */ 500 _PARTIALCOMPLETIONSCALE, 501 /** 502 * Value for Act.partialCompletionCode attribute that implies 81-99% completion 503 */ 504 G, 505 /** 506 * Value for Act.partialCompletionCode attribute that implies 61-80% completion 507 */ 508 LE, 509 /** 510 * Value for Act.partialCompletionCode attribute that implies 41-60% completion 511 */ 512 ME, 513 /** 514 * Value for Act.partialCompletionCode attribute that implies 1-20% completion 515 */ 516 MI, 517 /** 518 * Value for Act.partialCompletionCode attribute that implies 0% completion 519 */ 520 N, 521 /** 522 * Value for Act.partialCompletionCode attribute that implies 21-40% completion 523 */ 524 S, 525 /** 526 * Observation values used to indicate security observation metadata. 527 */ 528 _SECURITYOBSERVATIONVALUE, 529 /** 530 * Abstract security observation values used to indicate security integrity metadata. 531 532 533 Examples: Codes conveying integrity status, integrity confidence, and provenance. 534 */ 535 _SECINTOBV, 536 /** 537 * Abstract security metadata observation values used to indicate mechanism used for authorized alteration of an IT resource (data, information object, service, or system capability) 538 */ 539 _SECALTINTOBV, 540 /** 541 * Security metadata observation values used to indicate the use of a more abstract version of the content, e.g., replacing exact value of an age or date field with a range, or remove the left digits of a credit card number or SSN. 542 */ 543 ABSTRED, 544 /** 545 * Security metadata observation values used to indicate the use of an algorithmic combination of actual values with the result of an aggregate function, e.g., average, sum, or count in order to limit disclosure of an IT resource (data, information object, service, or system capability) to the minimum necessary. 546 */ 547 AGGRED, 548 /** 549 * Security metadata observation value conveying the alteration integrity of an IT resource (data, information object, service, or system capability) by used to indicate the mechanism by which software systems can strip portions of the resource that could allow the identification of the source of the information or the information subject. No key to relink the data is retained. 550 */ 551 ANONYED, 552 /** 553 * Security metadata observation value used to indicate that the IT resource semantic content has been transformed from one encoding to another. 554 555 556 Usage Note: "MAP" code does not indicate the semantic fidelity of the transformed content. 557 558 To indicate semantic fidelity for maps of HL7 to other code systems, this security alteration integrity observation may be further specified using an Act valued with Value Set: MapRelationship (2.16.840.1.113883.1.11.11052). 559 560 Semantic fidelity of the mapped IT Resource may also be indicated using a SecurityIntegrityConfidenceObservation. 561 */ 562 MAPPED, 563 /** 564 * Security metadata observation value conveying the alteration integrity of an IT resource (data, information object, service, or system capability) by indicating the mechanism by which software systems can make data unintelligible (that is, as unreadable and unusable by algorithmically transforming plaintext into ciphertext) such that it can only be accessed or used by authorized users. An authorized user may be provided a key to decrypt per license or "shared secret". 565 566 567 Usage Note: "MASKED" may be used, per applicable policy, as a flag to indicate to a user or receiver that some portion of an IT resource has been further encrypted, and may be accessed only by an authorized user or receiver to which a decryption key is provided. 568 */ 569 MASKED, 570 /** 571 * Security metadata observation value conveying the alteration integrity of an IT resource (data, information object, service, or system capability), by indicating the mechanism by which software systems can strip portions of the resource that could allow the identification of the source of the information or the information subject. Custodian may retain a key to relink data necessary to reidentify the information subject. 572 573 574 Rationale: Personal data which has been processed to make it impossible to know whose data it is. Used particularly for secondary use of health data. In some cases, it may be possible for authorized individuals to restore the identity of the individual, e.g.,for public health case management. Based on ISO/TS 25237:2008 Health informatics—Pseudonymization 575 */ 576 PSEUDED, 577 /** 578 * Security metadata observation value used to indicate the mechanism by which software systems can filter an IT resource (data, information object, service, or system capability) to remove any portion of the resource that is not authorized to be access, used, or disclosed. 579 580 581 Usage Note: "REDACTED" may be used, per applicable policy, as a flag to indicate to a user or receiver that some portion of an IT resource has filtered and not included in the content accessed or received. 582 */ 583 REDACTED, 584 /** 585 * Metadata observation used to indicate that some information has been removed from the source object when the view this object contains was constructed because of configuration options when the view was created. The content may not be suitable for use as the basis of a record update 586 587 588 Usage Note: This is not suitable to be used when information is removed for security reasons - see the code REDACTED for this use. 589 */ 590 SUBSETTED, 591 /** 592 * Security metadata observation value used to indicate that the IT resource syntax has been transformed from one syntactical representation to another. 593 594 595 Usage Note: "SYNTAC" code does not indicate the syntactical correctness of the syntactically transformed IT resource. 596 */ 597 SYNTAC, 598 /** 599 * Security metadata observation value used to indicate that the IT resource has been translated from one human language to another. 600 601 602 Usage Note: "TRSLT" does not indicate the fidelity of the translation or the languages translated. 603 604 The fidelity of the IT Resource translation may be indicated using a SecurityIntegrityConfidenceObservation. 605 606 To indicate languages, use the Value Set:HumanLanguage (2.16.840.1.113883.1.11.11526) 607 */ 608 TRSLT, 609 /** 610 * Security metadata observation value conveying the alteration integrity of an IT resource (data, information object, service, or system capability) which indicates that the resource only retains versions of an IT resource for access and use per applicable policy 611 612 613 Usage Note: When this code is used, expectation is that the system has removed historical versions of the data that falls outside the time period deemed to be the effective time of the applicable version. 614 */ 615 VERSIONED, 616 /** 617 * Abstract security observation values used to indicate data integrity metadata. 618 619 620 Examples: Codes conveying the mechanism used to preserve the accuracy and consistency of an IT resource such as a digital signature and a cryptographic hash function. 621 */ 622 _SECDATINTOBV, 623 /** 624 * Security metadata observation value used to indicate the mechanism by which software systems can establish that data was not modified in transit. 625 626 627 Rationale: This definition is intended to align with the ISO 22600-2 3.3.19 definition of cryptographic checkvalue: Information which is derived by performing a cryptographic transformation (see cryptography) on the data unit. The derivation of the checkvalue may be performed in one or more steps and is a result of a mathematical function of the key and a data unit. It is usually used to check the integrity of a data unit. 628 629 630 Examples: 631 632 633 634 SHA-1 635 SHA-2 (Secure Hash Algorithm) 636 */ 637 CRYTOHASH, 638 /** 639 * Security metadata observation value used to indicate the mechanism by which software systems use digital signature to establish that data has not been modified. 640 641 642 Rationale: This definition is intended to align with the ISO 22600-2 3.3.26 definition of digital signature: Data appended to, or a cryptographic transformation (see cryptography) of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g., by the recipient. 643 */ 644 DIGSIG, 645 /** 646 * Abstract security observation value used to indicate integrity confidence metadata. 647 648 649 Examples: Codes conveying the level of reliability and trustworthiness of an IT resource. 650 */ 651 _SECINTCONOBV, 652 /** 653 * Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be very high. 654 */ 655 HRELIABLE, 656 /** 657 * Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be adequate. 658 */ 659 RELIABLE, 660 /** 661 * Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be uncertain. 662 */ 663 UNCERTREL, 664 /** 665 * Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be inadequate. 666 */ 667 UNRELIABLE, 668 /** 669 * Abstract security metadata observation value used to indicate the provenance of an IT resource (data, information object, service, or system capability). 670 671 672 Examples: Codes conveying the provenance metadata about the entity reporting an IT resource. 673 */ 674 _SECINTPRVOBV, 675 /** 676 * Abstract security provenance metadata observation value used to indicate the entity that asserted an IT resource (data, information object, service, or system capability). 677 678 679 Examples: Codes conveying the provenance metadata about the entity asserting the resource. 680 */ 681 _SECINTPRVABOBV, 682 /** 683 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a clinician. 684 */ 685 CLINAST, 686 /** 687 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a device. 688 */ 689 DEVAST, 690 /** 691 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a healthcare professional. 692 */ 693 HCPAST, 694 /** 695 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a patient acquaintance. 696 */ 697 PACQAST, 698 /** 699 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a patient. 700 */ 701 PATAST, 702 /** 703 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a payer. 704 */ 705 PAYAST, 706 /** 707 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a professional. 708 */ 709 PROAST, 710 /** 711 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a substitute decision maker. 712 */ 713 SDMAST, 714 /** 715 * Abstract security provenance metadata observation value used to indicate the entity that reported the resource (data, information object, service, or system capability). 716 717 718 Examples: Codes conveying the provenance metadata about the entity reporting an IT resource. 719 */ 720 _SECINTPRVRBOBV, 721 /** 722 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a clinician. 723 */ 724 CLINRPT, 725 /** 726 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a device. 727 */ 728 DEVRPT, 729 /** 730 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a healthcare professional. 731 */ 732 HCPRPT, 733 /** 734 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a patient acquaintance. 735 */ 736 PACQRPT, 737 /** 738 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a patient. 739 */ 740 PATRPT, 741 /** 742 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a payer. 743 */ 744 PAYRPT, 745 /** 746 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a professional. 747 */ 748 PRORPT, 749 /** 750 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a substitute decision maker. 751 */ 752 SDMRPT, 753 /** 754 * Observation value used to indicate aspects of trust applicable to an IT resource (data, information object, service, or system capability). 755 */ 756 SECTRSTOBV, 757 /** 758 * Values for security trust accreditation 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. 759 */ 760 TRSTACCRDOBV, 761 /** 762 * Values for security trust agreement metadata observation made about privacy and security requirements with which a security domain must comply. [ISO IEC 10181-1] 763[ISO IEC 10181-1] 764 */ 765 TRSTAGREOBV, 766 /** 767 * Values for security trust certificate 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] 768 769 For example, a Certificate Policy (CP), which is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. A particular Certificate Policy might indicate the applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. Another example is Cross Certification with Federal Bridge. 770 */ 771 TRSTCERTOBV, 772 /** 773 * Values for security trust assurance metadata observation made about the digital quality or reliability of a trust assertion, activity, capability, information exchange, mechanism, process, or protocol. 774 */ 775 TRSTLOAOBV, 776 /** 777 * The value assigned as the indicator of the digital quality or reliability of the verification and validation process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2] 778 779 For example, the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies] 780 */ 781 LOAAN, 782 /** 783 * Indicator of low digital quality or reliability of the digital reliability of the verification and validation process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2] 784 785 The degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies] 786 787 Low authentication level of assurance indicates that the relying party may have little or no confidence in the asserted identity's validity. Level 1 requires little or no confidence in the asserted identity. No identity proofing is required at this level, but the authentication mechanism should provide some assurance that the same claimant is accessing the protected transaction or data. A wide range of available authentication technologies can be employed and any of the token methods of Levels 2, 3, or 4, including Personal Identification Numbers (PINs), may be used. To be authenticated, the claimant must prove control of the token through a secure authentication protocol. At Level 1, long-term shared authentication secrets may be revealed to verifiers. Assertions issued about claimants as a result of a successful authentication are either cryptographically authenticated by relying parties (using approved methods) or are obtained directly from a trusted party via a secure authentication protocol. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 788 */ 789 LOAAN1, 790 /** 791 * Indicator of basic digital quality or reliability of the digital reliability of the verification and validation process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2] 792 793 The degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies] 794 795 Basic authentication level of assurance indicates that the relying party may have some confidence in the asserted identity's validity. Level 2 requires confidence that the asserted identity is accurate. Level 2 provides for single-factor remote network authentication, including identity-proofing requirements for presentation of identifying materials or information. A wide range of available authentication technologies can be employed, including any of the token methods of Levels 3 or 4, as well as passwords. Successful authentication requires that the claimant prove through a secure authentication protocol that the claimant controls the token. Eavesdropper, replay, and online guessing attacks are prevented. 796Long-term shared authentication secrets, if used, are never revealed to any party except the claimant and verifiers operated by the CSP; however, session (temporary) shared secrets may be provided to independent verifiers by the CSP. Approved cryptographic techniques are required. Assertions issued about claimants as a result of a successful authentication are either cryptographically authenticated by relying parties (using approved methods) or are obtained directly from a trusted party via a secure authentication protocol. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 797 */ 798 LOAAN2, 799 /** 800 * Indicator of medium digital quality or reliability of the digital reliability of verification and validation of the process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2] 801 802 The degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies] 803 804 Medium authentication level of assurance indicates that the relying party may have high confidence in the asserted identity's validity. Level 3 is appropriate for transactions that need high confidence in the accuracy of the asserted identity. Level 3 provides multifactor remote network authentication. At this level, identity-proofing procedures require verification of identifying materials and information. Authentication is based on proof of possession of a key or password through a cryptographic protocol. Cryptographic strength mechanisms should protect the primary authentication token (a cryptographic key) against compromise by the protocol threats, including eavesdropper, replay, online guessing, verifier impersonation, and man-in-the-middle attacks. A minimum of two authentication factors is required. Three kinds of tokens may be used: 805 806 807 "soft" cryptographic token, which has the key stored on a general-purpose computer, 808 "hard" cryptographic token, which has the key stored on a special hardware device, and 809 "one-time password" device token, which has symmetric key stored on a personal hardware device that is a cryptographic module validated at FIPS 140-2 Level 1 or higher. Validation testing of cryptographic modules and algorithms for conformance to Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic Modules, is managed by NIST. 810 811 Authentication requires that the claimant prove control of the token through a secure authentication protocol. The token must be unlocked with a password or biometric representation, or a password must be used in a secure authentication protocol, to establish two-factor authentication. Long-term shared authentication secrets, if used, are never revealed to any party except the claimant and verifiers operated directly by the CSP; however, session (temporary) shared secrets may be provided to independent verifiers by the CSP. Approved cryptographic techniques are used for all operations. Assertions issued about claimants as a result of a successful authentication are either cryptographically authenticated by relying parties (using approved methods) or are obtained directly from a trusted party via a secure authentication protocol. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 812 */ 813 LOAAN3, 814 /** 815 * Indicator of high digital quality or reliability of the digital reliability of the verification and validation process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2] 816 817 The degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies] 818 819 High authentication level of assurance indicates that the relying party may have very high confidence in the asserted identity's validity. Level 4 is for transactions that need very high confidence in the accuracy of the asserted identity. Level 4 provides the highest practical assurance of remote network authentication. Authentication is based on proof of possession of a key through a cryptographic protocol. This level is similar to Level 3 except that only “hard� cryptographic tokens are allowed, cryptographic module validation requirements are strengthened, and subsequent critical data transfers must be authenticated via a key that is bound to the authentication process. The token should be a hardware cryptographic module validated at FIPS 140-2 Level 2 or higher overall with at least FIPS 140-2 Level 3 physical security. This level requires a physical token, which cannot readily be copied, and operator authentication at Level 2 and higher, and ensures good, two-factor remote authentication. 820 821 Level 4 requires strong cryptographic authentication of all parties and all sensitive data transfers between the parties. Either public key or symmetric key technology may be used. Authentication requires that the claimant prove through a secure authentication protocol that the claimant controls the token. Eavesdropper, replay, online guessing, verifier impersonation, and man-in-the-middle attacks are prevented. Long-term shared authentication secrets, if used, are never revealed to any party except the claimant and verifiers operated directly by the CSP; however, session (temporary) shared secrets may be provided to independent verifiers by the CSP. Strong approved cryptographic techniques are used for all operations. All sensitive data transfers are cryptographically authenticated using keys bound to the authentication process. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 822 */ 823 LOAAN4, 824 /** 825 * The value assigned as the indicator of the digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2] 826 */ 827 LOAAP, 828 /** 829 * Indicator of the low digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2] 830 831 Low authentication process level of assurance indicates that (1) long-term shared authentication secrets may be revealed to verifiers; and (2) assertions and assertion references require protection from manufacture/modification and reuse attacks. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 832 */ 833 LOAAP1, 834 /** 835 * Indicator of the basic digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2] 836 837 Basic authentication process level of assurance indicates that long-term shared authentication secrets are never revealed to any other party except Credential Service Provider (CSP). Sessions (temporary) shared secrets may be provided to independent verifiers by CSP. Long-term shared authentication secrets, if used, are never revealed to any other party except Verifiers operated by the Credential Service Provider (CSP); however, session (temporary) shared secrets may be provided to independent Verifiers by the CSP. In addition to Level 1 requirements, assertions are resistant to disclosure, redirection, capture and substitution attacks. Approved cryptographic techniques are required. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 838 */ 839 LOAAP2, 840 /** 841 * Indicator of the medium digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2] 842 843 Medium authentication process level of assurance indicates that the token can be unlocked with password, biometric, or uses a secure multi-token authentication protocol to establish two-factor authentication. Long-term shared authentication secrets are never revealed to any party except the Claimant and Credential Service Provider (CSP). 844 845 Authentication requires that the Claimant prove, through a secure authentication protocol, that he or she controls the token. The Claimant unlocks the token with a password or biometric, or uses a secure multi-token authentication protocol to establish two-factor authentication (through proof of possession of a physical or software token in combination with some memorized secret knowledge). Long-term shared authentication secrets, if used, are never revealed to any party except the Claimant and Verifiers operated directly by the CSP; however, session (temporary) shared secrets may be provided to independent Verifiers by the CSP. In addition to Level 2 requirements, assertions are protected against repudiation by the Verifier. 846 */ 847 LOAAP3, 848 /** 849 * Indicator of the high digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2] 850 851 High authentication process level of assurance indicates all sensitive data transfer are cryptographically authenticated using keys bound to the authentication process. Level 4 requires strong cryptographic authentication of all communicating parties and all sensitive data transfers between the parties. Either public key or symmetric key technology may be used. Authentication requires that the Claimant prove through a secure authentication protocol that he or she controls the token. All protocol threats at Level 3 are required to be prevented at Level 4. Protocols shall also be strongly resistant to man-in-the-middle attacks. Long-term shared authentication secrets, if used, are never revealed to any party except the Claimant and Verifiers operated directly by the CSP; however, session (temporary) shared secrets may be provided to independent Verifiers by the CSP. Approved cryptographic techniques are used for all operations. All sensitive data transfers are cryptographically authenticated using keys bound to the authentication process. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 852 */ 853 LOAAP4, 854 /** 855 * The value assigned as the indicator of the high quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes. 856 */ 857 LOAAS, 858 /** 859 * Indicator of the low quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes. 860 861 Assertions and assertion references require protection from modification and reuse attacks. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 862 */ 863 LOAAS1, 864 /** 865 * Indicator of the basic quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes. 866 867 Assertions are resistant to disclosure, redirection, capture and substitution attacks. Approved cryptographic techniques are required for all assertion protocols. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 868 */ 869 LOAAS2, 870 /** 871 * Indicator of the medium quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes. 872 873 Assertions are protected against repudiation by the verifier. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 874 */ 875 LOAAS3, 876 /** 877 * Indicator of the high quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes. 878 879 Strongly resistant to man-in-the-middle attacks. "Bearer" assertions are not used. "Holder-of-key" assertions may be used. RP maintains records of the assertions. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.] 880 */ 881 LOAAS4, 882 /** 883 * Indicator of the digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and its binding to an identity. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 884 */ 885 LOACM, 886 /** 887 * Indicator of the low digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and its binding to an identity. Little or no confidence that an individual has maintained control over a token that has been entrusted to him or her and that that token has not been compromised. Characteristics include weak identity binding to tokens and plaintext passwords or secrets not transmitted across a network. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 888 */ 889 LOACM1, 890 /** 891 * Indicator of the basic digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and its binding to an identity. Some confidence that an individual has maintained control over a token that has been entrusted to him or her and that that token has not been compromised. Characteristics include: Verification must prove claimant controls the token; token resists online guessing, replay, session hijacking, and eavesdropping attacks; and token is at least weakly resistant to man-in-the middle attacks. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 892 */ 893 LOACM2, 894 /** 895 * Indicator of the medium digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and it’s binding to an identity. High confidence that an individual has maintained control over a token that has been entrusted to him or her and that that token has not been compromised. Characteristics include: Ownership of token verifiable through security authentication protocol and credential management protects against verifier impersonation attacks. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 896 */ 897 LOACM3, 898 /** 899 * Indicator of the high digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and it’s binding to an identity. Very high confidence that an individual has maintained control over a token that has been entrusted to him or her and that that token has not been compromised. Characteristics include: Verifier can prove control of token through a secure protocol; credential management supports strong cryptographic authentication of all communication parties. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 900 */ 901 LOACM4, 902 /** 903 * Indicator of the quality or reliability in the process of ascertaining that an individual is who he or she claims to be. 904 */ 905 LOAID, 906 /** 907 * Indicator of low digital quality or reliability in the process of ascertaining that an individual is who he or she claims to be. Requires that a continuity of identity be maintained but does not require identity proofing. [Based on Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 908 */ 909 LOAID1, 910 /** 911 * Indicator of some digital quality or reliability in the process of ascertaining that that an individual is who he or she claims to be. Requires identity proofing via presentation of identifying material or information. [Based on Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 912 */ 913 LOAID2, 914 /** 915 * Indicator of high digital quality or reliability in the process of ascertaining that an individual is who he or she claims to be. Requires identity proofing procedures for verification of identifying materials and information. [Based on Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 916 */ 917 LOAID3, 918 /** 919 * Indicator of high digital quality or reliability in the process of ascertaining that an individual is who he or she claims to be. Requires identity proofing procedures for verification of identifying materials and information. [Based on Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 920 */ 921 LOAID4, 922 /** 923 * Indicator of the digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 924 */ 925 LOANR, 926 /** 927 * Indicator of low digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 928 */ 929 LOANR1, 930 /** 931 * Indicator of basic digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 932 */ 933 LOANR2, 934 /** 935 * Indicator of medium digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 936 */ 937 LOANR3, 938 /** 939 * Indicator of high digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 940 */ 941 LOANR4, 942 /** 943 * Indicator of the digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls. [Based on NIST SP 800-63-2] 944 */ 945 LOARA, 946 /** 947 * Indicator of low digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls. [Based on NIST SP 800-63-2] 948 */ 949 LOARA1, 950 /** 951 * Indicator of basic digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls. [Based on NIST SP 800-63-2] 952 */ 953 LOARA2, 954 /** 955 * Indicator of medium digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls. [Based on NIST SP 800-63-2] 956 */ 957 LOARA3, 958 /** 959 * Indicator of high digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization's security controls. [Based on NIST SP 800-63-2] 960 */ 961 LOARA4, 962 /** 963 * Indicator of the digital quality or reliability of single and multi-token authentication. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 964 */ 965 LOATK, 966 /** 967 * Indicator of the low digital quality or reliability of single and multi-token authentication. Permits the use of any of the token methods of Levels 2, 3, or 4. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 968 */ 969 LOATK1, 970 /** 971 * Indicator of the basic digital quality or reliability of single and multi-token authentication. Requires single factor authentication using memorized secret tokens, pre-registered knowledge tokens, look-up secret tokens, out of band tokens, or single factor one-time password devices. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 972 */ 973 LOATK2, 974 /** 975 * Indicator of the medium digital quality or reliability of single and multi-token authentication. Requires two authentication factors. Provides multi-factor remote network authentication. Permits multi-factor software cryptographic token. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 976 */ 977 LOATK3, 978 /** 979 * Indicator of the high digital quality or reliability of single and multi-token authentication. Requires token that is a hardware cryptographic module validated at validated at Federal Information Processing Standard (FIPS) 140-2 Level 2 or higher overall with at least FIPS 140-2 Level 3 physical security. Level 4 token requirements can be met by using the PIV authentication key of a FIPS 201 compliant Personal Identity Verification (PIV) Card. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011] 980 */ 981 LOATK4, 982 /** 983 * Values for security trust mechanism metadata observation made about a security architecture system component that supports enforcement of security policies. 984 */ 985 TRSTMECOBV, 986 /** 987 * Potential values for observations of severity. 988 */ 989 _SEVERITYOBSERVATION, 990 /** 991 * Indicates the condition may be life-threatening or has the potential to cause permanent injury. 992 */ 993 H, 994 /** 995 * Indicates the condition may result in some adverse consequences but is unlikely to substantially affect the situation of the subject. 996 */ 997 L, 998 /** 999 * Indicates the condition may result in noticable adverse adverse consequences but is unlikely to be life-threatening or cause permanent injury. 1000 */ 1001 M, 1002 /** 1003 * Contains codes for defining the observed, physical position of a subject, such as during an observation, assessment, collection of a specimen, etc. ECG waveforms and vital signs, such as blood pressure, are two examples where a general, observed position typically needs to be noted. 1004 */ 1005 _SUBJECTBODYPOSITION, 1006 /** 1007 * Lying on the left side. 1008 */ 1009 LLD, 1010 /** 1011 * Lying with the front or ventral surface downward; lying face down. 1012 */ 1013 PRN, 1014 /** 1015 * Lying on the right side. 1016 */ 1017 RLD, 1018 /** 1019 * A semi-sitting position in bed with the head of the bed elevated approximately 45 degrees. 1020 */ 1021 SFWL, 1022 /** 1023 * Resting the body on the buttocks, typically with upper torso erect or semi erect. 1024 */ 1025 SIT, 1026 /** 1027 * To be stationary, upright, vertical, on one's legs. 1028 */ 1029 STN, 1030 /** 1031 * supine 1032 */ 1033 SUP, 1034 /** 1035 * Lying on the back, on an inclined plane, typically about 30-45 degrees with head raised and feet lowered. 1036 */ 1037 RTRD, 1038 /** 1039 * Lying on the back, on an inclined plane, typically about 30-45 degrees, with head lowered and feet raised. 1040 */ 1041 TRD, 1042 /** 1043 * Values for observations of verification act results 1044 1045 1046 Examples: Verified, not verified, verified with warning. 1047 */ 1048 _VERIFICATIONOUTCOMEVALUE, 1049 /** 1050 * Definition: Coverage is in effect for healthcare service(s) and/or product(s). 1051 */ 1052 ACT, 1053 /** 1054 * Definition: Coverage is in effect for healthcare service(s) and/or product(s) - Pending Investigation 1055 */ 1056 ACTPEND, 1057 /** 1058 * Definition: Coverage is in effect for healthcare service(s) and/or product(s). 1059 */ 1060 ELG, 1061 /** 1062 * Definition: Coverage is not in effect for healthcare service(s) and/or product(s). 1063 */ 1064 INACT, 1065 /** 1066 * Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Investigation. 1067 */ 1068 INPNDINV, 1069 /** 1070 * Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Eligibility Update. 1071 */ 1072 INPNDUPD, 1073 /** 1074 * Definition: Coverage is not in effect for healthcare service(s) and/or product(s). May optionally include reasons for the ineligibility. 1075 */ 1076 NELG, 1077 /** 1078 * AnnotationValue 1079 */ 1080 _ANNOTATIONVALUE, 1081 /** 1082 * Description:Used in a patient care message to value simple clinical (non-lab) observations. 1083 */ 1084 _COMMONCLINICALOBSERVATIONVALUE, 1085 /** 1086 * This domain is established as a parent to a variety of value domains being defined to support the communication of Individual Case Safety Reports to regulatory bodies. Arguably, this aggregation is not taxonomically pure, but the grouping will facilitate the management of these domains. 1087 */ 1088 _INDIVIDUALCASESAFETYREPORTVALUEDOMAINS, 1089 /** 1090 * Indicates the specific observation result which is the reason for the action (prescription, lab test, etc.). E.g. Headache, Ear infection, planned diagnostic image (requiring contrast agent), etc. 1091 */ 1092 _INDICATIONVALUE, 1093 /** 1094 * added to help the parsers 1095 */ 1096 NULL; 1097 public static V3ObservationValue fromCode(String codeString) throws FHIRException { 1098 if (codeString == null || "".equals(codeString)) 1099 return null; 1100 if ("_ActCoverageAssessmentObservationValue".equals(codeString)) 1101 return _ACTCOVERAGEASSESSMENTOBSERVATIONVALUE; 1102 if ("_ActFinancialStatusObservationValue".equals(codeString)) 1103 return _ACTFINANCIALSTATUSOBSERVATIONVALUE; 1104 if ("ASSET".equals(codeString)) 1105 return ASSET; 1106 if ("ANNUITY".equals(codeString)) 1107 return ANNUITY; 1108 if ("PROP".equals(codeString)) 1109 return PROP; 1110 if ("RETACCT".equals(codeString)) 1111 return RETACCT; 1112 if ("TRUST".equals(codeString)) 1113 return TRUST; 1114 if ("INCOME".equals(codeString)) 1115 return INCOME; 1116 if ("CHILD".equals(codeString)) 1117 return CHILD; 1118 if ("DISABL".equals(codeString)) 1119 return DISABL; 1120 if ("INVEST".equals(codeString)) 1121 return INVEST; 1122 if ("PAY".equals(codeString)) 1123 return PAY; 1124 if ("RETIRE".equals(codeString)) 1125 return RETIRE; 1126 if ("SPOUSAL".equals(codeString)) 1127 return SPOUSAL; 1128 if ("SUPPLE".equals(codeString)) 1129 return SUPPLE; 1130 if ("TAX".equals(codeString)) 1131 return TAX; 1132 if ("LIVEXP".equals(codeString)) 1133 return LIVEXP; 1134 if ("CLOTH".equals(codeString)) 1135 return CLOTH; 1136 if ("FOOD".equals(codeString)) 1137 return FOOD; 1138 if ("HEALTH".equals(codeString)) 1139 return HEALTH; 1140 if ("HOUSE".equals(codeString)) 1141 return HOUSE; 1142 if ("LEGAL".equals(codeString)) 1143 return LEGAL; 1144 if ("MORTG".equals(codeString)) 1145 return MORTG; 1146 if ("RENT".equals(codeString)) 1147 return RENT; 1148 if ("SUNDRY".equals(codeString)) 1149 return SUNDRY; 1150 if ("TRANS".equals(codeString)) 1151 return TRANS; 1152 if ("UTIL".equals(codeString)) 1153 return UTIL; 1154 if ("ELSTAT".equals(codeString)) 1155 return ELSTAT; 1156 if ("ADOPT".equals(codeString)) 1157 return ADOPT; 1158 if ("BTHCERT".equals(codeString)) 1159 return BTHCERT; 1160 if ("CCOC".equals(codeString)) 1161 return CCOC; 1162 if ("DRLIC".equals(codeString)) 1163 return DRLIC; 1164 if ("FOSTER".equals(codeString)) 1165 return FOSTER; 1166 if ("MEMBER".equals(codeString)) 1167 return MEMBER; 1168 if ("MIL".equals(codeString)) 1169 return MIL; 1170 if ("MRGCERT".equals(codeString)) 1171 return MRGCERT; 1172 if ("PASSPORT".equals(codeString)) 1173 return PASSPORT; 1174 if ("STUDENRL".equals(codeString)) 1175 return STUDENRL; 1176 if ("HLSTAT".equals(codeString)) 1177 return HLSTAT; 1178 if ("DISABLE".equals(codeString)) 1179 return DISABLE; 1180 if ("DRUG".equals(codeString)) 1181 return DRUG; 1182 if ("IVDRG".equals(codeString)) 1183 return IVDRG; 1184 if ("PGNT".equals(codeString)) 1185 return PGNT; 1186 if ("LIVDEP".equals(codeString)) 1187 return LIVDEP; 1188 if ("RELDEP".equals(codeString)) 1189 return RELDEP; 1190 if ("SPSDEP".equals(codeString)) 1191 return SPSDEP; 1192 if ("URELDEP".equals(codeString)) 1193 return URELDEP; 1194 if ("LIVSIT".equals(codeString)) 1195 return LIVSIT; 1196 if ("ALONE".equals(codeString)) 1197 return ALONE; 1198 if ("DEPCHD".equals(codeString)) 1199 return DEPCHD; 1200 if ("DEPSPS".equals(codeString)) 1201 return DEPSPS; 1202 if ("DEPYGCHD".equals(codeString)) 1203 return DEPYGCHD; 1204 if ("FAM".equals(codeString)) 1205 return FAM; 1206 if ("RELAT".equals(codeString)) 1207 return RELAT; 1208 if ("SPS".equals(codeString)) 1209 return SPS; 1210 if ("UNREL".equals(codeString)) 1211 return UNREL; 1212 if ("SOECSTAT".equals(codeString)) 1213 return SOECSTAT; 1214 if ("ABUSE".equals(codeString)) 1215 return ABUSE; 1216 if ("HMLESS".equals(codeString)) 1217 return HMLESS; 1218 if ("ILGIM".equals(codeString)) 1219 return ILGIM; 1220 if ("INCAR".equals(codeString)) 1221 return INCAR; 1222 if ("PROB".equals(codeString)) 1223 return PROB; 1224 if ("REFUG".equals(codeString)) 1225 return REFUG; 1226 if ("UNEMPL".equals(codeString)) 1227 return UNEMPL; 1228 if ("_AllergyTestValue".equals(codeString)) 1229 return _ALLERGYTESTVALUE; 1230 if ("A0".equals(codeString)) 1231 return A0; 1232 if ("A1".equals(codeString)) 1233 return A1; 1234 if ("A2".equals(codeString)) 1235 return A2; 1236 if ("A3".equals(codeString)) 1237 return A3; 1238 if ("A4".equals(codeString)) 1239 return A4; 1240 if ("_CompositeMeasureScoring".equals(codeString)) 1241 return _COMPOSITEMEASURESCORING; 1242 if ("ALLORNONESCR".equals(codeString)) 1243 return ALLORNONESCR; 1244 if ("LINEARSCR".equals(codeString)) 1245 return LINEARSCR; 1246 if ("OPPORSCR".equals(codeString)) 1247 return OPPORSCR; 1248 if ("WEIGHTSCR".equals(codeString)) 1249 return WEIGHTSCR; 1250 if ("_CoverageLimitObservationValue".equals(codeString)) 1251 return _COVERAGELIMITOBSERVATIONVALUE; 1252 if ("_CoverageLevelObservationValue".equals(codeString)) 1253 return _COVERAGELEVELOBSERVATIONVALUE; 1254 if ("ADC".equals(codeString)) 1255 return ADC; 1256 if ("CHD".equals(codeString)) 1257 return CHD; 1258 if ("DEP".equals(codeString)) 1259 return DEP; 1260 if ("DP".equals(codeString)) 1261 return DP; 1262 if ("ECH".equals(codeString)) 1263 return ECH; 1264 if ("FLY".equals(codeString)) 1265 return FLY; 1266 if ("IND".equals(codeString)) 1267 return IND; 1268 if ("SSP".equals(codeString)) 1269 return SSP; 1270 if ("_CriticalityObservationValue".equals(codeString)) 1271 return _CRITICALITYOBSERVATIONVALUE; 1272 if ("CRITH".equals(codeString)) 1273 return CRITH; 1274 if ("CRITL".equals(codeString)) 1275 return CRITL; 1276 if ("CRITU".equals(codeString)) 1277 return CRITU; 1278 if ("_GeneticObservationValue".equals(codeString)) 1279 return _GENETICOBSERVATIONVALUE; 1280 if ("Homozygote".equals(codeString)) 1281 return HOMOZYGOTE; 1282 if ("_ObservationMeasureScoring".equals(codeString)) 1283 return _OBSERVATIONMEASURESCORING; 1284 if ("COHORT".equals(codeString)) 1285 return COHORT; 1286 if ("CONTVAR".equals(codeString)) 1287 return CONTVAR; 1288 if ("PROPOR".equals(codeString)) 1289 return PROPOR; 1290 if ("RATIO".equals(codeString)) 1291 return RATIO; 1292 if ("_ObservationMeasureType".equals(codeString)) 1293 return _OBSERVATIONMEASURETYPE; 1294 if ("COMPOSITE".equals(codeString)) 1295 return COMPOSITE; 1296 if ("EFFICIENCY".equals(codeString)) 1297 return EFFICIENCY; 1298 if ("EXPERIENCE".equals(codeString)) 1299 return EXPERIENCE; 1300 if ("OUTCOME".equals(codeString)) 1301 return OUTCOME; 1302 if ("PROCESS".equals(codeString)) 1303 return PROCESS; 1304 if ("RESOURCE".equals(codeString)) 1305 return RESOURCE; 1306 if ("STRUCTURE".equals(codeString)) 1307 return STRUCTURE; 1308 if ("_ObservationPopulationInclusion".equals(codeString)) 1309 return _OBSERVATIONPOPULATIONINCLUSION; 1310 if ("DENEX".equals(codeString)) 1311 return DENEX; 1312 if ("DENEXCEP".equals(codeString)) 1313 return DENEXCEP; 1314 if ("DENOM".equals(codeString)) 1315 return DENOM; 1316 if ("IP".equals(codeString)) 1317 return IP; 1318 if ("IPP".equals(codeString)) 1319 return IPP; 1320 if ("MSRPOPL".equals(codeString)) 1321 return MSRPOPL; 1322 if ("NUMER".equals(codeString)) 1323 return NUMER; 1324 if ("NUMEX".equals(codeString)) 1325 return NUMEX; 1326 if ("_PartialCompletionScale".equals(codeString)) 1327 return _PARTIALCOMPLETIONSCALE; 1328 if ("G".equals(codeString)) 1329 return G; 1330 if ("LE".equals(codeString)) 1331 return LE; 1332 if ("ME".equals(codeString)) 1333 return ME; 1334 if ("MI".equals(codeString)) 1335 return MI; 1336 if ("N".equals(codeString)) 1337 return N; 1338 if ("S".equals(codeString)) 1339 return S; 1340 if ("_SecurityObservationValue".equals(codeString)) 1341 return _SECURITYOBSERVATIONVALUE; 1342 if ("_SECINTOBV".equals(codeString)) 1343 return _SECINTOBV; 1344 if ("_SECALTINTOBV".equals(codeString)) 1345 return _SECALTINTOBV; 1346 if ("ABSTRED".equals(codeString)) 1347 return ABSTRED; 1348 if ("AGGRED".equals(codeString)) 1349 return AGGRED; 1350 if ("ANONYED".equals(codeString)) 1351 return ANONYED; 1352 if ("MAPPED".equals(codeString)) 1353 return MAPPED; 1354 if ("MASKED".equals(codeString)) 1355 return MASKED; 1356 if ("PSEUDED".equals(codeString)) 1357 return PSEUDED; 1358 if ("REDACTED".equals(codeString)) 1359 return REDACTED; 1360 if ("SUBSETTED".equals(codeString)) 1361 return SUBSETTED; 1362 if ("SYNTAC".equals(codeString)) 1363 return SYNTAC; 1364 if ("TRSLT".equals(codeString)) 1365 return TRSLT; 1366 if ("VERSIONED".equals(codeString)) 1367 return VERSIONED; 1368 if ("_SECDATINTOBV".equals(codeString)) 1369 return _SECDATINTOBV; 1370 if ("CRYTOHASH".equals(codeString)) 1371 return CRYTOHASH; 1372 if ("DIGSIG".equals(codeString)) 1373 return DIGSIG; 1374 if ("_SECINTCONOBV".equals(codeString)) 1375 return _SECINTCONOBV; 1376 if ("HRELIABLE".equals(codeString)) 1377 return HRELIABLE; 1378 if ("RELIABLE".equals(codeString)) 1379 return RELIABLE; 1380 if ("UNCERTREL".equals(codeString)) 1381 return UNCERTREL; 1382 if ("UNRELIABLE".equals(codeString)) 1383 return UNRELIABLE; 1384 if ("_SECINTPRVOBV".equals(codeString)) 1385 return _SECINTPRVOBV; 1386 if ("_SECINTPRVABOBV".equals(codeString)) 1387 return _SECINTPRVABOBV; 1388 if ("CLINAST".equals(codeString)) 1389 return CLINAST; 1390 if ("DEVAST".equals(codeString)) 1391 return DEVAST; 1392 if ("HCPAST".equals(codeString)) 1393 return HCPAST; 1394 if ("PACQAST".equals(codeString)) 1395 return PACQAST; 1396 if ("PATAST".equals(codeString)) 1397 return PATAST; 1398 if ("PAYAST".equals(codeString)) 1399 return PAYAST; 1400 if ("PROAST".equals(codeString)) 1401 return PROAST; 1402 if ("SDMAST".equals(codeString)) 1403 return SDMAST; 1404 if ("_SECINTPRVRBOBV".equals(codeString)) 1405 return _SECINTPRVRBOBV; 1406 if ("CLINRPT".equals(codeString)) 1407 return CLINRPT; 1408 if ("DEVRPT".equals(codeString)) 1409 return DEVRPT; 1410 if ("HCPRPT".equals(codeString)) 1411 return HCPRPT; 1412 if ("PACQRPT".equals(codeString)) 1413 return PACQRPT; 1414 if ("PATRPT".equals(codeString)) 1415 return PATRPT; 1416 if ("PAYRPT".equals(codeString)) 1417 return PAYRPT; 1418 if ("PRORPT".equals(codeString)) 1419 return PRORPT; 1420 if ("SDMRPT".equals(codeString)) 1421 return SDMRPT; 1422 if ("SECTRSTOBV".equals(codeString)) 1423 return SECTRSTOBV; 1424 if ("TRSTACCRDOBV".equals(codeString)) 1425 return TRSTACCRDOBV; 1426 if ("TRSTAGREOBV".equals(codeString)) 1427 return TRSTAGREOBV; 1428 if ("TRSTCERTOBV".equals(codeString)) 1429 return TRSTCERTOBV; 1430 if ("TRSTLOAOBV".equals(codeString)) 1431 return TRSTLOAOBV; 1432 if ("LOAAN".equals(codeString)) 1433 return LOAAN; 1434 if ("LOAAN1".equals(codeString)) 1435 return LOAAN1; 1436 if ("LOAAN2".equals(codeString)) 1437 return LOAAN2; 1438 if ("LOAAN3".equals(codeString)) 1439 return LOAAN3; 1440 if ("LOAAN4".equals(codeString)) 1441 return LOAAN4; 1442 if ("LOAAP".equals(codeString)) 1443 return LOAAP; 1444 if ("LOAAP1".equals(codeString)) 1445 return LOAAP1; 1446 if ("LOAAP2".equals(codeString)) 1447 return LOAAP2; 1448 if ("LOAAP3".equals(codeString)) 1449 return LOAAP3; 1450 if ("LOAAP4".equals(codeString)) 1451 return LOAAP4; 1452 if ("LOAAS".equals(codeString)) 1453 return LOAAS; 1454 if ("LOAAS1".equals(codeString)) 1455 return LOAAS1; 1456 if ("LOAAS2".equals(codeString)) 1457 return LOAAS2; 1458 if ("LOAAS3".equals(codeString)) 1459 return LOAAS3; 1460 if ("LOAAS4".equals(codeString)) 1461 return LOAAS4; 1462 if ("LOACM".equals(codeString)) 1463 return LOACM; 1464 if ("LOACM1".equals(codeString)) 1465 return LOACM1; 1466 if ("LOACM2".equals(codeString)) 1467 return LOACM2; 1468 if ("LOACM3".equals(codeString)) 1469 return LOACM3; 1470 if ("LOACM4".equals(codeString)) 1471 return LOACM4; 1472 if ("LOAID".equals(codeString)) 1473 return LOAID; 1474 if ("LOAID1".equals(codeString)) 1475 return LOAID1; 1476 if ("LOAID2".equals(codeString)) 1477 return LOAID2; 1478 if ("LOAID3".equals(codeString)) 1479 return LOAID3; 1480 if ("LOAID4".equals(codeString)) 1481 return LOAID4; 1482 if ("LOANR".equals(codeString)) 1483 return LOANR; 1484 if ("LOANR1".equals(codeString)) 1485 return LOANR1; 1486 if ("LOANR2".equals(codeString)) 1487 return LOANR2; 1488 if ("LOANR3".equals(codeString)) 1489 return LOANR3; 1490 if ("LOANR4".equals(codeString)) 1491 return LOANR4; 1492 if ("LOARA".equals(codeString)) 1493 return LOARA; 1494 if ("LOARA1".equals(codeString)) 1495 return LOARA1; 1496 if ("LOARA2".equals(codeString)) 1497 return LOARA2; 1498 if ("LOARA3".equals(codeString)) 1499 return LOARA3; 1500 if ("LOARA4".equals(codeString)) 1501 return LOARA4; 1502 if ("LOATK".equals(codeString)) 1503 return LOATK; 1504 if ("LOATK1".equals(codeString)) 1505 return LOATK1; 1506 if ("LOATK2".equals(codeString)) 1507 return LOATK2; 1508 if ("LOATK3".equals(codeString)) 1509 return LOATK3; 1510 if ("LOATK4".equals(codeString)) 1511 return LOATK4; 1512 if ("TRSTMECOBV".equals(codeString)) 1513 return TRSTMECOBV; 1514 if ("_SeverityObservation".equals(codeString)) 1515 return _SEVERITYOBSERVATION; 1516 if ("H".equals(codeString)) 1517 return H; 1518 if ("L".equals(codeString)) 1519 return L; 1520 if ("M".equals(codeString)) 1521 return M; 1522 if ("_SubjectBodyPosition".equals(codeString)) 1523 return _SUBJECTBODYPOSITION; 1524 if ("LLD".equals(codeString)) 1525 return LLD; 1526 if ("PRN".equals(codeString)) 1527 return PRN; 1528 if ("RLD".equals(codeString)) 1529 return RLD; 1530 if ("SFWL".equals(codeString)) 1531 return SFWL; 1532 if ("SIT".equals(codeString)) 1533 return SIT; 1534 if ("STN".equals(codeString)) 1535 return STN; 1536 if ("SUP".equals(codeString)) 1537 return SUP; 1538 if ("RTRD".equals(codeString)) 1539 return RTRD; 1540 if ("TRD".equals(codeString)) 1541 return TRD; 1542 if ("_VerificationOutcomeValue".equals(codeString)) 1543 return _VERIFICATIONOUTCOMEVALUE; 1544 if ("ACT".equals(codeString)) 1545 return ACT; 1546 if ("ACTPEND".equals(codeString)) 1547 return ACTPEND; 1548 if ("ELG".equals(codeString)) 1549 return ELG; 1550 if ("INACT".equals(codeString)) 1551 return INACT; 1552 if ("INPNDINV".equals(codeString)) 1553 return INPNDINV; 1554 if ("INPNDUPD".equals(codeString)) 1555 return INPNDUPD; 1556 if ("NELG".equals(codeString)) 1557 return NELG; 1558 if ("_AnnotationValue".equals(codeString)) 1559 return _ANNOTATIONVALUE; 1560 if ("_CommonClinicalObservationValue".equals(codeString)) 1561 return _COMMONCLINICALOBSERVATIONVALUE; 1562 if ("_IndividualCaseSafetyReportValueDomains".equals(codeString)) 1563 return _INDIVIDUALCASESAFETYREPORTVALUEDOMAINS; 1564 if ("_IndicationValue".equals(codeString)) 1565 return _INDICATIONVALUE; 1566 throw new FHIRException("Unknown V3ObservationValue code '"+codeString+"'"); 1567 } 1568 public String toCode() { 1569 switch (this) { 1570 case _ACTCOVERAGEASSESSMENTOBSERVATIONVALUE: return "_ActCoverageAssessmentObservationValue"; 1571 case _ACTFINANCIALSTATUSOBSERVATIONVALUE: return "_ActFinancialStatusObservationValue"; 1572 case ASSET: return "ASSET"; 1573 case ANNUITY: return "ANNUITY"; 1574 case PROP: return "PROP"; 1575 case RETACCT: return "RETACCT"; 1576 case TRUST: return "TRUST"; 1577 case INCOME: return "INCOME"; 1578 case CHILD: return "CHILD"; 1579 case DISABL: return "DISABL"; 1580 case INVEST: return "INVEST"; 1581 case PAY: return "PAY"; 1582 case RETIRE: return "RETIRE"; 1583 case SPOUSAL: return "SPOUSAL"; 1584 case SUPPLE: return "SUPPLE"; 1585 case TAX: return "TAX"; 1586 case LIVEXP: return "LIVEXP"; 1587 case CLOTH: return "CLOTH"; 1588 case FOOD: return "FOOD"; 1589 case HEALTH: return "HEALTH"; 1590 case HOUSE: return "HOUSE"; 1591 case LEGAL: return "LEGAL"; 1592 case MORTG: return "MORTG"; 1593 case RENT: return "RENT"; 1594 case SUNDRY: return "SUNDRY"; 1595 case TRANS: return "TRANS"; 1596 case UTIL: return "UTIL"; 1597 case ELSTAT: return "ELSTAT"; 1598 case ADOPT: return "ADOPT"; 1599 case BTHCERT: return "BTHCERT"; 1600 case CCOC: return "CCOC"; 1601 case DRLIC: return "DRLIC"; 1602 case FOSTER: return "FOSTER"; 1603 case MEMBER: return "MEMBER"; 1604 case MIL: return "MIL"; 1605 case MRGCERT: return "MRGCERT"; 1606 case PASSPORT: return "PASSPORT"; 1607 case STUDENRL: return "STUDENRL"; 1608 case HLSTAT: return "HLSTAT"; 1609 case DISABLE: return "DISABLE"; 1610 case DRUG: return "DRUG"; 1611 case IVDRG: return "IVDRG"; 1612 case PGNT: return "PGNT"; 1613 case LIVDEP: return "LIVDEP"; 1614 case RELDEP: return "RELDEP"; 1615 case SPSDEP: return "SPSDEP"; 1616 case URELDEP: return "URELDEP"; 1617 case LIVSIT: return "LIVSIT"; 1618 case ALONE: return "ALONE"; 1619 case DEPCHD: return "DEPCHD"; 1620 case DEPSPS: return "DEPSPS"; 1621 case DEPYGCHD: return "DEPYGCHD"; 1622 case FAM: return "FAM"; 1623 case RELAT: return "RELAT"; 1624 case SPS: return "SPS"; 1625 case UNREL: return "UNREL"; 1626 case SOECSTAT: return "SOECSTAT"; 1627 case ABUSE: return "ABUSE"; 1628 case HMLESS: return "HMLESS"; 1629 case ILGIM: return "ILGIM"; 1630 case INCAR: return "INCAR"; 1631 case PROB: return "PROB"; 1632 case REFUG: return "REFUG"; 1633 case UNEMPL: return "UNEMPL"; 1634 case _ALLERGYTESTVALUE: return "_AllergyTestValue"; 1635 case A0: return "A0"; 1636 case A1: return "A1"; 1637 case A2: return "A2"; 1638 case A3: return "A3"; 1639 case A4: return "A4"; 1640 case _COMPOSITEMEASURESCORING: return "_CompositeMeasureScoring"; 1641 case ALLORNONESCR: return "ALLORNONESCR"; 1642 case LINEARSCR: return "LINEARSCR"; 1643 case OPPORSCR: return "OPPORSCR"; 1644 case WEIGHTSCR: return "WEIGHTSCR"; 1645 case _COVERAGELIMITOBSERVATIONVALUE: return "_CoverageLimitObservationValue"; 1646 case _COVERAGELEVELOBSERVATIONVALUE: return "_CoverageLevelObservationValue"; 1647 case ADC: return "ADC"; 1648 case CHD: return "CHD"; 1649 case DEP: return "DEP"; 1650 case DP: return "DP"; 1651 case ECH: return "ECH"; 1652 case FLY: return "FLY"; 1653 case IND: return "IND"; 1654 case SSP: return "SSP"; 1655 case _CRITICALITYOBSERVATIONVALUE: return "_CriticalityObservationValue"; 1656 case CRITH: return "CRITH"; 1657 case CRITL: return "CRITL"; 1658 case CRITU: return "CRITU"; 1659 case _GENETICOBSERVATIONVALUE: return "_GeneticObservationValue"; 1660 case HOMOZYGOTE: return "Homozygote"; 1661 case _OBSERVATIONMEASURESCORING: return "_ObservationMeasureScoring"; 1662 case COHORT: return "COHORT"; 1663 case CONTVAR: return "CONTVAR"; 1664 case PROPOR: return "PROPOR"; 1665 case RATIO: return "RATIO"; 1666 case _OBSERVATIONMEASURETYPE: return "_ObservationMeasureType"; 1667 case COMPOSITE: return "COMPOSITE"; 1668 case EFFICIENCY: return "EFFICIENCY"; 1669 case EXPERIENCE: return "EXPERIENCE"; 1670 case OUTCOME: return "OUTCOME"; 1671 case PROCESS: return "PROCESS"; 1672 case RESOURCE: return "RESOURCE"; 1673 case STRUCTURE: return "STRUCTURE"; 1674 case _OBSERVATIONPOPULATIONINCLUSION: return "_ObservationPopulationInclusion"; 1675 case DENEX: return "DENEX"; 1676 case DENEXCEP: return "DENEXCEP"; 1677 case DENOM: return "DENOM"; 1678 case IP: return "IP"; 1679 case IPP: return "IPP"; 1680 case MSRPOPL: return "MSRPOPL"; 1681 case NUMER: return "NUMER"; 1682 case NUMEX: return "NUMEX"; 1683 case _PARTIALCOMPLETIONSCALE: return "_PartialCompletionScale"; 1684 case G: return "G"; 1685 case LE: return "LE"; 1686 case ME: return "ME"; 1687 case MI: return "MI"; 1688 case N: return "N"; 1689 case S: return "S"; 1690 case _SECURITYOBSERVATIONVALUE: return "_SecurityObservationValue"; 1691 case _SECINTOBV: return "_SECINTOBV"; 1692 case _SECALTINTOBV: return "_SECALTINTOBV"; 1693 case ABSTRED: return "ABSTRED"; 1694 case AGGRED: return "AGGRED"; 1695 case ANONYED: return "ANONYED"; 1696 case MAPPED: return "MAPPED"; 1697 case MASKED: return "MASKED"; 1698 case PSEUDED: return "PSEUDED"; 1699 case REDACTED: return "REDACTED"; 1700 case SUBSETTED: return "SUBSETTED"; 1701 case SYNTAC: return "SYNTAC"; 1702 case TRSLT: return "TRSLT"; 1703 case VERSIONED: return "VERSIONED"; 1704 case _SECDATINTOBV: return "_SECDATINTOBV"; 1705 case CRYTOHASH: return "CRYTOHASH"; 1706 case DIGSIG: return "DIGSIG"; 1707 case _SECINTCONOBV: return "_SECINTCONOBV"; 1708 case HRELIABLE: return "HRELIABLE"; 1709 case RELIABLE: return "RELIABLE"; 1710 case UNCERTREL: return "UNCERTREL"; 1711 case UNRELIABLE: return "UNRELIABLE"; 1712 case _SECINTPRVOBV: return "_SECINTPRVOBV"; 1713 case _SECINTPRVABOBV: return "_SECINTPRVABOBV"; 1714 case CLINAST: return "CLINAST"; 1715 case DEVAST: return "DEVAST"; 1716 case HCPAST: return "HCPAST"; 1717 case PACQAST: return "PACQAST"; 1718 case PATAST: return "PATAST"; 1719 case PAYAST: return "PAYAST"; 1720 case PROAST: return "PROAST"; 1721 case SDMAST: return "SDMAST"; 1722 case _SECINTPRVRBOBV: return "_SECINTPRVRBOBV"; 1723 case CLINRPT: return "CLINRPT"; 1724 case DEVRPT: return "DEVRPT"; 1725 case HCPRPT: return "HCPRPT"; 1726 case PACQRPT: return "PACQRPT"; 1727 case PATRPT: return "PATRPT"; 1728 case PAYRPT: return "PAYRPT"; 1729 case PRORPT: return "PRORPT"; 1730 case SDMRPT: return "SDMRPT"; 1731 case SECTRSTOBV: return "SECTRSTOBV"; 1732 case TRSTACCRDOBV: return "TRSTACCRDOBV"; 1733 case TRSTAGREOBV: return "TRSTAGREOBV"; 1734 case TRSTCERTOBV: return "TRSTCERTOBV"; 1735 case TRSTLOAOBV: return "TRSTLOAOBV"; 1736 case LOAAN: return "LOAAN"; 1737 case LOAAN1: return "LOAAN1"; 1738 case LOAAN2: return "LOAAN2"; 1739 case LOAAN3: return "LOAAN3"; 1740 case LOAAN4: return "LOAAN4"; 1741 case LOAAP: return "LOAAP"; 1742 case LOAAP1: return "LOAAP1"; 1743 case LOAAP2: return "LOAAP2"; 1744 case LOAAP3: return "LOAAP3"; 1745 case LOAAP4: return "LOAAP4"; 1746 case LOAAS: return "LOAAS"; 1747 case LOAAS1: return "LOAAS1"; 1748 case LOAAS2: return "LOAAS2"; 1749 case LOAAS3: return "LOAAS3"; 1750 case LOAAS4: return "LOAAS4"; 1751 case LOACM: return "LOACM"; 1752 case LOACM1: return "LOACM1"; 1753 case LOACM2: return "LOACM2"; 1754 case LOACM3: return "LOACM3"; 1755 case LOACM4: return "LOACM4"; 1756 case LOAID: return "LOAID"; 1757 case LOAID1: return "LOAID1"; 1758 case LOAID2: return "LOAID2"; 1759 case LOAID3: return "LOAID3"; 1760 case LOAID4: return "LOAID4"; 1761 case LOANR: return "LOANR"; 1762 case LOANR1: return "LOANR1"; 1763 case LOANR2: return "LOANR2"; 1764 case LOANR3: return "LOANR3"; 1765 case LOANR4: return "LOANR4"; 1766 case LOARA: return "LOARA"; 1767 case LOARA1: return "LOARA1"; 1768 case LOARA2: return "LOARA2"; 1769 case LOARA3: return "LOARA3"; 1770 case LOARA4: return "LOARA4"; 1771 case LOATK: return "LOATK"; 1772 case LOATK1: return "LOATK1"; 1773 case LOATK2: return "LOATK2"; 1774 case LOATK3: return "LOATK3"; 1775 case LOATK4: return "LOATK4"; 1776 case TRSTMECOBV: return "TRSTMECOBV"; 1777 case _SEVERITYOBSERVATION: return "_SeverityObservation"; 1778 case H: return "H"; 1779 case L: return "L"; 1780 case M: return "M"; 1781 case _SUBJECTBODYPOSITION: return "_SubjectBodyPosition"; 1782 case LLD: return "LLD"; 1783 case PRN: return "PRN"; 1784 case RLD: return "RLD"; 1785 case SFWL: return "SFWL"; 1786 case SIT: return "SIT"; 1787 case STN: return "STN"; 1788 case SUP: return "SUP"; 1789 case RTRD: return "RTRD"; 1790 case TRD: return "TRD"; 1791 case _VERIFICATIONOUTCOMEVALUE: return "_VerificationOutcomeValue"; 1792 case ACT: return "ACT"; 1793 case ACTPEND: return "ACTPEND"; 1794 case ELG: return "ELG"; 1795 case INACT: return "INACT"; 1796 case INPNDINV: return "INPNDINV"; 1797 case INPNDUPD: return "INPNDUPD"; 1798 case NELG: return "NELG"; 1799 case _ANNOTATIONVALUE: return "_AnnotationValue"; 1800 case _COMMONCLINICALOBSERVATIONVALUE: return "_CommonClinicalObservationValue"; 1801 case _INDIVIDUALCASESAFETYREPORTVALUEDOMAINS: return "_IndividualCaseSafetyReportValueDomains"; 1802 case _INDICATIONVALUE: return "_IndicationValue"; 1803 default: return "?"; 1804 } 1805 } 1806 public String getSystem() { 1807 return "http://hl7.org/fhir/v3/ObservationValue"; 1808 } 1809 public String getDefinition() { 1810 switch (this) { 1811 case _ACTCOVERAGEASSESSMENTOBSERVATIONVALUE: return "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."; 1812 case _ACTFINANCIALSTATUSOBSERVATIONVALUE: return "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."; 1813 case ASSET: return "Codes specifying asset indicators used to assess or establish eligibility for coverage under a policy or program."; 1814 case ANNUITY: return "Indicator of annuity ownership or status as beneficiary."; 1815 case PROP: return "Indicator of real property ownership, e.g., deed or real estate contract."; 1816 case RETACCT: return "Indicator of retirement investment account ownership."; 1817 case TRUST: return "Indicator of status as trust beneficiary."; 1818 case INCOME: return "Code specifying income indicators used to assess or establish eligibility for coverage under a policy or program; e.g., pay or pension check, child support payments received or provided, and taxes paid."; 1819 case CHILD: return "Indicator of child support payments received or provided."; 1820 case DISABL: return "Indicator of disability income replacement payment."; 1821 case INVEST: return "Indicator of investment income, e.g., dividend check, annuity payment; real estate rent, investment divestiture proceeds; trust or endowment check."; 1822 case PAY: return "Indicator of paid employment, e.g., letter of hire, contract, employer letter; copy of pay check or pay stub."; 1823 case RETIRE: return "Indicator of retirement payment, e.g., pension check."; 1824 case SPOUSAL: return "Indicator of spousal or partner support payments received or provided; e.g., alimony payment; support stipulations in a divorce settlement."; 1825 case SUPPLE: return "Indicator of income supplement, e.g., gifting, parental income support; stipend, or grant."; 1826 case TAX: return "Indicator of tax obligation or payment, e.g., statement of taxable income."; 1827 case LIVEXP: return "Codes specifying living expense indicators used to assess or establish eligibility for coverage under a policy or program."; 1828 case CLOTH: return "Indicator of clothing expenses."; 1829 case FOOD: return "Indicator of transportation expenses."; 1830 case HEALTH: return "Indicator of health expenses; including medication costs, health service costs, financial participations, and health coverage premiums."; 1831 case HOUSE: return "Indicator of housing expense, e.g., household appliances, fixtures, furnishings, and maintenance and repairs."; 1832 case LEGAL: return "Indicator of legal expenses."; 1833 case MORTG: return "Indicator of mortgage amount, interest, and payments."; 1834 case RENT: return "Indicator of rental or lease payments."; 1835 case SUNDRY: return "Indicator of transportation expenses."; 1836 case TRANS: return "Indicator of transportation expenses, e.g., vehicle payments, vehicle insurance, vehicle fuel, and vehicle maintenance and repairs."; 1837 case UTIL: return "Indicator of transportation expenses."; 1838 case ELSTAT: return "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."; 1839 case ADOPT: return "Indicator of adoption."; 1840 case BTHCERT: return "Indicator of birth."; 1841 case CCOC: return "Indicator of creditable coverage."; 1842 case DRLIC: return "Indicator of driving status."; 1843 case FOSTER: return "Indicator of foster child status."; 1844 case MEMBER: return "Indicator of status as covered member under a policy or program, e.g., member id card or coverage document."; 1845 case MIL: return "Indicator of military status."; 1846 case MRGCERT: return "Indicator of marriage status."; 1847 case PASSPORT: return "Indicator of citizenship."; 1848 case STUDENRL: return "Indicator of student status."; 1849 case HLSTAT: return "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."; 1850 case DISABLE: return "Indication of disability."; 1851 case DRUG: return "Indication of drug use."; 1852 case IVDRG: return "Indication of IV drug use ."; 1853 case PGNT: return "Non-clinical report of pregnancy."; 1854 case LIVDEP: return "Code specifying observations related to living dependency, such as dependent upon spouse for activities of daily living."; 1855 case RELDEP: return "Continued living in private residence requires functional and health care assistance from one or more relatives."; 1856 case SPSDEP: return "Continued living in private residence requires functional and health care assistance from spouse or life partner."; 1857 case URELDEP: return "Continued living in private residence requires functional and health care assistance from one or more unrelated persons."; 1858 case LIVSIT: return "Code specifying observations related to living situation for a person in a private residence."; 1859 case ALONE: return "Living alone. Maps to PD1-2 Living arrangement (IS) 00742 [A]"; 1860 case DEPCHD: return "Living with one or more dependent children requiring moderate supervision."; 1861 case DEPSPS: return "Living with disabled spouse requiring functional and health care assistance"; 1862 case DEPYGCHD: return "Living with one or more dependent children requiring intensive supervision"; 1863 case FAM: return "Living with family. Maps to PD1-2 Living arrangement (IS) 00742 [F]"; 1864 case RELAT: return "Living with one or more relatives. Maps to PD1-2 Living arrangement (IS) 00742 [R]"; 1865 case SPS: return "Living only with spouse or life partner. Maps to PD1-2 Living arrangement (IS) 00742 [S]"; 1866 case UNREL: return "Living with one or more unrelated persons."; 1867 case SOECSTAT: return "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."; 1868 case ABUSE: return "Indication of abuse victim."; 1869 case HMLESS: return "Indication of status as homeless."; 1870 case ILGIM: return "Indication of status as illegal immigrant."; 1871 case INCAR: return "Indication of status as incarcerated."; 1872 case PROB: return "Indication of probation status."; 1873 case REFUG: return "Indication of refugee status."; 1874 case UNEMPL: return "Indication of unemployed status."; 1875 case _ALLERGYTESTVALUE: return "Indicates the result of a particular allergy test. E.g. Negative, Mild, Moderate, Severe"; 1876 case A0: return "Description:Patient exhibits no reaction to the challenge agent."; 1877 case A1: return "Description:Patient exhibits a minimal reaction to the challenge agent."; 1878 case A2: return "Description:Patient exhibits a mild reaction to the challenge agent."; 1879 case A3: return "Description:Patient exhibits moderate reaction to the challenge agent."; 1880 case A4: return "Description:Patient exhibits a severe reaction to the challenge agent."; 1881 case _COMPOSITEMEASURESCORING: return "Observation values that communicate the method used in a quality measure to combine the component measure results included in an composite measure."; 1882 case ALLORNONESCR: return "Code specifying that the measure uses all-or-nothing scoring. All-or-nothing scoring places an individual in the numerator of the composite measure if and only if they are in the numerator of all component measures in which they are in the denominator."; 1883 case LINEARSCR: return "Code specifying that the measure uses linear scoring. Linear scoring computes the fraction of component measures in which the individual appears in the numerator, giving equal weight to each component measure."; 1884 case OPPORSCR: return "Code specifying that the measure uses opportunity-based scoring. In opportunity-based scoring the measure score is determined by combining the denominator and numerator of each component measure to determine an overall composite score."; 1885 case WEIGHTSCR: return "Code specifying that the measure uses weighted scoring. Weighted scoring assigns a factor to each component measure to weight that measure's contribution to the overall score."; 1886 case _COVERAGELIMITOBSERVATIONVALUE: return "Description:Coded observation values for coverage limitations, for e.g., types of claims or types of parties covered under a policy or program."; 1887 case _COVERAGELEVELOBSERVATIONVALUE: return "Description:Coded observation values for types of covered parties under a policy or program based on their personal relationships or employment status."; 1888 case ADC: return "Description:Child over an age as specified by coverage policy or program, e.g., student, differently abled, and income dependent."; 1889 case CHD: return "Description:Dependent biological, adopted, foster child as specified by coverage policy or program."; 1890 case DEP: return "Description:Person requiring functional and/or financial assistance from another person as specified by coverage policy or program."; 1891 case DP: return "Description:Persons registered as a family unit in a domestic partner registry as specified by law and by coverage policy or program."; 1892 case ECH: return "Description:An individual employed by an employer who receive remuneration in wages, salary, commission, tips, piece-rates, or pay-in-kind through the employeraTMs payment system (i.e., not a contractor) as specified by coverage policy or program."; 1893 case FLY: return "Description:As specified by coverage policy or program."; 1894 case IND: return "Description:Person as specified by coverage policy or program."; 1895 case SSP: return "Description:A pair of people of the same gender who live together as a family as specified by coverage policy or program, e.g., Naomi and Ruth from the Book of Ruth; Socrates and Alcibiades"; 1896 case _CRITICALITYOBSERVATIONVALUE: return "A clinical judgment as to the worst case result of a future exposure (including substance administration). When the worst case result is assessed to have a life-threatening or organ system threatening potential, it is considered to be of high criticality."; 1897 case CRITH: return "Worst case result of a future exposure is assessed to be life-threatening or having high potential for organ system failure."; 1898 case CRITL: return "Worst case result of a future exposure is not assessed to be life-threatening or having high potential for organ system failure."; 1899 case CRITU: return "Unable to assess the worst case result of a future exposure."; 1900 case _GENETICOBSERVATIONVALUE: return "Description: The domain contains genetic analysis specific observation values, e.g. Homozygote, Heterozygote, etc."; 1901 case HOMOZYGOTE: return "Description: An individual having different alleles at one or more loci regarding a specific character"; 1902 case _OBSERVATIONMEASURESCORING: return "Observation values used to indicate the type of scoring (e.g. proportion, ratio) used by a health quality measure."; 1903 case COHORT: return "A measure in which either short-term cross-section or long-term longitudinal analysis is performed over a group of subjects defined by a set of common properties or defining characteristics (e.g., Male smokers between the ages of 40 and 50 years, exposure to treatment, exposure duration)."; 1904 case CONTVAR: return "A measure score in which each individual value for the measure can fall anywhere along a continuous scale (e.g., mean time to thrombolytics which aggregates the time in minutes from a case presenting with chest pain to the time of administration of thrombolytics)."; 1905 case PROPOR: return "A score derived by dividing the number of cases that meet a criterion for quality (the numerator) by the number of eligible cases within a given time frame (the denominator) where the numerator cases are a subset of the denominator cases (e.g., percentage of eligible women with a mammogram performed in the last year)."; 1906 case RATIO: return "A score that may have a value of zero or greater that is derived by dividing a count of one type of data by a count of another type of data (e.g., the number of patients with central lines who develop infection divided by the number of central line days)."; 1907 case _OBSERVATIONMEASURETYPE: return "Observation values used to indicate what kind of health quality measure is used."; 1908 case COMPOSITE: return "A measure that is composed from one or more other measures and indicates an overall summary of those measures."; 1909 case EFFICIENCY: return "A measure related to the efficiency of medical treatment."; 1910 case EXPERIENCE: return "A measure related to the level of patient engagement or patient experience of care."; 1911 case OUTCOME: return "A measure that indicates the result of the performance (or non-performance) of a function or process."; 1912 case PROCESS: return "A measure which focuses on a process which leads to a certain outcome, meaning that a scientific basis exists for believing that the process, when executed well, will increase the probability of achieving a desired outcome."; 1913 case RESOURCE: return "A measure related to the extent of use of clinical resources or cost of care."; 1914 case STRUCTURE: return "A measure related to the structure of patient care."; 1915 case _OBSERVATIONPOPULATIONINCLUSION: return "Observation values used to assert various populations that a subject falls into."; 1916 case DENEX: return "Patients who should be removed from the eMeasure population and denominator before determining if numerator criteria are met. Denominator exclusions are used in proportion and ratio measures to help narrow the denominator."; 1917 case DENEXCEP: return "Denominator exceptions are those conditions that should remove a patient, procedure or unit of measurement from the denominator only if the numerator criteria are not met. Denominator exceptions allow for adjustment of the calculated score for those providers with higher risk populations. Denominator exceptions are used only in proportion eMeasures. They are not appropriate for ratio or continuous variable eMeasures. Denominator exceptions allow for the exercise of clinical judgment and should be specifically defined where capturing the information in a structured manner fits the clinical workflow. Generic denominator exception reasons used in proportion eMeasures fall into three general categories:\r\n\n \n Medical reasons\n Patient reasons\n System reasons"; 1918 case DENOM: return "It can be the same as the initial patient population or a subset of the initial patient population to further constrain the population for the purpose of the eMeasure. Different measures within an eMeasure set may have different Denominators. Continuous Variable eMeasures do not have a Denominator, but instead define a Measure Population."; 1919 case IP: return "The initial population refers to all entities to be evaluated by a specific quality measure who share a common set of specified characteristics within a specific measurement set to which a given measure belongs."; 1920 case IPP: return "The initial patient population refers to all patients to be evaluated by a specific quality measure who share a common set of specified characteristics within a specific measurement set to which a given measure belongs. Details often include information based upon specific age groups, diagnoses, diagnostic and procedure codes, and enrollment periods."; 1921 case MSRPOPL: return "Measure population is used only in continuous variable eMeasures. It is a narrative description of the eMeasure population. \n(e.g., all patients seen in the Emergency Department during the measurement period)."; 1922 case NUMER: return "Numerators are used in proportion and ratio eMeasures. In proportion measures the numerator criteria are the processes or outcomes expected for each patient, procedure, or other unit of measurement defined in the denominator. In ratio measures the numerator is related, but not directly derived from the denominator (e.g., a numerator listing the number of central line blood stream infections and a denominator indicating the days per thousand of central line usage in a specific time period)."; 1923 case NUMEX: return "Numerator Exclusions are used only in ratio eMeasures to define instances that should not be included in the numerator data. (e.g., if the number of central line blood stream infections per 1000 catheter days were to exclude infections with a specific bacterium, that bacterium would be listed as a numerator exclusion.)"; 1924 case _PARTIALCOMPLETIONSCALE: return "PartialCompletionScale"; 1925 case G: return "Value for Act.partialCompletionCode attribute that implies 81-99% completion"; 1926 case LE: return "Value for Act.partialCompletionCode attribute that implies 61-80% completion"; 1927 case ME: return "Value for Act.partialCompletionCode attribute that implies 41-60% completion"; 1928 case MI: return "Value for Act.partialCompletionCode attribute that implies 1-20% completion"; 1929 case N: return "Value for Act.partialCompletionCode attribute that implies 0% completion"; 1930 case S: return "Value for Act.partialCompletionCode attribute that implies 21-40% completion"; 1931 case _SECURITYOBSERVATIONVALUE: return "Observation values used to indicate security observation metadata."; 1932 case _SECINTOBV: return "Abstract security observation values used to indicate security integrity metadata.\r\n\n \n Examples: Codes conveying integrity status, integrity confidence, and provenance."; 1933 case _SECALTINTOBV: return "Abstract security metadata observation values used to indicate mechanism used for authorized alteration of an IT resource (data, information object, service, or system capability)"; 1934 case ABSTRED: return "Security metadata observation values used to indicate the use of a more abstract version of the content, e.g., replacing exact value of an age or date field with a range, or remove the left digits of a credit card number or SSN."; 1935 case AGGRED: return "Security metadata observation values used to indicate the use of an algorithmic combination of actual values with the result of an aggregate function, e.g., average, sum, or count in order to limit disclosure of an IT resource (data, information object, service, or system capability) to the minimum necessary."; 1936 case ANONYED: return "Security metadata observation value conveying the alteration integrity of an IT resource (data, information object, service, or system capability) by used to indicate the mechanism by which software systems can strip portions of the resource that could allow the identification of the source of the information or the information subject. No key to relink the data is retained."; 1937 case MAPPED: return "Security metadata observation value used to indicate that the IT resource semantic content has been transformed from one encoding to another.\r\n\n \n Usage Note: \"MAP\" code does not indicate the semantic fidelity of the transformed content.\r\n\n To indicate semantic fidelity for maps of HL7 to other code systems, this security alteration integrity observation may be further specified using an Act valued with Value Set: MapRelationship (2.16.840.1.113883.1.11.11052).\r\n\n Semantic fidelity of the mapped IT Resource may also be indicated using a SecurityIntegrityConfidenceObservation."; 1938 case MASKED: return "Security metadata observation value conveying the alteration integrity of an IT resource (data, information object, service, or system capability) by indicating the mechanism by which software systems can make data unintelligible (that is, as unreadable and unusable by algorithmically transforming plaintext into ciphertext) such that it can only be accessed or used by authorized users. An authorized user may be provided a key to decrypt per license or \"shared secret\".\r\n\n \n Usage Note: \"MASKED\" may be used, per applicable policy, as a flag to indicate to a user or receiver that some portion of an IT resource has been further encrypted, and may be accessed only by an authorized user or receiver to which a decryption key is provided."; 1939 case PSEUDED: return "Security metadata observation value conveying the alteration integrity of an IT resource (data, information object, service, or system capability), by indicating the mechanism by which software systems can strip portions of the resource that could allow the identification of the source of the information or the information subject. Custodian may retain a key to relink data necessary to reidentify the information subject.\r\n\n \n Rationale: Personal data which has been processed to make it impossible to know whose data it is. Used particularly for secondary use of health data. In some cases, it may be possible for authorized individuals to restore the identity of the individual, e.g.,for public health case management. Based on ISO/TS 25237:2008 Health informatics—Pseudonymization"; 1940 case REDACTED: return "Security metadata observation value used to indicate the mechanism by which software systems can filter an IT resource (data, information object, service, or system capability) to remove any portion of the resource that is not authorized to be access, used, or disclosed.\r\n\n \n Usage Note: \"REDACTED\" may be used, per applicable policy, as a flag to indicate to a user or receiver that some portion of an IT resource has filtered and not included in the content accessed or received."; 1941 case SUBSETTED: return "Metadata observation used to indicate that some information has been removed from the source object when the view this object contains was constructed because of configuration options when the view was created. The content may not be suitable for use as the basis of a record update\r\n\n \n Usage Note: This is not suitable to be used when information is removed for security reasons - see the code REDACTED for this use."; 1942 case SYNTAC: return "Security metadata observation value used to indicate that the IT resource syntax has been transformed from one syntactical representation to another. \r\n\n \n Usage Note: \"SYNTAC\" code does not indicate the syntactical correctness of the syntactically transformed IT resource."; 1943 case TRSLT: return "Security metadata observation value used to indicate that the IT resource has been translated from one human language to another. \r\n\n \n Usage Note: \"TRSLT\" does not indicate the fidelity of the translation or the languages translated.\r\n\n The fidelity of the IT Resource translation may be indicated using a SecurityIntegrityConfidenceObservation.\r\n\n To indicate languages, use the Value Set:HumanLanguage (2.16.840.1.113883.1.11.11526)"; 1944 case VERSIONED: return "Security metadata observation value conveying the alteration integrity of an IT resource (data, information object, service, or system capability) which indicates that the resource only retains versions of an IT resource for access and use per applicable policy\r\n\n \n Usage Note: When this code is used, expectation is that the system has removed historical versions of the data that falls outside the time period deemed to be the effective time of the applicable version."; 1945 case _SECDATINTOBV: return "Abstract security observation values used to indicate data integrity metadata.\r\n\n \n Examples: Codes conveying the mechanism used to preserve the accuracy and consistency of an IT resource such as a digital signature and a cryptographic hash function."; 1946 case CRYTOHASH: return "Security metadata observation value used to indicate the mechanism by which software systems can establish that data was not modified in transit.\r\n\n \n Rationale: This definition is intended to align with the ISO 22600-2 3.3.19 definition of cryptographic checkvalue: Information which is derived by performing a cryptographic transformation (see cryptography) on the data unit. The derivation of the checkvalue may be performed in one or more steps and is a result of a mathematical function of the key and a data unit. It is usually used to check the integrity of a data unit.\r\n\n \n Examples: \n \r\n\n \n SHA-1\n SHA-2 (Secure Hash Algorithm)"; 1947 case DIGSIG: return "Security metadata observation value used to indicate the mechanism by which software systems use digital signature to establish that data has not been modified. \r\n\n \n Rationale: This definition is intended to align with the ISO 22600-2 3.3.26 definition of digital signature: Data appended to, or a cryptographic transformation (see cryptography) of, a data unit that allows a recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g., by the recipient."; 1948 case _SECINTCONOBV: return "Abstract security observation value used to indicate integrity confidence metadata.\r\n\n \n Examples: Codes conveying the level of reliability and trustworthiness of an IT resource."; 1949 case HRELIABLE: return "Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be very high."; 1950 case RELIABLE: return "Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be adequate."; 1951 case UNCERTREL: return "Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be uncertain."; 1952 case UNRELIABLE: return "Security metadata observation value used to indicate that the veracity or trustworthiness of an IT resource (data, information object, service, or system capability) for a specified purpose of use is perceived to be or deemed by policy to be inadequate."; 1953 case _SECINTPRVOBV: return "Abstract security metadata observation value used to indicate the provenance of an IT resource (data, information object, service, or system capability).\r\n\n \n Examples: Codes conveying the provenance metadata about the entity reporting an IT resource."; 1954 case _SECINTPRVABOBV: return "Abstract security provenance metadata observation value used to indicate the entity that asserted an IT resource (data, information object, service, or system capability).\r\n\n \n Examples: Codes conveying the provenance metadata about the entity asserting the resource."; 1955 case CLINAST: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a clinician."; 1956 case DEVAST: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a device."; 1957 case HCPAST: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a healthcare professional."; 1958 case PACQAST: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a patient acquaintance."; 1959 case PATAST: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a patient."; 1960 case PAYAST: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a payer."; 1961 case PROAST: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a professional."; 1962 case SDMAST: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a substitute decision maker."; 1963 case _SECINTPRVRBOBV: return "Abstract security provenance metadata observation value used to indicate the entity that reported the resource (data, information object, service, or system capability).\r\n\n \n Examples: Codes conveying the provenance metadata about the entity reporting an IT resource."; 1964 case CLINRPT: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a clinician."; 1965 case DEVRPT: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a device."; 1966 case HCPRPT: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a healthcare professional."; 1967 case PACQRPT: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a patient acquaintance."; 1968 case PATRPT: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a patient."; 1969 case PAYRPT: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a payer."; 1970 case PRORPT: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a professional."; 1971 case SDMRPT: return "Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a substitute decision maker."; 1972 case SECTRSTOBV: return "Observation value used to indicate aspects of trust applicable to an IT resource (data, information object, service, or system capability)."; 1973 case TRSTACCRDOBV: return "Values for security trust accreditation 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."; 1974 case TRSTAGREOBV: return "Values for security trust agreement metadata observation made about privacy and security requirements with which a security domain must comply. [ISO IEC 10181-1]\n[ISO IEC 10181-1]"; 1975 case TRSTCERTOBV: return "Values for security trust certificate 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]\r\n\n For example, a Certificate Policy (CP), which is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. A particular Certificate Policy might indicate the applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. Another example is Cross Certification with Federal Bridge."; 1976 case TRSTLOAOBV: return "Values for security trust assurance metadata observation made about the digital quality or reliability of a trust assertion, activity, capability, information exchange, mechanism, process, or protocol."; 1977 case LOAAN: return "The value assigned as the indicator of the digital quality or reliability of the verification and validation process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2]\r\n\n For example, the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies]"; 1978 case LOAAN1: return "Indicator of low digital quality or reliability of the digital reliability of the verification and validation process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2] \r\n\n The degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies] \r\n\n Low authentication level of assurance indicates that the relying party may have little or no confidence in the asserted identity's validity. Level 1 requires little or no confidence in the asserted identity. No identity proofing is required at this level, but the authentication mechanism should provide some assurance that the same claimant is accessing the protected transaction or data. A wide range of available authentication technologies can be employed and any of the token methods of Levels 2, 3, or 4, including Personal Identification Numbers (PINs), may be used. To be authenticated, the claimant must prove control of the token through a secure authentication protocol. At Level 1, long-term shared authentication secrets may be revealed to verifiers. Assertions issued about claimants as a result of a successful authentication are either cryptographically authenticated by relying parties (using approved methods) or are obtained directly from a trusted party via a secure authentication protocol. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1979 case LOAAN2: return "Indicator of basic digital quality or reliability of the digital reliability of the verification and validation process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2] \r\n\n The degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies]\r\n\n Basic authentication level of assurance indicates that the relying party may have some confidence in the asserted identity's validity. Level 2 requires confidence that the asserted identity is accurate. Level 2 provides for single-factor remote network authentication, including identity-proofing requirements for presentation of identifying materials or information. A wide range of available authentication technologies can be employed, including any of the token methods of Levels 3 or 4, as well as passwords. Successful authentication requires that the claimant prove through a secure authentication protocol that the claimant controls the token. Eavesdropper, replay, and online guessing attacks are prevented. \nLong-term shared authentication secrets, if used, are never revealed to any party except the claimant and verifiers operated by the CSP; however, session (temporary) shared secrets may be provided to independent verifiers by the CSP. Approved cryptographic techniques are required. Assertions issued about claimants as a result of a successful authentication are either cryptographically authenticated by relying parties (using approved methods) or are obtained directly from a trusted party via a secure authentication protocol. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1980 case LOAAN3: return "Indicator of medium digital quality or reliability of the digital reliability of verification and validation of the process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2] \r\n\n The degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies] \r\n\n Medium authentication level of assurance indicates that the relying party may have high confidence in the asserted identity's validity. Level 3 is appropriate for transactions that need high confidence in the accuracy of the asserted identity. Level 3 provides multifactor remote network authentication. At this level, identity-proofing procedures require verification of identifying materials and information. Authentication is based on proof of possession of a key or password through a cryptographic protocol. Cryptographic strength mechanisms should protect the primary authentication token (a cryptographic key) against compromise by the protocol threats, including eavesdropper, replay, online guessing, verifier impersonation, and man-in-the-middle attacks. A minimum of two authentication factors is required. Three kinds of tokens may be used:\r\n\n \n \"soft\" cryptographic token, which has the key stored on a general-purpose computer, \n \"hard\" cryptographic token, which has the key stored on a special hardware device, and \n \"one-time password\" device token, which has symmetric key stored on a personal hardware device that is a cryptographic module validated at FIPS 140-2 Level 1 or higher. Validation testing of cryptographic modules and algorithms for conformance to Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic Modules, is managed by NIST.\n \n Authentication requires that the claimant prove control of the token through a secure authentication protocol. The token must be unlocked with a password or biometric representation, or a password must be used in a secure authentication protocol, to establish two-factor authentication. Long-term shared authentication secrets, if used, are never revealed to any party except the claimant and verifiers operated directly by the CSP; however, session (temporary) shared secrets may be provided to independent verifiers by the CSP. Approved cryptographic techniques are used for all operations. Assertions issued about claimants as a result of a successful authentication are either cryptographically authenticated by relying parties (using approved methods) or are obtained directly from a trusted party via a secure authentication protocol. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1981 case LOAAN4: return "Indicator of high digital quality or reliability of the digital reliability of the verification and validation process used to verify the claimed identity of an entity by securely associating an identifier and its authenticator. [Based on ISO 7498-2] \r\n\n The degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. [OMB M-04-04 E-Authentication Guidance for Federal Agencies]\r\n\n High authentication level of assurance indicates that the relying party may have very high confidence in the asserted identity's validity. Level 4 is for transactions that need very high confidence in the accuracy of the asserted identity. Level 4 provides the highest practical assurance of remote network authentication. Authentication is based on proof of possession of a key through a cryptographic protocol. This level is similar to Level 3 except that only “hard� cryptographic tokens are allowed, cryptographic module validation requirements are strengthened, and subsequent critical data transfers must be authenticated via a key that is bound to the authentication process. The token should be a hardware cryptographic module validated at FIPS 140-2 Level 2 or higher overall with at least FIPS 140-2 Level 3 physical security. This level requires a physical token, which cannot readily be copied, and operator authentication at Level 2 and higher, and ensures good, two-factor remote authentication.\r\n\n Level 4 requires strong cryptographic authentication of all parties and all sensitive data transfers between the parties. Either public key or symmetric key technology may be used. Authentication requires that the claimant prove through a secure authentication protocol that the claimant controls the token. Eavesdropper, replay, online guessing, verifier impersonation, and man-in-the-middle attacks are prevented. Long-term shared authentication secrets, if used, are never revealed to any party except the claimant and verifiers operated directly by the CSP; however, session (temporary) shared secrets may be provided to independent verifiers by the CSP. Strong approved cryptographic techniques are used for all operations. All sensitive data transfers are cryptographically authenticated using keys bound to the authentication process. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1982 case LOAAP: return "The value assigned as the indicator of the digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2]"; 1983 case LOAAP1: return "Indicator of the low digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2]\r\n\n Low authentication process level of assurance indicates that (1) long-term shared authentication secrets may be revealed to verifiers; and (2) assertions and assertion references require protection from manufacture/modification and reuse attacks. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1984 case LOAAP2: return "Indicator of the basic digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2]\r\n\n Basic authentication process level of assurance indicates that long-term shared authentication secrets are never revealed to any other party except Credential Service Provider (CSP). Sessions (temporary) shared secrets may be provided to independent verifiers by CSP. Long-term shared authentication secrets, if used, are never revealed to any other party except Verifiers operated by the Credential Service Provider (CSP); however, session (temporary) shared secrets may be provided to independent Verifiers by the CSP. In addition to Level 1 requirements, assertions are resistant to disclosure, redirection, capture and substitution attacks. Approved cryptographic techniques are required. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1985 case LOAAP3: return "Indicator of the medium digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2]\r\n\n Medium authentication process level of assurance indicates that the token can be unlocked with password, biometric, or uses a secure multi-token authentication protocol to establish two-factor authentication. Long-term shared authentication secrets are never revealed to any party except the Claimant and Credential Service Provider (CSP).\r\n\n Authentication requires that the Claimant prove, through a secure authentication protocol, that he or she controls the token. The Claimant unlocks the token with a password or biometric, or uses a secure multi-token authentication protocol to establish two-factor authentication (through proof of possession of a physical or software token in combination with some memorized secret knowledge). Long-term shared authentication secrets, if used, are never revealed to any party except the Claimant and Verifiers operated directly by the CSP; however, session (temporary) shared secrets may be provided to independent Verifiers by the CSP. In addition to Level 2 requirements, assertions are protected against repudiation by the Verifier."; 1986 case LOAAP4: return "Indicator of the high digital quality or reliability of a defined sequence of messages between a Claimant and a Verifier that demonstrates that the Claimant has possession and control of a valid token to establish his/her identity, and optionally, demonstrates to the Claimant that he or she is communicating with the intended Verifier. [Based on NIST SP 800-63-2]\r\n\n High authentication process level of assurance indicates all sensitive data transfer are cryptographically authenticated using keys bound to the authentication process. Level 4 requires strong cryptographic authentication of all communicating parties and all sensitive data transfers between the parties. Either public key or symmetric key technology may be used. Authentication requires that the Claimant prove through a secure authentication protocol that he or she controls the token. All protocol threats at Level 3 are required to be prevented at Level 4. Protocols shall also be strongly resistant to man-in-the-middle attacks. Long-term shared authentication secrets, if used, are never revealed to any party except the Claimant and Verifiers operated directly by the CSP; however, session (temporary) shared secrets may be provided to independent Verifiers by the CSP. Approved cryptographic techniques are used for all operations. All sensitive data transfers are cryptographically authenticated using keys bound to the authentication process. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1987 case LOAAS: return "The value assigned as the indicator of the high quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes."; 1988 case LOAAS1: return "Indicator of the low quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes.\r\n\n Assertions and assertion references require protection from modification and reuse attacks. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1989 case LOAAS2: return "Indicator of the basic quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes.\r\n\n Assertions are resistant to disclosure, redirection, capture and substitution attacks. Approved cryptographic techniques are required for all assertion protocols. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1990 case LOAAS3: return "Indicator of the medium quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes.\r\n\n Assertions are protected against repudiation by the verifier. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1991 case LOAAS4: return "Indicator of the high quality or reliability of the statement from a Verifier to a Relying Party (RP) that contains identity information about a Subscriber. Assertions may also contain verified attributes.\r\n\n Strongly resistant to man-in-the-middle attacks. \"Bearer\" assertions are not used. \"Holder-of-key\" assertions may be used. RP maintains records of the assertions. [Summary of the technical requirements specified in NIST SP 800-63 for the four levels of assurance defined by the December 2003, the Office of Management and Budget (OMB) issued Memorandum M-04-04, E-Authentication Guidance for Federal Agencies.]"; 1992 case LOACM: return "Indicator of the digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and its binding to an identity. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 1993 case LOACM1: return "Indicator of the low digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and its binding to an identity. Little or no confidence that an individual has maintained control over a token that has been entrusted to him or her and that that token has not been compromised. Characteristics include weak identity binding to tokens and plaintext passwords or secrets not transmitted across a network. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 1994 case LOACM2: return "Indicator of the basic digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and its binding to an identity. Some confidence that an individual has maintained control over a token that has been entrusted to him or her and that that token has not been compromised. Characteristics include: Verification must prove claimant controls the token; token resists online guessing, replay, session hijacking, and eavesdropping attacks; and token is at least weakly resistant to man-in-the middle attacks. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 1995 case LOACM3: return "Indicator of the medium digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and it’s binding to an identity. High confidence that an individual has maintained control over a token that has been entrusted to him or her and that that token has not been compromised. Characteristics include: Ownership of token verifiable through security authentication protocol and credential management protects against verifier impersonation attacks. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 1996 case LOACM4: return "Indicator of the high digital quality or reliability of the activities performed by the Credential Service Provider (CSP) subsequent to electronic authentication registration, identity proofing and issuance activities to manage and safeguard the integrity of an issued credential and it’s binding to an identity. Very high confidence that an individual has maintained control over a token that has been entrusted to him or her and that that token has not been compromised. Characteristics include: Verifier can prove control of token through a secure protocol; credential management supports strong cryptographic authentication of all communication parties. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 1997 case LOAID: return "Indicator of the quality or reliability in the process of ascertaining that an individual is who he or she claims to be."; 1998 case LOAID1: return "Indicator of low digital quality or reliability in the process of ascertaining that an individual is who he or she claims to be. Requires that a continuity of identity be maintained but does not require identity proofing. [Based on Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 1999 case LOAID2: return "Indicator of some digital quality or reliability in the process of ascertaining that that an individual is who he or she claims to be. Requires identity proofing via presentation of identifying material or information. [Based on Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 2000 case LOAID3: return "Indicator of high digital quality or reliability in the process of ascertaining that an individual is who he or she claims to be. Requires identity proofing procedures for verification of identifying materials and information. [Based on Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 2001 case LOAID4: return "Indicator of high digital quality or reliability in the process of ascertaining that an individual is who he or she claims to be. Requires identity proofing procedures for verification of identifying materials and information. [Based on Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 2002 case LOANR: return "Indicator of the digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2]"; 2003 case LOANR1: return "Indicator of low digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2]"; 2004 case LOANR2: return "Indicator of basic digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2]"; 2005 case LOANR3: return "Indicator of medium digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2]"; 2006 case LOANR4: return "Indicator of high digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2]"; 2007 case LOARA: return "Indicator of the digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls. [Based on NIST SP 800-63-2]"; 2008 case LOARA1: return "Indicator of low digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls. [Based on NIST SP 800-63-2]"; 2009 case LOARA2: return "Indicator of basic digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls. [Based on NIST SP 800-63-2]"; 2010 case LOARA3: return "Indicator of medium digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization’s security controls. [Based on NIST SP 800-63-2]"; 2011 case LOARA4: return "Indicator of high digital quality or reliability of the information exchange between network-connected devices where the information cannot be reliably protected end-to-end by a single organization's security controls. [Based on NIST SP 800-63-2]"; 2012 case LOATK: return "Indicator of the digital quality or reliability of single and multi-token authentication. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 2013 case LOATK1: return "Indicator of the low digital quality or reliability of single and multi-token authentication. Permits the use of any of the token methods of Levels 2, 3, or 4. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 2014 case LOATK2: return "Indicator of the basic digital quality or reliability of single and multi-token authentication. Requires single factor authentication using memorized secret tokens, pre-registered knowledge tokens, look-up secret tokens, out of band tokens, or single factor one-time password devices. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 2015 case LOATK3: return "Indicator of the medium digital quality or reliability of single and multi-token authentication. Requires two authentication factors. Provides multi-factor remote network authentication. Permits multi-factor software cryptographic token. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 2016 case LOATK4: return "Indicator of the high digital quality or reliability of single and multi-token authentication. Requires token that is a hardware cryptographic module validated at validated at Federal Information Processing Standard (FIPS) 140-2 Level 2 or higher overall with at least FIPS 140-2 Level 3 physical security. Level 4 token requirements can be met by using the PIV authentication key of a FIPS 201 compliant Personal Identity Verification (PIV) Card. [Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-63-1, Dec 2011]"; 2017 case TRSTMECOBV: return "Values for security trust mechanism metadata observation made about a security architecture system component that supports enforcement of security policies."; 2018 case _SEVERITYOBSERVATION: return "Potential values for observations of severity."; 2019 case H: return "Indicates the condition may be life-threatening or has the potential to cause permanent injury."; 2020 case L: return "Indicates the condition may result in some adverse consequences but is unlikely to substantially affect the situation of the subject."; 2021 case M: return "Indicates the condition may result in noticable adverse adverse consequences but is unlikely to be life-threatening or cause permanent injury."; 2022 case _SUBJECTBODYPOSITION: return "Contains codes for defining the observed, physical position of a subject, such as during an observation, assessment, collection of a specimen, etc. ECG waveforms and vital signs, such as blood pressure, are two examples where a general, observed position typically needs to be noted."; 2023 case LLD: return "Lying on the left side."; 2024 case PRN: return "Lying with the front or ventral surface downward; lying face down."; 2025 case RLD: return "Lying on the right side."; 2026 case SFWL: return "A semi-sitting position in bed with the head of the bed elevated approximately 45 degrees."; 2027 case SIT: return "Resting the body on the buttocks, typically with upper torso erect or semi erect."; 2028 case STN: return "To be stationary, upright, vertical, on one's legs."; 2029 case SUP: return "supine"; 2030 case RTRD: return "Lying on the back, on an inclined plane, typically about 30-45 degrees with head raised and feet lowered."; 2031 case TRD: return "Lying on the back, on an inclined plane, typically about 30-45 degrees, with head lowered and feet raised."; 2032 case _VERIFICATIONOUTCOMEVALUE: return "Values for observations of verification act results\r\n\n \n Examples: Verified, not verified, verified with warning."; 2033 case ACT: return "Definition: Coverage is in effect for healthcare service(s) and/or product(s)."; 2034 case ACTPEND: return "Definition: Coverage is in effect for healthcare service(s) and/or product(s) - Pending Investigation"; 2035 case ELG: return "Definition: Coverage is in effect for healthcare service(s) and/or product(s)."; 2036 case INACT: return "Definition: Coverage is not in effect for healthcare service(s) and/or product(s)."; 2037 case INPNDINV: return "Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Investigation."; 2038 case INPNDUPD: return "Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Eligibility Update."; 2039 case NELG: return "Definition: Coverage is not in effect for healthcare service(s) and/or product(s). May optionally include reasons for the ineligibility."; 2040 case _ANNOTATIONVALUE: return "AnnotationValue"; 2041 case _COMMONCLINICALOBSERVATIONVALUE: return "Description:Used in a patient care message to value simple clinical (non-lab) observations."; 2042 case _INDIVIDUALCASESAFETYREPORTVALUEDOMAINS: return "This domain is established as a parent to a variety of value domains being defined to support the communication of Individual Case Safety Reports to regulatory bodies. Arguably, this aggregation is not taxonomically pure, but the grouping will facilitate the management of these domains."; 2043 case _INDICATIONVALUE: return "Indicates the specific observation result which is the reason for the action (prescription, lab test, etc.). E.g. Headache, Ear infection, planned diagnostic image (requiring contrast agent), etc."; 2044 default: return "?"; 2045 } 2046 } 2047 public String getDisplay() { 2048 switch (this) { 2049 case _ACTCOVERAGEASSESSMENTOBSERVATIONVALUE: return "ActCoverageAssessmentObservationValue"; 2050 case _ACTFINANCIALSTATUSOBSERVATIONVALUE: return "ActFinancialStatusObservationValue"; 2051 case ASSET: return "asset"; 2052 case ANNUITY: return "annuity"; 2053 case PROP: return "real property"; 2054 case RETACCT: return "retirement investment account"; 2055 case TRUST: return "trust"; 2056 case INCOME: return "income"; 2057 case CHILD: return "child support"; 2058 case DISABL: return "disability pay"; 2059 case INVEST: return "investment income"; 2060 case PAY: return "paid employment"; 2061 case RETIRE: return "retirement pay"; 2062 case SPOUSAL: return "spousal or partner support"; 2063 case SUPPLE: return "income supplement"; 2064 case TAX: return "tax obligation"; 2065 case LIVEXP: return "living expense"; 2066 case CLOTH: return "clothing expense"; 2067 case FOOD: return "food expense"; 2068 case HEALTH: return "health expense"; 2069 case HOUSE: return "household expense"; 2070 case LEGAL: return "legal expense"; 2071 case MORTG: return "mortgage"; 2072 case RENT: return "rent"; 2073 case SUNDRY: return "sundry expense"; 2074 case TRANS: return "transportation expense"; 2075 case UTIL: return "utility expense"; 2076 case ELSTAT: return "eligibility indicator"; 2077 case ADOPT: return "adoption document"; 2078 case BTHCERT: return "birth certificate"; 2079 case CCOC: return "creditable coverage document"; 2080 case DRLIC: return "driver license"; 2081 case FOSTER: return "foster child document"; 2082 case MEMBER: return "program or policy member"; 2083 case MIL: return "military identification"; 2084 case MRGCERT: return "marriage certificate"; 2085 case PASSPORT: return "passport"; 2086 case STUDENRL: return "student enrollment"; 2087 case HLSTAT: return "health status"; 2088 case DISABLE: return "disabled"; 2089 case DRUG: return "drug use"; 2090 case IVDRG: return "IV drug use"; 2091 case PGNT: return "pregnant"; 2092 case LIVDEP: return "living dependency"; 2093 case RELDEP: return "relative dependent"; 2094 case SPSDEP: return "spouse dependent"; 2095 case URELDEP: return "unrelated person dependent"; 2096 case LIVSIT: return "living situation"; 2097 case ALONE: return "alone"; 2098 case DEPCHD: return "dependent children"; 2099 case DEPSPS: return "dependent spouse"; 2100 case DEPYGCHD: return "dependent young children"; 2101 case FAM: return "live with family"; 2102 case RELAT: return "relative"; 2103 case SPS: return "spouse only"; 2104 case UNREL: return "unrelated person"; 2105 case SOECSTAT: return "socio economic status"; 2106 case ABUSE: return "abuse victim"; 2107 case HMLESS: return "homeless"; 2108 case ILGIM: return "illegal immigrant"; 2109 case INCAR: return "incarcerated"; 2110 case PROB: return "probation"; 2111 case REFUG: return "refugee"; 2112 case UNEMPL: return "unemployed"; 2113 case _ALLERGYTESTVALUE: return "AllergyTestValue"; 2114 case A0: return "no reaction"; 2115 case A1: return "minimal reaction"; 2116 case A2: return "mild reaction"; 2117 case A3: return "moderate reaction"; 2118 case A4: return "severe reaction"; 2119 case _COMPOSITEMEASURESCORING: return "CompositeMeasureScoring"; 2120 case ALLORNONESCR: return "All-or-nothing Scoring"; 2121 case LINEARSCR: return "Linear Scoring"; 2122 case OPPORSCR: return "Opportunity Scoring"; 2123 case WEIGHTSCR: return "Weighted Scoring"; 2124 case _COVERAGELIMITOBSERVATIONVALUE: return "CoverageLimitObservationValue"; 2125 case _COVERAGELEVELOBSERVATIONVALUE: return "CoverageLevelObservationValue"; 2126 case ADC: return "adult child"; 2127 case CHD: return "child"; 2128 case DEP: return "dependent"; 2129 case DP: return "domestic partner"; 2130 case ECH: return "employee"; 2131 case FLY: return "family coverage"; 2132 case IND: return "individual"; 2133 case SSP: return "same sex partner"; 2134 case _CRITICALITYOBSERVATIONVALUE: return "CriticalityObservationValue"; 2135 case CRITH: return "high criticality"; 2136 case CRITL: return "low criticality"; 2137 case CRITU: return "unable to assess criticality"; 2138 case _GENETICOBSERVATIONVALUE: return "GeneticObservationValue"; 2139 case HOMOZYGOTE: return "HOMO"; 2140 case _OBSERVATIONMEASURESCORING: return "ObservationMeasureScoring"; 2141 case COHORT: return "cohort measure scoring"; 2142 case CONTVAR: return "continuous variable measure scoring"; 2143 case PROPOR: return "proportion measure scoring"; 2144 case RATIO: return "ratio measure scoring"; 2145 case _OBSERVATIONMEASURETYPE: return "ObservationMeasureType"; 2146 case COMPOSITE: return "composite measure type"; 2147 case EFFICIENCY: return "efficiency measure type"; 2148 case EXPERIENCE: return "experience measure type"; 2149 case OUTCOME: return "outcome measure type"; 2150 case PROCESS: return "process measure type"; 2151 case RESOURCE: return "resource use measure type"; 2152 case STRUCTURE: return "structure measure type"; 2153 case _OBSERVATIONPOPULATIONINCLUSION: return "ObservationPopulationInclusion"; 2154 case DENEX: return "denominator exclusions"; 2155 case DENEXCEP: return "denominator exceptions"; 2156 case DENOM: return "denominator"; 2157 case IP: return "initial population"; 2158 case IPP: return "initial patient population"; 2159 case MSRPOPL: return "measure population"; 2160 case NUMER: return "numerator"; 2161 case NUMEX: return "numerator exclusions"; 2162 case _PARTIALCOMPLETIONSCALE: return "PartialCompletionScale"; 2163 case G: return "Great extent"; 2164 case LE: return "Large extent"; 2165 case ME: return "Medium extent"; 2166 case MI: return "Minimal extent"; 2167 case N: return "None"; 2168 case S: return "Some extent"; 2169 case _SECURITYOBSERVATIONVALUE: return "SecurityObservationValue"; 2170 case _SECINTOBV: return "security integrity"; 2171 case _SECALTINTOBV: return "alteration integrity"; 2172 case ABSTRED: return "abstracted"; 2173 case AGGRED: return "aggregated"; 2174 case ANONYED: return "anonymized"; 2175 case MAPPED: return "mapped"; 2176 case MASKED: return "masked"; 2177 case PSEUDED: return "pseudonymized"; 2178 case REDACTED: return "redacted"; 2179 case SUBSETTED: return "subsetted"; 2180 case SYNTAC: return "syntactic transform"; 2181 case TRSLT: return "translated"; 2182 case VERSIONED: return "versioned"; 2183 case _SECDATINTOBV: return "data integrity"; 2184 case CRYTOHASH: return "cryptographic hash function"; 2185 case DIGSIG: return "digital signature"; 2186 case _SECINTCONOBV: return "integrity confidence"; 2187 case HRELIABLE: return "highly reliable"; 2188 case RELIABLE: return "reliable"; 2189 case UNCERTREL: return "uncertain reliability"; 2190 case UNRELIABLE: return "unreliable"; 2191 case _SECINTPRVOBV: return "provenance"; 2192 case _SECINTPRVABOBV: return "provenance asserted by"; 2193 case CLINAST: return "clinician asserted"; 2194 case DEVAST: return "device asserted"; 2195 case HCPAST: return "healthcare professional asserted"; 2196 case PACQAST: return "patient acquaintance asserted"; 2197 case PATAST: return "patient asserted"; 2198 case PAYAST: return "payer asserted"; 2199 case PROAST: return "professional asserted"; 2200 case SDMAST: return "substitute decision maker asserted"; 2201 case _SECINTPRVRBOBV: return "provenance reported by"; 2202 case CLINRPT: return "clinician reported"; 2203 case DEVRPT: return "device reported"; 2204 case HCPRPT: return "healthcare professional reported"; 2205 case PACQRPT: return "patient acquaintance reported"; 2206 case PATRPT: return "patient reported"; 2207 case PAYRPT: return "payer reported"; 2208 case PRORPT: return "professional reported"; 2209 case SDMRPT: return "substitute decision maker reported"; 2210 case SECTRSTOBV: return "security trust observation"; 2211 case TRSTACCRDOBV: return "trust accreditation observation"; 2212 case TRSTAGREOBV: return "trust agreement observation"; 2213 case TRSTCERTOBV: return "trust certificate observation"; 2214 case TRSTLOAOBV: return "trust assurance observation"; 2215 case LOAAN: return "authentication level of assurance value"; 2216 case LOAAN1: return "low authentication level of assurance"; 2217 case LOAAN2: return "basic authentication level of assurance"; 2218 case LOAAN3: return "medium authentication level of assurance"; 2219 case LOAAN4: return "high authentication level of assurance"; 2220 case LOAAP: return "authentication process level of assurance value"; 2221 case LOAAP1: return "low authentication process level of assurance"; 2222 case LOAAP2: return "basic authentication process level of assurance"; 2223 case LOAAP3: return "medium authentication process level of assurance"; 2224 case LOAAP4: return "high authentication process level of assurance"; 2225 case LOAAS: return "assertion level of assurance value"; 2226 case LOAAS1: return "low assertion level of assurance"; 2227 case LOAAS2: return "basic assertion level of assurance"; 2228 case LOAAS3: return "medium assertion level of assurance"; 2229 case LOAAS4: return "high assertion level of assurance"; 2230 case LOACM: return "token and credential management level of assurance value)"; 2231 case LOACM1: return "low token and credential management level of assurance"; 2232 case LOACM2: return "basic token and credential management level of assurance"; 2233 case LOACM3: return "medium token and credential management level of assurance"; 2234 case LOACM4: return "high token and credential management level of assurance"; 2235 case LOAID: return "identity proofing level of assurance"; 2236 case LOAID1: return "low identity proofing level of assurance"; 2237 case LOAID2: return "basic identity proofing level of assurance"; 2238 case LOAID3: return "medium identity proofing level of assurance"; 2239 case LOAID4: return "high identity proofing level of assurance"; 2240 case LOANR: return "non-repudiation level of assurance value"; 2241 case LOANR1: return "low non-repudiation level of assurance"; 2242 case LOANR2: return "basic non-repudiation level of assurance"; 2243 case LOANR3: return "medium non-repudiation level of assurance"; 2244 case LOANR4: return "high non-repudiation level of assurance"; 2245 case LOARA: return "remote access level of assurance value"; 2246 case LOARA1: return "low remote access level of assurance"; 2247 case LOARA2: return "basic remote access level of assurance"; 2248 case LOARA3: return "medium remote access level of assurance"; 2249 case LOARA4: return "high remote access level of assurance"; 2250 case LOATK: return "token level of assurance value"; 2251 case LOATK1: return "low token level of assurance"; 2252 case LOATK2: return "basic token level of assurance"; 2253 case LOATK3: return "medium token level of assurance"; 2254 case LOATK4: return "high token level of assurance"; 2255 case TRSTMECOBV: return "none supplied 6"; 2256 case _SEVERITYOBSERVATION: return "SeverityObservation"; 2257 case H: return "High"; 2258 case L: return "Low"; 2259 case M: return "Moderate"; 2260 case _SUBJECTBODYPOSITION: return "_SubjectBodyPosition"; 2261 case LLD: return "left lateral decubitus"; 2262 case PRN: return "prone"; 2263 case RLD: return "right lateral decubitus"; 2264 case SFWL: return "Semi-Fowler's"; 2265 case SIT: return "sitting"; 2266 case STN: return "standing"; 2267 case SUP: return "supine"; 2268 case RTRD: return "reverse trendelenburg"; 2269 case TRD: return "trendelenburg"; 2270 case _VERIFICATIONOUTCOMEVALUE: return "verification outcome"; 2271 case ACT: return "active coverage"; 2272 case ACTPEND: return "active - pending investigation"; 2273 case ELG: return "eligible"; 2274 case INACT: return "inactive"; 2275 case INPNDINV: return "inactive - pending investigation"; 2276 case INPNDUPD: return "inactive - pending eligibility update"; 2277 case NELG: return "not eligible"; 2278 case _ANNOTATIONVALUE: return "AnnotationValue"; 2279 case _COMMONCLINICALOBSERVATIONVALUE: return "common clinical observation"; 2280 case _INDIVIDUALCASESAFETYREPORTVALUEDOMAINS: return "Individual Case Safety Report Value Domains"; 2281 case _INDICATIONVALUE: return "IndicationValue"; 2282 default: return "?"; 2283 } 2284 } 2285 2286 2287} 2288