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

Difference between revisions of "Conformance Profile"

From HL7Wiki
Jump to navigation Jump to search
 
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
The conformance committee defines two types of profiles:
+
Definition: A '''conformance profile''' is a ''machine testable'' specification of all kinds of conformance issues related to '''one single interaction'''. This profile is also known (in v2) as a '''Message Profile'''. The purpose of a conformance profile is twofold:  
- static profiles which describe *exactly* what data can be sent/received
+
#To specify the requirements for a v3 artefact (e.g. as part of an [[Implementation Guide]] created by HL7, an HL7 country organization, or IHE)
for a particular interaction. These will be based on the standard "static
+
#To identify how one particular software application has implemented the artefact (as part of a [[Conformance Statement]])
model" MIF structure, possibly extended to capture a couple of additional
 
pieces of data, such as ITS support, realm support, etc.  One of the things
 
a static model indicates is what templates apply at a particular node in the
 
model.
 
  
- dynamic profiles which describe a set of expected behavior across a set of
+
 
interactions.  This is where we get into behavioral aspects, and there will
+
The conformance profile (as defined by the [[Implementation and Conformance|ICTC Workgroup]]) contains two parts:
certainly be extensions here to indicate such content as expected response
+
*'''static profile''': describes *exactly* what data can be sent/received for a particular interaction.  These will be based on the standard "static model" [[MIF]] structure, possibly extended to capture a couple of additional pieces of data, such as ITS support, realm support, etc.  One of the things a static model indicates is what templates apply at a particular node in the model. It all describes the background on datatypes and vocabulary, in as far as this isn't determined by [[Realm|binding realm]] or [[template]].
times.
+
*'''dynamic profile''': describes a set of expected behavior across a set of interactions.  This is where we get into behavioral aspects, and there will certainly be extensions here to indicate such content as expected response times.
 +
 
 +
Note on tooling:
 +
*In v2 the MWB can be used to specify conformance profiles.
 +
*In v3 the MIF is ready to support both profile types (with the exception of the [[Constraint Language]] portion, which isn't really a MIF issue). What we're lacking (as of October 2006) is a full set of tooling to support MIF maintenance.
 +
 
 +
== Related ==
 +
*An [[Conformance Statement]] (or: conformance claim) is a statement by a software vendor how a specific (set of) application(s) supports the conformance requirements of both the standard (as a whole) as well as those mentioned in a (set of) Conformance Profile(s).
 +
*An [[Implementation Guide]] is a non-machine testable description of various messages, the description of which may extend well above the detail offered by message profiles. It contains the background on why the specification exists and how the messages (mostly it describes more than 1 message) fit within the business context.

Latest revision as of 12:34, 3 November 2008

Definition: A conformance profile is a machine testable specification of all kinds of conformance issues related to one single interaction. This profile is also known (in v2) as a Message Profile. The purpose of a conformance profile is twofold:

  1. To specify the requirements for a v3 artefact (e.g. as part of an Implementation Guide created by HL7, an HL7 country organization, or IHE)
  2. To identify how one particular software application has implemented the artefact (as part of a Conformance Statement)


The conformance profile (as defined by the ICTC Workgroup) contains two parts:

  • static profile: describes *exactly* what data can be sent/received for a particular interaction. These will be based on the standard "static model" MIF structure, possibly extended to capture a couple of additional pieces of data, such as ITS support, realm support, etc. One of the things a static model indicates is what templates apply at a particular node in the model. It all describes the background on datatypes and vocabulary, in as far as this isn't determined by binding realm or template.
  • dynamic profile: describes a set of expected behavior across a set of interactions. This is where we get into behavioral aspects, and there will certainly be extensions here to indicate such content as expected response times.

Note on tooling:

  • In v2 the MWB can be used to specify conformance profiles.
  • In v3 the MIF is ready to support both profile types (with the exception of the Constraint Language portion, which isn't really a MIF issue). What we're lacking (as of October 2006) is a full set of tooling to support MIF maintenance.

Related

  • An Conformance Statement (or: conformance claim) is a statement by a software vendor how a specific (set of) application(s) supports the conformance requirements of both the standard (as a whole) as well as those mentioned in a (set of) Conformance Profile(s).
  • An Implementation Guide is a non-machine testable description of various messages, the description of which may extend well above the detail offered by message profiles. It contains the background on why the specification exists and how the messages (mostly it describes more than 1 message) fit within the business context.