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