Difference between revisions of "Implementation Guide"
Charliemccay (talk | contribs) |
|||
(9 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | A v3 [[Implementation Guide]] (created by HL7 or by any other organization) is a non-machine testable description of various artefacts (be they CDA documents or v3 messages), the description of which may extend well above the detail offered by machine processable definitions such as Templates or [[ | + | A v3 [[Implementation Guide]] (created by HL7 or by any other organization) is a non-machine testable description of various artefacts (be they FHIR artifacts, CDA documents or v3 messages), the description of which may extend well above the detail offered by machine processable definitions such as Templates or [[Conformance Profile|conformance profiles]]. |
− | + | The table of contents for a v3 messaging or CDA implementation guide should include: (based on best practices from CDC/NLM/IHE/v2/v3 implementation guides): | |
− | |||
− | The table of contents for a v3 messaging or CDA implementation guide should include: (based on best practices from CDC/NLM/IHE/v2 implementation guides): | ||
*background on why the specification exists and how it fits into business context | *background on why the specification exists and how it fits into business context | ||
+ | **exec summary, introduction (overview, purpose, audience, scope, assumptions, conventions) | ||
*background on reading HL7 specifications | *background on reading HL7 specifications | ||
− | *[[Storyboard]]s and "Transctions" ( | + | *[[Storyboard]]s and "Transctions" (biz level, comprised of multiple interactions; group dynamic interactions into transactions) |
**various [[Interaction]]s and [[Trigger Event]]s | **various [[Interaction]]s and [[Trigger Event]]s | ||
*static models & walkthroughs | *static models & walkthroughs | ||
+ | **properties of object/attributes: specify business names of objects/attributes, implementation notes | ||
**background on datatypes and vocabulary/vocabulary binding | **background on datatypes and vocabulary/vocabulary binding | ||
*"implementation considerations", both relating to code as well as relating to workflow, regulatory environment and other stakeholder considerations | *"implementation considerations", both relating to code as well as relating to workflow, regulatory environment and other stakeholder considerations | ||
Line 16: | Line 16: | ||
The "profile" portion of most implementation guides will probably be implemented using existing tooling to document static model and dynamic model constraints. | The "profile" portion of most implementation guides will probably be implemented using existing tooling to document static model and dynamic model constraints. | ||
− | Especially for HL7-authored implementation guides, but in principle also for others: Implementation guides may be [[MIF]]-driven and use the same publication process we use for balloting. | + | Especially for HL7-authored implementation guides, but in principle also for others: Implementation guides may be [[MIF]]-driven and use the same publication process we use for balloting. |
== Related == | == Related == | ||
− | A [[ | + | A [[Conformance Profile]] is a ''machine testable'' specification of all kinds of conformance issues related to '''one single message'''. |
+ | More guidance on what parts are or could be relevant in an implementation guide here: [[ImplementationGuide_Guidance]] | ||
==Examples== | ==Examples== | ||
− | + | Examples to [[Implementation Guides|Implemenation Guides]] are listed on a separate page. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Latest revision as of 11:14, 19 May 2016
A v3 Implementation Guide (created by HL7 or by any other organization) is a non-machine testable description of various artefacts (be they FHIR artifacts, CDA documents or v3 messages), the description of which may extend well above the detail offered by machine processable definitions such as Templates or conformance profiles.
The table of contents for a v3 messaging or CDA implementation guide should include: (based on best practices from CDC/NLM/IHE/v2/v3 implementation guides):
- background on why the specification exists and how it fits into business context
- exec summary, introduction (overview, purpose, audience, scope, assumptions, conventions)
- background on reading HL7 specifications
- Storyboards and "Transctions" (biz level, comprised of multiple interactions; group dynamic interactions into transactions)
- various Interactions and Trigger Events
- static models & walkthroughs
- properties of object/attributes: specify business names of objects/attributes, implementation notes
- background on datatypes and vocabulary/vocabulary binding
- "implementation considerations", both relating to code as well as relating to workflow, regulatory environment and other stakeholder considerations
- test scenarios
- Examples (and plenty of them - these tend to be crucial for implementers)
The "profile" portion of most implementation guides will probably be implemented using existing tooling to document static model and dynamic model constraints.
Especially for HL7-authored implementation guides, but in principle also for others: Implementation guides may be MIF-driven and use the same publication process we use for balloting.
Related
A Conformance Profile is a machine testable specification of all kinds of conformance issues related to one single message. More guidance on what parts are or could be relevant in an implementation guide here: ImplementationGuide_Guidance
Examples
Examples to Implemenation Guides are listed on a separate page.