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

Difference between revisions of "Conformance SIG"

From HL7Wiki
Jump to navigation Jump to search
Line 10: Line 10:
 
== Discussion ==
 
== Discussion ==
  
<h2>Mandatory</h2>
+
<h3>Mandatory vs. required vs. null-flavors</h3>
 
Another issue comes up with the definiton of what "mandatory" and "required" means. Mandatory means the a value must be present and a null-value is not allowed. Unfortunately, that is the same as what required means in v2. Due to the fact that we do have the same issues in v2 as well as in V3 we should find a way to use the same terminology.
 
Another issue comes up with the definiton of what "mandatory" and "required" means. Mandatory means the a value must be present and a null-value is not allowed. Unfortunately, that is the same as what required means in v2. Due to the fact that we do have the same issues in v2 as well as in V3 we should find a way to use the same terminology.
 
This becomes terribly strange if it is combined with other attributes like cardinality. Doesn't it sounds reasonable to talk about presence/required and null-flavour-types (allowed, emtpy, non-empty, no-nulls).
 
This becomes terribly strange if it is combined with other attributes like cardinality. Doesn't it sounds reasonable to talk about presence/required and null-flavour-types (allowed, emtpy, non-empty, no-nulls).
Line 19: Line 19:
  
  
<h2>publication of specifications</h2>
+
<h3>publication of specifications</h3>
 
In DICOM it is required to publish a conformance statement, i.e. is clear definition of what a system supports.
 
In DICOM it is required to publish a conformance statement, i.e. is clear definition of what a system supports.
 
In HL7 currently everyone can implement what (s)he wants without such a requirement.
 
In HL7 currently everyone can implement what (s)he wants without such a requirement.

Revision as of 11:28, 23 February 2006

The Conformance Special Interest Group is working on creating conformance criteria for HL7 2.x and V3.

Here we should add documentation and FAQs.

One of the key HL7 v3 conformance artefacts is the Application Role, a core element of a Conformance Claim.

During the Phoenix (January 2006) WGM the Conformance SIG (and MnM/INM) had a look at the proposed Feature Discovery Interactiona s described in the Ping and Feature Discovery proposal document. The Conformance SIG expressed it would be useful to have such an interaction, and approved a motion to work with INM to progress the proposal in San Antonio. It was however unclear if a new HL7 interaction should be developed, or whether we should re-use an existing industry standard.

Discussion

Mandatory vs. required vs. null-flavors

Another issue comes up with the definiton of what "mandatory" and "required" means. Mandatory means the a value must be present and a null-value is not allowed. Unfortunately, that is the same as what required means in v2. Due to the fact that we do have the same issues in v2 as well as in V3 we should find a way to use the same terminology. This becomes terribly strange if it is combined with other attributes like cardinality. Doesn't it sounds reasonable to talk about presence/required and null-flavour-types (allowed, emtpy, non-empty, no-nulls).

Here we have to distinguish an element's presence in an XML instance from the presence with a no-null-value. The latter is meant by mandatory.

This leads to something like a null-flavor-indicator in a conformance statement.


publication of specifications

In DICOM it is required to publish a conformance statement, i.e. is clear definition of what a system supports. In HL7 currently everyone can implement what (s)he wants without such a requirement.

This leads to two issues: a) whether the publication of a conformance statement/claim should be made required? b) how such a specification should be made available?