|VSD Element||FHIR resource/extension url||MS?||Cardinality change needed||Notes||FHIR Action Needed?||Action|
Value Set Identifier
|url or identifier||No||In VSD, the value set identifer is the "globally unique string that characterizes the Value Set Definition". In FHIR the valueset.uri is the "Canonical identifier for this value set, represented as a URI (globally unique)". In FHIR, valueset = the defintion, expansion and metadata.||Yes|
1) Update VSD to adopt the FHIR URI definition - "A globally unique string for this value set, when it is referenced in a specification, model, design or an instance".
To Do: confirm FHIR definition for valueSet.identifier is correct.
Value Set Scope
|purpose or description or useContext||No||Neither purpose, useContext or any other existing FHIR element represents this VSD definitional element.||Yes|
1. Add a FHIR JIRA ticket (FHIR-25273) to summarize the gap. Options for resolution: update purpose? Update description and move what is in description currently into purpose?
Note that FHIR-24085 is related.
2. Add a FHIR JIRA ticket (FHIR-25272) to add a new complex element valueSet.scope with sub-elements named clinicalFocus, inclusionCriteria, exclusionCriteria and modelContext. All data types = string.
Definitions from VSD:
Scope: Description of the semantic space the Value Set Expansion is intended to cover.
Focus: The general focus of the Value Set as it relates to the intended semantic space. This can be the information about clinical relevancy or the statement about the general focus of the Value Set, such as a description of types of messages, payment options, geographic locations, etc.
Model Context: A statement that describes how this Value Set is to be used in an artifact.
Inclusion Criteria: Criteria describing what concepts or codes should be included and why.
Exclusion Criteria: Criteria describing what concepts or codes should be excluded and why.
Still to be decided: core element or extension. This is a required VSD element.
3/27/2020 update: may reverse course on this item and use valueSet.description one field - no separation of inclusion, exclusion, etc.
|4||Value Set Immutable||immutable||Yes||VSD requires the immutable element, FHIR does not, but that's OK||No||In the profile, this needs to be required|
|6||name or title or valueset-otherName||Yes (FHIR is 0...1, VSD is 1...1)||In FHIR, supports both a human readable (title) and computable (name) string. Though VSD does not include a computable string for this purpose, that's OK. Would be ideal if the preferred vsd.name is the FHIR.name||Yes|
VSD Profile - Note for vsd.name that fhir.valueset.title is the preferred corresponding name/match to the vsd.valueset.name. However, if a language or a preferred indicator is present, then you must use the valuset-otherTitle extension.
FHIR - the following need to be entered into a ticket:
1) update name of valuset-otherName to otherTitle, as its definition is currently inconsistent with the use of Name (computer friendly) vs Title (Human friendly) within FHIR
2) Update attribute "name" to "title"
3) Add attribute "titleLanguage" to support vsd.preferrednameindicator
|7||naming.NameLanguage||gap||gap, but ok||Yes||See item 6|
|8||naming.PreferredNameIndicator||gap||gap, but ok||Yes||See item 6|
|9||Definition URL||valueset-authoritativeSource||VSD definition for this: "a web pointer to where the Value Set Definition may be located." So this is simply a location to find the value set definition and is not an identifier.|
This has been resolved in FHIR by the addition of this resource: http://build.fhir.org/extension-valueset-authoritativesource.html
|10||Intellectual Property Information||copyright||OK||No|
|12||Source Reference||valueset-sourceReference||Added as an extension in FHIR: http://build.fhir.org/extension-valueset-sourcereference.html||No|
|13||Keyword||valueset-keyWord||FHIR Extension: http://build.fhir.org/extension-valueset-keyword.html||No|
|14||Use||useContext or valueset-usage||UseContext requires a code-value pair with codable concepts, usage is all text.||Yes|
|15||Value Set Definition Version||No|
|16||ValueSetDefinitionVersion.Identifier||version||Yes, required||The only version in valueSet is the overall version. This could change based on metadata or compose changes. When an expansion is the only included element in a resource, this is the version used for the expand.||No||Discussed on Jan 14, 2020 - version is critical to understanding a value set definition or expansion. See notes on ValueSetDefinition.activityStatus. Consider changing cardinality to 1.1|
|18||ValueSetDefinitionVersion.Content Logical Definition||compose||No|
Clarification needed in FHIR.
1) Has been addressed in the definition of valuset.expansion with the inclusion of an explicit statement around the stateless nature of expansions http://build.fhir.org/valueset-definitions.html#ValueSet.expansion
2) Upon review on 1/14/2020, group does not believe an invariant is required. Rather, an update to ticket FHIR-22664 (previously entered to address the issue with naked expansions) to state that, if a value set is to be persisted, the instance information received on a value set resource must be persisted by the terminology service. In other words, both valueset.status and valueset.version SHALL be populated with the instance information from the resource used for the expansion. See verbiage in http://build.fhir.org/valueset-definitions.html#ValueSet.expansion.parameter as an example. TICKET UPDATE COMPLETE 3/10/2020
3) Upn even futher review during 04/07/2020 call, it was noted that using valueset.status means the required binding to the PublicationStatus valueset must be compared to the allowed values in VSD. Initial review shows the following mapping:
FHIR <-> VSD
Active <-> Active
Unknown -> No equivalent
No equivalent ↔ Deleted
This will need to be included in the FHIR IG/Profile
|21||ValueSetDefinitionVersion.Activity Status Date||valueset-activityStatusDate||current extensions only address one activity status which means a new resource instance for every status update.|
extension modification needed; needs change request
guidnace needs to be included in VSDP
OPEN ISSUE: 3/10/2020
3/24/2020: this extension description is not correct because >1 version of a VSD may be active at one time. Without this date, you would only be able to use the lastUpdateDate (meta?) - and not know that it was a status change. Business version vs: resource version (which would be tracked in FHIR history, and not all servers have to support).
Most likely cardinality is wrong, the same business version can go through >1 FHIR status change
valueset.status.activityStatusDate (the extension is not at the right level)
Maybe guidance - every time you update valueSet.status, you should update activity status date.
04/07/2022: Ticket needs to be opened to update valueset.valueset-activityStatusDate to be set to valueset.status.valueset-activityStatusDate (i.e., updated to be an extension of valueset.status not valueset). Ticket should also reflect a change to the associated verbiage.
"activityStatusDate: The date when the associated Value Set Definition Version activity status is in effect."
"activityStatusDate: The date when the associated Value Set status is in effect."
"The date when the associated Value Set Definition Version activity status is in effect.
When the Activity Status is set to “Active”, the Activity Status Date defines the Effective Date which is the date-time the Value Set Definition Version becomes active. When the Activity Status is set to “Inactive”, the Activity Status Date is the date-time when the Value Set Definition version becomes Inactive. This cycle may happen multiple times. The specified time is expected to be one second after midnight UTC of the Activity Status Date. The date may be in the future.
It is strongly encouraged that the Activity Status be set such that no more than one Value Set Definition Version for a single Value Set Identifier can have an Activity Status of ACTIVE at the same time within a single realm. In cases where this is not true, evaluation of the alignment of a Value Set Expansion Code Set to a specific Value Set Definition, as referenced in a CD, will be problematic.
Changes to this element should never result in a new Value Set Definition Version."
"The date when the associated Value Set Status is in effect.
When the Status is set to “Active”, the Activity Status Date defines the Effective Date which is the date-time the Value Set becomes active. When the Status is set to “Inactive”, the Activity Status Date is the date-time when the Value Set Definition version becomes Inactive. This cycle may happen multiple times. The specified time is expected to be one second after midnight UTC of the Activity Status Date. The date may be in the future.
It is strongly encouraged that the Status be set such that no more than one Value Set Version for a single Value Set Identifier can have an Status of ACTIVE at the same time within a single realm. In cases where this is not true, evaluation of the alignment of a Value Set Expansion to a specific Value Set, as referenced in a CD, will be problematic.
Changes to this element should never result in a new Value Set Definition Version."
|22||ValueSetDefinitionVersion.Workflow Status||valueset-workflowStatus||VSD element has broader scope in that it applies to any activity state, not just 'draft' (FHIR 'preliminary') as FHIR does.||extension modification needed; needs change request|
make definition of extension and how used more robust. Note: the text changed to not restrict to preliminary status (found at the Feb 2020 meeting). Discussed that this element could be a coded element with an example binding.
Feb 2020: ADD JIRA: Change the name of the existing extension to workflowStatusDescription. FHIR-26550
APril 2020: commented that this one just requires a name change for the extension
|23||ValueSetDefinitionVersion.Steward||valueset-steward, publisher + contact|
extension was added as an extension for UTG, 0-* ContactDetail,
|guidnace needs to be included in VSDP|
April 2020: valueset.publisher includes the notion of a "steward" however there is overlap with the existing valueset.steward extension. We will recommend in the VSDP that if both exist, valueset.steward and valueset.author are used instead of valueset.publisher. If steward and author are the same, then valueset.publisher be used. It should be noted that the extensions all have datatype = ContactDetail whereas valueset.publisher is a string and contact details would be placed in valueset.contact.
|24||ValueSetDefinitionVersion.Author||valueset-author||valueset-author is 0-* ContactDetail||guidnace needs to be included in VSDP||See above|
|25||valueset.jurisdiction||In FHIR this reflects the jurisdiction where the value set author expects that the value set is intended to be used. It is not the same as the V3 realm that is part of value set binding in V3.||April 2020: VSD has no equivalent for jurisdiction. As this is not a required definitional element, users could choose to add Jurisdiction information to a Comment.|
|29||ValueSetDefinitionVersion.Trusted Value Set Expansion Source||valueset-trusted-expansion||This extension should only be used if the "authoritative source" (valueset-authoritativeSource extension) does not have a FHIR service which is capable of generating a valid FHIR expansion.||Add a tracker to add text to the valueset-authoritativeSource extension to state that the designated "authoritative source" is normally expected to be able to generate a valid expansion of the value set, and if for some reason it cannot then the valueset-trusted-expansion should be used.|
Change the valueset-trusted-expansion text to:
If the designated "authoritative source" (as specified in the valueset-authoritativeSource extension, if present) is unable to provide a valid expansion, this extension indicates an alternate authoritative source where the value set expansion may be obtained.
Note: this topic is related to the discussion in the August 29, 2019 vocab call.
authoritative source: #23784
trusted expansion: #23785
|31||ValueSetDefinitionVersion.Code System Source||valueset.compose.include.system||Datatype uri|
|33||ValueSetDefinitionVersion.Creation Date||ValueSet.date||gap?||There is no equivalent currently in FHIR (valueset-effectiveDate is not the same thing). It will be one of the .dates for the various resource "copies" stored.|
May 5, 2020
Propose extension on valueset.compose where
name = Valuse Set Definition Creation Date
URL = http://hl7.org/fhir/StructureDefinition/valueset-compose-creationdate
|34||ValueSetDefinitionVersion.CreatedBy||gap?||There is no equivalent currently in FHIR (valueset-author is not the same thing). At best this would require identifying a specific stored resource copy that is "the creation" version.|
May 5, 2020
Propose extension on valueset.compose where
name = Valuse Set Definition Created By
URL = http://hl7.org/fhir/StructureDefinition/valueset-compose-createdby
|35||Revision History||gap||This might be via linking in Provenance|
May 5, 2020
The expectation is that via the FHIR API (e.g., history interactions), Provenance resourec and/or the Audit Event, adequately provides the ability to caputre Revision History of the ValueSet resource. It is recognized that the intent within VSD is to capture revision of the Concept Logical Definition. As noted elsewwhere, FHIR does not separate the CLD from the expansion, and thus the history tracking capabilities will be at the resource level. This will be described in the VSDP IG
|36||ValueSetDefinitionVersion.Revision Date||gap||There is no equivalent currently in FHIR (meta is not sufficient).|
|37||ValueSetDefinitionVersion.Tracking Identifier||gap||There is no equivalent currently in FHIR.|
|38||ValueSetDefinitionVersion.Revised By||gap||There is no equivalent currently in FHIR.|
|39||ValueSetDefinitionVersion.Change Notes||gap||There is no equivalent currently in FHIR.|
|40||ValueSetDefinitionVersion.Revision History - derived||gap||There is no equivalent currently in FHIR.|
|41||ValueSetDefinitionVersion.Revision Version Identifier||gap||There is no equivalent currently in FHIR (meta is not sufficient).|
|42||Content Logical Definition - Definitional?||Ended here on 20180911. Note this is not an element but is a header.|
|43||LockedDate||Valueset.compose.lockedDate||the text in the FHIR defintion is an explanatory usage note, not a definition; must be fixed||new tracker item to update the FHIR definition of the element to match the VSD definition tracker FHIR-18702|
|44||ActiveOnly||compose.inactive||the semantic matches OK, but note that the flag states are reversed ie VSD.ActiveOnly=TRUE is the same as ValueSet.compose.inactive=FALSE.||No change needed|
NO CHANGE TO RESOURCE, HOWEVER SHOULD BE TAGGED FOR IMPLEMENTATION NOTES
(We are not sure if this is the correct syntax for this)
FHIR does not support multiple defining syntaxes in ValueSet.compose.
When Valueset.compose is not used, then when the expression is computable - has a syntax - that expression is found in valueset-expression which uses the datatype Expression. Within that datatype the element language would be used to represent the syntax.
The issue is that element is bound Extensable to ExpressionLanguage but limited to (i.e., max binding) to the document http://www.rfc-editor.org/bcp/bcp13.txt - which outlines how to request an addition to bcp13.
This restriction/expectation will be discussed at next SNOMED on FHIR Meeting.
May 5, 2020
Open tickets to
1) Validate maturity level
2) Suggest expansion of ExpressionLanguage value set to include commonly used expression languages known to Vocab and/or used by common terminology services (e.g., SNOMED ECL, OWL, SQL, DTS TQL...)
Robert Hausam to discuss on SNOMED on FHIR meeting on 5/5/2020
June 2nd, 2020
Within VSDP assign Max binding to valueset composed of bcp13 media type codesystem (https://www.iana.org/assignments/media-types/media-types.xhtml / https://terminology.hl7.org/CodeSystem-v3-mediatypes.html) plus those found (and added to in the future via UTG) in ExpressionLanguage Codesystem
1) Clarify the various code systems and value sets in FHIR for mime type and mediatype
2) Determine what identifier should be used for the external mediatype codesystem (i.e. urn:ietf:bcp:13 and/or http://terminology.hl7.org/CodeSystem/v3-mediatypes)
3) By definition, the additional expressions types are valid as long as it complies to the syntax defined BCP13. However, the community should be encouraged to register the additions with IANA.
4) Declare a code sytem fragment of the BCP13 code system of known media types (IANA + ExpressionLanguage + http://terminology.hl7.org/CodeSystem/v3-mediatypes + known expression languages (e.g., SNOMED ECL, OWL...)
5) Remove the existing code sytem http://hl7.org/fhir/codesystem-expression-language.html
6) Update the defintion of value set http://hl7.org/fhir/valueset-expression-language.html to be based on alll codes in BCP13 code system fragment (binding type change may need to be updated)
|47||Syntax-based Content Expressions||ValueSet.extension(http://hl7.org/fhir/StructureDefinition/valueset-expression).expression|
This uses the valueset-expression extension as noted above. When this extension is used and the syntax is intended to be computable, ValueSet.compose should NOT exist (although technically it is allowed.) Use the rules-text extension for a non-computable description.
The expression may be a reference or the actual expression, and is expected to be a computable format.
(note: Nov 21, 2019 WG conf call reviewed cpg-expressionvalueset)
|See row 45|
|48||Non-computable Content Expression||ValueSet.extension(http://hl7.org/fhir/StructureDefinition/valueset-rules-text)|
Use the rules-text extension for a non-computable description.
(note: Nov 21, 2019 WG conf call reviewed cpg-cachedvalueset - definition that act like expansion because of a HAPI and other basic terminology server limitation)
|49||Content Defining Element Types|
There are two instances of DrawnFromCodeSystem. This instance corresponds with 220.127.116.11 in VSD.
compose.include.system is equivalent to VSD DrawnFromCodeSystem. Only change is to review/remove the extension valueset-system.
Removing the the valueset-system extension to ValueSet.compose.include.system. This extension requires review, as it seems to be redundant and doesn't provide any additional semantics.
VSD separates out valueset and code based valuesets, the compose.include is equivalent as it can apply to both
|53||CodeBasedContent||compose.include||VSD separates out valueset and code based valuesets, the compose.include is equivalent as it can apply to both|
|54||ContentSystemElement.CodeBasedContent.code||compose.include.concept.code or compose.include.filter.value|
VSD defines the CodeBasedContent.code to be the code included on its own or it may define a header code. In FHIR, the former is equivalent to compose.include.concept.code and the latter is equivalent to compose.include.filter.value in combination of the compose.include.filter.op = is-a and compose.include.filter.property = concept
|55||ContentSystemElement.CodeBasedContent.IncludeRelatedCodes||compose.include.filter||This is the collection of lines 56-58|
|56||ContentSystemElement.CodeBasedContent.IncludeRelatedCodes.RelationshipName||compose.include.filter.property||Similar to the above description, for IncludeRelatedCodes, the FHIR equivalent is compose.include.filter where value = code, op is = and property = relationshipName|
The operation is equivalent to compose.include.filter.op. However it has a required binding to the FilterOperator value set. When compared, we have the following:
VSD TransitiveClosure = descendant-of
VSD DirectRelationsOnly = GAP
VSD TransitiveClosureLeaves = GAP
Also, it should be noted in the result VSD profile that the VSD considers the above an "exhaustive list for this item" and therefore the FilterOperator valueset will need to be constrained, assuming new values are added to cover the gaps above
|Yes||see item 58|
|58||ContentSystemElement.CodeBasedContent.IncludeRelatedCodes.IncludeHeadCode||if true: compose.include.filter.op = is-a|
As noted above, there is a gap in the FilterOperator valueset. There is not boolean operation in FHIR for inclusion or exclusion of head codes. When combined with above, we have the following:
VSD TransitiveClosure w/head code (FALSE) = descendant-of
VSD TransitiveClosure w/head code (TRUE) = is-a
VSD DirectRelationsOnly w/head code (FALSE) = GAP
VSD DirectRelationsOnly w/head code (TRUE) = GAP
VSD TransitiveClosureLeaves w/head code (FALSE) = GAP
VSD TransitiveClosureLeaves w/head code (TRUE) = GAP
|Yes||gForge ticket requesting additions to the FilterOperator valueset to cover the gaps noted. #23783|
|59||PropertyBasedContentSet||compose.include||This is the collection of lines 60-63|
|This is the group of possibly repeating elements, See lines 61-63|
In this group of elements, only this one (property.name) is required (if the group exists).
compose. include.filter.property = Name'
Per VSD, either Value or Expression must be present
If Value is provided and expression not:
If Expression is provided and Value is not
|62||ContentSystemElement.PropertyBasedContentSet.IncludeWithProperty.Value||compose.include.filter.op||see line 61|
|63||ContentSystemElement.PropertyBasedContentSet.IncludeWithProperty.Expression||compose.include.filter.value||see line 61|
|64||RelationshipBasedContent||This is the group of possibly repeating elements,|
Per VSD, either RelationshipType = string uniquely identifying the relationship being used to filter the content.
compose.include.filter.property = RelationshipType
The Data Type in VSD = STR while FHIR filter.property's Data Type = code. However code includes "a set of constrained strings", in which the relationship types are constrained by the code system.
Where FHIR filter.property.op is used, to determine absence or presence:
filter.property.op = '='
Further, where FHIR filter.property.value is used, to specify the presence or absence or of a specific target of the relationship:
filter.property.value = a code defined by the code system
For example, to find all concepts in Code System A with the SNOMED CT 'laterality' relationship to the SNOMED CT Concept 'Left', the following combination would be used:
filter.property.name = '272741003'
filter.property.op = '='
filter.property.value = '7771000'
For WGM - discuss use of Regex to fill this gap.
Decision 9/16/2019: add TRACKER extensions to cover minimum and maximum multiplicity
|Yes. FHIRPath? Issues w/An extension might be more straight forward to use rather than requiring implementers intepret regex|
IMPLEMENTATION NOTES and
|67||ContentSystemElement.RelationshipBasedContent.MaximumMultiplicity||See note above|
compose.include.filter.op = in
comma separated list - of concept identifiers (this should be clearly stated)
9/16/2019 Discussion: change value to a choice element to allow a value set uri? Cannot change the normative resource. Implementers cannot set value = value set uri as the value of "in" is documented as being a comma separated list. An extension isn't feasible as it would be a sibling of filter.
06/16/2020 IMPLEMENTATION NOTE: Group review has determined that implementers should be discouraged from using compose.include.filter to represent Target Concepts. Rather an syntax based expression (e.g., ECL, SQL, DTS TQL).
"VSD supports the idea of identifiying value set members based on a defined relationship pointing to a domain of concepts. This idea is not supported with the compose filter element. Instead, the use of a expression based syntax and tools that support a richer set of operations is recomended..."
|69||CodeFilterContent||This is the group of possibly repeating elements,|
9/16/2019 Discussed: value-set.expression extension. Rejected. This extension is at the resource level.
There is an available value set called "Expression Language".
We have the construct to represent what we need - through the value-set.expression extension. The extension provides an alternative to compose.
Implementation Note: Base functionality to evaluate expressions varies by Terminology Service and there are various types of regular expression
compose.include.filter.op = "property"
compose.include.filter.op = regex
compose.include.filter.value = "property value"
Tracker: Need to specify which flavor/type of Regex should be used in FHIR consistently
(See note below for 6/30/2020)
6/30/2020: discussed whether it is necessary to recommend a flavor, or document a default. What benefit would it serve when implementers have been managing this? There are many regex engines, they vary by programming language, platform. Decided to not enter a tracker item. Upon a quick review, they vary mostly on look ahead/behind capabilities and how recursion is managed.
Identified during 6/16/2020 meetintg.
Tracker: Change code system type on Expression Language. Currently it is "complete" and should be "fragment" (of urn:ietf:bcp:13 and/or http://terminology.hl7.org/CodeSystem/v3-mediatypes)
See above - supported in the value-set.expression extension.
TRACKER: change the language to allow one or the other, compose or value-set.expression extension. (see note dated 6/20/2020)
The JIRA entered for row 70 does not specifically address adding guidance for the value-set.expression extension that it should only be used when there is no compose.
Add a new tracker to address adding this guidance to the text for the extension.
|72||ValueSetReference||This is the group of possibly repeating elements,|
Attendees agree to this map.
|74||ContentSystemElement.ValueSetReference.Version||compose.include.valueSet||Because this is now a canonical data type, version is supported.|
Canonical data type supports expressing a version (separated with a vertical bar)
|75||ContentSystemElement.ValueSetReference.Name||ValueSet.title for the compose.include.valueSet|
Reminder to attendees: valueSet.title is the human readable "name", not "ValueSet.name"
Tracker: 4 options discussed
WINNER = 4
Question: is the goal of this project to create a profile that supports all of VSD? Yes.
|Yes - add text in the profile indicating how ValueSet.description should be used.|
Shifting gears to suggest
|76||CombinedContent||Quick review, group thinks the spirit of these CombinedContent items are captured through the compose.includes and compose.excludes when combined with $expansion operation||No|
See comment on line 76 AND
compose.include.valueset in FHIR states "If multiple value sets are specified this includes the union of the contents of all of the referenced value sets."
Per the definition of compose.include.valueset, multiple valuesets listed in an include.valueset reference results in a UNION of members. However, composition rules here, indicate that within compose.include, multiple criterion result in the intersection of the criterion...which appears to be contradictory. Thus, the group is unaware of how existing elements can be used to result in the intersection of two references value sets.
Update:10/27/19: Grahame has confirmed that the definition of compose.include.valueset appears to be erroneous, when it was moved under compose.include (previously it was under compose), the definition was supposed to be updated FROM:
"If multiple value sets are specified this includes the union of the contents of all of the referenced value sets."
"If multiple value sets are specified this includes the intersection of the contents of all of the referenced value sets."
Tracker should be opened to state the issue.
Grahame has indicated that there are two possible paths
1) Correct the error in R5
2) Update the valueset-filter-operator valueset (bound to compose.include.filter.op) to include an "in valueset" option.
General initial survey of implementers (Peter and Michael) is that #1 is optimal.
Additionally, looking at VSAC, who is using FHIR 3.0.1) to determine if correcting the include.valuset definition would have an impact, it appears that the Grouping valuesets (example of union) use multiple include statements for union (e.g. here), not multiple include..valueset instances to perform a union. Thus, would not be impacted by the proposed change.
As Valueset is normative, Vocab would need to query "all" implementers and get agreement that the definition was wrong to begin with and should be fixed.
If that were done, Grahame has indicated, as product manager, he would accept the requested change for inclusion into R5.
Tracker to be added: (CC) (minutes updated)
Once the ticket 25179 is fixed, both union and intersection will be documented and supported in the ValueSet resource.
|79||ContentSystemElement.CombinedContent.ExcludeContent||compose.exclude||See comment on line 76|
confirmed the VSD element is supported
|80||SOURCE CODE SYSTEM SPECIFICATION||Set of parameters that lay out a series of constraints relative to Code Systems|
|81||DrawnFromCodeSystem||This is the group of possibly repeating elements,|
|83||DrawnFromCodeSystem.VersionLockedDate||compose.include.version||VSD allows for the specification of versionlockeddate to a particular code system. FHIR only allows for compose.lockeddate to be set for the entire compose statement, i.e., FHIR allows you to specify compose.include.system and compose.include.version, it does not allow you to pass a date per code system||No tracker item needed, consider inclusion in future documentation regarding alignment of VSD with FHIR|
confirmed the VSD element is supported
|84||DrawnFromCodeSystem.VersionLockedString||compose.include.version||VSD allows for the specification of versionlockeddate to a particular code system. FHIR only allows for compose.lockeddate to be set for the entire compose statement, i.e., FHIR allows you to specify compose.include.system and compose.include.version, it does not allow you to pass a date per code system||No tracker item needed, consider inclusion in future documentation regarding alignment of VSD with FHIR|
confirmed the VSD element is supported
|85||DrawnFromCodeSystem.DescriptiveName||extension valueset-systemName||MS||present as an extension||No|
Define extension as must support
Discussed whether we should change the name of this extension to valueset-systemTitle. A code system might not have a Code System resource (therefore would not have a title element). OR - should we add text to the extension page to document that if a CodeSystem resource exists, the value in this extension would align with CodeSystem.title.
Enter Tracker to update the extension text.
|86||DrawnFromCodeSystem.UsedCodeSystemPartition||Not present, only extension available is valueset-supplement, which indicates when a expansion is dependent upon a supplement, no current way to indicate when a partition is required. Not deemed to require further action||No||IMPLEMENTATION NOTES|
|89||CodeSystemConstraintParameters.AllowedRepresentation||valueset.expansion.parameter.name||To do this, you would pass a name = AllowedRepresentation (or the codesystem defined name for the representation) for valueset.expansion.parameter.name then value = as defined by the codesystem, the representation you intend to retrieve||No|
|91||AllowedQualifiers||Does not appear possible to restrict qualifiers. Is that correct?||Yes|
enter tracker item to pose the question and confirm if there is a way to restrict qualifiers
OPEN ISSUE 3/10/2020 - not clear what to enter in the JIRA ticket
|97||CodeSystemPartitions and Supplements??|