Templates DSTU 1 Comments

Related Links Templates Home Page

Templates DSTU Release 1 Comments

Back to Templates WG langing page

Invitation to submit DSTU 1 comments

Invitation to submit DSTU 1 comments

During the time the HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 is a DSTU you are invited to submit your comments here. Alternatively ou may submit comments on the Templates DSTU Release 1 here: http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=132. The comments discussed on this page in the wiki will be moved to the DSTU comment page at a later point in time.

Please submit a new section at the end of this page and do not forget to sign it by adding your name and date, preferably by adding the macro ~~~~ at the end of your edit.

Add a new comment section

Templates life-cycle state terms

The Trifolia team would like to submit a DSTU Comment against the Templates DSTU ...

Here’s the issue:

We have found inconsistency in two of the “life-cycle” state terms. The Templates DSTU used the terms "Retired" and "Terminated" in a way that is inconsistent with the way the HL7 Harmonization Process uses these words. Also, HL7 Harmonization uses "Deprecated" and "Retired". Trifolia uses the terms "Deprecated" and “Retired”. However, we don’t think that everyone is using the term “Retired” to mean the same thing. Also, the ActStatus code system needs to be reviewed to see where these "states" are actually defined within HL7.

All this needs to get further clarified, and then the DSTU should be updated to reflect the agreed “common” view/usage.

Sarah will confirm the definitions as they are being used in Trifolia.

If you add this topic to a discussion item at a Templates Meeting and let this group know when that discussion could take place, we will send representatives to help work through this. We think Vocab (due to Harmonization Process overlap) and M&M should also be included in the analysis/discussion. The material in question can be found in chapter 2.9.6 in the Templates DSTU. -- Lisa Nelson (talk) 07:47, 21 October 2014 (UTC)

The state terms are drawn from the Document HL7 Templates Business Process Requirements Analysis, previously balloted successfully by the Templates WG in 2012. In Chapter 6.3 TEMPLATE METADATA INFORMATION LIFECYCLE MANAGEMENT you'll find the state terms and their descriptions. -- Kai (talk) 08:00, 21 October 2014 (UTC)

This topic will be discussed during the Templates Work Group Conference Call on 11-Nov-2014, 1pm Eastern -- Kai (talk) 18:14, 4 November 2014 (UTC)

Templates Work Group Conference Call on 11-Nov-2014, 1pm Eastern : Sean McIlvenna stated that the analysts at Lanatana said: deprecated is handled as "this template should no longer be in use (contemplating)", while retired means it shall no longer be in use.

Lisa explained it using the Problem Status Template that was in existence in C-CDA r1 and was used by Problem Observation template v1. Going to C-CDA r2 Problem Status in Problem Observation v2 is still used but it is set to Lantana's vision of deprecated to indicate that you should not used any more (while usage would still be valid) it and may go away some day. Such a template may then set to Lantana's vision of retired some day which in essence means that it is no longer published (and used of course).

Kai explained that this is a publication issue rather that a status issue. Templates that are referenced somewhere need to be published anyway, regardless of their state. Precursors of the Templates DSTU had the status inactive but this was erased as we found no real use case for it. Furthermore the terms deprecated and retired are very close from a language perspective. FHIR profile status uses the term retired with the description: ...has been withdrawn or superceded and should no longer be used.

Chris mentioned that in software development the transition phase is sometimes referred to as "twilight"

Decision: to add a sentence to the explanation of retired in the DSTU on page 19: "... previously recorded using this design. It may be included in current designs to enable smooth transitions and to indicated that it may go aways in the future."

Decision: Change retire transition label in status diagram on page 20, i.e. the arrow ---> retired from "retire" to "retire/deprecate"

Lisa re-stated that a governance group may have a 2nd version of a template with a retired template in it (and with a conformance MAY) to allow smooth transitions and later to have a 3rd version of the template that completely leaves out the formerly mentioned retired template.

Kai (talk) 19:20, 11 November 2014 (UTC)

The new diagram will look like this: Kai (talk) 14:57, 27 January 2015 (UTC)

Cardinality constraint

Original Ballot Reconciliation Item#70 Templates Sec 2.10.3

Original text: choice to be one out of n (cardinality constraint).

Ballot comment Frank Oemig 2014-01: this is not a cardinality constraint. It would be good to see an example where n out of m choice elements are selected! This is just for choices if I have to repeat an element n times and to present n different selections.

Templates Work Group comment 2014-09-19: Why not? It says something about the mulitplicity of the choice set members. What would be the correct term? Will add more examples.

Frank's comment 2014-10-15: Constraining choices has two aspects: a) constraining the selectable branches and b) the cardinality. You start with b) and uses an exmple for a).

Optional conformance

Original Ballot Reconciliation Item#103 Templates sec 7.4.1.5

Original text: O - optional

Ballot comment Frank Oemig 2014-01: what about optional?

Templates Work Group comment 2014-09-19: In this specification "optional" is derived (minimumMultiplicity = 0 and no other conformance specified). Do you think one need to be able to explicitly specify this redundantly?

Frank's comment 2014-10-15: it is not the same: "R"is SHOULD while "O" is "MAY". So: yes.

Better example for choices

Original Ballot Reconciliation Item#108 Templates sec 7.4.12

Ballot comment Frank Oemig 2014-01: we should have an example here…

Templates Work Group comment 2014-09-19: There is one example for choice! What else do you wish to see?

Frank's comment 2014-10-15: it refers to my other comment about choices. A better example would be to use the clinical statement pattern. You may constrain the number to say it must contain 2..* items (cardinality) out of reduced set (observation, procedure, substanceAdmin).

Will consider an example from Clinical Statement as well for choices. Kai (talk) 18:08, 4 November 2014 (UTC)

Constraints

Original Ballot Reconciliation Item#109 Templates sec 7.4.13

Original text: .. Transparent to the user

Ballot comment Frank Oemig 2014-01: It must be visible whether a constraint is inherited or new!

Templates Work Group comment 2014-09-19: What do you mean by this choice "inherited" or "new"? You simple include the constraints specified in the mentioned template, that theoretically can be in any status. This is about inclusion and we will add another example on how inclusion actually works plus a statement that cardinalities in include statements overrides the cards of the root element(s) of the included template. We will also add that the change of cardinalities may not violate any formal restrictive conformance rules.

Frank's comment 2014-10-15: it sohuld be made visible whether within this specification an attribute has more constraints than in the underlying one.

Example of Trifolia

Original Ballot Reconciliation Item#112 Templates sec 7.5.3

Ballot comment Frank Oemig 2014-01: where is an example of Trifolia?

Templates Work Group comment 2014-09-19: The examples later are the MS-Word output from Trifolia. We will add additional screenshots of Trifolia for your convenience

Frank's comment 2014-10-15: Section 11.1 now reflects the experience CGIT has made with SDWG. They stopped their cooperation after discussiing our comments on their approach.

Add constraint section

The DSTU still missing a paragraph about the constraint element. Add something similar as the following text:

An optional and repeatable free text, natural language and non computable description of constraints applicable in this context. May contain markup and supports the @language attribute. Occurs max once only per language.

You MAY also convey the same constraints in the <desc> element but separating them out into constraints allows different rendering in your publications making the constraints stand out more than they would in <desc>.

<constraint language="en-US">If the attribute qualifier is used for this element it should be derived from epSOSEntityNamePartQualifier 2.16.840.1.113883.5.43</constraint>
<constraint language="en-US">The &lt;functionCode&gt; element is mandatory when this participant is the preferred HP</constraint>
<constraint language="nl-NL">Het element &lt;functionCode&gt; is mandatory wanneer deze participant de geprefereerde zorgaanbieder/zorgverlener is</constraint>

Kai (talk) 18:28, 22 January 2015 (UTC)

Add attribute/@id similar to element/@id

In section 7.4.1.7. an element/@id is described as an optional attribute that allows the element to be uniquely identified. Add the same mechanism for attributes.

Kai (talk) 18:31, 22 January 2015 (UTC)

Add coding strength CNE/CWE

Add coding strength as a property of an codeable element.

CNE: This equals a SHALL vocab binding, e.g. the code must come from the value set bound, otherwise an error is emitted on validation. CNE shall be the default.

CWE: This equals a binding with a SHOULD and means that a warning is emitted on validation if a code is not drawn from the value set bound to that element. A coding strength of CWE is loosening the binding: if a concept is not available in the value set the concept could also be expressed by a code from another code system.

Kai (talk) 04:47, 25 March 2015 (EDT)

Status change and Template Versions

Q: Which changes in the status of a template version (either in design or implementation) require a new version to be created. There are several examples of this in our DSTU, but no clear rules.

A: No status change *requires* a new version in principle. A governance group may decide to create a new (initially identical) version once a template version became for example deprecated/retired or terminated.

Simultaneus Template Versions

Q: How many versions of a given template may be 'in use' at a given time,

A: First: What is ‘in use’?

There may be any number of template versions in the same status, e.g. Active.

A governance group may decide to have only one active template version in place at a time.

Note: Considered to put into best practices section in the new normative document.

Active Period

Q: Which of the metadata 'date/time values' (e.g. the effectiveDate or the officialReleaseDate or the expirationDate) refer to the start and end of a template versions 'active' time (the time in which it may be 'in use').

A: as a recap from the DSTU:

• effectiveDate = start of existence of the template version
• expirationDate = end of any useful use of the template version, typically co-incides with a status change to deprecated/retired
• officialReleaseDate = the first date/time when the template version is officially released (regardless of status)

What is the reason to know the start and end date of a template in status active? One could use officialReleaseDate for that if status is active at or after that date. In a proper repository the status change history and periods can be determined based on the historical records of the template version.

Note: Considered to put into best practices section in the new normative document.

URL for Value Set Versioning

Q: What is a definite URL reference to vocabulary value set versioning (which would also be helpful to implementers).

A note: Value Set versioning is out-of-scope for Templates.

A: Distinguish between Design Principles and Binding Mechanics.

The Design Principles a different for Value Set Versions. The Binding Mechanics are the same as for templates.

Note: Considered to put into best practices section in the new normative document.