This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">


From HL7Wiki
Jump to navigation Jump to search
  • General - Very difficult to read the HTML version because of the need for horizontal scrolling. We solved this problem for CDA by making sure there was no inline content that was too wide.
  • General - Need to resolve the differences in terminology between the CTS document and the V3 Vocabulary chapter. For instance, the vocabulary chapter shows "x-domains" simply as abstract concepts. At the very least, it would help for this document to include enough information so that folks can then go to the vocabulary chapter and know how to identify vocabulary domains, value sets, etc.
  • General - Define the API using good vocabulary practices. Coded parameters are presumably similar to RIM attributes in that they can have an associated Vocabulary Domain, which can be constrained to a particular realm and coding system? In section 6.2.2, definition of RelationshipCode, the document states "… codes must be drawn from the HL7 ConceptRelationship code system whenever possible". Why not just declare the parameter as having a CWE value set?
  • Section 2.3 - please update reference to Terminology Query Language (TQL). The current hyperlink doesn't work.
  • Section 5.1.1 - please include reference to meta-model classes from which you've taken the yellow classes. You have a yellow class "ApplicationContext", which isn't present in HL7_V3_Meta-Model V 1.16, which is the latest version on the HL7 Models page.
  • Section 6.3 - Section labels should be the functions, rather then some new string. For instance, 6.3.2 is labeled "Validate a Coded Attribute", but would be easier to cross-reference with the tables in section 4 if it were labeled "validateCode". Hyperlinks from the functions in section 4 to their descriptions in section 6 would help.
  • Section 6.3 - There's a lack of consistency in the parameter names in section 6 vs. the corresponding names in the tables in section 4.
  • Section 6.3 - Would help to relate parameters back to the corresponding attribute in one of the models. For instance, section 6.3.2 defines an activeConceptsOnly parameter, which presumably is testing the value of CodedConcept.conceptStatus in the model in section 5.3.
  • Section 6.3 - Need to QA that a parameter is defined the same way each time it is used. For instance, section 6.3.2 defines an activeConceptsOnly parameter, stating that the allowable values are "true" or "false". The description of the activeConceptsOnly parameter in section 8.3.3 states that the allowable values are "TRUE" or "FALSE".
  • Section 7.2 - The model conflicts with the one in section 5.3 (e.g. codeSystem_id is of type string in 7.2 vs. OID in 5.3). Would recommend to clean up the model in section 5.3, and remove the model from section 7.2.
  • Section 9.1 - I think it might be clearer to keep all the models together towards the beginning of the document so that they are easier to turn to for reference.