1 / 13

Standards Analysis Summary

Standards Analysis Summary. vMR Pros Designed for computability Compact Wire Format Aligned with HeD Efforts Cons Limited Vendor Adoption thus far Represents an additional required format for EHRs. Standards Analysis Summary (cont.). CDA (C-CDA & QRDA) Pros

manjit
Télécharger la présentation

Standards Analysis Summary

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Standards Analysis Summary • vMR • Pros • Designed for computability • Compact Wire Format • Aligned with HeD Efforts • Cons • Limited Vendor Adoption thus far • Represents an additional required format for EHRs

  2. Standards Analysis Summary (cont.) • CDA (C-CDA & QRDA) • Pros • Well specified for various use cases • Established Vendor Basis • Aligned with MU • Cons • Difficult for computability • Expensive wire format

  3. Standards Analysis Conclusion • Conclusion • Not likely to be able to recommend a single format • Should provide a solution that allows flexibility in payload formats, but still enables interoperability

  4. Proposed IG Outline • DSS Profile for CDS Request • DSS Profile for CDS Response • Container Profile for CDS Request • Container Profile for CDS Response • Payload Format Guidance • Data Requirements • Interaction Types • Modular Transport Options

  5. DSS Profile • DSS Profile for CDS Request • DSS Profile for CDS Response For each, either a single, general profile or one profiled for each functional interaction type, if necessary

  6. Container Profile • CDSInput • vMR Container • Extended w/ additional context as specified in UC2 • Extended to allow multiple payload formats • CDSOutput • vMR Container • Extended to allow multiple payload formats For each, either a single, general profile or one profiled for each functional interaction type, if necessary

  7. Payload Formats • This section would describe supported payload formats (vMR, CDA, QRDA) • For each format, describe generally how each type of clinical concept would map into the target format • This effort would leverage the Value Sets & Terminologies work, basically defining how to express each clinical concept in the terminology space in each format

  8. Data Requirements • Mapping between clinical concepts, data requirements, payload standards, and vocabulary/terminology bindings for all 225 data requirements specified in Use Case 2 • This section would describe the formal mechanism for expressing data requirements for a particular exchange • Each exchange would be represented by a set of data requirements, where each data requirement includes: • Clinical Concept (Encounter, Problem, Procedure, etc.) • Value Set (A specific value set identifying codes) • Date Range (A date range, relative to the time of the request) • Number needed (e.g., collect X of most recent in timeframe)

  9. Interaction Types • A section for each functional interaction type, where each section includes: • Data Requirements, using the formal specification described above • Mapping for each of those requirements into a specific format for this functional interaction type. • This would involve selection of a specific C-CDA document type, QRDA CDA template, or vMR template, as well as potentially further constraints on those specifications as appropriate

  10. Interaction Types (cont.) • Proposal is to select the most broadly applicable functional interaction types, along with the most appropriate payload format for each type to use as examples, for example: • Disease Management – C-CDA, History & Physical • Quality Measurement – QRDA, specific template • Immunization – vMR, specific template

  11. Transport Format • Recommend DSS Release 1 • SOAP vs REST can be addressed as an additional profile for DSS • This effort may be part of DSS Release 2, or may be part of the HeD UC2 IG

  12. CDS Request Options for Functional Interaction Types Functional Interaction Type A: vMR Request Service: DSS Request Element Request Service: DSS Request Element Request Service: DSS Request Element Request Items Organizer/Container: vMR Request Items Organizer/Container: vMR Request Items Organizer/Container: vMR Request Item Payload: vMR Clinical Statement Request Item Payload: QRDA Request Item Payload: CCDA Functional Interaction Type B: QRDA Functional Interaction Type C: CCDA

  13. Overview of Process to Develop Specific Functional Interaction Type Guidance Determine Functional Interaction Type Determine Data Elements for Functional Interaction Type Select Standard (vMR,CCDA, QRDA) Begin Update/Constrain template Select template(s) by leveraging mapped data elements What is selected Standard? Include Mapped Data Elements into Selected Standard CCDA,QRDA vMR Select template(s) by leveraging mapped data elements Create vMR data profile by leveraging mapped data elements Document as Implementation Guide

More Related