001package org.hl7.fhir.instance.model.valuesets; 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 Wed, Nov 11, 2015 10:54-0500 for FHIR v1.0.2 033 034 035public enum V3ObservationValue { 036 037 /** 038 * 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. 039 */ 040 _ACTCOVERAGEASSESSMENTOBSERVATIONVALUE, 041 /** 042 * 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. 043 */ 044 _ACTFINANCIALSTATUSOBSERVATIONVALUE, 045 /** 046 * Codes specifying asset indicators used to assess or establish eligibility for coverage under a policy or program. 047 */ 048 ASSET, 049 /** 050 * Indicator of annuity ownership or status as beneficiary. 051 */ 052 ANNUITY, 053 /** 054 * Indicator of real property ownership, e.g. deed or real estate contract. 055 */ 056 PROP, 057 /** 058 * Indicator of retirement investment account ownership. 059 */ 060 RETACCT, 061 /** 062 * Indicator of status as trust beneficiary. 063 */ 064 TRUST, 065 /** 066 * 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. 067 */ 068 INCOME, 069 /** 070 * Indicator of child support payments received or provided. 071 */ 072 CHILD, 073 /** 074 * Indicator of disability income replacement payment. 075 */ 076 DISABL, 077 /** 078 * Indicator of investment income, e.g. dividend check, annuity payment; real estate rent, investment divestiture proceeds; trust or endowment check. 079 */ 080 INVEST, 081 /** 082 * Indicator of paid employment, e.g. letter of hire, contract, employer letter; copy of pay check or pay stub. 083 */ 084 PAY, 085 /** 086 * Indicator of retirement payment, e.g. pension check. 087 */ 088 RETIRE, 089 /** 090 * Indicator of spousal or partner support payments received or provided; e.g. alimony payment; support stipulations in a divorce settlement. 091 */ 092 SPOUSAL, 093 /** 094 * Indicator of income supplement, e.g. gifting, parental income support; stipend, or grant. 095 */ 096 SUPPLE, 097 /** 098 * Indicator of tax obligation or payment, e.g. statement of taxable income. 099 */ 100 TAX, 101 /** 102 * Codes specifying living expense indicators used to assess or establish eligibility for coverage under a policy or program. 103 */ 104 LIVEXP, 105 /** 106 * Indicator of clothing expenses. 107 */ 108 CLOTH, 109 /** 110 * Indicator of transportation expenses. 111 */ 112 FOOD, 113 /** 114 * Indicator of health expenses; including medication costs, health service costs, financial participations, and health coverage premiums. 115 */ 116 HEALTH, 117 /** 118 * Indicator of housing expense, e.g. household appliances, fixtures, furnishings, and maintenance and repairs. 119 */ 120 HOUSE, 121 /** 122 * Indicator of legal expenses. 123 */ 124 LEGAL, 125 /** 126 * Indicator of mortgage amount, interest, and payments. 127 */ 128 MORTG, 129 /** 130 * Indicator of rental or lease payments. 131 */ 132 RENT, 133 /** 134 * Indicator of transportation expenses. 135 */ 136 SUNDRY, 137 /** 138 * Indicator of transportation expenses, e.g. vehicle payments, vehicle insurance, vehicle fuel, and vehicle maintenance and repairs. 139 */ 140 TRANS, 141 /** 142 * Indicator of transportation expenses. 143 */ 144 UTIL, 145 /** 146 * 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. 147 */ 148 ELSTAT, 149 /** 150 * Indicator of adoption. 151 */ 152 ADOPT, 153 /** 154 * Indicator of birth. 155 */ 156 BTHCERT, 157 /** 158 * Indicator of creditable coverage. 159 */ 160 CCOC, 161 /** 162 * Indicator of driving status. 163 */ 164 DRLIC, 165 /** 166 * Indicator of foster child status. 167 */ 168 FOSTER, 169 /** 170 * Indicator of status as covered member under a policy or program, e.g. member id card or coverage document. 171 */ 172 MEMBER, 173 /** 174 * Indicator of military status. 175 */ 176 MIL, 177 /** 178 * Indicator of marriage status. 179 */ 180 MRGCERT, 181 /** 182 * Indicator of citizenship. 183 */ 184 PASSPORT, 185 /** 186 * Indicator of student status. 187 */ 188 STUDENRL, 189 /** 190 * 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. 191 */ 192 HLSTAT, 193 /** 194 * Indication of disability. 195 */ 196 DISABLE, 197 /** 198 * Indication of drug use. 199 */ 200 DRUG, 201 /** 202 * Indication of IV drug use . 203 */ 204 IVDRG, 205 /** 206 * Non-clinical report of pregnancy. 207 */ 208 PGNT, 209 /** 210 * Code specifying observations related to living dependency, such as dependent upon spouse for activities of daily living. 211 */ 212 LIVDEP, 213 /** 214 * Continued living in private residence requires functional and health care assistance from one or more relatives. 215 */ 216 RELDEP, 217 /** 218 * Continued living in private residence requires functional and health care assistance from spouse or life partner. 219 */ 220 SPSDEP, 221 /** 222 * Continued living in private residence requires functional and health care assistance from one or more unrelated persons. 223 */ 224 URELDEP, 225 /** 226 * Code specifying observations related to living situation for a person in a private residence. 227 */ 228 LIVSIT, 229 /** 230 * Living alone. Maps to PD1-2 Living arrangement (IS) 00742 [A] 231 */ 232 ALONE, 233 /** 234 * Living with one or more dependent children requiring moderate supervision. 235 */ 236 DEPCHD, 237 /** 238 * Living with disabled spouse requiring functional and health care assistance 239 */ 240 DEPSPS, 241 /** 242 * Living with one or more dependent children requiring intensive supervision 243 */ 244 DEPYGCHD, 245 /** 246 * Living with family. Maps to PD1-2 Living arrangement (IS) 00742 [F] 247 */ 248 FAM, 249 /** 250 * Living with one or more relatives. Maps to PD1-2 Living arrangement (IS) 00742 [R] 251 */ 252 RELAT, 253 /** 254 * Living only with spouse or life partner. Maps to PD1-2 Living arrangement (IS) 00742 [S] 255 */ 256 SPS, 257 /** 258 * Living with one or more unrelated persons. 259 */ 260 UNREL, 261 /** 262 * 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. 263 */ 264 SOECSTAT, 265 /** 266 * Indication of abuse victim. 267 */ 268 ABUSE, 269 /** 270 * Indication of status as homeless. 271 */ 272 HMLESS, 273 /** 274 * Indication of status as illegal immigrant. 275 */ 276 ILGIM, 277 /** 278 * Indication of status as incarcerated. 279 */ 280 INCAR, 281 /** 282 * Indication of probation status. 283 */ 284 PROB, 285 /** 286 * Indication of refugee status. 287 */ 288 REFUG, 289 /** 290 * Indication of unemployed status. 291 */ 292 UNEMPL, 293 /** 294 * Indicates the result of a particular allergy test; e.g. Negative, Mild, Moderate, Severe 295 */ 296 _ALLERGYTESTVALUE, 297 /** 298 * Description:Patient exhibits no reaction to the challenge agent. 299 */ 300 A0, 301 /** 302 * Description:Patient exhibits a minimal reaction to the challenge agent. 303 */ 304 A1, 305 /** 306 * Description:Patient exhibits a mild reaction to the challenge agent. 307 */ 308 A2, 309 /** 310 * Description:Patient exhibits moderate reaction to the challenge agent. 311 */ 312 A3, 313 /** 314 * Description:Patient exhibits a severe reaction to the challenge agent. 315 */ 316 A4, 317 /** 318 * Description:Coded observation values for coverage limitations, for e.g. types of claims or types of parties covered under a policy or program. 319 */ 320 _COVERAGELIMITOBSERVATIONVALUE, 321 /** 322 * Description:Coded observation values for types of covered parties under a policy or program based on their personal relationships or employment status. 323 */ 324 _COVERAGELEVELOBSERVATIONVALUE, 325 /** 326 * Description:Child over an age as specified by coverage policy or program, e.g. student, differently abled, and income dependent. 327 */ 328 ADC, 329 /** 330 * Description:Dependent biological, adopted, foster child as specified by coverage policy or program. 331 */ 332 CHD, 333 /** 334 * Description:Person requiring functional and/or financial assistance from another person as specified by coverage policy or program. 335 */ 336 DEP, 337 /** 338 * Description:Persons registered as a family unit in a domestic partner registry as specified by law and by coverage policy or program. 339 */ 340 DP, 341 /** 342 * 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. 343 */ 344 ECH, 345 /** 346 * Description:As specified by coverage policy or program. 347 */ 348 FLY, 349 /** 350 * Description:Person as specified by coverage policy or program. 351 */ 352 IND, 353 /** 354 * 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 355 */ 356 SSP, 357 /** 358 * 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. 359 */ 360 _CRITICALITYOBSERVATIONVALUE, 361 /** 362 * Worst case result of a future exposure is assessed to be life-threatening. 363 */ 364 CRITH, 365 /** 366 * Worst case result of a future exposure is not assessed to be life-threatening. 367 */ 368 CRITL, 369 /** 370 * Unable to assess the worst case result of a future exposure. 371 */ 372 CRITU, 373 /** 374 * Description: The domain contains genetic analysis specific observation values, e.g. Homozygote, Heterozygote, etc. 375 */ 376 _GENETICOBSERVATIONVALUE, 377 /** 378 * Description: An individual having different alleles at one or more loci regarding a specific character 379 */ 380 HOMOZYGOTE, 381 /** 382 * Observation values used to indicate the type of scoring (e.g. proportion, ratio) used by a health quality measure. 383 */ 384 _OBSERVATIONMEASURESCORING, 385 /** 386 * 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). 387 */ 388 COHORT, 389 /** 390 * 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). 391 */ 392 CONTVAR, 393 /** 394 * 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). 395 */ 396 PROPOR, 397 /** 398 * 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). 399 */ 400 RATIO, 401 /** 402 * Observation values used to indicate what kind of health quality measure is used. 403 */ 404 _OBSERVATIONMEASURETYPE, 405 /** 406 * A measure that is composed from one or more other measures and indicates an overall summary of those measures. 407 */ 408 COMPOSITE, 409 /** 410 * A measure related to the efficiency of medical treatment. 411 */ 412 EFFICIENCY, 413 /** 414 * A measure related to the level of patient engagement or patient experience of care. 415 */ 416 EXPERIENCE, 417 /** 418 * A measure that indicates the result of the performance (or non-performance) of a function or process. 419 */ 420 OUTCOME, 421 /** 422 * 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. 423 */ 424 PROCESS, 425 /** 426 * A measure related to the extent of use of clinical resources or cost of care. 427 */ 428 RESOURCE, 429 /** 430 * A measure related to the structure of patient care. 431 */ 432 STRUCTURE, 433 /** 434 * Observation values used to assert various populations that a subject falls into. 435 */ 436 _OBSERVATIONPOPULATIONINCLUSION, 437 /** 438 * 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. 439 */ 440 DENEX, 441 /** 442 * 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: 443 444 445 Medical reasons 446 Patient reasons 447 System reasons 448 */ 449 DENEXCEP, 450 /** 451 * 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. 452 */ 453 DENOM, 454 /** 455 * 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. 456 */ 457 IP, 458 /** 459 * 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. 460 */ 461 IPP, 462 /** 463 * Measure population is used only in continuous variable eMeasures. It is a narrative description of the eMeasure population. 464(e.g. all patients seen in the Emergency Department during the measurement period). 465 */ 466 MSRPOPL, 467 /** 468 * 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). 469 */ 470 NUMER, 471 /** 472 * 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.) 473 */ 474 NUMEX, 475 /** 476 * PartialCompletionScale 477 */ 478 _PARTIALCOMPLETIONSCALE, 479 /** 480 * Value for Act.partialCompletionCode attribute that implies 81-99% completion 481 */ 482 G, 483 /** 484 * Value for Act.partialCompletionCode attribute that implies 61-80% completion 485 */ 486 LE, 487 /** 488 * Value for Act.partialCompletionCode attribute that implies 41-60% completion 489 */ 490 ME, 491 /** 492 * Value for Act.partialCompletionCode attribute that implies 1-20% completion 493 */ 494 MI, 495 /** 496 * Value for Act.partialCompletionCode attribute that implies 0% completion 497 */ 498 N, 499 /** 500 * Value for Act.partialCompletionCode attribute that implies 21-40% completion 501 */ 502 S, 503 /** 504 * Observation values used to indicate security observation metadata. 505 */ 506 _SECURITYOBSERVATIONVALUE, 507 /** 508 * Abstract security observation values used to indicate security integrity metadata. 509 510 511 Examples: Codes conveying integrity status, integrity confidence, and provenance. 512 */ 513 _SECINTOBV, 514 /** 515 * Abstract security metadata observation values used to indicate mechanism used for authorized alteration of an IT resource (data, information object, service, or system capability) 516 */ 517 _SECALTINTOBV, 518 /** 519 * 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. 520 */ 521 ABSTRED, 522 /** 523 * 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. 524 */ 525 AGGRED, 526 /** 527 * 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. 528 */ 529 ANONYED, 530 /** 531 * Security metadata observation value used to indicate that the IT resource semantic content has been transformed from one encoding to another. 532 533 534 Usage Note: "MAP" code does not indicate the semantic fidelity of the transformed content. 535 536 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). 537 538 Semantic fidelity of the mapped IT Resource may also be indicated using a SecurityIntegrityConfidenceObservation. 539 */ 540 MAPPED, 541 /** 542 * 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". 543 544 545 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. 546 */ 547 MASKED, 548 /** 549 * 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. 550 551 552 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 553 */ 554 PSEUDED, 555 /** 556 * 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. 557 558 559 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. 560 */ 561 REDACTED, 562 /** 563 * 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 564 565 566 Usage Note: This is not suitable to be used when information is removed for security reasons - see the code REDACTED for this use. 567 */ 568 SUBSETTED, 569 /** 570 * Security metadata observation value used to indicate that the IT resource syntax has been transformed from one syntactical representation to another. 571 572 573 Usage Note: "SYNTAC" code does not indicate the syntactical correctness of the syntactically transformed IT resource. 574 */ 575 SYNTAC, 576 /** 577 * Security metadata observation value used to indicate that the IT resource has been translated from one human language to another. 578 579 580 Usage Note: "TRSLT" does not indicate the fidelity of the translation or the languages translated. 581 582 The fidelity of the IT Resource translation may be indicated using a SecurityIntegrityConfidenceObservation. 583 584 To indicate languages, use the Value Set:HumanLanguage (2.16.840.1.113883.1.11.11526) 585 */ 586 TRSLT, 587 /** 588 * 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 589 590 591 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. 592 */ 593 VERSIONED, 594 /** 595 * Abstract security observation values used to indicate data integrity metadata. 596 597 598 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. 599 */ 600 _SECDATINTOBV, 601 /** 602 * Security metadata observation value used to indicate the mechanism by which software systems can establish that data was not modified in transit. 603 604 605 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. 606 607 608 Examples: 609 610 611 612 SHA-1 613 SHA-2 (Secure Hash Algorithm) 614 */ 615 CRYTOHASH, 616 /** 617 * Security metadata observation value used to indicate the mechanism by which software systems use digital signature to establish that data has not been modified. 618 619 620 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. 621 */ 622 DIGSIG, 623 /** 624 * Abstract security observation value used to indicate integrity confidence metadata. 625 626 627 Examples: Codes conveying the level of reliability and trustworthiness of an IT resource. 628 */ 629 _SECINTCONOBV, 630 /** 631 * 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. 632 */ 633 HRELIABLE, 634 /** 635 * 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. 636 */ 637 RELIABLE, 638 /** 639 * 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. 640 */ 641 UNCERTREL, 642 /** 643 * 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. 644 */ 645 UNRELIABLE, 646 /** 647 * Abstract security metadata observation value used to indicate the provenance of an IT resource (data, information object, service, or system capability). 648 649 650 Examples: Codes conveying the provenance metadata about the entity reporting an IT resource. 651 */ 652 _SECINTPRVOBV, 653 /** 654 * Abstract security provenance metadata observation value used to indicate the entity that asserted an IT resource (data, information object, service, or system capability). 655 656 657 Examples: Codes conveying the provenance metadata about the entity asserting the resource. 658 */ 659 _SECINTPRVABOBV, 660 /** 661 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a clinician. 662 */ 663 CLINAST, 664 /** 665 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a device. 666 */ 667 DEVAST, 668 /** 669 * 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. 670 */ 671 HCPAST, 672 /** 673 * 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. 674 */ 675 PACQAST, 676 /** 677 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a patient. 678 */ 679 PATAST, 680 /** 681 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a payer. 682 */ 683 PAYAST, 684 /** 685 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was asserted by a professional. 686 */ 687 PROAST, 688 /** 689 * 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. 690 */ 691 SDMAST, 692 /** 693 * Abstract security provenance metadata observation value used to indicate the entity that reported the resource (data, information object, service, or system capability). 694 695 696 Examples: Codes conveying the provenance metadata about the entity reporting an IT resource. 697 */ 698 _SECINTPRVRBOBV, 699 /** 700 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a clinician. 701 */ 702 CLINRPT, 703 /** 704 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a device. 705 */ 706 DEVRPT, 707 /** 708 * 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. 709 */ 710 HCPRPT, 711 /** 712 * 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. 713 */ 714 PACQRPT, 715 /** 716 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a patient. 717 */ 718 PATRPT, 719 /** 720 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a payer. 721 */ 722 PAYRPT, 723 /** 724 * Security provenance metadata observation value used to indicate that an IT resource (data, information object, service, or system capability) was reported by a professional. 725 */ 726 PRORPT, 727 /** 728 * 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. 729 */ 730 SDMRPT, 731 /** 732 * Observation value used to indicate aspects of trust applicable to an IT resource (data, information object, service, or system capability). 733 */ 734 SECTRSTOBV, 735 /** 736 * 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. 737 */ 738 TRSTACCRDOBV, 739 /** 740 * Values for security trust agreement metadata observation made about privacy and security requirements with which a security domain must comply. [ISO IEC 10181-1] 741[ISO IEC 10181-1] 742 */ 743 TRSTAGREOBV, 744 /** 745 * 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] 746 747 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. 748 */ 749 TRSTCERTOBV, 750 /** 751 * 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. 752 */ 753 TRSTLOAOBV, 754 /** 755 * 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] 756 757 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] 758 */ 759 LOAAN, 760 /** 761 * 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] 762 763 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] 764 765 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.] 766 */ 767 LOAAN1, 768 /** 769 * 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] 770 771 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] 772 773 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. 774Long-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.] 775 */ 776 LOAAN2, 777 /** 778 * 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] 779 780 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] 781 782 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: 783 784 785 "soft" cryptographic token, which has the key stored on a general-purpose computer, 786 "hard" cryptographic token, which has the key stored on a special hardware device, and 787 "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. 788 789 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.] 790 */ 791 LOAAN3, 792 /** 793 * 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] 794 795 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] 796 797 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. 798 799 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.] 800 */ 801 LOAAN4, 802 /** 803 * 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] 804 */ 805 LOAAP, 806 /** 807 * 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] 808 809 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.] 810 */ 811 LOAAP1, 812 /** 813 * 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] 814 815 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.] 816 */ 817 LOAAP2, 818 /** 819 * 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] 820 821 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). 822 823 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. 824 */ 825 LOAAP3, 826 /** 827 * 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] 828 829 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.] 830 */ 831 LOAAP4, 832 /** 833 * 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. 834 */ 835 LOAAS, 836 /** 837 * 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. 838 839 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.] 840 */ 841 LOAAS1, 842 /** 843 * 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. 844 845 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.] 846 */ 847 LOAAS2, 848 /** 849 * 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. 850 851 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.] 852 */ 853 LOAAS3, 854 /** 855 * 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 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.] 858 */ 859 LOAAS4, 860 /** 861 * 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] 862 */ 863 LOACM, 864 /** 865 * 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] 866 */ 867 LOACM1, 868 /** 869 * 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] 870 */ 871 LOACM2, 872 /** 873 * 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] 874 */ 875 LOACM3, 876 /** 877 * 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] 878 */ 879 LOACM4, 880 /** 881 * Indicator of the quality or reliability in the process of ascertaining that an individual is who he or she claims to be. 882 */ 883 LOAID, 884 /** 885 * 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] 886 */ 887 LOAID1, 888 /** 889 * 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] 890 */ 891 LOAID2, 892 /** 893 * 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] 894 */ 895 LOAID3, 896 /** 897 * 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] 898 */ 899 LOAID4, 900 /** 901 * Indicator of the digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 902 */ 903 LOANR, 904 /** 905 * Indicator of low digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 906 */ 907 LOANR1, 908 /** 909 * Indicator of basic digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 910 */ 911 LOANR2, 912 /** 913 * Indicator of medium digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 914 */ 915 LOANR3, 916 /** 917 * Indicator of high digital quality or reliability in the process of establishing proof of delivery and proof of origin. [Based on ISO 7498-2] 918 */ 919 LOANR4, 920 /** 921 * 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] 922 */ 923 LOARA, 924 /** 925 * 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] 926 */ 927 LOARA1, 928 /** 929 * 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] 930 */ 931 LOARA2, 932 /** 933 * 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] 934 */ 935 LOARA3, 936 /** 937 * 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] 938 */ 939 LOARA4, 940 /** 941 * 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] 942 */ 943 LOATK, 944 /** 945 * 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] 946 */ 947 LOATK1, 948 /** 949 * 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] 950 */ 951 LOATK2, 952 /** 953 * 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] 954 */ 955 LOATK3, 956 /** 957 * 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] 958 */ 959 LOATK4, 960 /** 961 * Values for security trust mechanism metadata observation made about a security architecture system component that supports enforcement of security policies. 962 */ 963 TRSTMECOBV, 964 /** 965 * Potential values for observations of severity. 966 */ 967 _SEVERITYOBSERVATION, 968 /** 969 * Indicates the condition may be life-threatening or has the potential to cause permanent injury. 970 */ 971 H, 972 /** 973 * Indicates the condition may result in some adverse consequences but is unlikely to substantially affect the situation of the subject. 974 */ 975 L, 976 /** 977 * Indicates the condition may result in noticable adverse adverse consequences but is unlikely to be life-threatening or cause permanent injury. 978 */ 979 M, 980 /** 981 * 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. 982 */ 983 _SUBJECTBODYPOSITION, 984 /** 985 * Lying on the left side. 986 */ 987 LLD, 988 /** 989 * Lying with the front or ventral surface downward; lying face down. 990 */ 991 PRN, 992 /** 993 * Lying on the right side. 994 */ 995 RLD, 996 /** 997 * A semi-sitting position in bed with the head of the bed elevated approximately 45 degrees. 998 */ 999 SFWL, 1000 /** 1001 * Resting the body on the buttocks, typically with upper torso erect or semi erect. 1002 */ 1003 SIT, 1004 /** 1005 * To be stationary, upright, vertical, on one's legs. 1006 */ 1007 STN, 1008 /** 1009 * supine 1010 */ 1011 SUP, 1012 /** 1013 * Lying on the back, on an inclined plane, typically about 30-45 degrees with head raised and feet lowered. 1014 */ 1015 RTRD, 1016 /** 1017 * Lying on the back, on an inclined plane, typically about 30-45 degrees, with head lowered and feet raised. 1018 */ 1019 TRD, 1020 /** 1021 * Values for observations of verification act results 1022 1023 1024 Examples: Verified, not verified, verified with warning. 1025 */ 1026 _VERIFICATIONOUTCOMEVALUE, 1027 /** 1028 * Definition: Coverage is in effect for healthcare service(s) and/or product(s). 1029 */ 1030 ACT, 1031 /** 1032 * Definition: Coverage is in effect for healthcare service(s) and/or product(s) - Pending Investigation 1033 */ 1034 ACTPEND, 1035 /** 1036 * Definition: Coverage is in effect for healthcare service(s) and/or product(s). 1037 */ 1038 ELG, 1039 /** 1040 * Definition: Coverage is not in effect for healthcare service(s) and/or product(s). 1041 */ 1042 INACT, 1043 /** 1044 * Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Investigation. 1045 */ 1046 INPNDINV, 1047 /** 1048 * Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Eligibility Update. 1049 */ 1050 INPNDUPD, 1051 /** 1052 * Definition: Coverage is not in effect for healthcare service(s) and/or product(s). May optionally include reasons for the ineligibility. 1053 */ 1054 NELG, 1055 /** 1056 * AnnotationValue 1057 */ 1058 _ANNOTATIONVALUE, 1059 /** 1060 * Description:Used in a patient care message to value simple clinical (non-lab) observations. 1061 */ 1062 _COMMONCLINICALOBSERVATIONVALUE, 1063 /** 1064 * 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. 1065 */ 1066 _INDIVIDUALCASESAFETYREPORTVALUEDOMAINS, 1067 /** 1068 * 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. 1069 */ 1070 _INDICATIONVALUE, 1071 /** 1072 * added to help the parsers 1073 */ 1074 NULL; 1075 public static V3ObservationValue fromCode(String codeString) throws Exception { 1076 if (codeString == null || "".equals(codeString)) 1077 return null; 1078 if ("_ActCoverageAssessmentObservationValue".equals(codeString)) 1079 return _ACTCOVERAGEASSESSMENTOBSERVATIONVALUE; 1080 if ("_ActFinancialStatusObservationValue".equals(codeString)) 1081 return _ACTFINANCIALSTATUSOBSERVATIONVALUE; 1082 if ("ASSET".equals(codeString)) 1083 return ASSET; 1084 if ("ANNUITY".equals(codeString)) 1085 return ANNUITY; 1086 if ("PROP".equals(codeString)) 1087 return PROP; 1088 if ("RETACCT".equals(codeString)) 1089 return RETACCT; 1090 if ("TRUST".equals(codeString)) 1091 return TRUST; 1092 if ("INCOME".equals(codeString)) 1093 return INCOME; 1094 if ("CHILD".equals(codeString)) 1095 return CHILD; 1096 if ("DISABL".equals(codeString)) 1097 return DISABL; 1098 if ("INVEST".equals(codeString)) 1099 return INVEST; 1100 if ("PAY".equals(codeString)) 1101 return PAY; 1102 if ("RETIRE".equals(codeString)) 1103 return RETIRE; 1104 if ("SPOUSAL".equals(codeString)) 1105 return SPOUSAL; 1106 if ("SUPPLE".equals(codeString)) 1107 return SUPPLE; 1108 if ("TAX".equals(codeString)) 1109 return TAX; 1110 if ("LIVEXP".equals(codeString)) 1111 return LIVEXP; 1112 if ("CLOTH".equals(codeString)) 1113 return CLOTH; 1114 if ("FOOD".equals(codeString)) 1115 return FOOD; 1116 if ("HEALTH".equals(codeString)) 1117 return HEALTH; 1118 if ("HOUSE".equals(codeString)) 1119 return HOUSE; 1120 if ("LEGAL".equals(codeString)) 1121 return LEGAL; 1122 if ("MORTG".equals(codeString)) 1123 return MORTG; 1124 if ("RENT".equals(codeString)) 1125 return RENT; 1126 if ("SUNDRY".equals(codeString)) 1127 return SUNDRY; 1128 if ("TRANS".equals(codeString)) 1129 return TRANS; 1130 if ("UTIL".equals(codeString)) 1131 return UTIL; 1132 if ("ELSTAT".equals(codeString)) 1133 return ELSTAT; 1134 if ("ADOPT".equals(codeString)) 1135 return ADOPT; 1136 if ("BTHCERT".equals(codeString)) 1137 return BTHCERT; 1138 if ("CCOC".equals(codeString)) 1139 return CCOC; 1140 if ("DRLIC".equals(codeString)) 1141 return DRLIC; 1142 if ("FOSTER".equals(codeString)) 1143 return FOSTER; 1144 if ("MEMBER".equals(codeString)) 1145 return MEMBER; 1146 if ("MIL".equals(codeString)) 1147 return MIL; 1148 if ("MRGCERT".equals(codeString)) 1149 return MRGCERT; 1150 if ("PASSPORT".equals(codeString)) 1151 return PASSPORT; 1152 if ("STUDENRL".equals(codeString)) 1153 return STUDENRL; 1154 if ("HLSTAT".equals(codeString)) 1155 return HLSTAT; 1156 if ("DISABLE".equals(codeString)) 1157 return DISABLE; 1158 if ("DRUG".equals(codeString)) 1159 return DRUG; 1160 if ("IVDRG".equals(codeString)) 1161 return IVDRG; 1162 if ("PGNT".equals(codeString)) 1163 return PGNT; 1164 if ("LIVDEP".equals(codeString)) 1165 return LIVDEP; 1166 if ("RELDEP".equals(codeString)) 1167 return RELDEP; 1168 if ("SPSDEP".equals(codeString)) 1169 return SPSDEP; 1170 if ("URELDEP".equals(codeString)) 1171 return URELDEP; 1172 if ("LIVSIT".equals(codeString)) 1173 return LIVSIT; 1174 if ("ALONE".equals(codeString)) 1175 return ALONE; 1176 if ("DEPCHD".equals(codeString)) 1177 return DEPCHD; 1178 if ("DEPSPS".equals(codeString)) 1179 return DEPSPS; 1180 if ("DEPYGCHD".equals(codeString)) 1181 return DEPYGCHD; 1182 if ("FAM".equals(codeString)) 1183 return FAM; 1184 if ("RELAT".equals(codeString)) 1185 return RELAT; 1186 if ("SPS".equals(codeString)) 1187 return SPS; 1188 if ("UNREL".equals(codeString)) 1189 return UNREL; 1190 if ("SOECSTAT".equals(codeString)) 1191 return SOECSTAT; 1192 if ("ABUSE".equals(codeString)) 1193 return ABUSE; 1194 if ("HMLESS".equals(codeString)) 1195 return HMLESS; 1196 if ("ILGIM".equals(codeString)) 1197 return ILGIM; 1198 if ("INCAR".equals(codeString)) 1199 return INCAR; 1200 if ("PROB".equals(codeString)) 1201 return PROB; 1202 if ("REFUG".equals(codeString)) 1203 return REFUG; 1204 if ("UNEMPL".equals(codeString)) 1205 return UNEMPL; 1206 if ("_AllergyTestValue".equals(codeString)) 1207 return _ALLERGYTESTVALUE; 1208 if ("A0".equals(codeString)) 1209 return A0; 1210 if ("A1".equals(codeString)) 1211 return A1; 1212 if ("A2".equals(codeString)) 1213 return A2; 1214 if ("A3".equals(codeString)) 1215 return A3; 1216 if ("A4".equals(codeString)) 1217 return A4; 1218 if ("_CoverageLimitObservationValue".equals(codeString)) 1219 return _COVERAGELIMITOBSERVATIONVALUE; 1220 if ("_CoverageLevelObservationValue".equals(codeString)) 1221 return _COVERAGELEVELOBSERVATIONVALUE; 1222 if ("ADC".equals(codeString)) 1223 return ADC; 1224 if ("CHD".equals(codeString)) 1225 return CHD; 1226 if ("DEP".equals(codeString)) 1227 return DEP; 1228 if ("DP".equals(codeString)) 1229 return DP; 1230 if ("ECH".equals(codeString)) 1231 return ECH; 1232 if ("FLY".equals(codeString)) 1233 return FLY; 1234 if ("IND".equals(codeString)) 1235 return IND; 1236 if ("SSP".equals(codeString)) 1237 return SSP; 1238 if ("_CriticalityObservationValue".equals(codeString)) 1239 return _CRITICALITYOBSERVATIONVALUE; 1240 if ("CRITH".equals(codeString)) 1241 return CRITH; 1242 if ("CRITL".equals(codeString)) 1243 return CRITL; 1244 if ("CRITU".equals(codeString)) 1245 return CRITU; 1246 if ("_GeneticObservationValue".equals(codeString)) 1247 return _GENETICOBSERVATIONVALUE; 1248 if ("Homozygote".equals(codeString)) 1249 return HOMOZYGOTE; 1250 if ("_ObservationMeasureScoring".equals(codeString)) 1251 return _OBSERVATIONMEASURESCORING; 1252 if ("COHORT".equals(codeString)) 1253 return COHORT; 1254 if ("CONTVAR".equals(codeString)) 1255 return CONTVAR; 1256 if ("PROPOR".equals(codeString)) 1257 return PROPOR; 1258 if ("RATIO".equals(codeString)) 1259 return RATIO; 1260 if ("_ObservationMeasureType".equals(codeString)) 1261 return _OBSERVATIONMEASURETYPE; 1262 if ("COMPOSITE".equals(codeString)) 1263 return COMPOSITE; 1264 if ("EFFICIENCY".equals(codeString)) 1265 return EFFICIENCY; 1266 if ("EXPERIENCE".equals(codeString)) 1267 return EXPERIENCE; 1268 if ("OUTCOME".equals(codeString)) 1269 return OUTCOME; 1270 if ("PROCESS".equals(codeString)) 1271 return PROCESS; 1272 if ("RESOURCE".equals(codeString)) 1273 return RESOURCE; 1274 if ("STRUCTURE".equals(codeString)) 1275 return STRUCTURE; 1276 if ("_ObservationPopulationInclusion".equals(codeString)) 1277 return _OBSERVATIONPOPULATIONINCLUSION; 1278 if ("DENEX".equals(codeString)) 1279 return DENEX; 1280 if ("DENEXCEP".equals(codeString)) 1281 return DENEXCEP; 1282 if ("DENOM".equals(codeString)) 1283 return DENOM; 1284 if ("IP".equals(codeString)) 1285 return IP; 1286 if ("IPP".equals(codeString)) 1287 return IPP; 1288 if ("MSRPOPL".equals(codeString)) 1289 return MSRPOPL; 1290 if ("NUMER".equals(codeString)) 1291 return NUMER; 1292 if ("NUMEX".equals(codeString)) 1293 return NUMEX; 1294 if ("_PartialCompletionScale".equals(codeString)) 1295 return _PARTIALCOMPLETIONSCALE; 1296 if ("G".equals(codeString)) 1297 return G; 1298 if ("LE".equals(codeString)) 1299 return LE; 1300 if ("ME".equals(codeString)) 1301 return ME; 1302 if ("MI".equals(codeString)) 1303 return MI; 1304 if ("N".equals(codeString)) 1305 return N; 1306 if ("S".equals(codeString)) 1307 return S; 1308 if ("_SecurityObservationValue".equals(codeString)) 1309 return _SECURITYOBSERVATIONVALUE; 1310 if ("_SECINTOBV".equals(codeString)) 1311 return _SECINTOBV; 1312 if ("_SECALTINTOBV".equals(codeString)) 1313 return _SECALTINTOBV; 1314 if ("ABSTRED".equals(codeString)) 1315 return ABSTRED; 1316 if ("AGGRED".equals(codeString)) 1317 return AGGRED; 1318 if ("ANONYED".equals(codeString)) 1319 return ANONYED; 1320 if ("MAPPED".equals(codeString)) 1321 return MAPPED; 1322 if ("MASKED".equals(codeString)) 1323 return MASKED; 1324 if ("PSEUDED".equals(codeString)) 1325 return PSEUDED; 1326 if ("REDACTED".equals(codeString)) 1327 return REDACTED; 1328 if ("SUBSETTED".equals(codeString)) 1329 return SUBSETTED; 1330 if ("SYNTAC".equals(codeString)) 1331 return SYNTAC; 1332 if ("TRSLT".equals(codeString)) 1333 return TRSLT; 1334 if ("VERSIONED".equals(codeString)) 1335 return VERSIONED; 1336 if ("_SECDATINTOBV".equals(codeString)) 1337 return _SECDATINTOBV; 1338 if ("CRYTOHASH".equals(codeString)) 1339 return CRYTOHASH; 1340 if ("DIGSIG".equals(codeString)) 1341 return DIGSIG; 1342 if ("_SECINTCONOBV".equals(codeString)) 1343 return _SECINTCONOBV; 1344 if ("HRELIABLE".equals(codeString)) 1345 return HRELIABLE; 1346 if ("RELIABLE".equals(codeString)) 1347 return RELIABLE; 1348 if ("UNCERTREL".equals(codeString)) 1349 return UNCERTREL; 1350 if ("UNRELIABLE".equals(codeString)) 1351 return UNRELIABLE; 1352 if ("_SECINTPRVOBV".equals(codeString)) 1353 return _SECINTPRVOBV; 1354 if ("_SECINTPRVABOBV".equals(codeString)) 1355 return _SECINTPRVABOBV; 1356 if ("CLINAST".equals(codeString)) 1357 return CLINAST; 1358 if ("DEVAST".equals(codeString)) 1359 return DEVAST; 1360 if ("HCPAST".equals(codeString)) 1361 return HCPAST; 1362 if ("PACQAST".equals(codeString)) 1363 return PACQAST; 1364 if ("PATAST".equals(codeString)) 1365 return PATAST; 1366 if ("PAYAST".equals(codeString)) 1367 return PAYAST; 1368 if ("PROAST".equals(codeString)) 1369 return PROAST; 1370 if ("SDMAST".equals(codeString)) 1371 return SDMAST; 1372 if ("_SECINTPRVRBOBV".equals(codeString)) 1373 return _SECINTPRVRBOBV; 1374 if ("CLINRPT".equals(codeString)) 1375 return CLINRPT; 1376 if ("DEVRPT".equals(codeString)) 1377 return DEVRPT; 1378 if ("HCPRPT".equals(codeString)) 1379 return HCPRPT; 1380 if ("PACQRPT".equals(codeString)) 1381 return PACQRPT; 1382 if ("PATRPT".equals(codeString)) 1383 return PATRPT; 1384 if ("PAYRPT".equals(codeString)) 1385 return PAYRPT; 1386 if ("PRORPT".equals(codeString)) 1387 return PRORPT; 1388 if ("SDMRPT".equals(codeString)) 1389 return SDMRPT; 1390 if ("SECTRSTOBV".equals(codeString)) 1391 return SECTRSTOBV; 1392 if ("TRSTACCRDOBV".equals(codeString)) 1393 return TRSTACCRDOBV; 1394 if ("TRSTAGREOBV".equals(codeString)) 1395 return TRSTAGREOBV; 1396 if ("TRSTCERTOBV".equals(codeString)) 1397 return TRSTCERTOBV; 1398 if ("TRSTLOAOBV".equals(codeString)) 1399 return TRSTLOAOBV; 1400 if ("LOAAN".equals(codeString)) 1401 return LOAAN; 1402 if ("LOAAN1".equals(codeString)) 1403 return LOAAN1; 1404 if ("LOAAN2".equals(codeString)) 1405 return LOAAN2; 1406 if ("LOAAN3".equals(codeString)) 1407 return LOAAN3; 1408 if ("LOAAN4".equals(codeString)) 1409 return LOAAN4; 1410 if ("LOAAP".equals(codeString)) 1411 return LOAAP; 1412 if ("LOAAP1".equals(codeString)) 1413 return LOAAP1; 1414 if ("LOAAP2".equals(codeString)) 1415 return LOAAP2; 1416 if ("LOAAP3".equals(codeString)) 1417 return LOAAP3; 1418 if ("LOAAP4".equals(codeString)) 1419 return LOAAP4; 1420 if ("LOAAS".equals(codeString)) 1421 return LOAAS; 1422 if ("LOAAS1".equals(codeString)) 1423 return LOAAS1; 1424 if ("LOAAS2".equals(codeString)) 1425 return LOAAS2; 1426 if ("LOAAS3".equals(codeString)) 1427 return LOAAS3; 1428 if ("LOAAS4".equals(codeString)) 1429 return LOAAS4; 1430 if ("LOACM".equals(codeString)) 1431 return LOACM; 1432 if ("LOACM1".equals(codeString)) 1433 return LOACM1; 1434 if ("LOACM2".equals(codeString)) 1435 return LOACM2; 1436 if ("LOACM3".equals(codeString)) 1437 return LOACM3; 1438 if ("LOACM4".equals(codeString)) 1439 return LOACM4; 1440 if ("LOAID".equals(codeString)) 1441 return LOAID; 1442 if ("LOAID1".equals(codeString)) 1443 return LOAID1; 1444 if ("LOAID2".equals(codeString)) 1445 return LOAID2; 1446 if ("LOAID3".equals(codeString)) 1447 return LOAID3; 1448 if ("LOAID4".equals(codeString)) 1449 return LOAID4; 1450 if ("LOANR".equals(codeString)) 1451 return LOANR; 1452 if ("LOANR1".equals(codeString)) 1453 return LOANR1; 1454 if ("LOANR2".equals(codeString)) 1455 return LOANR2; 1456 if ("LOANR3".equals(codeString)) 1457 return LOANR3; 1458 if ("LOANR4".equals(codeString)) 1459 return LOANR4; 1460 if ("LOARA".equals(codeString)) 1461 return LOARA; 1462 if ("LOARA1".equals(codeString)) 1463 return LOARA1; 1464 if ("LOARA2".equals(codeString)) 1465 return LOARA2; 1466 if ("LOARA3".equals(codeString)) 1467 return LOARA3; 1468 if ("LOARA4".equals(codeString)) 1469 return LOARA4; 1470 if ("LOATK".equals(codeString)) 1471 return LOATK; 1472 if ("LOATK1".equals(codeString)) 1473 return LOATK1; 1474 if ("LOATK2".equals(codeString)) 1475 return LOATK2; 1476 if ("LOATK3".equals(codeString)) 1477 return LOATK3; 1478 if ("LOATK4".equals(codeString)) 1479 return LOATK4; 1480 if ("TRSTMECOBV".equals(codeString)) 1481 return TRSTMECOBV; 1482 if ("_SeverityObservation".equals(codeString)) 1483 return _SEVERITYOBSERVATION; 1484 if ("H".equals(codeString)) 1485 return H; 1486 if ("L".equals(codeString)) 1487 return L; 1488 if ("M".equals(codeString)) 1489 return M; 1490 if ("_SubjectBodyPosition".equals(codeString)) 1491 return _SUBJECTBODYPOSITION; 1492 if ("LLD".equals(codeString)) 1493 return LLD; 1494 if ("PRN".equals(codeString)) 1495 return PRN; 1496 if ("RLD".equals(codeString)) 1497 return RLD; 1498 if ("SFWL".equals(codeString)) 1499 return SFWL; 1500 if ("SIT".equals(codeString)) 1501 return SIT; 1502 if ("STN".equals(codeString)) 1503 return STN; 1504 if ("SUP".equals(codeString)) 1505 return SUP; 1506 if ("RTRD".equals(codeString)) 1507 return RTRD; 1508 if ("TRD".equals(codeString)) 1509 return TRD; 1510 if ("_VerificationOutcomeValue".equals(codeString)) 1511 return _VERIFICATIONOUTCOMEVALUE; 1512 if ("ACT".equals(codeString)) 1513 return ACT; 1514 if ("ACTPEND".equals(codeString)) 1515 return ACTPEND; 1516 if ("ELG".equals(codeString)) 1517 return ELG; 1518 if ("INACT".equals(codeString)) 1519 return INACT; 1520 if ("INPNDINV".equals(codeString)) 1521 return INPNDINV; 1522 if ("INPNDUPD".equals(codeString)) 1523 return INPNDUPD; 1524 if ("NELG".equals(codeString)) 1525 return NELG; 1526 if ("_AnnotationValue".equals(codeString)) 1527 return _ANNOTATIONVALUE; 1528 if ("_CommonClinicalObservationValue".equals(codeString)) 1529 return _COMMONCLINICALOBSERVATIONVALUE; 1530 if ("_IndividualCaseSafetyReportValueDomains".equals(codeString)) 1531 return _INDIVIDUALCASESAFETYREPORTVALUEDOMAINS; 1532 if ("_IndicationValue".equals(codeString)) 1533 return _INDICATIONVALUE; 1534 throw new Exception("Unknown V3ObservationValue code '"+codeString+"'"); 1535 } 1536 public String toCode() { 1537 switch (this) { 1538 case _ACTCOVERAGEASSESSMENTOBSERVATIONVALUE: return "_ActCoverageAssessmentObservationValue"; 1539 case _ACTFINANCIALSTATUSOBSERVATIONVALUE: return "_ActFinancialStatusObservationValue"; 1540 case ASSET: return "ASSET"; 1541 case ANNUITY: return "ANNUITY"; 1542 case PROP: return "PROP"; 1543 case RETACCT: return "RETACCT"; 1544 case TRUST: return "TRUST"; 1545 case INCOME: return "INCOME"; 1546 case CHILD: return "CHILD"; 1547 case DISABL: return "DISABL"; 1548 case INVEST: return "INVEST"; 1549 case PAY: return "PAY"; 1550 case RETIRE: return "RETIRE"; 1551 case SPOUSAL: return "SPOUSAL"; 1552 case SUPPLE: return "SUPPLE"; 1553 case TAX: return "TAX"; 1554 case LIVEXP: return "LIVEXP"; 1555 case CLOTH: return "CLOTH"; 1556 case FOOD: return "FOOD"; 1557 case HEALTH: return "HEALTH"; 1558 case HOUSE: return "HOUSE"; 1559 case LEGAL: return "LEGAL"; 1560 case MORTG: return "MORTG"; 1561 case RENT: return "RENT"; 1562 case SUNDRY: return "SUNDRY"; 1563 case TRANS: return "TRANS"; 1564 case UTIL: return "UTIL"; 1565 case ELSTAT: return "ELSTAT"; 1566 case ADOPT: return "ADOPT"; 1567 case BTHCERT: return "BTHCERT"; 1568 case CCOC: return "CCOC"; 1569 case DRLIC: return "DRLIC"; 1570 case FOSTER: return "FOSTER"; 1571 case MEMBER: return "MEMBER"; 1572 case MIL: return "MIL"; 1573 case MRGCERT: return "MRGCERT"; 1574 case PASSPORT: return "PASSPORT"; 1575 case STUDENRL: return "STUDENRL"; 1576 case HLSTAT: return "HLSTAT"; 1577 case DISABLE: return "DISABLE"; 1578 case DRUG: return "DRUG"; 1579 case IVDRG: return "IVDRG"; 1580 case PGNT: return "PGNT"; 1581 case LIVDEP: return "LIVDEP"; 1582 case RELDEP: return "RELDEP"; 1583 case SPSDEP: return "SPSDEP"; 1584 case URELDEP: return "URELDEP"; 1585 case LIVSIT: return "LIVSIT"; 1586 case ALONE: return "ALONE"; 1587 case DEPCHD: return "DEPCHD"; 1588 case DEPSPS: return "DEPSPS"; 1589 case DEPYGCHD: return "DEPYGCHD"; 1590 case FAM: return "FAM"; 1591 case RELAT: return "RELAT"; 1592 case SPS: return "SPS"; 1593 case UNREL: return "UNREL"; 1594 case SOECSTAT: return "SOECSTAT"; 1595 case ABUSE: return "ABUSE"; 1596 case HMLESS: return "HMLESS"; 1597 case ILGIM: return "ILGIM"; 1598 case INCAR: return "INCAR"; 1599 case PROB: return "PROB"; 1600 case REFUG: return "REFUG"; 1601 case UNEMPL: return "UNEMPL"; 1602 case _ALLERGYTESTVALUE: return "_AllergyTestValue"; 1603 case A0: return "A0"; 1604 case A1: return "A1"; 1605 case A2: return "A2"; 1606 case A3: return "A3"; 1607 case A4: return "A4"; 1608 case _COVERAGELIMITOBSERVATIONVALUE: return "_CoverageLimitObservationValue"; 1609 case _COVERAGELEVELOBSERVATIONVALUE: return "_CoverageLevelObservationValue"; 1610 case ADC: return "ADC"; 1611 case CHD: return "CHD"; 1612 case DEP: return "DEP"; 1613 case DP: return "DP"; 1614 case ECH: return "ECH"; 1615 case FLY: return "FLY"; 1616 case IND: return "IND"; 1617 case SSP: return "SSP"; 1618 case _CRITICALITYOBSERVATIONVALUE: return "_CriticalityObservationValue"; 1619 case CRITH: return "CRITH"; 1620 case CRITL: return "CRITL"; 1621 case CRITU: return "CRITU"; 1622 case _GENETICOBSERVATIONVALUE: return "_GeneticObservationValue"; 1623 case HOMOZYGOTE: return "Homozygote"; 1624 case _OBSERVATIONMEASURESCORING: return "_ObservationMeasureScoring"; 1625 case COHORT: return "COHORT"; 1626 case CONTVAR: return "CONTVAR"; 1627 case PROPOR: return "PROPOR"; 1628 case RATIO: return "RATIO"; 1629 case _OBSERVATIONMEASURETYPE: return "_ObservationMeasureType"; 1630 case COMPOSITE: return "COMPOSITE"; 1631 case EFFICIENCY: return "EFFICIENCY"; 1632 case EXPERIENCE: return "EXPERIENCE"; 1633 case OUTCOME: return "OUTCOME"; 1634 case PROCESS: return "PROCESS"; 1635 case RESOURCE: return "RESOURCE"; 1636 case STRUCTURE: return "STRUCTURE"; 1637 case _OBSERVATIONPOPULATIONINCLUSION: return "_ObservationPopulationInclusion"; 1638 case DENEX: return "DENEX"; 1639 case DENEXCEP: return "DENEXCEP"; 1640 case DENOM: return "DENOM"; 1641 case IP: return "IP"; 1642 case IPP: return "IPP"; 1643 case MSRPOPL: return "MSRPOPL"; 1644 case NUMER: return "NUMER"; 1645 case NUMEX: return "NUMEX"; 1646 case _PARTIALCOMPLETIONSCALE: return "_PartialCompletionScale"; 1647 case G: return "G"; 1648 case LE: return "LE"; 1649 case ME: return "ME"; 1650 case MI: return "MI"; 1651 case N: return "N"; 1652 case S: return "S"; 1653 case _SECURITYOBSERVATIONVALUE: return "_SecurityObservationValue"; 1654 case _SECINTOBV: return "_SECINTOBV"; 1655 case _SECALTINTOBV: return "_SECALTINTOBV"; 1656 case ABSTRED: return "ABSTRED"; 1657 case AGGRED: return "AGGRED"; 1658 case ANONYED: return "ANONYED"; 1659 case MAPPED: return "MAPPED"; 1660 case MASKED: return "MASKED"; 1661 case PSEUDED: return "PSEUDED"; 1662 case REDACTED: return "REDACTED"; 1663 case SUBSETTED: return "SUBSETTED"; 1664 case SYNTAC: return "SYNTAC"; 1665 case TRSLT: return "TRSLT"; 1666 case VERSIONED: return "VERSIONED"; 1667 case _SECDATINTOBV: return "_SECDATINTOBV"; 1668 case CRYTOHASH: return "CRYTOHASH"; 1669 case DIGSIG: return "DIGSIG"; 1670 case _SECINTCONOBV: return "_SECINTCONOBV"; 1671 case HRELIABLE: return "HRELIABLE"; 1672 case RELIABLE: return "RELIABLE"; 1673 case UNCERTREL: return "UNCERTREL"; 1674 case UNRELIABLE: return "UNRELIABLE"; 1675 case _SECINTPRVOBV: return "_SECINTPRVOBV"; 1676 case _SECINTPRVABOBV: return "_SECINTPRVABOBV"; 1677 case CLINAST: return "CLINAST"; 1678 case DEVAST: return "DEVAST"; 1679 case HCPAST: return "HCPAST"; 1680 case PACQAST: return "PACQAST"; 1681 case PATAST: return "PATAST"; 1682 case PAYAST: return "PAYAST"; 1683 case PROAST: return "PROAST"; 1684 case SDMAST: return "SDMAST"; 1685 case _SECINTPRVRBOBV: return "_SECINTPRVRBOBV"; 1686 case CLINRPT: return "CLINRPT"; 1687 case DEVRPT: return "DEVRPT"; 1688 case HCPRPT: return "HCPRPT"; 1689 case PACQRPT: return "PACQRPT"; 1690 case PATRPT: return "PATRPT"; 1691 case PAYRPT: return "PAYRPT"; 1692 case PRORPT: return "PRORPT"; 1693 case SDMRPT: return "SDMRPT"; 1694 case SECTRSTOBV: return "SECTRSTOBV"; 1695 case TRSTACCRDOBV: return "TRSTACCRDOBV"; 1696 case TRSTAGREOBV: return "TRSTAGREOBV"; 1697 case TRSTCERTOBV: return "TRSTCERTOBV"; 1698 case TRSTLOAOBV: return "TRSTLOAOBV"; 1699 case LOAAN: return "LOAAN"; 1700 case LOAAN1: return "LOAAN1"; 1701 case LOAAN2: return "LOAAN2"; 1702 case LOAAN3: return "LOAAN3"; 1703 case LOAAN4: return "LOAAN4"; 1704 case LOAAP: return "LOAAP"; 1705 case LOAAP1: return "LOAAP1"; 1706 case LOAAP2: return "LOAAP2"; 1707 case LOAAP3: return "LOAAP3"; 1708 case LOAAP4: return "LOAAP4"; 1709 case LOAAS: return "LOAAS"; 1710 case LOAAS1: return "LOAAS1"; 1711 case LOAAS2: return "LOAAS2"; 1712 case LOAAS3: return "LOAAS3"; 1713 case LOAAS4: return "LOAAS4"; 1714 case LOACM: return "LOACM"; 1715 case LOACM1: return "LOACM1"; 1716 case LOACM2: return "LOACM2"; 1717 case LOACM3: return "LOACM3"; 1718 case LOACM4: return "LOACM4"; 1719 case LOAID: return "LOAID"; 1720 case LOAID1: return "LOAID1"; 1721 case LOAID2: return "LOAID2"; 1722 case LOAID3: return "LOAID3"; 1723 case LOAID4: return "LOAID4"; 1724 case LOANR: return "LOANR"; 1725 case LOANR1: return "LOANR1"; 1726 case LOANR2: return "LOANR2"; 1727 case LOANR3: return "LOANR3"; 1728 case LOANR4: return "LOANR4"; 1729 case LOARA: return "LOARA"; 1730 case LOARA1: return "LOARA1"; 1731 case LOARA2: return "LOARA2"; 1732 case LOARA3: return "LOARA3"; 1733 case LOARA4: return "LOARA4"; 1734 case LOATK: return "LOATK"; 1735 case LOATK1: return "LOATK1"; 1736 case LOATK2: return "LOATK2"; 1737 case LOATK3: return "LOATK3"; 1738 case LOATK4: return "LOATK4"; 1739 case TRSTMECOBV: return "TRSTMECOBV"; 1740 case _SEVERITYOBSERVATION: return "_SeverityObservation"; 1741 case H: return "H"; 1742 case L: return "L"; 1743 case M: return "M"; 1744 case _SUBJECTBODYPOSITION: return "_SubjectBodyPosition"; 1745 case LLD: return "LLD"; 1746 case PRN: return "PRN"; 1747 case RLD: return "RLD"; 1748 case SFWL: return "SFWL"; 1749 case SIT: return "SIT"; 1750 case STN: return "STN"; 1751 case SUP: return "SUP"; 1752 case RTRD: return "RTRD"; 1753 case TRD: return "TRD"; 1754 case _VERIFICATIONOUTCOMEVALUE: return "_VerificationOutcomeValue"; 1755 case ACT: return "ACT"; 1756 case ACTPEND: return "ACTPEND"; 1757 case ELG: return "ELG"; 1758 case INACT: return "INACT"; 1759 case INPNDINV: return "INPNDINV"; 1760 case INPNDUPD: return "INPNDUPD"; 1761 case NELG: return "NELG"; 1762 case _ANNOTATIONVALUE: return "_AnnotationValue"; 1763 case _COMMONCLINICALOBSERVATIONVALUE: return "_CommonClinicalObservationValue"; 1764 case _INDIVIDUALCASESAFETYREPORTVALUEDOMAINS: return "_IndividualCaseSafetyReportValueDomains"; 1765 case _INDICATIONVALUE: return "_IndicationValue"; 1766 default: return "?"; 1767 } 1768 } 1769 public String getSystem() { 1770 return "http://hl7.org/fhir/v3/ObservationValue"; 1771 } 1772 public String getDefinition() { 1773 switch (this) { 1774 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."; 1775 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."; 1776 case ASSET: return "Codes specifying asset indicators used to assess or establish eligibility for coverage under a policy or program."; 1777 case ANNUITY: return "Indicator of annuity ownership or status as beneficiary."; 1778 case PROP: return "Indicator of real property ownership, e.g. deed or real estate contract."; 1779 case RETACCT: return "Indicator of retirement investment account ownership."; 1780 case TRUST: return "Indicator of status as trust beneficiary."; 1781 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."; 1782 case CHILD: return "Indicator of child support payments received or provided."; 1783 case DISABL: return "Indicator of disability income replacement payment."; 1784 case INVEST: return "Indicator of investment income, e.g. dividend check, annuity payment; real estate rent, investment divestiture proceeds; trust or endowment check."; 1785 case PAY: return "Indicator of paid employment, e.g. letter of hire, contract, employer letter; copy of pay check or pay stub."; 1786 case RETIRE: return "Indicator of retirement payment, e.g. pension check."; 1787 case SPOUSAL: return "Indicator of spousal or partner support payments received or provided; e.g. alimony payment; support stipulations in a divorce settlement."; 1788 case SUPPLE: return "Indicator of income supplement, e.g. gifting, parental income support; stipend, or grant."; 1789 case TAX: return "Indicator of tax obligation or payment, e.g. statement of taxable income."; 1790 case LIVEXP: return "Codes specifying living expense indicators used to assess or establish eligibility for coverage under a policy or program."; 1791 case CLOTH: return "Indicator of clothing expenses."; 1792 case FOOD: return "Indicator of transportation expenses."; 1793 case HEALTH: return "Indicator of health expenses; including medication costs, health service costs, financial participations, and health coverage premiums."; 1794 case HOUSE: return "Indicator of housing expense, e.g. household appliances, fixtures, furnishings, and maintenance and repairs."; 1795 case LEGAL: return "Indicator of legal expenses."; 1796 case MORTG: return "Indicator of mortgage amount, interest, and payments."; 1797 case RENT: return "Indicator of rental or lease payments."; 1798 case SUNDRY: return "Indicator of transportation expenses."; 1799 case TRANS: return "Indicator of transportation expenses, e.g. vehicle payments, vehicle insurance, vehicle fuel, and vehicle maintenance and repairs."; 1800 case UTIL: return "Indicator of transportation expenses."; 1801 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."; 1802 case ADOPT: return "Indicator of adoption."; 1803 case BTHCERT: return "Indicator of birth."; 1804 case CCOC: return "Indicator of creditable coverage."; 1805 case DRLIC: return "Indicator of driving status."; 1806 case FOSTER: return "Indicator of foster child status."; 1807 case MEMBER: return "Indicator of status as covered member under a policy or program, e.g. member id card or coverage document."; 1808 case MIL: return "Indicator of military status."; 1809 case MRGCERT: return "Indicator of marriage status."; 1810 case PASSPORT: return "Indicator of citizenship."; 1811 case STUDENRL: return "Indicator of student status."; 1812 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."; 1813 case DISABLE: return "Indication of disability."; 1814 case DRUG: return "Indication of drug use."; 1815 case IVDRG: return "Indication of IV drug use ."; 1816 case PGNT: return "Non-clinical report of pregnancy."; 1817 case LIVDEP: return "Code specifying observations related to living dependency, such as dependent upon spouse for activities of daily living."; 1818 case RELDEP: return "Continued living in private residence requires functional and health care assistance from one or more relatives."; 1819 case SPSDEP: return "Continued living in private residence requires functional and health care assistance from spouse or life partner."; 1820 case URELDEP: return "Continued living in private residence requires functional and health care assistance from one or more unrelated persons."; 1821 case LIVSIT: return "Code specifying observations related to living situation for a person in a private residence."; 1822 case ALONE: return "Living alone. Maps to PD1-2 Living arrangement (IS) 00742 [A]"; 1823 case DEPCHD: return "Living with one or more dependent children requiring moderate supervision."; 1824 case DEPSPS: return "Living with disabled spouse requiring functional and health care assistance"; 1825 case DEPYGCHD: return "Living with one or more dependent children requiring intensive supervision"; 1826 case FAM: return "Living with family. Maps to PD1-2 Living arrangement (IS) 00742 [F]"; 1827 case RELAT: return "Living with one or more relatives. Maps to PD1-2 Living arrangement (IS) 00742 [R]"; 1828 case SPS: return "Living only with spouse or life partner. Maps to PD1-2 Living arrangement (IS) 00742 [S]"; 1829 case UNREL: return "Living with one or more unrelated persons."; 1830 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."; 1831 case ABUSE: return "Indication of abuse victim."; 1832 case HMLESS: return "Indication of status as homeless."; 1833 case ILGIM: return "Indication of status as illegal immigrant."; 1834 case INCAR: return "Indication of status as incarcerated."; 1835 case PROB: return "Indication of probation status."; 1836 case REFUG: return "Indication of refugee status."; 1837 case UNEMPL: return "Indication of unemployed status."; 1838 case _ALLERGYTESTVALUE: return "Indicates the result of a particular allergy test; e.g. Negative, Mild, Moderate, Severe"; 1839 case A0: return "Description:Patient exhibits no reaction to the challenge agent."; 1840 case A1: return "Description:Patient exhibits a minimal reaction to the challenge agent."; 1841 case A2: return "Description:Patient exhibits a mild reaction to the challenge agent."; 1842 case A3: return "Description:Patient exhibits moderate reaction to the challenge agent."; 1843 case A4: return "Description:Patient exhibits a severe reaction to the challenge agent."; 1844 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."; 1845 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."; 1846 case ADC: return "Description:Child over an age as specified by coverage policy or program, e.g. student, differently abled, and income dependent."; 1847 case CHD: return "Description:Dependent biological, adopted, foster child as specified by coverage policy or program."; 1848 case DEP: return "Description:Person requiring functional and/or financial assistance from another person as specified by coverage policy or program."; 1849 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."; 1850 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."; 1851 case FLY: return "Description:As specified by coverage policy or program."; 1852 case IND: return "Description:Person as specified by coverage policy or program."; 1853 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"; 1854 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."; 1855 case CRITH: return "Worst case result of a future exposure is assessed to be life-threatening."; 1856 case CRITL: return "Worst case result of a future exposure is not assessed to be life-threatening."; 1857 case CRITU: return "Unable to assess the worst case result of a future exposure."; 1858 case _GENETICOBSERVATIONVALUE: return "Description: The domain contains genetic analysis specific observation values, e.g. Homozygote, Heterozygote, etc."; 1859 case HOMOZYGOTE: return "Description: An individual having different alleles at one or more loci regarding a specific character"; 1860 case _OBSERVATIONMEASURESCORING: return "Observation values used to indicate the type of scoring (e.g. proportion, ratio) used by a health quality measure."; 1861 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)."; 1862 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)."; 1863 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)."; 1864 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)."; 1865 case _OBSERVATIONMEASURETYPE: return "Observation values used to indicate what kind of health quality measure is used."; 1866 case COMPOSITE: return "A measure that is composed from one or more other measures and indicates an overall summary of those measures."; 1867 case EFFICIENCY: return "A measure related to the efficiency of medical treatment."; 1868 case EXPERIENCE: return "A measure related to the level of patient engagement or patient experience of care."; 1869 case OUTCOME: return "A measure that indicates the result of the performance (or non-performance) of a function or process."; 1870 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."; 1871 case RESOURCE: return "A measure related to the extent of use of clinical resources or cost of care."; 1872 case STRUCTURE: return "A measure related to the structure of patient care."; 1873 case _OBSERVATIONPOPULATIONINCLUSION: return "Observation values used to assert various populations that a subject falls into."; 1874 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."; 1875 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"; 1876 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."; 1877 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."; 1878 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."; 1879 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)."; 1880 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)."; 1881 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.)"; 1882 case _PARTIALCOMPLETIONSCALE: return "PartialCompletionScale"; 1883 case G: return "Value for Act.partialCompletionCode attribute that implies 81-99% completion"; 1884 case LE: return "Value for Act.partialCompletionCode attribute that implies 61-80% completion"; 1885 case ME: return "Value for Act.partialCompletionCode attribute that implies 41-60% completion"; 1886 case MI: return "Value for Act.partialCompletionCode attribute that implies 1-20% completion"; 1887 case N: return "Value for Act.partialCompletionCode attribute that implies 0% completion"; 1888 case S: return "Value for Act.partialCompletionCode attribute that implies 21-40% completion"; 1889 case _SECURITYOBSERVATIONVALUE: return "Observation values used to indicate security observation metadata."; 1890 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."; 1891 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)"; 1892 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."; 1893 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."; 1894 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."; 1895 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."; 1896 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."; 1897 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"; 1898 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."; 1899 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."; 1900 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."; 1901 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)"; 1902 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."; 1903 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."; 1904 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)"; 1905 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."; 1906 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."; 1907 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."; 1908 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."; 1909 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."; 1910 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."; 1911 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."; 1912 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."; 1913 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."; 1914 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."; 1915 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."; 1916 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."; 1917 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."; 1918 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."; 1919 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."; 1920 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."; 1921 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."; 1922 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."; 1923 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."; 1924 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."; 1925 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."; 1926 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."; 1927 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."; 1928 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."; 1929 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."; 1930 case SECTRSTOBV: return "Observation value used to indicate aspects of trust applicable to an IT resource (data, information object, service, or system capability)."; 1931 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."; 1932 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]"; 1933 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."; 1934 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."; 1935 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]"; 1936 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.]"; 1937 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.]"; 1938 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.]"; 1939 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.]"; 1940 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]"; 1941 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.]"; 1942 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.]"; 1943 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."; 1944 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.]"; 1945 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."; 1946 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.]"; 1947 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.]"; 1948 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.]"; 1949 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.]"; 1950 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]"; 1951 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]"; 1952 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]"; 1953 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]"; 1954 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]"; 1955 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."; 1956 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]"; 1957 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]"; 1958 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]"; 1959 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]"; 1960 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]"; 1961 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]"; 1962 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]"; 1963 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]"; 1964 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]"; 1965 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]"; 1966 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]"; 1967 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]"; 1968 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]"; 1969 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]"; 1970 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]"; 1971 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]"; 1972 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]"; 1973 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]"; 1974 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]"; 1975 case TRSTMECOBV: return "Values for security trust mechanism metadata observation made about a security architecture system component that supports enforcement of security policies."; 1976 case _SEVERITYOBSERVATION: return "Potential values for observations of severity."; 1977 case H: return "Indicates the condition may be life-threatening or has the potential to cause permanent injury."; 1978 case L: return "Indicates the condition may result in some adverse consequences but is unlikely to substantially affect the situation of the subject."; 1979 case M: return "Indicates the condition may result in noticable adverse adverse consequences but is unlikely to be life-threatening or cause permanent injury."; 1980 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."; 1981 case LLD: return "Lying on the left side."; 1982 case PRN: return "Lying with the front or ventral surface downward; lying face down."; 1983 case RLD: return "Lying on the right side."; 1984 case SFWL: return "A semi-sitting position in bed with the head of the bed elevated approximately 45 degrees."; 1985 case SIT: return "Resting the body on the buttocks, typically with upper torso erect or semi erect."; 1986 case STN: return "To be stationary, upright, vertical, on one's legs."; 1987 case SUP: return "supine"; 1988 case RTRD: return "Lying on the back, on an inclined plane, typically about 30-45 degrees with head raised and feet lowered."; 1989 case TRD: return "Lying on the back, on an inclined plane, typically about 30-45 degrees, with head lowered and feet raised."; 1990 case _VERIFICATIONOUTCOMEVALUE: return "Values for observations of verification act results\r\n\n \n Examples: Verified, not verified, verified with warning."; 1991 case ACT: return "Definition: Coverage is in effect for healthcare service(s) and/or product(s)."; 1992 case ACTPEND: return "Definition: Coverage is in effect for healthcare service(s) and/or product(s) - Pending Investigation"; 1993 case ELG: return "Definition: Coverage is in effect for healthcare service(s) and/or product(s)."; 1994 case INACT: return "Definition: Coverage is not in effect for healthcare service(s) and/or product(s)."; 1995 case INPNDINV: return "Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Investigation."; 1996 case INPNDUPD: return "Definition: Coverage is not in effect for healthcare service(s) and/or product(s) - Pending Eligibility Update."; 1997 case NELG: return "Definition: Coverage is not in effect for healthcare service(s) and/or product(s). May optionally include reasons for the ineligibility."; 1998 case _ANNOTATIONVALUE: return "AnnotationValue"; 1999 case _COMMONCLINICALOBSERVATIONVALUE: return "Description:Used in a patient care message to value simple clinical (non-lab) observations."; 2000 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."; 2001 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."; 2002 default: return "?"; 2003 } 2004 } 2005 public String getDisplay() { 2006 switch (this) { 2007 case _ACTCOVERAGEASSESSMENTOBSERVATIONVALUE: return "ActCoverageAssessmentObservationValue"; 2008 case _ACTFINANCIALSTATUSOBSERVATIONVALUE: return "ActFinancialStatusObservationValue"; 2009 case ASSET: return "asset"; 2010 case ANNUITY: return "annuity"; 2011 case PROP: return "real property"; 2012 case RETACCT: return "retirement investment account"; 2013 case TRUST: return "trust"; 2014 case INCOME: return "income"; 2015 case CHILD: return "child support"; 2016 case DISABL: return "disability pay"; 2017 case INVEST: return "investment income"; 2018 case PAY: return "paid employment"; 2019 case RETIRE: return "retirement pay"; 2020 case SPOUSAL: return "spousal or partner support"; 2021 case SUPPLE: return "income supplement"; 2022 case TAX: return "tax obligation"; 2023 case LIVEXP: return "living expense"; 2024 case CLOTH: return "clothing expense"; 2025 case FOOD: return "food expense"; 2026 case HEALTH: return "health expense"; 2027 case HOUSE: return "household expense"; 2028 case LEGAL: return "legal expense"; 2029 case MORTG: return "mortgage"; 2030 case RENT: return "rent"; 2031 case SUNDRY: return "sundry expense"; 2032 case TRANS: return "transportation expense"; 2033 case UTIL: return "utility expense"; 2034 case ELSTAT: return "eligibility indicator"; 2035 case ADOPT: return "adoption document"; 2036 case BTHCERT: return "birth certificate"; 2037 case CCOC: return "creditable coverage document"; 2038 case DRLIC: return "driver license"; 2039 case FOSTER: return "foster child document"; 2040 case MEMBER: return "program or policy member"; 2041 case MIL: return "military identification"; 2042 case MRGCERT: return "marriage certificate"; 2043 case PASSPORT: return "passport"; 2044 case STUDENRL: return "student enrollment"; 2045 case HLSTAT: return "health status"; 2046 case DISABLE: return "disabled"; 2047 case DRUG: return "drug use"; 2048 case IVDRG: return "IV drug use"; 2049 case PGNT: return "pregnant"; 2050 case LIVDEP: return "living dependency"; 2051 case RELDEP: return "relative dependent"; 2052 case SPSDEP: return "spouse dependent"; 2053 case URELDEP: return "unrelated person dependent"; 2054 case LIVSIT: return "living situation"; 2055 case ALONE: return "alone"; 2056 case DEPCHD: return "dependent children"; 2057 case DEPSPS: return "dependent spouse"; 2058 case DEPYGCHD: return "dependent young children"; 2059 case FAM: return "live with family"; 2060 case RELAT: return "relative"; 2061 case SPS: return "spouse only"; 2062 case UNREL: return "unrelated person"; 2063 case SOECSTAT: return "socio economic status"; 2064 case ABUSE: return "abuse victim"; 2065 case HMLESS: return "homeless"; 2066 case ILGIM: return "illegal immigrant"; 2067 case INCAR: return "incarcerated"; 2068 case PROB: return "probation"; 2069 case REFUG: return "refugee"; 2070 case UNEMPL: return "unemployed"; 2071 case _ALLERGYTESTVALUE: return "AllergyTestValue"; 2072 case A0: return "no reaction"; 2073 case A1: return "minimal reaction"; 2074 case A2: return "mild reaction"; 2075 case A3: return "moderate reaction"; 2076 case A4: return "severe reaction"; 2077 case _COVERAGELIMITOBSERVATIONVALUE: return "CoverageLimitObservationValue"; 2078 case _COVERAGELEVELOBSERVATIONVALUE: return "CoverageLevelObservationValue"; 2079 case ADC: return "adult child"; 2080 case CHD: return "child"; 2081 case DEP: return "dependent"; 2082 case DP: return "domestic partner"; 2083 case ECH: return "employee"; 2084 case FLY: return "family coverage"; 2085 case IND: return "individual"; 2086 case SSP: return "same sex partner"; 2087 case _CRITICALITYOBSERVATIONVALUE: return "CriticalityObservationValue"; 2088 case CRITH: return "high criticality"; 2089 case CRITL: return "low criticality"; 2090 case CRITU: return "unable to assess criticality"; 2091 case _GENETICOBSERVATIONVALUE: return "GeneticObservationValue"; 2092 case HOMOZYGOTE: return "HOMO"; 2093 case _OBSERVATIONMEASURESCORING: return "ObservationMeasureScoring"; 2094 case COHORT: return "cohort measure scoring"; 2095 case CONTVAR: return "continuous variable measure scoring"; 2096 case PROPOR: return "proportion measure scoring"; 2097 case RATIO: return "ratio measure scoring"; 2098 case _OBSERVATIONMEASURETYPE: return "ObservationMeasureType"; 2099 case COMPOSITE: return "composite measure type"; 2100 case EFFICIENCY: return "efficiency measure type"; 2101 case EXPERIENCE: return "experience measure type"; 2102 case OUTCOME: return "outcome measure type"; 2103 case PROCESS: return "process measure type"; 2104 case RESOURCE: return "resource use measure type"; 2105 case STRUCTURE: return "structure measure type"; 2106 case _OBSERVATIONPOPULATIONINCLUSION: return "ObservationPopulationInclusion"; 2107 case DENEX: return "denominator exclusions"; 2108 case DENEXCEP: return "denominator exceptions"; 2109 case DENOM: return "denominator"; 2110 case IP: return "initial population"; 2111 case IPP: return "initial patient population"; 2112 case MSRPOPL: return "measure population"; 2113 case NUMER: return "numerator"; 2114 case NUMEX: return "numerator exclusions"; 2115 case _PARTIALCOMPLETIONSCALE: return "PartialCompletionScale"; 2116 case G: return "Great extent"; 2117 case LE: return "Large extent"; 2118 case ME: return "Medium extent"; 2119 case MI: return "Minimal extent"; 2120 case N: return "None"; 2121 case S: return "Some extent"; 2122 case _SECURITYOBSERVATIONVALUE: return "SecurityObservationValue"; 2123 case _SECINTOBV: return "security integrity"; 2124 case _SECALTINTOBV: return "alteration integrity"; 2125 case ABSTRED: return "abstracted"; 2126 case AGGRED: return "aggregated"; 2127 case ANONYED: return "anonymized"; 2128 case MAPPED: return "mapped"; 2129 case MASKED: return "masked"; 2130 case PSEUDED: return "pseudonymized"; 2131 case REDACTED: return "redacted"; 2132 case SUBSETTED: return "subsetted"; 2133 case SYNTAC: return "syntactic transform"; 2134 case TRSLT: return "translated"; 2135 case VERSIONED: return "versioned"; 2136 case _SECDATINTOBV: return "data integrity"; 2137 case CRYTOHASH: return "cryptographic hash function"; 2138 case DIGSIG: return "digital signature"; 2139 case _SECINTCONOBV: return "integrity confidence"; 2140 case HRELIABLE: return "highly reliable"; 2141 case RELIABLE: return "reliable"; 2142 case UNCERTREL: return "uncertain reliability"; 2143 case UNRELIABLE: return "unreliable"; 2144 case _SECINTPRVOBV: return "provenance"; 2145 case _SECINTPRVABOBV: return "provenance asserted by"; 2146 case CLINAST: return "clinician asserted"; 2147 case DEVAST: return "device asserted"; 2148 case HCPAST: return "healthcare professional asserted"; 2149 case PACQAST: return "patient acquaintance asserted"; 2150 case PATAST: return "patient asserted"; 2151 case PAYAST: return "payer asserted"; 2152 case PROAST: return "professional asserted"; 2153 case SDMAST: return "substitute decision maker asserted"; 2154 case _SECINTPRVRBOBV: return "provenance reported by"; 2155 case CLINRPT: return "clinician reported"; 2156 case DEVRPT: return "device reported"; 2157 case HCPRPT: return "healthcare professional reported"; 2158 case PACQRPT: return "patient acquaintance reported"; 2159 case PATRPT: return "patient reported"; 2160 case PAYRPT: return "payer reported"; 2161 case PRORPT: return "professional reported"; 2162 case SDMRPT: return "substitute decision maker reported"; 2163 case SECTRSTOBV: return "security trust observation"; 2164 case TRSTACCRDOBV: return "trust accreditation observation"; 2165 case TRSTAGREOBV: return "trust agreement observation"; 2166 case TRSTCERTOBV: return "trust certificate observation"; 2167 case TRSTLOAOBV: return "trust assurance observation"; 2168 case LOAAN: return "authentication level of assurance value"; 2169 case LOAAN1: return "low authentication level of assurance"; 2170 case LOAAN2: return "basic authentication level of assurance"; 2171 case LOAAN3: return "medium authentication level of assurance"; 2172 case LOAAN4: return "high authentication level of assurance"; 2173 case LOAAP: return "authentication process level of assurance value"; 2174 case LOAAP1: return "low authentication process level of assurance"; 2175 case LOAAP2: return "basic authentication process level of assurance"; 2176 case LOAAP3: return "medium authentication process level of assurance"; 2177 case LOAAP4: return "high authentication process level of assurance"; 2178 case LOAAS: return "assertion level of assurance value"; 2179 case LOAAS1: return "low assertion level of assurance"; 2180 case LOAAS2: return "basic assertion level of assurance"; 2181 case LOAAS3: return "medium assertion level of assurance"; 2182 case LOAAS4: return "high assertion level of assurance"; 2183 case LOACM: return "token and credential management level of assurance value)"; 2184 case LOACM1: return "low token and credential management level of assurance"; 2185 case LOACM2: return "basic token and credential management level of assurance"; 2186 case LOACM3: return "medium token and credential management level of assurance"; 2187 case LOACM4: return "high token and credential management level of assurance"; 2188 case LOAID: return "identity proofing level of assurance"; 2189 case LOAID1: return "low identity proofing level of assurance"; 2190 case LOAID2: return "basic identity proofing level of assurance"; 2191 case LOAID3: return "medium identity proofing level of assurance"; 2192 case LOAID4: return "high identity proofing level of assurance"; 2193 case LOANR: return "non-repudiation level of assurance value"; 2194 case LOANR1: return "low non-repudiation level of assurance"; 2195 case LOANR2: return "basic non-repudiation level of assurance"; 2196 case LOANR3: return "medium non-repudiation level of assurance"; 2197 case LOANR4: return "high non-repudiation level of assurance"; 2198 case LOARA: return "remote access level of assurance value"; 2199 case LOARA1: return "low remote access level of assurance"; 2200 case LOARA2: return "basic remote access level of assurance"; 2201 case LOARA3: return "medium remote access level of assurance"; 2202 case LOARA4: return "high remote access level of assurance"; 2203 case LOATK: return "token level of assurance value"; 2204 case LOATK1: return "low token level of assurance"; 2205 case LOATK2: return "basic token level of assurance"; 2206 case LOATK3: return "medium token level of assurance"; 2207 case LOATK4: return "high token level of assurance"; 2208 case TRSTMECOBV: return "none supplied 6"; 2209 case _SEVERITYOBSERVATION: return "SeverityObservation"; 2210 case H: return "High"; 2211 case L: return "Low"; 2212 case M: return "Moderate"; 2213 case _SUBJECTBODYPOSITION: return "_SubjectBodyPosition"; 2214 case LLD: return "left lateral decubitus"; 2215 case PRN: return "prone"; 2216 case RLD: return "right lateral decubitus"; 2217 case SFWL: return "Semi-Fowler's"; 2218 case SIT: return "sitting"; 2219 case STN: return "standing"; 2220 case SUP: return "supine"; 2221 case RTRD: return "reverse trendelenburg"; 2222 case TRD: return "trendelenburg"; 2223 case _VERIFICATIONOUTCOMEVALUE: return "verification outcome"; 2224 case ACT: return "active coverage"; 2225 case ACTPEND: return "active - pending investigation"; 2226 case ELG: return "eligible"; 2227 case INACT: return "inactive"; 2228 case INPNDINV: return "inactive - pending investigation"; 2229 case INPNDUPD: return "inactive - pending eligibility update"; 2230 case NELG: return "not eligible"; 2231 case _ANNOTATIONVALUE: return "AnnotationValue"; 2232 case _COMMONCLINICALOBSERVATIONVALUE: return "common clinical observation"; 2233 case _INDIVIDUALCASESAFETYREPORTVALUEDOMAINS: return "Individual Case Safety Report Value Domains"; 2234 case _INDICATIONVALUE: return "IndicationValue"; 2235 default: return "?"; 2236 } 2237 } 2238 2239 2240} 2241