Page tree

2018Nov_HARM_INITIALPROPOSAL_VOCAB_FM_kathleen_connor_Add 2 codes to ActCoverageType_20181026235609 v2.doc

Recommendation for HL7 RIM and/or Vocabulary Changes

RECOMMENDATION ID [1] :

 

For Harmonization During:

Nov 2018

FM WG 2

Sponsored by [2] :

FM WG

Sponsor’s Draft [3] :

v2 prep for final

Date Approved by Sponsor:

Final approved on 10/30/18

Initial – 10/19/18

Sponsor’s Status [4]

TBD

Editor/ Author:

Kathleen Connor

PROPOSALNAME:

New ActCoverageType Codes

Class Model Change Structural Vocabulary Change

Datatypes Change Other Vocabulary Change

 

SUMMARY RECOMMENDATION

Add MENTPOLOP (mental health outpatient policy) and MENTPOLIP (mental health inpatient policy) as two new leaf codes to  ActCode_ActCoverageTypeCode_ActInsuranceTypeCode_ActHealthInsuranceType Code ( OID: 2.16.840.1.113883.5.4) in response to FHIR FM CR 13024.

 

Add MENTPRGOP (mental health outpatient program) and MENTPRGIP (mental health inpatient program) as two new leaf codes to  ActCode_ActCoverageTypeCode_ActInsuranceTypeCode_ActProgramTypeCode ( OID: 2.16.840.1.113883.5.4) in response to FHIR FM CR 13024.

 

Add to _ActCoverageTypeCode value set and to FHIR CoverageTypeAndSelf-PayCodes (Coverage Type and Self-Pay Codes) value set @ http://hl7.org/fhir/ValueSet/coverage-type (2.16.840.1.113883.4.642.3.520)

 

VOCABULARY OBJECTS CHANGE SUMMARY

<<REQUIRED – fill in the numbers in the rightmost three columns that total the number of vocabulary changes in the proposal.  This is used to cross-check the accuracy of capturing and applying the requested changes>>

Abbrev.

Description

# to add

# to remove

# to change

D

Concept Domains

 

 

 

S

Code Systems

 

 

 

C

Concept Codes in a Code System

4

 

 

V

Value Sets

 

 

1 [A1]

B

Context Bindings

 

 

 

 

 

POSITION OF CONCERNED ORGANIZATIONS:

<<REQUIRED - This table should contain one row for each organization (e.g., TC, SIG, other SDO) known to be interested, and should outline any consultation with – and feedback from – the organization.  Overwrite the examples below. >>

 

ORG  

 

RECOMMENDATION APPROVAL STATUS

 

AFFECTED ELEMENTS OF INTEREST TO ORG

FM

Initial submission approved 10/19/2018

ActCoverageType

 

 

 

 

ISSUE:

FHIR Implementer asked that FM WG add MentalOP (mental health outpatient policy) and MentalIP (mental health inpatient policy) as two new leaf codes to  CR13024 , which the WG approved.

 

CR 13014 Details HL7 v3 Code System ActCode     _ActHealthInsuranceTypeCode defines a set of coverage types including:

MENTPOL:   a code for a   health insurance policy that covers benefits for mental health services and prescriptions

When processing health insurance   claims, it is often necessary to identify the specific type of coverage(inpatient or outpatient).  

Could   _ActHealthInsuranceTypeCode be extended to include the following codes?

MENTPOL-INP:   a code for a   health insurance policy that covers benefits for inpatient   mental health services and prescriptions

MENTPOL-OUTP:   a code for a   health insurance policy that covers benefits for   outpatient   mental health services and prescriptions

 

FM WG decided to make similar changes for mental health programs specifically covering benefits under a government program.

CURRENT STATE:

Concepts are missing.

OPTIONS CONSIDERED :

<<OPTIONAL – alternative approaches considered.  Include reason(s) for rejecting/selecting particular alternatives.>>

 

RATIONALE:

CR13024 was approved by FM 10/19/18.


RECOMMENDATION DETAILS:

 

  1. Add the following 2 codes as leaf codes in the ActCode_ActCoverageTypeCode_ActInsuranceTypeCode_ActHealthInsuranceType Code ( OID: 2.16.840.1.113883.5.4) .

 

Add Concept

Leaf CONCEPT:

MENTPOLIP (Mental health inpatient policy)

Description:

 

A health insurance policy that covers benefits for inpatient mental health services and prescriptions.

 

Add Concept

LEAF CONCEPT:

MENTPOLOP (Mental health outpatient policy)

Description:

A health insurance policy that covers benefits for outpatient mental health services and prescriptions.

 

  1. Add the following 2 codes as leaf codes in the ActCode_ActCoverageTypeCode_ActInsuranceTypeCode_ActProgramTypeCode ( OID: 2.16.840.1.113883.5.4) .

 

 

Add Concept

Leaf CONCEPT:

MENTPRGIP (Mental health inpatient program)

Description:

Government administered and funded mental health inpatient program for beneficiaries meeting financial and mental health status criteria. Administration, funding levels, eligibility criteria, covered benefits, provider types, and financial participation are typically set by a regulatory process. Payer responsibilities for administering the program may be delegated to contractors.

 

Add Concept

LEAF CONCEPT:

MENTPRGOP (Mental health outpatient program)

Description:

Government administered and funded mental health outpatient program for beneficiaries meeting financial and mental health status criteria. Administration, funding levels, eligibility criteria, covered benefits, provider types, and financial participation are typically set by a regulatory process. Payer responsibilities for administering the program may be delegated to contractors.

A health insurance policy that covers benefits for outpatient mental health services and prescriptions.

 

Value Set Recommendations

 

Add to ActCoverageTypeCode value set as intentional.  Definition of ActCoverageType is not immutable.

Bound to Domains: ActCoverageTypeCode (CWE) in C1 (Unclassified Realm)

 

Add to FHIR CoverageTypeAndSelf-PayCodes (Coverage Type and Self-Pay Codes) value set @ http://hl7.org/fhir/ValueSet/coverage-type ( 2.16.840.1.113883.4.642.3.520)

 

DISCUSSION:

<< OPTIONAL - Any additional information needed to understand, evaluate or implement the recommendation, such as model fragments or other context that demonstrates use of the requested change.  Include implications.>>

 

ACTION ITEMS:

<< REQUIRED - Actions needed to address this recommendation.  Minimal recommended action item is: "M&M to implement recommendation".>>

 

RESOLUTION:

<< REQUIRED before recommendation can be closed.  Indicates how recommendation was brought to closure. Can include notes on further study or networking required, and by whom.>>

 

Add requested Compartment codes to the ActCode code system as specializations of Compartment, and add to the Compartment value set.

 

 

Checklist for HL7 Vocabulary Harmonization Submissions

The following checklist must be completed for each submission and attached as part of the submission posting for every HL7 harmonization proposal that proposes a change to any HL7 terminology artifact.  (Submit your proposal as a zip containing the base proposal and this form, or copy this form onto the end of your proposal.)  If a revised proposal is submitted (e.g. detailed proposal after cover page), a new copy of the checklist must be attached confirming that the revised proposal has been re-reviewed.  The failure to attach a completed checklist will result in the tabling or deferral of the proposal to a subsequent harmonization meeting with the assumption the proposal will be re-introduced with a completed form.

The proposal has been constructed in such a way that the “correct” answer to each question is either “Yes” or “N/A”.  In the event that the answer is “No”, please provide an explanation at the end noting the question number and the reason why the checklist item has not been met.  Harmonization proposals that do not satisfy all checklist items may still be considered at harmonization at the discretion of the harmonization group and the vocabulary maintenance team if there is a satisfactory reason the checklist item could not be met.  Lack of time to complete the form does not constitute a satisfactory reason.

A section of the form may be marked as “N/A” and all checklist items within that section ignored if none of the terminology items submitted apply to that section.

In most circumstances, this checklist should be completed by the sponsor committee’s vocabulary facilitator, but it may be completed by any submitter.

Note : When checking for existing codes, code systems, value sets, etc., please make sure that your RoseTree configuration options are set to display Retired and Deprecated elements, as the “no duplicates” rule applies to those as well.

Before completing this checklist, please consult the following “best practices” and guidelines documents.  (They will be updated from time to time, so please review the documents for changes prior to each harmonization.)

Concept domain & Value set naming: http://wiki.hl7.org/index.php?title=Concept_Domain_Naming_Conventions

http://wiki.hl7.org/index.php?title=Value_Set_Naming_Conventions

 

Definitions: http://wiki.hl7.org/index.php?title=Anno t ations_Best_Practices

 

Terminology Good Practices: http://wiki.hl7.org/index.php?title=Good_Termin o lo g y_Practices

 

General

  1. Has the proposal, in its final form, been reviewed by the sponsor committee’s vocabulary facilitator (mark N/A if there is no facilitator)? ( - Yes; - No; - N/A)
  2. Have you completely filled out header section for the proposal and checked that the dates are correct and the submission number is unique across all of your submissions for this harmonization cycle? ( - Yes; - No; - N/A)
  3. Have you filled out the summary form identifying the number of created, updated and deprecated objects of each type? ( - Yes;)
  4. Has your proposal been submitted to and reviewed by all relevant WGs and been formally endorsed (with a vote recorded in the WG minutes) to be brought forward to harmonization?  (For harmonization submissions from international affiliates, approval by an appropriate affiliate level committee or project is sufficient, though submission to the relevant HL7 UV WG is strongly recommended.) ( - Yes; - No; - N/A)

New Concept Domains ( - N/A )

For all concept domains being created by this proposal:

  1. Have you done a key-word search for equivalent or similar concept domains and, if any exist, identified appropriate parent and child relationships to position your concept domain? ( - Yes; - No; - N/A)
  2. Have you provided a name for your concept domain that follows the naming guidelines?( - Yes; - No; - N/A)
  3. If your concept domain is not associated with a new RIM attribute or datatype property, have you identified a parent for your concept domain? ( - Yes; - No; - N/A)
  4. Have you checked whether any existing concept domains are proper specializations of your concept domain and, if so, identified those new specialization relationships as part of your proposal? ( - Yes; - No; - N/A)
  5. If your concept domain is in the ActCode, RoleCode or EntityCode hierarchy, have you identified the classCode that acts as the “root” for the concept domain? ( - Yes; - No; - N/A)
  6. Have you verified that all concept domains referenced as parent or child concepts actually exist in the most recent vocabulary repository and are correctly spelled in your proposal using U.S. language settings? ( - Yes; - No; - N/A)
  7. Have you provided a concise, non-tautological definition for your concept domain and confirmed that the definition follows the best practices for definitions? ( - Yes; - No; - N/A)
  8. Have you checked the name of your concept domain and associated definition for appropriate spelling and grammar using U.S. language settings, and consistency with the current Concept Domain naming conventions? ( - Yes; - No; - N/A)
  9. Have you either: Provided 3 distinct examples; identified a binding to an example value set with 3 distinct example codes; identified a representative binding; or identified a universal binding? ( - Yes; - No; - N/A)

Revised Concept Domains ( - N/A )

For all concept domains being revised by this proposal:

  1. Have you identified the name of the existing concept domain, and verified that the concept domain does in fact exist in the most recent vocabulary repository with the name spelled as referenced? ( - Yes; - No; - N/A)
  2. Have you verified that any additional concept domains identified as parents or children and any code referenced as the anchor for the concept domain actually exist and are spelled properly? ( - Yes; - No; - N/A)
  3. Have you confirmed that any change to the definition would not cause backwards compatibility issues with any models that reference the Concept Domain under the old definition? ( - Yes; - No; - N/A)
  4. Have you confirmed that any changes to the Concept Domain definition continue to comply with best practices for definitions? ( - Yes; - No; - N/A)
  5. Have you spell-checked and grammar checked your revised definition using U.S. language settings? ( - Yes; - No; - N/A)

New/Revised Code System ( - N/A )

For all code systems created or whose metadata is updated by this proposal:

  1. For new HL7-maintained code systems, have you confirmed that no other terminology maintenance organization is a more appropriate organization to maintain the code system and codes within it? ( - Yes; - No; - N/A)
  2. For new external code systems, have you confirmed that the code system follows the good terminology practices and is therefore appropriate for use in HL7 instances? ( - Yes; - No; - N/A)
  3. For external code systems where there is a desire for HL7 to publish codes from the external code system, have you verified that there are no copyright issues associated with the publication and provided a justification for why HL7 should take on this administrative effort as well as identified how the HL7 published versions will be kept in sync with the source? ( - Yes; - No; - N/A)
  4. Have you provided a short-name for the code system that is unique among all other code systems found in the HL7 OID registry? ( - Yes; - No; - N/A)
  5. For all code systems, have you provided:
    1. A long, unique “descriptive” name for the code system? ( - Yes; - No; - N/A)
    2. A description of the intended use and scope of the code system ( - Yes; - No; - N/A)
  6. For external code systems, have you provided:
    1. OID for the code system (if already registered in the HL7 OID registry or otherwise assigned an OID)? ( - Yes; - No; - N/A)
    2. Licensing information ( - Yes; - No; - N/A)
    3. URL information for the official source of the vocabulary ( - Yes; - No; - N/A)
    4. Contact Information ( - Yes; - No; - N/A)
    5. The “short name” for the code system is consistent with the following rules (ISO Secondary Identifier rules plus some HL7 constraints)
      1. No spaces
      2. Only the characters 0-9, a-z, A-Z and hyphens
      3. Cannot have multiple consecutive hyphens or end with a hyphen
      4. Leading character must be a lower-case alpha
      5. Must be unique from among all registered code systems in HL7’s OID registry
      6. Should not match any code system in HL7’s OID registry even when treating both as upper-case

Revised Code in Code System ( - N/A )

For all new codes created by this proposal:

  1. Have you searched the code system in the most recent repository using keywords to verify that an equivalent code doesn’t already exist? ( - Yes; - No; - N/A)
  2. Have you searched the code system in the most recent repository to confirm that no code already exists with the same code? ( - Yes; - No; - N/A)  Note that you must also check existing retired and/or deprecated codes for existence.
  3. If adding a code from an external code system for HL7 publication (where HL7 has agreed to publish codes from the external code system), have you confirmed that the code has actually been accepted by the external code system and confirmed the code, print names and definition are identical to those in the most recent version of the external code system? ( - Yes; - No; - N/A)

Added or Revised Code in Code System ( - N/A )

For all new codes created or updated by this proposal:

  1. When adding a code or changing a print name, have you search searched the code syste m in the most recent repository that no code already exists with the same print name? ( - Yes; - No; - N/A)
  2. Have you provided a code values and (where appropriate) print names that align with the naming convention for the code system?  (Generally all upper case, no spaces for codes, lower case for print names.  Depending on the code system, the code may be mnemonic or not). ( - Yes; - No; - N/A)
  3. Have you provided a definition for the code that follows the best practices for definitions? ( - Yes; - No; - N/A)
  4. Have you spell-checked (and for definitions grammar-checked) the definitions and print names using U.S. language settings? ( - Yes; - No; - N/A)
  5. Have you defined all required properties for the code system in which the code is being added? ( - Yes; - No; - N/A)
    1. ActClass: “specialized by concept domain”, Formal class name, formal name for association from participation to Act
    2. ActCode: “specialized by concept domain”
    3. ActMood: Formal name
    4. ActRelationshipType: “is document characteristic?”; applies to; how applies; Formal name from Act to outbound ActRelationship, ActRelationship to source Act, ActRelationship to target Act and Act to inbound ActRelationship; Sort for Act to inbound ActRelationship and Act to outbound ActRelationship
    5. CompressionAlgorithm: howApplies (mandatory, deprecated, other)
    6. EntityClass: “specialized by concept domain”, applies to determinerCode, Formal class name
    7. EntityDeterminer: Formal name
    8. GTSAbbreviation: Equivalent expression
    9. ObservationMethod: how applies?
    10. ParticipationType: “specialized by concept domain”, “is document characteristic?”, Formal name from Act to Participation and Role to Participation; Sort from Act to Participation and Role to Participation
    11. RoleClass: “specialized by concept domain”, Formal name, Participation to Role name, Role to player Entity name, Entity to played Role name, Entity to scoped Role name, Role to scoper Entity name, Entity to played Role sort, Entity to scoped Role sort
    12. RoleCode: conceptStatusQualifier
    13. RoleLinkType: Formal name from Role to outbound RoleLink, RoleLink to source Role, RoleLink to target Role and Role to inbound RoleLink; Sort for Role to inbound RoleLink and Role to outboundRoleLink
  6. Have you checked the current version of the code system and identified all code(s) that should be parents and/or children of the new concept and verified that you have listed them all appropriately (and spelled correctly) in your proposal? ( - Yes; - No; - N/A)
  7. Have you identified whether the code should be considered abstract or not? ( - Yes; - No; - N/A)
  8. If deprecating a code, have you identified a reason for the deprecation and provided guidance for what should be used instead? ( - Yes; - No; - N/A)

New Value Sets ( - N/A )

For all new value sets created as part of this proposal:

  1. Have you verified that the value set is appropriate to be registered in the HL7 Inc. repository (created against structural code systems, used in a UV, Example or Representative binding)? ( - Yes; - No; - N/A)
  2. Have you identified whether the value set definition is immutable?  I.e. It is a definition that must never be changed. ( - Yes; - No; - N/A)
  3. Have you verified that the name for the value set does not already exist in the existing HL7 repository? ( - Yes; - No; - N/A)
  4. Have you named the value set using the naming guidelines found here: http://wiki.hl7.org/index.php?title=Value_Set_Naming_Conventions ( - Yes; - No; - N/A)

New or Modified Value Sets ( - N/A )

For all value sets created or modified as part of this proposal:

  1. That any modified value sets are not flagged as immutable. ( - Yes; - No; - N/A)
  2. For non-immutable value sets, have you provided a description that explains the scope of the value set and the “owning” WG that should be responsible for determining how the value set definition evolves over time? ( - Yes; - No; - N/A)
  3. Have you defined all required properties for value sets drawn from one of the following structural code systems? ( - Yes; - No; - N/A)
    1. ActClass: Formal class name, formal name for association from participation to Act
    2. ActMood: Formal name
    3. ActRelationshipType: Formal name from Act to outbound ActRelationship, ActRelationship to source Act, ActRelationship to target Act and Act to inbound ActRelationship; Sort for Act to inbound ActRelationship and Act to outbound ActRelationship
    4. EntityClassFormal class name
    5. EntityDeterminer: Formal name
    6. ParticipationType: Formal name from Act to Participation and Role to Participation; Sort from Act to Participation and Role to Participation
    7. RoleClass: Formal name, Participation to Role name, Role to player Entity name, Entity to played Role name, Entity to scoped Role name, Role to scoper Entity name, Entity to played Role sort, Entity to scoped Role sort
    8. RoleLinkType: Formal name from Role to outbound RoleLink, RoleLink to source Role, RoleLink to target Role and Role to inbound RoleLink; Sort for Role to inbound RoleLink and Role to outboundRoleLink
  4. Have you checked that your value set name and description are correctly spelled (and for descriptions, have correct grammar) using U.S. language settings, and is consistent with the current Value Set naming conventions? ( - Yes; - No; - N/A)
  5. Have you checked that all references to codes in your value set definition identify their associated code system and actually exist within the current version of their respective code systems (both HL7 and external code systems)? ( - Yes; - No; - N/A)
  6. Have you verified that if your value set content definition is enumerated (extensional) that there is no appropriate or better way to define it as an expression-based (intentional) definition? ( - Yes; - No; - N/A)
  7. For expression-based value set content definitions, have you confirmed that your expression is expressed in a way that is fully defined against the HL7 metamodel? ( - Yes; - No; - N/A)
    1. For code-based value sets, identify whether the head-code is included or not
    2. For code-based value sets, identify whether the included codes should be children, all descendants or leaf nodes only
    3. For code based value sets, that the specific type of association to be navigated is identified if it is something other than the subsumption relationship
    4. For complex value sets, that they are expressed as a combination of unions, intersections and exclusions where “order of operations” is clearly documented
    5. For property-based value sets, that the referenced property names actually exist in their respective code systems and are spelled correctly
    6. That for mnemonic-based value sets, that the reg-ex expression to be evaluated against the codes is a valid reg-ex expression
  8. If deprecating a value set, have you identified a reason for the deprecation and provided guidance for what should be used instead? ( - Yes; - No; - N/A)

New Binding Realms (   - N/A )

For all new Binding Realms created as part of this proposal:

  1. Have you identified the owning affiliate and the superset binding realm? ( - Yes; - No; - N/A)
  2. Have you received official permission from the affiliate to create the new binding realm ( - Yes; - No; - N/A)
  3. Have you identified a proposed code for the binding realm that is unique amongst all binding realms in the most recent version of the repository following binding realm naming conventions (i.e. starting with the code for the affiliate)? ( - Yes; - No; - N/A)
  4. Have you provided a unique descriptive name for the new binding realm? ( - Yes; - No; - N/A)
  5. Have you provided a description that explains the scope of the new binding realm and spell-checked and grammar-checked it? ( - Yes; - No; - N/A)

New Context Bindings (   - N/A )

For all new Context Bindings created as part of this proposal:

  1. Have you declared the name of the concept domain, the binding realm and the value set name or OID? ( - Yes; - No; - N/A)
  2. Have you checked that the concept domain name, binding realm code and value set name or OID actually exist in the most recent version of the repository? ( - Yes; - No; - N/A)
  3. If the binding is not to be effective immediately upon harmonization approval and application of approved changes, have you identified the effective date? ( - Yes; - No; - N/A)
  4. Have you checked whether there is already a binding for the same concept domain and binding realm and if so, either specified a new sequence number (to allow parallel bindings) or a date to on which the old binding should end and the new one should become effective? ( - Yes; - No; - N/A)
  5. If binding in a realm other than “example”, have you conformed that the set of codes in the valueset being bound provides full coverage for the concept space defined by the concept domain? ( - Yes; - No; - N/A)

Explanation for N/A Items

 

 

Vocabulary Submission Checklist:

The following identifies the pieces of information that must be included or identified for the different types of vocabulary harmonization actions.  It is included here for convenience in order to make certain the proposal is complete; this is not intended to be ‘filled in’, but are things that must be checked and/or considered when making the proposals.  Any of these that are not included or done must be done during the application of the harmonization proposals after the meeting, and thus may not be deduced correctly if not explicit.  Each of these needed pieces of information is REQUIRED for that particular operation.

 

New Concept Domain:

Parent Domain if the new Domain is not at the root

Definition, plus three examples of concepts which would be in the same semantic category labeled by the Domain OR an Example binding. NOTE: these are not coded concepts, i.e. codes from a codeSystem

The name of the new Domain should follow the current practice pattern for naming

Modify Concept Domain:

New Parent if hierarchy change

Evaluation or Disposition of existing bindings

Impact on any models if name is to be changed

Remove Concept Domain:

Disposition of existing bindings

Removal comment

New Code Systems

Whether they are HL7-maintained or External, OID if one exists

Description

Full name (title) and short name (with no spaces or punctuation)

Modify Code System:

Only descriptions or full names may be modified; for content see Concept Codes

Deprecate/Delete Code System:

Disposition of existing value sets built on it, along with their existing bindings

Identification of what it is being superceded by

Deprecation comment

New Concept Codes:

The code system they are to be added to

The extensional value set(s) they are to be added to, if any

Their parent, if they are not at the root of the code system

Whether or not they are abstract (selectable)

Mnemonic, or code value (try to follow any pre-existing practice pattern)

Description

Print Name (try to follow any pre-existing practice pattern)

Deprecation/Deletion of Concept Codes:

The code system they are to be removed from

The new parent for any child concepts they may have had

The extensional value set(s) that they should also be removed from, if any

Deprecation comment

Modify Concept Codes:

The code system it is in

Modified description (if that is the modification)

Change to/from abstract (if that is the modification)

Change position of code in hierarchy – identify old/new parent, and any impacts on child codes

New Value Set:

Name (without spaces); must fit the current practice pattern of naming style

Name (Title)

Optional Description

Code System it is based on (primary)

Extensional vs. Intensional

Definition expression/contents list

Deprecate/Delete Value Set:

Disposition of existing bindings, both Model and Context

Identification of other value sets that include the one to be deleted

Modify Value Set

Updated Print Name, with identification of Model bindings affected

Updated defining expression/contents list

New Context Binding

Name of Domain plus Name of Value Set plus OID of Value Set (if present) plus Context

Modify Context Binding

Name of Domain plus Name of Value Set plus OID of Value Set (if present) plus New Context

Removal of Existing Context Binding

Name of Domain plus Name of Value Set plus OID of Value Set (if present) plus Context

 

 

Note that you must follow up name changes to Concept Domains or Value Sets that are done during the harmonization meeting are applied to any bindings that have been specified in the Static Model (using the RMIM designer tool) so that the binding will point to the new name of the object.


[1] identifier by which proposal is known to sponsor

[2] must be sponsored by an HL7 TC, the HL7 International Committee, an HL7 SIG, or an ANSI or ISO accredited SDO

[3] for sponsor tracking only; not for Harmonization identification

[4] for sponsor tracking only, Sponsor’s status must be “Approved” for submission to Harmonization


[A1] Not sure if I should count the change to the FHIR value set as a change.  Don’t think I need to add count for additions to the intentionally defined ActCoverageTypeCode value set