This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">
Requirements-Dynamic Model
From HL7Wiki
This page documents one or more V3 Methodology Requirements
Requirements
Requirement | Each trigger event must have a unique name |
Rationale | The trigger events must be able to be precisely referenced when creating interactions. The trigger event is the reason for communicating information. |
MIF |
|
Requirement | Trigger events may have annotations |
Rationale | Some HL7 artifacts and components convey explicit semantic meaning, for example classes, attributes, concept domains, coded concepts, etc. Other artifacts do not represent particular meaning but still require an explanation of that the artifact is and why it exists.
Lack of documentation on an artifact or component can lead to confusion about what the artifact or component is or what it's for. |
MIF |
|
Requirement | There are three types of triggering events
|
Rationale | The triggering event type describes the pattern that the interaction follows. |
MIF |
|
Requirement | EnvironmentalOccurrence may have associated text. |
Rationale | Describes the nature of the environmental occurrence (e.g. user action) |
MIF |
|
Requirement | Each interaction must have a unique name |
Rationale | The interactions must be able to be precisely referenced esp. as part of receiver responsibilities. |
MIF |
|
Requirement | Interactions may have annotations |
Rationale | Some HL7 artifacts and components convey explicit semantic meaning, for example classes, attributes, concept domains, coded concepts, etc. Other artifacts do not represent particular meaning but still require an explanation of that the artifact is and why it exists.
Lack of documentation on an artifact or component can lead to confusion about what the artifact or component is or what it's for. |
MIF |
|
Requirement | Each interaction must include one (reference to a) trigger event and static model. |
Rationale | The interactions must be able to be precisely referenced esp. as part of receiver responsibilities. |
MIF |
|
Requirement | Each interaction may include one or more receiver responsibilities |
Rationale | Frequently in response to an interaction, one or more 'response' interactions are triggered. There can be multiple responses. |
MIF |
|
Requirement | Each interaction may include one or more sending application and receiving application. |
Rationale | ?. |
MIF |
|
Requirement | Each application role must have a unique name |
Rationale | The sending and receiving application role must be able to be precisely referenced when creating interactions. |
MIF |
|
Requirement | Interactions have to be able to bind to a message model or a document as the payload. |
Rationale | There are two 'types' of static model content at HL7. RMIMs which represent workflow-type communications and Documents which represent point-in-time information. |
MIF |
|
Requirement | For each interaction, trigger event, document, and application role, annotations must be supported: |
Rationale | Annotations assist with usability. |
MIF |
|
Requirement | For each query interaction, an additional binding to the parameter list is required. Note this includes query requests as well as query responses. |
Rationale | The parameter list is required for both requests and responses. |
MIF |
|
Future Requirements (not complete)
Note that HL7 is currently re-developing and replacing the current dynamic model methodolgy. Below are SOME of the requirements. Requirements are still being determined and documented as part of the HL7 Enterprise Architecture Framework Alpha implementation projects.
Future Requirement | Communicate conformance of receiver responsibilities. It is necessary to know which receiver responsibilities must happen (mandatory), should happen (required), may happen (optional), and must not happen (usually based on a previous elaboration of a receiver responsibility). |
Rationale | It is necessary to know which receiver responsibilities must happen (mandatory), should happen (required), may happen (optional), and must not happen (usually based on a previous elaboration of a receiver responsibility). |
MIF |
|