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

• Extension definition StructureDefinitions
  • 1a (Could be multiple or just one)
  • 1b (Only in the scope of HL7 Int’l-defined artifacts)
  • 1c
  • 2a (Should have at least 1 for non-trivial extensions – i.e. not for dates, numbers, etc. However good for complex multi-element extensions or for strings or unbound coded elements to show how element might be used. Can be covered by an example instance using a containing resource instance.)
  • 2b
  • 3a HL7 Int’l defined extensions must include RIM mappings or must explicitly declare they are not RIM mappable
  • 3b
  • 4a Preferred is generally desired. Use "Required" or "Extensible" only where there's certainty that the codes will be useful across all countries and scopes, or where the extension is explicitly defined as realm-specific.
  • 4b, 4c, 4d, 4e
  • 5a 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
  • 5c 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
  • 6a ??? - 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).
  • 6b (For complex extensions)

• Constraint StructureDefinitions
  • 1a (Could be multiple or just one)
  • 1b (Only in the scope of HL7 Int’l-defined artifacts)
  • 1c
  • 2a
  • 2b
  • 2c
  • 3a RIM mappings are only required for HL7 Int’l-defined constraint profiles if the mappings would differ from the underlying resource.
  • 3b
  • 4a Preferred is generally desired. Use "Required" or "Extensible" only where there's certainty that the codes will be useful across all countries and scopes, or where the extension is explicitly defined as realm-specific.
  • 4b, 4c, 4d, 4e
  • 6a Slice names must be UpperCamelCase alphanumeric. Slice names should be consistent within a profile and within families of related profiles (same IG, same domain)
  • 6b (When listing permitted extensions)

• ValueSets
  • 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 ??? - Will explore whether there should be a 'computation-friendly' value set name. If so, will need naming guidelines. 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 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.

• ImplementationGuide instance
  • 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

• 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.

• NamingSystem
• Conformance
  • 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.

• 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 lowerCamelCase alphanumeric avoiding reserved words. Operations must be unique within HL7-Int'l 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.

• 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 Int'l for the resource they apply to. Names and codes should be consistent within the resource and across families

• TestScript
  • 1a (Just one)
  • 6a ??? Will reach out to FHIR list for guidance here
  • 6b ??? Will reach out to FHIR list for guidance here