IDDate CreatedLast UpdatedCommentorComment TypeExisting WordingProposed WordingDispositionDisposition CommentChanges made in revised STU documentVotevote date
10146/22/20166/22/2016Klein, William TedNewDescriptions of LockedDate (section 6.2.1) and the sections on VersionDate and VersionString (sections 7.1.2.1.2 and 7.1.2.1.3) seem to indicate by the current wording that they act differently or have different impacts. This would be erroneous.Wording needs to improved, possible with a change in naming, to make it explicitly clear that the VersionDate and VerstionString in the DrawnFromCodeSystem section are intended to function the same way and have the same effect (in the defined code system part of the CLD in the HL7 syntax) as the LockedDate (which scopes the entire CLD and all its components).PersuasiveVersionDate and VerstionString in the DrawnFromCodeSystem are part of the "HL7 Value Set Definition Expressions Syntax" and therefore is an optional expression syntax while LockedDate would be used for any syntax. Even so, it does seem prudent to align them to help clarify the similarity. Change VersionDate and VersionString to VersionLockedDate and VersionLockedString. Update the text in these sections to align. Also made changes to Expansion section (8.4.1.2, 8.4.1.3)YesRuss/Carol 9-0-09/11/2017
10789/14/20169/14/2016Beale, ThomasNew1.1 DataTypes used This specification makes use of the ISO 21090 data types, ...This is a widely applicable spec, but I don't think it needs to use ISO 21090, which is not widely used and creates an unnecessary dependency. As far as I could see, only a few types are needed, either primitive types like String, and a few types to do with representing codes, which could be defined inline in this spec. I think that would simplify.Not Persuasive with ModClarify that the spec is consistent with ISO 21090 but does not require implementation of ISO 21090 since so few are needed. Also list the set of datatypes we actually use, STR, ID, Integer, code. YesCarmella/Sandy. 9-0-09/11/2017
10799/14/20169/14/2016Beale, ThomasNew5.2.2.2.1 ScopeGiven the importance and potential items needed in scope, maybe it should be a fully structured class with attributes like 'focus', 'modelContext' and so on?Considered for future useGiven the practical difficulties implementations have had to even get a bit of scope text, we should collect data on less restrictive specification first.None neededCarmella/Sandy. 9-0-19/11/2017
10809/14/20169/14/2016Beale, ThomasNew5.2.2.3.3 License and IP InformationI would suggest two fields here, these are different things and usually need to be extracted separately. Also you may need a copyright field.PersuasiveAgree, will add a complex object with at least two additional text fields so there will be License, IP, and Copyright text, each with a slightly different focus and clarify how each would be used differently.Yes but need to update 5.1.4 class diagramRuss/Carol 9-0-09/11/2017
10819/14/20169/14/2016Beale, ThomasNew5.2.2.3.5 Example ContentThis is another attribute I would suggest doesn't belong in the VS Def per se, since it relates to the authoring and governance workflow but isn't really part of the definition as such, and will just be extra baggage in published VSDs.Persuasive with ModWe will remove this attribute and place text in the comment attribute usage notes indicating that if example concepts for the value set are needed during the workflow of the development and use of the value set, those examples should be placed in the comment field.Jim / Ted. 9-0-09/11/2017
10829/14/20169/14/2016Beale, ThomasNew5.2.2.3.6 Source ReferenceWe found we needed to make this a set of keyed Strings for archetypes, to allow for multiple references. Example - https://github.com/openEHR/adl-archetypes/blob/master/ADL2-reference/features/description/meta_data/openehr-test_pkg-WHOLE.full_meta_data.v0.0.1.adlsPersuasive with ModChange cardinality to 0..* Change text to indicate this can be a set of stringsYesJim / Ted. 9-0-09/11/2017
10839/14/20169/14/2016Beale, ThomasNew5.2.3.3.1 Activity StatusThe description is not clear - is the 'stage of use' by a particular user? By the development group? By some other organisation?Persuasive with Modtext updated. Note the lifecycle in next comment might be also useful? Clarify that this is the state variable for the VSD authoring and pubilcation state machineYesJim / Ted. 9-0-09/11/2017
10849/14/20169/14/2016Beale, ThomasNew5.2.3.3.3 Workflow StatusBy way of reference, this life cycle model might be a useful comparison. http://www.openehr.org/releases/AM/latest/docs/Identification/Identification.html#_lifecycle_modelConsidered for future useThe values for this element are up to the implementer to define. While comprehensive, the openEHR state model is more complex and in particular includes a "release candidate" which has not been reqested in our environment. After use, it may become apparent that this should be in the formal specification.Carmella/Sandy. 9-0-19/11/2017
10859/14/20169/14/2016Beale, ThomasNew5.2.3.3.6.2 CommentTimeStampNormally these separate timestamps of specific attributes would be covered by the global timestamp in the audit trail of each version, as managed by the versioning system? I can't imagine anyone wanting to query the timestamp just of a comment field... Robert McClure: I think you are noting that when implementing, the commentTImeStamp can be the global time stamp, but you're probably right that this can be improved.Persuasive with Modmake cardinality 0..1 but this does allow comments with no timestamp "defined within our model."YesJim / Ted. 9-0-09/11/2017
10869/14/20169/14/2016Beale, ThomasNew5.2.3.3.7 SufficientWouldn't it be more obvious to adjust the scope to correspond to whatever is actually in the Value Set? 'Sufficiency' is a subjective concept and I can't see how it can be set such that any user can determine whether the Value Set is safe to use or not. Robert McClure: This is a soft attribute that is intended to communicate to users as noted in the usage note. Note that the expectation is this would be populated when a value set "is sufficient" but I agree it's not real tight to that as a 0..1 ST . I think we did that to allow for more expressive documentation. Would you think it's better if this was a boolean with the default F? Thomas Beale: It just doesn't seem useful to me. Let's imagine some VS authors develop a VS under a defined life cycle and governance scheme. At some point they publish a release 1.0 version of the VS, ready for public use. Shouldn't the scope of that VS just correspond to the Expansion code set it generates? If not, it's probably not ready for publishing.PersuasiveAgree, this attribute will be removed from the specification.Jim / Ted. 9-0-09/11/2017
10879/14/20169/14/2016Beale, ThomasNew5.2.3.4.2 Type Definition: indicator of Value Set Definition being Extensional (Enumerated) or Intensional (Criteria-based) or Grouping (only references other Value Sets)Was the notion of a 'grouping' VS described earlier? Robert McClure: Apparently not. I think we removed a prior discussion of this in the final document. That said, even though VSAC uses this idea, it is an artifact of the VSAC implementation and not inherent in the VSD approach. I'd like to see the notion of "grouping" value sets go away as it's very similar to identifying "intensional/enumerated" as a type. This section likely needs work and could allow any implementation defined "type".Persuasive with ModWill make this less proscriptive. Change type to STRING. VSAC examples of Grouping, Extensional, Intensional will be described as potentially useful approach for use of this. Cardinality remains 0..1Jim / Ted. 9-0-09/11/2017
10889/14/20169/15/2016Beale, ThomasNew8 Value Set Expansion FileFirstly, why is this artefact a 'file'? Secondly, I'd argue that either here or in the VS Expansion, IS-A relationships are needed so that non-trivial value sets can be traversed in a meaningful fashion on the UI. Robert McClure: This is worthy of a bigger discussion and you should comment. We've held that what can be included in an expansion file is pretty open, but it would have to tie to the value set expansion set as created by the VSD. As such, this means we would need to have an expansion file definition that takes the output of the VSD and crafts the set of information desired in the expansion file. The bigger issue, which was discussed resulting in the specification, is can we have the VSD define more than the concept IDs as the expansion code set? I'd say in part, this is a discussion on what should be the "default" expansion file for any expansion? What must be included in all of them versus what can be added for special ones. What we are trying to avoid is the need to craft a different VSD because some users don't want all the code system info. Thomas Beale: I might suggest an object model of the fullest possible version of a published VS, with various attributes optional, allowing them to be added or not as required. Then various formats of this structure could be requested, e.g. - meta-data: basic, complete - content: concepts-only; concepts plus IS-A relationships; ... I think the more comprehensive meta-data relevant to internal governance pre-release of a VS should probably be in separate structures maintained in the VS repository, not in the VS artefact structure itself. I.e. associated with the VS in the manner of meta-data in versioning systems. Note: I have not studied this carefully so the above is only an initial suggestion, not a considered alternative!Persuasive with ModWe will remove the entire section on Value Set Expansions. Instead we will note that there is an upcoming Value Set Expansion specification that describes how an expansion is derived from a definition, how the content of the expansion is characterized, and that an expansion should point back to the definition used.Jim / Ted. 9-0-09/11/2017
10899/15/20169/15/2016Beale, ThomasNew5.2.1 Implied Constraints of Definitional and Non-definitionalElements .... For example, in the VSAC, "Steward" is a Value Set Definition version element that has been designated as definitional so when changed, will always result in a new version of the Value Set Definition, even if no other items have been changed.This statement appears to be an error - it contradicts the model shown here.Persuasive with ModThe intent was to show an example where something NON-DEFINITIONAL by the spec is used to force a new version in a specific implementation. This entire example has been removed since it is no longer accurate for VSAC functionality.YesJim / Ted. 9-0-09/11/2017
110910/14/201610/14/2016Hausam MD, RobertNew6.2.2 ActiveOnly It is assumed that a concept activity status of “DEPRECATED” or “RETIRED” or “INACTIVE” all represent a status that is NOT ACTIVE.The statement that a concept activity status of “DEPRECATED” represents a status that is NOT ACTIVE is inconsistent with the understanding of this as specified in other HL7 standards including V3 and FHIR. In both V3 and FHIR a concept that has been deprecated is still considered to be active, but for one or more reasons it is recommended to avoid using it (particularly for new development). Recommended new wording: It is assumed that a concept activity status value of “RETIRED” or “INACTIVE” represents a status that is NOT ACTIVE. A concept activity status of “DEPRECATED” is considered to be ACTIVE. A “DEPRECATED” concept remains available for use, if needed, but for one or more reasons it is recommended to avoid using that concept (particularly for new development).Persuasive with Modchanges made with a small addition. Ted: this shojuld be removed IMHO, as it is part of the profiling control over the Expansion now.Yes