IG+Policy+Variance+Analysis

Refer to the LRI Consensus and Strategy page for consensus.

What are the policy differences we need to address?
 * Problem Statement**:

Section 2.2 of the document as described ||  || needed for the use case, left rest of the standard for "regular/optional" use || constrained vocubalary specific for providers || up-to-date) ||  || OIDs || provided more options to allow organizations to either use or not use strong identification to allow for adoption || More granular desired. || More flexibility on identifiers (OIDs not necessary but allowed) Less granular uniqueness allowed || Use of required (R) where the use case required it || More use of required (R) fields || SNOMED-CT for results / specimens, UCUM for units of measure || LOINC for common lab codes, HL7 codes for units of measure ||
 * **Criteria of Variance** || **Interoperable Laboratory Result Reporting To EHR (US Realm) R1** || **Ambulatory Care Lab Result (ELINCS) R1** ||
 * Meaningful Use Requirement || No || No ||
 * EHR Certification Requirement || No || No ||
 * State/Local Requirement || No || No ||
 * Policy Drivers || Driven by AHIC Use Case || Driven by implementation needs (CHCF to clarify) ||
 * || escape sequences variances (clarify)
 * Policy Drivers || Driven by AHIC Use Case || Driven by implementation needs (CHCF to clarify) ||
 * || escape sequences variances (clarify)
 * || did not try to exclude "stuff" outside the use case - constrained what was
 * || synced vocabulary with general HITSP choices (but guide was not fully kept
 * || early adoption of post-V2.5.1 data types ||  ||
 * || use of strong identifiers (following HITSP guides) with assigning authorities
 * Use Case || Driven by AHIC Use Case || Driven by implementation needs (CHCF to clarify) ||
 * Privacy ||  ||   ||
 * Security ||  ||   ||
 * Use of Identifiers || Greater use of strong identifiers
 * Vocabulary Constraints || Use of optionality to allow for flexibility
 * Vocabulary Usage || LOINC for common lab codes,


 * The initial discussion of the variances above lead to the following initial policy considerations (subject to further debate)

Use of components not in scope of the Ambulatory Use Cases yet present in the underlying standard:
 * Should be clear what is necessary for the use case at hand (e.g., annotation, grey out, new conformance code, etc.)
 * Need clear indication whether the receiver should be able to support the component or not
 * Other components should remain available, but without receiver responsibilities to support (will use "Indifferent" for now as mark / grey)
 * provides opportunity for growth/consistency with other care settings not in scope
 * need usage notes over time to clarify potential use beyond ambulatory (to be discussed what this means)
 * Use X only to denote components not to be used if not to be used in any lab results setting. It should therefore be used very cautiously

Use of post-V2.5.1 data types:
 * No blanket pre-adoption of all post-V2.5.1 data types
 * For each data type, determine which newer version can be adopted across the board, or case-by-case, or not at all
 * Clear indication of which data type components are to be used
 * If defined at the data type level, applies to all uses
 * If defined at the field level, applies to that field only
 * Need clear documentation to avoid confusion

Use of truncation:
 * Do not truncate

Review Public Health IG policies to further inform the following policy considerations
 * HL7 2.5.1 Appendix C - Sender and Receiver rules
 * For now, only ambulatory sender and receiver columns would need to be completed, as outlined in this appendix.
 * Sender profile needs to be outlined - objective is to remove inconsistencies
 * Group Consensus -
 * Basic principles covered by prior bullets (Use of components not in scope of Ambulatory)
 * Will address specific highlighting as part of Ambulatory detailed component review

Use of identifiers
 * Challenges with uniqueness of
 * Placer Order Number -
 * Filler Order Number -
 * Universal Service Identifier
 * Placer Group Number
 * Three choices:
 * Non-Unique Order Number and Universal Service Identifier are necessary to uniquely identify a individual test being ordered, and the Universal Service Identifier
 * Unique Order Number alone is sufficient to uniquely identify an individual test being ordered, while the Universal Service Identifier only comes across to indicate the test
 * Transition to Unique Order Numbers at a later stage (pinned to meaningful use stage)
 * Stage 2 - allow both
 * Identify profile and which one you are compliant to
 * Stage 3
 * Under either option the Placer Group Number can be used for Requisition Number that covers multiple tests being ordered
 * Consider to require all fields to be present and over time to then shift focus (Kate Hamilton's suggestion)
 * Group Consensus - TBD
 * Patient Identifier - No concern
 * Result Identification
 * Order in paper mode:
 * The order is communicated on paper from the requester to the lab.
 * Placer Order Number is not unique
 * Filler Order Number would be assigned by Filler. Not necessarily unique. Receiving EHR needs to know whether the filler order number is unique.
 * Document in the IG that the uniqueness needs to be decided upon implementation so it is clear what the sending system is sending for all test results.
 * Orders in electronic mode:
 * Requester is either unique or not unique.
 * Non-unique receiver continues to use both and can echo.

Use of escape sequences
 * Be specific as with HITSP or be more open as per ELINCS? - (Cited specifically in HITSP in Section 2.2)
 * Group Consensus
 * Include HITSP guide language to start and everybody can suggest potential strengthening statements.
 * Agreed to HITSP.
 * Maintain in one document
 * Mark as conformance requirement

Conformance constraints concept need to be well-defined in the implementation guide
 * To be deferred to the CIM/Vocab SWG
 * Rob Snelick - ensure these conformance constraints are well defined in the IG - include in appendix
 * Group Consensus - No objections
 * Need to define shall, should, etc. A minimum statement that has key "shalls".
 * Suggestion to align with CDA Consolidation for shall, may, should
 * Suggestion to align with proposed HL7 V2 Chapter 2 on Required, RE, etc.
 * Rob, Kate to pull proposal together May 10. Freida to forward what she has ||  ||