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

Difference between revisions of "Implementation Guide"

From HL7Wiki
Jump to navigation Jump to search
 
(13 intermediate revisions by 5 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 [[Message Profile|message profiles]].  
+
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 implementation committee aims to finalize the description of an implementation guide by May 2007, styleguide, and requirements for tooling in this area. We'll need to distinguish between v3, CDA and other 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/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" (business rules)
+
*[[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. However, at this point in time (October 2006) the tooling to support this is still a way off. 
+
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 [[Message Profile]] is a ''machine testable'' specification of all kinds of conformance issues related to '''one single message'''.
+
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==
Links to example implementation guides:
+
Examples to [[Implementation Guides|Implemenation Guides]] are listed on a separate page.
*[http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Suppl_PIX_PDQ_HL7v3_TI_2006_11_06.pdf IHE ITI MPI]. IHE profile for v3 messages.
 
*[http://www.ihe.net/Technical_Framework/upload/LabTFVol1_v1_1_jul08_FT.pdf IHE Lab profile, volume 1], [http://www.ihe.net/Technical_Framework/upload/LabTFVol2_v1_2_feb27_FT.pdf IHE Lab profile, volume 2]. Typical IHE v2 message based profile.
 
 
 
==Discussion==
 
*(Virginia) I like the definition on the wiki.  Its important to me that Implementation Guides have a standard format if possible and best practices.  I have seen so many V2 specs with different look and feel and often missing important explanations.  Each one leaves out something and often not the same thing.  I think message profiles will take care of alot of that (for example, MWB for V2 prompts users to fill in information.  But it would be nice if the entire publication related to implementation had standards applied to it.
 
*(Virginia) Are we considering how IHE does implementation guides?
 
*(Patrick Lloyd, 20061107 Implementation TelCon) Use the NLM content description as a guideline/checklist. GordonPoint Informatics creating impl guides.  Similar to HL7 ballot infrastructure. Based on extsion on R-MIM designer, to capture additional information, used to generate HTML files. Spreadsheet which takes over some of the function of the biz level transaction, multiple interactions, presented in document. MS Word driven, set of macro. Link in Exec summary, links to external documents e.g. external vocab document. Mostly HL7 driven, driven from HL7 models. RMIM documentation inherited (for consistency) from D-MIM documentation, hard to do though. NLM has a February deadline for its implementation guide project.
 
**NLM Implementation Guide Tool. exec summary, introduction (overview, purpose, audience, scope, assumptions, conventions), biz models, transactions (biz level, comprised of multiple interactions), message models.
 
**RMIM designer: properties of object/attributes: enter business names, implementation notes, etc. Used by harvester and pulls it into generated HTML by implementation guide tool.
 
**Dynamic spreadsheet: ability to group dynamic interactions into transactions, to illustrate what you're doing in your use-case. Pubs DB not usable here, use spreadsheet to captute information which is needed in implementation guide. Linking of transactions and interactions.
 
**Macro's in background which produce HTML shown at beginning of demo.
 

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)
  • 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.