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

Difference between revisions of "Template Functional Requirements"

From HL7Wiki
Jump to navigation Jump to search
Line 44: Line 44:
  
 
=== Description Metadata – Optional ===
 
=== Description Metadata – Optional ===
==== '''''implimentationFormat''''' ==== The preferred format that the Template should be implimented in.  Implimentation formats other than that specified (if any) are not deemed suitable for this Template by the '''''publishingAuthority'''''.
+
==== '''''implementationFormat''''' ==== The preferred format that the Template should be implimented in.  Implementation formats other than that specified (if any) are not deemed suitable for this Template by the '''''publishingAuthority'''''.
 
 
  
 
=== Publication Metadata – Required ===
 
=== Publication Metadata – Required ===

Revision as of 11:42, 19 October 2005

HL7 V3 Templates maintain a set of functional requirements. What is the list of functional requirements required of Templates for use in HL7?


HL7 Template Metadata

Identification Metadata - Required

templateID

A globally unique, non-semantic, identifier for the Template. Within the context of HL7, a templateID should take the form of an ISO Object Identifier (OID) or an HL7 Artifact ID. This is the primary identifier for all Templates.

templateName

A free text natural language name identifying the Template. It is anticipated that there will be far too many templates to be able to assign a unique mnemonic or meaningful name to all of them. This is the secondary identifier for all Templates. (Refer to templateCodedTerm.)

originatingAuthorEntityID

A globally unique non-semantic identifier for the original author of the Template.

templateIntention

A free text natural language description of the intent and scope of the Template. The purpose is to provide the author’s initial intent for the Template.

templateVersion

The version identifier for the Template. The ability to determine the correct version of a Template is essential to its identification.

==== templateReferenceModelID ==== The globally unique identifier (ISO OID or HL7 Artifact ID) of the reference model against which the Template was developed. The underlying reference model may be A DIM, LIM, or Profile or Template.

==== templateRepositoryIdentifier ==== The identifier of the repository where the Template is located. This is a required metadata item since the core functional purpose of a Template is reuse, and things in general are much harder to reuse when they cannot be easily located.

Open Issue: What form should this identifier take?

==== templateRegistrationAuthority ==== The identifier of the registration authority (organization, institution, committee, or individual ) for the Template.

Open Issues: What are registration rules? What is the relationship between the repository and registration? What is the purpose of regsistration?

Identification Metadata - Optional

==== templateCodedTerm ==== The coded concept that uniquely represents the templateName within a given code system. A concept code can be assigned to an entire Template, providing it with a language independent method of secondary indentification. This can be used in conjunction with the templateName to convey the intended purpose and use of the template. (Refer to templateName.) The same templateCodedTerm and templateName may be used in multiple Templates.



Description Metadata – Required

==== descriptionLanguage ==== The natural language in which the Template is represented.

==== templateDescription ==== A free text natural language description of the intent and scope of the Template. The purpose is to provide the author’s initial intent for the Template.


Description Metadata – Optional

==== implementationFormat ==== The preferred format that the Template should be implimented in. Implementation formats other than that specified (if any) are not deemed suitable for this Template by the publishingAuthority.

Publication Metadata – Required

==== publicationStatus ==== The current publication status for the template.

==== publicationDate ==== The date that the current value for publicationStatus was applied of the Template.

==== publisher ==== The name of the author(s) institutional affiliations and contact infomation for the creators of the Template.

==== publishingAuthority ==== The autoritative body who has reviewed the Template for clinical accuracy and relevance, and autorized it for publication.

==== revisionHistory ==== The free text description describing the changes in this version of the Template as compared to the previous version. Since Template versions are built off of previous versions, the net effect of this field is to function as a comprehensive historical reference of the Template.


Publication Metadata – Optional

==== effectiveDate ==== The date after which the Template can be considered for use. Use of the Template prior to this date would be considered an invalid use of the Template.

==== expirationDate ==== The date at which the clincal concept represented by this Template becomes stale, and should be reviewed for clinical relevance and accuracy. Use of the Template after this date would be considered venturesome.


Template Assertions

Static assertions


  • A template can constrain the cardinality of a clone’s association.
  • A template can constrain the cardinality of a clone’s attribute.
  • A template can constrain the allowable date/time values in a date/time field.
  • A template can constrain any attribute value to be a subset of those values legally permissible in the specification being constrained.
  • A template can constrain the range of allowable date/time values for attributes valued by date/time data types.
  • A template can constrain the range of allowable code values for attributes valued by terminology concepts.
  • A template can constrain the range of allowable numbers for attributes valued by numbers.
  • A template can express a regular expression constraint on attributes valued by strings.
  • A template can constrain any data type component, including recursively-nested components.
  • A template can constrain the range of allowable values of a clone’s attribute.
  • All additional constraints that can be expressed in a normative specification (including all the columns in an HMD) can be further constrained in a template.

Co-occurrence Assertions


  • The value of one field can be constrained based on the value of another field.
    Example: If fieldOne is “X”, then fieldTwo’s value must be “A”.

  • Chronological assertions can constrain the date/time value of one field based on the date/time of another field.
    Example: The start time for fieldOne is (earlier | later | equal to) the start time of fieldTwo.

  • Numeric comparison assertions can constrain the numeric value of one field based on the value of another field.
    Example: The value of fieldOne is (equal to | less than | greater than) the value of fieldTwo.

  • Numeric operation assertions can constrain the numeric value of one field based on a numeric operator applied to the value of another field or constant.
    Example: The value of fieldOne is (equal to | less than | greater than) the value of fieldTwo (plus 7 | divided by 27).

  • String comparison assertions can constrain the string value of one field based on the value of another field.
    Example: The string value of fieldOne is contained in the value of fieldTwo.

  • Any constraint a template and constituent archetypes can make can be made dependent on the value expressed in one or more other fields. For instance, in addition to constraining the cardinality of an association, a template and constituent archetypes can constrain the cardinality based on the value in a particular field.
    Example: If ((fieldOne is “X” or “Y”) OR (fieldTwo is “ABC”)) then ((a nested act relationship under Observation is required) AND (fieldThree in the nested act has a value of “A” or “B” or “C”) AND (fieldThree in the nested act cannot be NULL)).


Containment Assertions


  • Data descendant assertions can constrain allowable depth at which one component is nested within another component.
    Example: The vital-signs section must be (a direct child of | some descendant of | less than a depth of X from) the physical-exam section.

  • Items in a template and constituent archetypes can be “ordered” or “unordered”. In an ordered template and archetype, the order of the stated assertions is important. In an unordered template and archetype, the order is not important.
    Example: Assertion One: There is a nested act under observationOne that has an observation.cd for “hemoglobin”. Assertion Two: There is a nested act under observationOne that has an observation.cd for “hematocrit. If the template and constituent archetypes are “ordered”, the “hemoglobin” must come before the “hematocrit”. If the template and constituent archetypes is “unordered” the “hemoglobin” can come before or after the “hematocrit”.


Logic Assertions


  • Logical operators can be applied to a set of assertions to indicate which assertions in the set must be true or false. Example: (All | at least X | at most X | exactly X) of the assertions contained in this set must be (true | false).