FHIR Conformance QA Criteria

Note: the following criteria are draft and propose criteria that may apply to various Conformance resources. They are based on the conformance criteria found here: DSTU_QA_Guidelines

StructureDefinition - Resource definition

1. Introduction

a. Contexts Identified: Resource introductions should identify a broad set of example contexts in which the resource might be used. (Should be minimum of 3, as many as 8-10.)

b. Differentiated from peers: Resource introductions must clearly differentiate the resource from any similar resources where an implementer might wonder "which of these should I use in my scenario?"

c. Non-examples provided: Where implementers might be tempted to use a resource inappropriately, work groups should explicitly document "non-examples" (i.e. don't use this resource for x)

d. TOOL? Specify entered-in-error: Resource should have an definition for 'entered in error' status (see lifecyle.html#error)

2. Examples

a. Examples are comprehensive: Examples should exist for every example context identified in the resource introduction and must, between them, show the use of every data element in the resource definition. Examples should include a mixture of "simple" and fully fleshed out "complex" scenarios. (Expect 5-10 examples/resource)

b. Examples ok for clinical/business w/ comments: Examples should be valid and reasonable from a clinical/business perspective and include comments explaining what they are representing where this is not obvious from the instance.

c. TOOL? Extensions have valid/example URLs: Where extensions appear in examples, those extensions should either be defined within published profiles (and point to those profiles by a valid URL) or should clearly be example extensions (using the prefix http://example.org/fhir/StructureDefinition)

3. Mappings

a. RIM mappings ok: Work group (or modeling representatives from it) must review the RIM mappings and verify they are correct and aligned with definitions

b. External mappings provided: Mappings should be provided to a minimum of 1 and ideally at least 2 or 3 broadly implemented specifications in the space covered by the resource (HL7 or non-HL7 – e.g. v2, CCDA, NCPDP, X12, ISO, etc.) where there is prior implementation experience

4. Value sets

a. Use correct code systems: Coded values should draw from external code systems as much as possible. If defining a CodeableConcept, FHIR-specific codes must only be used when no external code systems apply (and should be verified for 80% if this occurs).

• Preference is to use international code systems (SNOMED, LOINC, UCUM, ICD, etc.) where possible and where content is appropriate. These should be Preferred bindings - i.e. Appropriate and recommended for use.
• Existing HL7-maintained code systems (v2, v3) may be used if clearly superior to other international code systems after consulting HL7's Terminology Authority to confirm there are no plans to move these to an external code system (e.g. SNOMED, LOINC). These would also typically be Preferred bindings
• National code systems may be used when international codes don't apply/exist (e.g. manufactured drug codes). When using national code systems, draw from different countries (i.e. not just U.S.). National code systems can only be bound with type=Example, never with type=Preferred.
• If no appropriate external code exists for a CodeableConcept, look to the HL7 Terminology Authority to define one before considering defining one in FHIR. These would generally be type=Preferred bindings. (If you're not creating a "recommended" value set, it may be better to not create a value set at all.)
• For "code" elements, terminology should be HL7-controlled - either FHIR-specific or leveraging existing v2/v3 code systems
• "code" elements should have human-readable codes

b. Representative where possible: Value set bindings should be "Representative" whenever possible. I.e. The value set should be useable in production systems, at least as a reasonable starting point. (Though in some cases, might be limited to a specific country.)

c. omitted

d. code data type appropriate: Ensure the "code" data type is only used for "structural" elements or where it's reasonable to expect all implementations to use (or map to) a single value set. (Check with FMG if you're not sure.) Coding should only be used if the work group is confident that translations (and transitions) to other code systems will not be relevant for the element. I.e. CodeableConcept is the default.

e. Codes cover space, don't overlap: If constraining to the "code" data type, ensure that the set of available codes will be sufficient in all possible business scenarios (including "unknown" and possibly "other" situations), particularly if the element is minOccurs = 1. Also ensure all codes are mutually exclusive or are defined in a proper hierarchy where siblings are mutually exclusive

5. Elements

a. References point right way: Elements with a type of Resource Reference should be reviewed such that a given relationship shall only be represented in one resource, not both (and should generally be present on the resource that is normally created second – e.g. Procedure is usually created after Encounter, so reference would live on Procedure)

b. Inline vs. Reference ok: When a resource needs to refer to elements that could be modeled by referencing another resource, that is the preferred mechanism. However, content may be handled inline (as nested elements rather than by reference) if it is expected that less that 20% of existing systems would be capable of managing the content as a discrete resource.

c. isModifier ok: Ensure all elements (and only those elements) that could change the interpretation of other data are marked as "isModifier"

d. summary ok: Ensure resource identifies "summary" data elements and only includes those elements necessary for a summary "low bandwidth" list-type view of a resource

e. W5 column ok: The W5 column must be filled in with all matching elements. w5 elements not present in the resource should be evaluated as to whether they make sense for the resource and fall within the 80%. (See w5 page for details.

f. Workflow column ok: The workflow mapping column is filled in for all matching elements if the resource is based on 'Act' or one of its specializations in the RIM mapping. Workflow template elements not present in the resource should be evaluated as to whether they make sense for the resource and fall within the 80%.

g. Slice names computable: Slice names should be software-friendly: UpperCamelCase alpha-numeric, starting with an alpha

h. No use of prohibited elements: MnM approval should be sought before populating the "StructureDefinition.description", "identifier", "version", "code" or "snapshot.element.code" elements (so MnM can get a sense of how they're being used and ensure consistency)

6. Elements & search criterion items

a. Names appropriately consistent: Names of elements & search criteria for resources should be consistent across FHIR, particularly within the same "family" (e.g. medications, interventions, orders, w5 report equivalents, etc.), unless business convention dictates otherwise.

b. Elements sorted ok: Data elements & search criteria should be ordered in the same way across resources (particularly within the same "family"). Data elements should in general be ordered in a "sensible" way – related elements together, more important elements towards the top, "big" elements (those that take a lot of space in instances) towards the bottom. W5 elements must appear in the order defined unless there are strong business reasons for a different order (raise with MnM to get permission to override the sort rule for a given resource). Note that items related to W5 items can still be inter-mixed with W5 items.

7. Descriptive Content

a. Todos resolved: Review and resolve all "todos" in the specification

b. Best practice definitions: All data elements must have definitions that follow best practices:

• The first sentence (the main ‘definition') should be substitutable for the element name in a sentence
• It should include examples unless the data type makes examples meaningless (e.g. no need for example integers or dates) or there is a vocabulary binding
• It should provide additional guidance beyond the name and short description)
• Definitions should not document constraints that can be conveyed by invariants . I.e. If you can use an xpath to enforce a constraint, use the invariant mechanism.
• Definitions should use singular words for the element (e.g. "An observation related to this observation" not "Observations related to this observation")

c. Rationale provided where needed: Where not obvious even to those with little industry experience, rationale should be provided for each element indicating why it is necessary/appropriate

d. Committee notes filled in: The Committee notes column for the resource should identify all points of contention/controversy that have been resolved over the course of development (what elements got dropped & why, choice of repeating/non-repeating, choice of optionality, etc.)

8. Constraints

a. Narrative-only allowed: Constraints and minimum repetitions must not prevent "narrative only" resources and must allow for broad use of the resource (summary and anonymized reporting, scenarios of partial availability, etc.). MinOccurs=1 should only occur when the work group is certain that there are no known use-cases where a system might need to communicate when the value could potentially be unknown or unavailable. This will tend to be for "structural" elements.

b. Not over-restrictive: Ensure that constraints (minOccurs, formalConstraints) are ones that can be reasonably met across all possible resource usages (partial data, summary reporting, etc.) and, if not, make them conditional on some other element.

c. Profiles on types approved: Profiles on element types, if present, must be HL7 International defined profiles and their use requires MnM approval

9. Search

a. Criteria meet 80%: Ensure that appropriate search criteria are defined for the 80% (i.e. everything that most systems would use, but not more)

b. Descriptions complete: Search descriptions should provide guidance or examples on how they could be used in addition to what they're searching – i.e. how is this search parameter useful?

StructureDefinition - Data type definition

• TODO

StructureDefinition - Constraint / Profile

1. Introduction

a. Contexts Identified: Profile introductions should identify the set of example contexts in which the profile might be used. (May be as few as 1, but can be multiple.)

b. Differentiated from peers: Profile introductions must clearly differentiate the profile from any similar profiles where an implementer might wonder "which of these should I use in my scenario?" This differentiation only needs to be done in the context of artifacts produced by the same organization. E.g. HL7 International

c. Non-examples provided: Where implementers might be tempted to use a profile inappropriately, work groups should explicitly document "non-examples" (i.e. don't use this profile for x)

e. Publisher/contact included: Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact

f. Jurisdiction declared: Profile must declare the jurisdiction(s) for which it was designed. (Use the code for International if not jurisdiction-specific). As well context should be declared where appropriate (e.g. oncology, veterinary, etc.)

g. Copyright ok For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required

h. Description present Must have StructureDefinition.description which provides an overview of the purpose of this particular profile

2. Examples

a. Examples are comprehensive: Examples should exist for every example context identified in the profile introduction and must, between them, show the use of every data element in the profile definition. (This can be limited to 'mustSupport' elements for profiles that set this property.) Examples should include a mixture of "simple" and fully fleshed out "complex" scenarios. (Expect 2-5 examples/profile)

b. Examples ok for clinical/business w/ comments: Examples should be valid and reasonable from a clinical/business perspective and include comments explaining what they are representing where this is not obvious from the instance.

c. TOOL? Extensions have valid/example URLs: Where extensions appear in examples, those extensions should either be defined within published profiles (and point to those profiles by a valid URL) or should clearly be example extensions (using the prefix http://example.org/fhir/StructureDefinition)

3. Mappings

a. RIM mappings ok: Work group(or modeling representatives from it) must review the RIM mappings and verify they are correct and aligned with definitions. Mappings will be imported from base resource but may be overridden to reflect the tighter semantics of the profile.

b. External mappings provided: Mappings should be provided to a minimum of 1 and ideally at least 2 or 3 broadly implemented specifications in the space covered by the resource (HL7 or non-HL7 – e.g. v2, CCDA, NCPDP, X12, ISO, etc.) where there is prior implementation experience

4. Value sets

a. Use correct code systems: Coded values should draw from external code systems as much as possible. (See resource criteria for guidance on code system selection.) If defining a CodeableConcept, FHIR-specific codes must only be used when no external code systems apply (and should be verified for 80% if this occurs).

b. Representative where possible: Value set bindings should be "Representative" whenever possible. I.e. The value set should be useable in production systems, at least as a reasonable starting point. (Though in some cases, might be limited to a specific country.) Use "Required" or "Extensible" only where there's certainty that the codes will be useful across all countries and scopes, or where the profile is explicitly defined as realm-specific.

c. omitted

g. Names computable: Slice names and re-useable type names should be software-friendly: UpperCamelCase alpha-numeric, starting with an alpha

h. No prohibited elements: MnM approval should be sought before populating the "identifier", "version", "code" or "snapshot.element.code" elements (so MnM can get a sense of how they're being used and ensure consistency)

5. Elements

i. Slicing Description present: If slicing is present, description must be present.

j. Discriminator for slices: If slicing is present, MnM approval must be sought if discriminator is not specified

k. Type profiles are HL7-defined: Profiles on element types, if present, must be HL7-Internationall-defined profiles

6. Elements & search criterion items

a. TOOL? Slice names must be UpperCamelCase alphanumeric. Slice names should be consistent within a profile and within families of related profiles (same IG, same domain)

b. Extensions sorted ok: Extensions should be ordered in the same way across profiles (particularly within the same "family"). Extensions should in general be ordered in a "sensible" way – related elements together, more important elements towards the top, "big" elements (those that take a lot of space in instances) towards the bottom.

7. Descriptive Content

a. Todos resolved: Review and resolve all "todos" in the specification

b. Best practice definitions: All overrides to definitions must follow definition best practices (see Resource criteria)

c. Rationale provided where needed: Where the reason for constraints would not be obvious even to those with little industry experience, rationale should be adjusted to include the reason for profile-specific constraints

d. Committee notes filled in: The Committee notes column for the profile should identify all points of contention/controversy that have been resolved over the course of development (what elements were marked as mustSupport & why, constraints on choice elements, cardinality, etc.)

8. Constraints

a. Narrative-only allowed?: Evaluate whether the use-case served by the profile should support narrative-only instances and, if so, ensure that constraints and minimum repetitions do not prevent "narrative only" instances. MinOccurs=1 should only occur when the work group is certain that there are no known use-cases in the profile context(s) where a system might need to communicate when the value could potentially be unknown or unavailable.

b. Not over-restrictive: Ensure that constraints (minOccurs, formalConstraints) are ones that can be reasonably met across all intended profile usages (partial data, summary reporting, etc.) and, if not, make them conditional on some other element.

StructureDefinition - Extension definition

1. Introduction

a. Contexts Identified: Extension introductions should identify the set of example contexts in which the extension might be used. (May be as few as 1, but can be multiple.)

b. Differentiated from peers: Extension introductions must clearly differentiate the extension from any similar extensions where an implementer might wonder "which of these should I use in my scenario?" This differentiation only needs to be done in the context of artifacts produced by the same organization. E.g. HL7 International

c. Non-examples provided: Where implementers might be tempted to use an extension inappropriately, work groups should explicitly document "non-examples" (i.e. don't use this extension for x)

e. Publisher/contact included: Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact

f. Jurisdiction declared: Extensions that are not "global" in scope must declare the jurisdiction(s) for which it was designed. (Use the code for International if not jurisdiction-specific). As well context should be declared where appropriate (e.g. oncology, veterinary, etc.)

g. Copyright ok For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required

h. Description blank Seek MnM approval before specifying any content for StructureDefinition.description

2. Examples

a. Examples are comprehensive: Examples should exist for every example context identified in the extension introduction and must, between them, show the use of every data element in the extension definition. Examples should include a mixture of "simple" and fully fleshed out "complex" scenarios. (Should have at least 1 example for non-trivial extensions – i.e. not for dates, numbers, etc. Complex multi-element extensions, strings or unbound coded elements should show how the extension might be used. Can be covered by an example instance using a containing resource instance.)

b. Examples ok for clinical/business w/ comments: Examples should be valid and reasonable from a clinical/business perspective and include comments explaining what they are representing where this is not obvious from the instance.

3. Mappings

a. RIM mappings ok: Work group (or modeling representatives from it) must review the RIM mappings and verify they are correct and aligned with definitions. HL7 International defined extensions must include RIM mappings or must explicitly declare they are not RIM mappable.

b. External mappings provided: Mappings should be provided to a minimum of 1 and ideally at least 2 or 3 broadly implemented specifications in the space covered by the resource (HL7 or non-HL7 – e.g. v2, CCDA, NCPDP, X12, ISO, etc.) where there is prior implementation experience.

4. Value sets

a. Use correct code systems: Coded values should draw from external code systems as much as possible. (See resource criteria for guidance on code system selection.) If defining a CodeableConcept, FHIR-specific codes must only be used when no external code systems apply (and should be verified for 80% if this occurs).

b. Representative where possible: Value set bindings should be "Representative" whenever possible. I.e. The value set should be useable in production systems, at least as a reasonable starting point. (Though in some cases, might be limited to a specific country.) Use "Required" or "Extensible" only where there's certainty that the codes will be useful across all countries and scopes, or where the profile is explicitly defined as realm-specific.

c. omitted

d. code data type appropriate: Ensure the "code" data type is only used for "structural" elements or where it's reasonable to expect all implementations to use (or map to) a single value set. (Check with FMG if you're not sure.) Coding should only be used if the work group is confident that translations (and transitions) to other code systems will not be relevant for the element. I.e. CodeableConcept is the default.

e. Codes cover space, don't overlap: If constraining to the "code" data type, ensure that the set of available codes will be sufficient in all possible business scenarios (including "unknown" and possibly "other" situations), particularly if the element is minOccurs = 1. Also ensure all codes are mutually exclusive or are defined in a proper hierarchy where siblings are mutually exclusive

h. No prohibited elements: MnM approval should be sought before populating the "identifier", "version", "code" or "snapshot.element.code" elements (so MnM can get a sense of how they're being used and ensure consistency)

5. Elements

a. References point right way: Elements with a type of Resource Reference should be reviewed such that a given relationship shall only be represented in one resource, not both (and should generally be present on the resource that is normally created second – e.g. Procedure is usually created after Encounter, so reference would live on Procedure). Should avoid defining extensions that could result in bi-directional associations. If necessary, ensure that implementation notes are included that warn of the risks of actually using bi-directional links between two instances.

c. isModifier ok: Ensure all elements (and only those elements) that could change the interpretation of other data are marked as "isModifier". If an extension can change the meaning of other elements, make sure it's marked as a modifier and make sure it's defined as appearing as a child of the deepest element that contains all elements modified by the extension.

6. Elements & search criterion items

a. Names appropriately consistent: Names of elements & search criteria for extensions should be consistent across FHIR, particularly within the same "family" (e.g. medications, interventions, orders, w5 report equivalents, etc.), unless business convention dictates otherwise. Extensions must be lower-camel-case alphanumeric only.

•  ??? TODO - See with more experience whether any naming consistency or notions of "families" arises, but no QA criteria as yet. At minimum, enforce consistent naming in terms of the use of camel-case vs. dashes vs. all lower case. Extensions must be lower-camel-case alphanumeric only, search parameter names must be all lower case alphanumeric only. Enforce a "banned" list of reserved words for Java, C#, SQL, Javascript & Delphi (for Grahame).

b. Elements sorted ok: For complex extensions, data elements & search criteria should be ordered in the same way across extensions/resources (particularly within the same "family"). Data elements should in general be ordered in a "sensible" way – related elements together, more important elements towards the top, "big" elements (those that take a lot of space in instances) towards the bottom. W5 elements must appear in the order defined unless there are strong business reasons for a different order (raise with MnM to get permission to override the sort rule for a given resource). Note that items related to W5 items can still be inter-mixed with W5 items.

7. Descriptive Content

a. Todos resolved: Review and resolve all "todos" in the specification

b. Best practice definitions: All data elements must have definitions that follow best practices (see Resource criteria)

c. Rationale provided where needed: Where not obvious even to those with little industry experience, rationale should be provided for each element indicating why it is necessary/appropriate

d. Committee notes filled in: The Committee notes column for the extension should identify all points of contention/controversy that have been resolved over the course of development (what elements got dropped & why, choice of repeating/non-repeating, choice of optionality, etc.)

8. Constraints

a. Narrative-only allowed: Constraints and minimum repetitions must not prevent "narrative only" resources and must allow for broad use of the resource (summary and anonymized reporting, scenarios of partial availability, etc.). MinOccurs=1 should only occur when the work group is certain that there are no known use-cases where a system might need to communicate when the value could potentially be unknown or unavailable. This will tend to be for "structural" elements.

b. Not over-restrictive: Ensure that constraints (minOccurs, formalConstraints) are ones that can be reasonably met across all possible resource usages (partial data, summary reporting, etc.) and, if not, make them conditional on some other element.

c. Profiles on types approved: Profiles on element types, if present, must be HL7 International defined profiles and their use requires MnM approval

9. Search

a. Criteria meet 80%: Ensure that appropriate search criteria are defined for the 80% (i.e. everything that most systems would use, but not more)

b. Descriptions complete: Search descriptions should provide guidance or examples on how they could be used in addition to what they're searching – i.e. how is this search parameter useful?

• A corresponding search criteria should exist for the extension if it's reasonable for systems to want to search on it

• Extension definitions should not overlap in purpose/meaning with other extensions (even if defined in other HL7 International maintained implementation guides) or with core elements that are found on the resource or data type element to be extended. Extensions that convey meaning that can be conveyed by chaining to elements found in other resources should be used with caution. (E.g. A data enterer extension isn't explicitly prohibited, but strong consideration should be given to using Provenance before adding an extension.)
• Display should be present if the name is made up of multiple words or would otherwise be inappropriate to use as the user interface display term for the extension
• MnM approval should be sought before defining extensions whose root element has a minimum cardinality of "1"
• Element names (for type references or slicing) should be software-friendly: UpperCamelCase alpha-numeric, starting with an alpha
• Profiles on element types, if present, must be HL7 International defined profiles
• mustSupport must not be declared on HL7-International defined extension definitions (declare it on the profiles where the extension is invoked)

StructureDefinition - Logical Model

• TODO

StructureMap

• 1a - must define the single context in which the mapping is intended to apply
• 1b - if there's more than one in the same space
• 1c
• 6a - StructureMaps should be named consistently within an IG and across similar/related IGs and within domains
• 7a
• 7c (Must populate the "requirements" element explaining why the structure map is needed and what its purpose is)
• 7d
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For structuremaps that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• FMG approval is required for an HL7-defined structure map to import other structure maps that are not HL7-defined
• Implementation Guides containing structure maps should include sample instances showing source and product when applying the structure map.

Terminology - CodeSystem

• 1a (Could be multiple or just one)
• 1b (Only in the scope of HL7 Int’l-defined artifacts)
• 1c
• 3a - Expect mappings to HL7 v3 vocabularies for FHIR-defined code systems where such mappings exist
• 3b - FHIR-defined code systems should try to map to 1-3 other "common" code systems where such mappings exist and would be of value to implementers (e.g. v2, CDA, ISO 21090, etc.)
• 6a Code system names within the same "families" should be labeled in a consistent fashion. Names should reflect the scope of intended use of the value set.
• 6b For large code systems (>~10 codes), codes should be listed in alphabetic order by code within hierarchy. For smaller code systems, concepts may be listed in "intuitive"/related order. For codes having ordinal relationships, list by either increasing or decreasing ordinal value.
• 7a
• 7b (Will use Vocab's rules for good practices, including non-tautological)
• 7c (Must populate the "requirements" element explaining why the code system is needed and why it's structured as it is)
• 7d
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For code systems that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• All codes must have both display names and definitions
• property names must be lowerCamelCase alpha-numeric
• properties must have meaningful/useful descriptions
• Filters must have descriptions explaining what the formal representation is doing
• If designations with a particular use/language are present on some codes, such designations must be present on all codes
• FHIR defined code systems cannot set compositional or versionNeeded to true and must set content=complete
• FHIR defined code systems must have "meaningful" code values, expressed in US-English
• HL7-defined code systems must be case sensitive
• For non-HL7-maintained code systems, FMG approval must be sought before allowing a content value other than "none"

Terminology - ValueSet

• 1a (Could be multiple or just one)
• 1b (Only in the scope of HL7 Int’l-defined artifacts)
• 1c
• 6a Value set names within the same "families" should be labeled in a consistent fashion. Names should reflect the scope of intended use of the value set.
• 6b For large enumerated value sets (>~10 codes), codes should be listed in alphabetic order by code within hierarchy. For smaller value sets, concepts may be listed in "intuitive"/related order. For codes having ordinal relationships, list by either increasing or decreasing ordinal value.
• 7a
• 7c (Must populate the "requirements" element explaining why the value set is needed and why it's structured as it is, draws from the terminology it does)
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For value sets that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• Value sets marked as immutable must have the use of isImmutable approved by the vocabulary work group

Terminology - ConceptMap

• 1c
• 6a ??? Will also explore the need for computable names here. Human-readable names should identify the two artifacts mapped and the primary scope/purpose of the mapping.
• 6b Mappings should be listed based on order of source concept, then target concept, the same as the codes/structure elements appear in their source systems.
• 7a
• 7c (Must populate the "requirements" element explaining why the concept map is needed and what its purpose is)
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For extensions that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• Source and target should be version-specific
• Source, target and OtherElement concepts must exist in their respective value set versions (automate)
• ConceptMap description should indicate whether the mapping is complete from a source and target perspective, and if incomplete, roughly what the coverage gaps are
• Description should provide an explanation of how dependsOn and product are used in the context of the mapping.

Terminology - NamingSystem

• 1a (Could be multiple or just one)
• 1b (Only in the scope of HL7 Int’l-defined artifacts)
• 1c
• 3b - Provide all other known "identifiers" for the naming system - OIDs, v2 code system labels or identifier types (where 1..1 with the system), etc.
• 6a Should be consistent with names of other artifacts of the same type. E.g. Avoid "Florida Drivers License" for one naming system and "Drivers License - Ohio" for another.
• 7a
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For naming systems that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• Include usage about how the identifier or code should be rendered (e.g. case sensitive, always upper case, remove whitespace or dashes, retain leading zeros, etc.) whenever there are usage constraints
• For HL7-defined naming systems, always use a meaningful URL, not an OID-based urn
• All NamingSystems should include at keast a URL for FHIR and, where one exists, the corresponding OID, both marked as primary
• Try to be consistent in populating "responsible" when the same agency is responsible for multiple identifier or code system types
• Do not use abbreviations for organizations in descriptions

Terminology - DataElement

• 1a - Could be just one
• 1b -
• 3b
• 4a-e
• 6a - consistency within "families" of data elements created for use in the same context(s)
• 7a
• 7b
• 7c (Must populate the "requirements" element explaining why the data element is needed and what its purpose is)
• 7d
• 8b
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For data elements that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• Stringency must be present

Behavior - ImplementationGuide

• 1a (Just one context)
• 1b (Only in the scope of HL7 Int’l-defined artifacts)
• 1c
• 6a Must adhere to naming guidelines for HL7 specifications as published by TSC.
• 6b ?? Will have separate guidance around implementation guide sections & ordering
• 7a
• 7c (Should have a "page" or section that describes why the implementation guide is needed and how/where it's intended to be used - e.g. use cases, storyboards, etc.)
• 7d Implementation guides should have a non-published text document that identifies any issues/controversial areas that came up during design and how they were resolved. (Not necessary to document discussion already present in tracker items)
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For extensions that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• Should start with a table of contents consisting of links that include, in most cases:
  • Overview
  • Purpose/Use cases
  • Conformance expectations & naming conventions
  • Security & General conformance rules
  • List of used Profiles
  • List of defined extensions
  • List of used value sets
  • List of defined system roles (Conformance instances)
  • Credits & contact information
• All pages within the IG should include links at the top and bottom that allow returning to the IG "home page" and should make it clear which implementation guide a page belongs to.

Behavior - CapabilityStatement

• 1a - Could be just one
• 1b - if not implementation-specific
• 6a - Conformance resources should be named consistently within an IG and across similar/related IGs and within domains
• 7a
• 7c (Must populate the "requirements" element explaining why the Conformance instance is needed and what its purpose is)
• 7d
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For conformance instances that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• "software" and "implementation" must not be present for Conformance instances intended to define system behavior as part of an implementation guide

Behavior - OperationDefinition

• 1a (Could be multiple or just one)
• 1b (Only in the scope of HL7 Int’l-defined artifacts)
• 1c
• 2a (1 or more examples showing invocation & response. Examples should cover major expected parameter combinations. Every parameter should be covered at least once)
• 2b
• 6a code must be lowerCamelCase alphanumeric avoiding reserved words. Operations must be unique within HL7-International defined OperationDefinitions taking into account the different contexts in which the operations can be invoked. Operations should be named consistently within resources and across families of resources, within IGs, etc.
• 6b Parameters should be grouped such that "related" parameters appear together and "more important" or required parameters appear before less important/optional parameters. All other things being equal, use alphabetic order.
• 7a
• 7b
  • The first sentence (the main ‘definition') should be substitutable for the element name in a sentence
  • It should include examples unless the data type makes examples meaningless (e.g. no need for example integers or dates) or there is a vocabulary binding
  • It should provide additional guidance beyond the name
  • Definitions should use singular words for the element (e.g. "An observation related to this observation" not "Observations related to this observation")
• 7c (Must populate the "requirements" element explaining why the operation is needed and what its purpose is)
• 7d
• 8b (if we add invariants)
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For operation definitions that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• Allow operations to be invoked in the context of a specific resource as well as by passing in a reference to the resource. Where appropriate, also allow invocation by business identifier
• Names of operations should be unique within HL7 and sufficiently descriptive to differentiate and understand the purpose when looking at a list of operations available
• Align parameter name and usage (including data type) with other operations defined by HL7, particularly for similar "types" of operations or operations intended to be invoked with the same context
• Adhere to 80% principles when deciding what parameters should be present, what data types and cardinalities to support, etc.
• Every parameter must have documentation explaining what the parameter does - this must be more than just a repetition of the name

Behavior - SearchParameter

• 1a (Could be multiple or just one)
• 1b (Only in the scope of HL7 Int’l-defined artifacts)
• 2a (At least one - Show in combination with other parameters with an explanation of intent of the search. I.e. how might this parameter be used to solve real use-cases.)
• 2b
• 6a Code must be alllowercase alphanumeric avoiding reserved words. Both code and name must be unique across all SearchParameters defined by HL7 International for the resource they apply to. Names and codes should be consistent within the resource and across families
• 7a
• 7b
  • The first sentence (the main ‘definition') should be substitutable for the element name in a sentence
  • It should include examples of use (why/how would you use the parameter)
  • It should provide additional guidance beyond the name
  • Definitions should use singular words for the element (e.g. "An observation related to this observation" not "Observations related to this observation")
• 7c (Where not obvious even to non-domain experts, should populate the "requirements" element explaining why the search criteria is needed and what its purpose is)
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For extensions that are not "global" in scope useContext should be declared for domain (e.g. pharmacy), realm (e.g. US), patient type (e.g. human vs. veterinary) should be declared
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• expression must be present (automate)

Behavior - MessageDefinition

• TODO

Behavior - CompartmentDefinition

• TODO

Behavior - GraphDefinition

• TODO

Testing - TestScript

• 1a (Just one)
• 6a ??? Will reach out to FHIR list for guidance here
• 6b ??? Will reach out to FHIR list for guidance here
• 7a
• 7c (Must populate the "requirements" element explaining what the test script is trying to accomplish and to differentiate it from other test scripts for the same resource(s) and/or profile(s))
• 7d If there are major points of contention in the design of a test script, XML comments should be used to capture those issues and their resolutions to help guide future development/maintenance
• Publisher and contact information must be set to the work group (and, where appropriate, project) responsible for maintaining the artifact
• For HL7 International defined artifacts, copyright should be left unspecified (and will default to the standard FHIR license). If alternate licensing arrangements are desired, FMG approval is required
• Metadata must be present for all systems involved in the test case
• Include metadata links to relevant portions of the spec to make clear what areas are being tested
• Setup & teardown must be defined such that the system returns to its original state, even in case of test failure
• Include descriptions for each test step explaining the purpose

Web Page

(e.g. http.html, xml.html, etc.)

• All non-navigation pages (i.e. pages whose primary purposes is not navigation of the spec) must have a header that allows identification of the responsible work group
• Only "implementable" pages should have an FMM level and ballot status. (Ballot status of non-implementable pages is "supporting material")
  • Note: We will need to add the notion of "supporting material" and mixed-level artifacts to the GOM