Health eDecisions (HeD) All Hands Meeting May 16th, 2013

Health eDecisions (HeD)All Hands Meeting

May 16th, 2013

Meeting Etiquette• Remember: If you are not speaking, please keep your

phone on mute• Do not put your phone on hold. If you need to take a call,

hang up and dial in again when finished with your other call • Hold = Elevator Music = frustrated speakers and

participants• This meeting is being recorded

• Another reason to keep your phone on mute when not speaking

• Use the “Chat” feature for questions, comments and items you would like the moderator or other participants to know.• Send comments to All Panelists so they can be

addressed publically in the chat, or discussed in the meeting (as appropriate).

From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute

All Panelists

Agenda

Topic Time Allotted

Announcements 5 minutes

Work Stream 1 Update: HL7 Meeting Update

5 minutes

Work Stream 2 Update: Pilots 5 minutes

vMR Overview – Dave Shields, Claude Nanjo

45 minutes

C-CDA Overview - Calvin Beebe 45 minutes

Wrap up/Questions 5 minutes

Announcements• Vocabulary and Terminologies sub work will be meeting this

week Friday 12:30-1:30 EDT

– http://wiki.siframework.org/Health+eDecisions+Homepage

• Updates from the HL7 Meeting

– vMR updates

• We are starting the preparation process for balloting UC 2 through HL7 in September

– Stay tuned for updates and ways to participate

– We are submitting the Project Scope Statement (PSS) this week for Use Case 2 (due May 17th)

• AMIA????

http://wiki.siframework.org/Health+eDecisions+Homepage


HL7 Update • We have completed a rough draft of the Implementation Guide

– http://wiki.siframework.org/HeD+Pilot+Tools • The Vocabulary and Terminology IG is also complete and will be

incorporated into our IG.– To view and comment on the work of the Vocab and Terminology

team please see the pilots tool page: http://wiki.siframework.org/HeD+Pilot+Tools

• We met this week and approved the pending issues as discovered during the Pilot process with CDC: – Next week: we will determine after HL7 meeting if we need to meet

next week• http://wiki.siframework.org/Health+eDecisions+Homepage )

• We are beginning the process of preparing UC 2 for HL7 balloting – We will resume these meetings in the near future for UC 2

disscussions

http://wiki.siframework.org/HeD+Pilot+Tools







HeD Pilots Update

• We met this week• Pilots Update

– CDC and Practice Fusion –ECA Rule• Aziz is working on the transformation from HQMF to HeD (90% complete)

– There will be 2 rules – one of the Laboratory and one for the clinic

– NewMentor and AllScripts – ECA Rule (98% complete)• The team has transformed the NQF 0068 (Million Hearts) into HeD and then into

the Allscripts native format (CREF)• The initial pass was completed and we have successfully loaded the rule into the

AllScripts test environment– Still need tweaks

– Zynx and DesignClinicals - Order Set (60% complete)• Working on simple and complex order sets

– VA and Wolters Kluwer - Documentation Template (75% complete)• UTI Documentation Template was transformed into HeD schema• Wolters Kluwer is checking the rule to ensure it captures what is needed• Ken, Robert Lario and Dave Sheilds are working with the VA to prepare for the

final rule to be implemented into their system.

HeD Pilots Goal Goal

The goal of this initiative is to produce, consume and where feasible, execute implementable CDS interventions.1. Event Condition Action Rules (ECA Rules)2. Order Sets3. Documentation Templates

Pilot Scope4. Health eDecisions will apply defined aspects of the Implementation Guide

in a real-world setting.5. Modify the Implementation Guide to ensure it is usable 6. Submission of explicit feedback to sub workgroups such as vMR and

Vocabulary and Terminology work group to close gaps7. The real-world pilots evaluate not only the technology, standards and

model (VMR), but also provide a test bed to evaluate the interaction of technology, implementation support, and operational infrastructure required to meet Health eDecisions use case 1 objectives at the stakeholder or organization levels.

8. Demonstrate intent of artifact (specifically structures and semantics) are communicated either by direct execution or by translation to native format

9. Ensure completeness and consumability of artifact

New

8

Timeline

10/11/2011

We are Here

Goal & Activities EST. Time

Dates Deliverables

Kickoff /Establish Goals & Partnerships: - Review HeD Initiative Goals - Review Piloting Process & Resources - Define Value Statement - Define HeD Pilot Goals & Success Metrics - Establish & Approve Pilots - Develop Pilot Briefs

4 wks.(reality 5 weeks)

1/07-2/25 (we missed 2 meetings in January pushing our Dates back)

-Wiki Capturing Pilot Deliverables-Established Partnerships-Documented Value Statements and Success Metrics-Documented Pilot Briefs

Pilot Configuration: - Establish Pilot Test Environment & Resources - Establish Pilot Implementation & Testing Process - Develop & Review Pilot Configuration

2 wks.(reality- 4

weeks)

2/25-3/25

-Use Case is Updated with HL7 Comments (3/4)-Approved Pilot Briefs -Committed Pilot Resources-Documented & Reviewed Pilot Configuration Guide-Weekly Feedback on Use-Cases & IG Alignment

Pilot Development : - Setup & Develop Pilot Prototypes - Review prototypes

6 wks. or less

depending on Pilot activity

3/25 – 5/6

-Use Case is Updated with HL7 Comments (3/4)-Weekly Pilot Development Status Updates-Weekly Feedback on Use-Cases & IG Alignment-Updates to Pilot Configuration Guides

Pilot Testing & Showcase : - Complete Testing - Prepare Solution Showcase

2wks 5/6 -5/20 -Weekly Pilot Testing Updates & KPIs-Showcase-Prepare for HL7

Pilot Wrap-up : - Develop Lessons Learned an ONC Feedback - Review Initiative Goal Alignment - Establish Next-Steps

2 wks. 5/20 – 6/3 -Documented ONC Feedback- Next Steps Action Plan

Vendor Partners

10/11/2011 9

EHR Area of Interest Potential or Actual Match

Design Clinicals Order Sets Zynx

AllScripts ECA Rules –NQMF Rule (for Ambulatory Setting) – Million Hearts

NewMentor (have catalog for rules in ambulatory setting)

Practice Fusion/ AllScripts

Anything MU centered

CDC (also may need Artifact supplier to help) Wolters Kluwer NewMentor (MU rule as example)

VA Documentation Template

Wolters Kluwer

vMR Overview

Presented by Claude Nanjo and Dave Shields

Overview of C-CDA

Health eDecisions All Hands Community Meeting

May 16, 2013

C. Beebe

Presenter

Calvin E. [email protected] SpecialistMayo Clinic, Rochester MN

Co-editor - CDA R1, CDA R2 Author - CDA Certification Exam

Co-chair - HL7 Structured Documents Member - HL7 Technical Steering

Committee Treasure - HL7 Board of Directors

Today’s Topics

– What’s in the C-CDA Implementation Guide – Review sample C-CDA document– Identify HL7 & other useful resources– Summary

01/01/2011 14

Basic C-CDA 101

Technical Name:

HL7 Implementation Guides for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1 - US Realm

Called: Consolidated CDA, C-CDA …

– The C-CDA contains a library of CDA templates.– Updates 11 CDA document types, including CCD– Harmonizes previous HL7, IHE, HITSP efforts

It consolidated previous document templates into a single library, resolving conflicts, ambiguities as needed!

HL7’s CDA vs. C-CDA

• CDAThe HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange.

• C-CDAThe HL7 Consolidated CDA is an implementation guide which specifies a library of templates and proscribes their use for a set of specific document types.

defines a set of CDA documents!

the schema for those documents!

Consolidated CDA (C-CDA)

C-CDA

History and Physical Discharge Summary Consultation Notes Diagnostic Imaging Rpt Procedure Note Operative Note Progress Note Unstructured Documents HL7 Health Story Implementation Guides

CCD

ONC - CEHRTHITSP - C32, C80, C83 IHE – PCCHL7 – CCDHL7 – CDA

Continuity of Care Document

Consolidated CDA

• The guide contains a library of CDA templates, incorporating and harmonizing previous efforts from:

• Health Level Seven (HL7)• Integrating the Healthcare Enterprise (IHE) • Health Information Technology Standards Panel (HITSP)

It includes harmonized HL7 Health Story guides, HITSP C32, related components of IHE Patient Care Coordination, and the Continuity of Care (CCD). It includes all required CDA templates in Final Rules for Stage 1 Meaningful Use and can support Stage 2 Meaningful Use requirements.*

Templated CDA: C-CDA, QRDA

01/01/2011 19

Figure 1: Templated CDA

A QRDA Category I report is an individual-patient-level quality report. Each report contains quality data for one patient for one or more quality measures.

(126 Entry Templates)

HL7 C-CDA Implementation Guide

• Document Organization– Introduction– General Header Template– Document-Level Templates– Section-Level Templates– Entry-Level Templates– Appendix

• Template IDs, Code Systems, Value Sets, Extensions, …

ConsolidatedCDA Documents

H&PH&P Diagnostic Imaging

Diagnostic Imaging ConsultConsult Surgical

OperationSurgical

Operation

ProgressProgress ProcedureProcedure Discharge Summary

Discharge Summary

Unstructured(Non-XML Body)

Unstructured(Non-XML Body)

CCDCCD9 Document Types

74 C-CDA SectionsAdvance Directives Section (entries optional)Advance Directives Section (entries required)Allergies Section (entries optional)Allergies Section (entries required)Anesthesia SectionAssessment and Plan SectionAssessment SectionChief Complaint and Reason for Visit SectionChief Complaint SectionComplications SectionDICOM Object Catalog Section - DCM 121181Discharge Diet SectionEncounters Section (entries optional)Encounters Section (entries required)Family History SectionFetus Subject ContextFindings Section (DIR)Functional Status SectionGeneral Status SectionHistory of Past Illness SectionHistory of Present Illness SectionHospital Admission Diagnosis SectionHospital Admission Medications Section (entries optional)Hospital Consultations SectionHospital Course SectionHospital Discharge Diagnosis SectionHospital Discharge Instructions SectionHospital Discharge Medications Section (entries optional)Hospital Discharge Medications Section (entries required)Hospital Discharge Physical SectionHospital Discharge Studies Summary SectionImmunizations Section (entries optional)Immunizations Section (entries required)Implants SectionInstructions SectionInterventions SectionMedical (General) History Section

Medical Equipment SectionMedications Administered SectionMedications Section (entries optional)Medications Section (entries required)Objective SectionObserver ContextOperative Note Fluids SectionOperative Note Surgical Procedure SectionPayers SectionPhysical Exam SectionPlan of Care SectionPlanned Procedure SectionPostoperative Diagnosis SectionPostprocedure Diagnosis SectionPreoperative Diagnosis SectionProblem Section (entries optional)Problem Section (entries required)Procedure Description SectionProcedure Disposition SectionProcedure Estimated Blood Loss SectionProcedure Findings SectionProcedure Implants SectionProcedure Indications SectionProcedure Specimens Taken SectionProcedures Section (entries optional)Procedures Section (entries required)Reason for Referral SectionReason for Visit SectionResults Section (entries optional)Results Section (entries required)Review of Systems SectionSocial History SectionSubjective SectionSurgery Description SectionSurgical Drains SectionVital Signs Section (entries optional)Vital Signs Section (entries required)

By

the

num

bers

65 C-CDA EntriesAdmission MedicationAdvance Directive ObservationAge ObservationAllergy ObservationAllergy Problem ActAllergy Status ObservationBoundary ObservationCode ObservationsComment ActivityCoverage ActivityDischarge MedicationDrug VehicleEncounter ActivitiesEstimated Date of DeliveryFamily History Death ObservationFamily History ObservationFamily History OrganizerHealth Status ObservationHospital Admission DiagnosisHospital Discharge DiagnosisImmunization ActivityImmunization Medication InformationImmunization Refusal ReasonIndicationInstructionsMedication ActivityMedication DispenseMedication InformationMedication Supply OrderMedication Use - None Known (deprecated)Non-Medicinal Supply ActivityPlan of Care Activity ActPlan of Care Activity Encounter

Plan of Care Activity ObservationPlan of Care Activity ProcedurePlan of Care Activity Substance AdministrationPlan of Care Activity SupplyPolicy ActivityPostprocedure DiagnosisPrecondition for Substance AdministrationPregnancy ObservationPreoperative DiagnosisProblem Concern Act (Condition)Problem ObservationProblem StatusProcedure Activity ActProcedure Activity ObservationProcedure Activity ProcedureProcedure ContextProduct InstancePurpose of Reference ObservationQuantity Measurement ObservationReaction ObservationReferenced Frames ObservationResult ObservationResult OrganizerSeries ActService Delivery LocationSeverity ObservationSocial History ObservationSop Instance ObservationStudy ActText ObservationVital Sign ObservationVital Signs Organizer B

y th

e nu

mbe

rs

38 C-CDA Code SystemsISO 3166-1 Country Codes DCMInternet Society LanguageVaccines administered (CVX)Adminstrative GenderActMoodReligious AffiliationRoleClassRoleCodeAddressUseActStatusMaritalStatusLOINCNUCC Health Care Provider TaxonomyICD9 CM ProceduresCPT-4Confidentiality CodeNational Cancer Institute (NCI) Thesaurus US Postal Codes

Race and Ethnicity - CDC HealthcareServiceLocationActCodeEntityNamePartQualifierEntityNameUseASC X12LanguageAbilityMode LanguageAbilityProficiencyNDF-RTActPriorityUnique Ingredient Identifier (UNII)ActReasonObservationInterpretationParticipationFunctionParticipationsignatureUnified Code for Units of Measure (UCUM) RXNormFIPS 5-2 (State)SNOMED CT

By

the

num

bers

S&I Companion Guide references (links) on CEHRT Vocabularies: CDT – Dental Codes ICD – 10 CM / PCS CPT – AMA Procedure Codes ISO 639-2 Language Codes HCPCS – Procedure Codes LOINC – Lab Codes CVX – HL7 table 0292 OMB Race / Ethnicity Codes RxNorm – Medication Codes SNOMED CT – via UMLS

C-CDA Header Constraints

• It describes constraints that apply to the header for all documents within the scope of this implementation guide. – Header constraints specific to each document type are described in the

appropriate document-specific section below.

• SHALL contain:– realmCode– typeId– templateId– id– code– title– effectiveTime– confidentialityCode – languageCode

recordTargetw/ 1 patient

name in US realm format administrativeGenderCode birthtime (precise to the year)

serviceEvent effectiveTime performer

author custodian

ethnicity preferred Language race

encompassing Encounter healthcareFacility responsibleParty encounterParticipant

addr name

MU 2 - Document Types

• With respect to the Consolidated CDA, certification will not focus on a specific document-level template…

Surprise!

Rather, certification will focus on an EHR technology’s ability to properly implement the US Realm header and the associated section-level templates necessary to support each certification criterion in which the Consolidated CDA is referenced and for the appropriate data specified in each of those certification criteria.

Where vocabularies are specified in § 170.207 the accompanying section-template must be implemented using structured data , i.e. coded entries required.

Unstructured Document template is not permitted.

Document Types

• S&I performed a goodness of fitness assessment and deemed the C-CDA CCD best fit.

01/01/2011 27

However…MU3 advocates that the visit document should not simply be EMR extracts (need exact language!)

You may want to start thinking about generating clinical notes based on C-CDA MU2 requirements.

I.e. H&P Notes, Consult Notes, Diagnostic Imaging Notes, Surgical Notes, Progress Notes, Discharge Summary Notes.

All said, for MU2 – the CCD seems like the likely target.



Consolidated CDA SectionsMU2 Data Requirements Consolidated CDA Section CCD

Advance Directives (entries optional) OMedication allergies Allergies (entries required) R

Encounters (entries optional) OFamily History O

Functional Status; Cognitive Status Functional Status ODischarge instructions (Inpatient setting) Hospital Discharge InstructionsImmunizations Immunizations (entries optional) O

Clinical instructions; Recommended patient decision aids Instructions

Medical Equipment OMedications Medications (entries required) R

Payers O

Care plan, including goals and instructions; Future appointments; Future scheduled tests; Referrals to other providers; Diagnostic tests pending

Plan of Care or Assessment and Plan O

Problems Problem (entries required) RProcedures Procedures (entries required) OReason for Referral Reason for ReferralReason(s) for visit or Reason(s) for hospitalization (Inpatient setting)

Reason for Visit or Chief Complaint or Chief Complaint and Reason for Visit

Laboratory Tests; Values/results of laboratory tests Results (entries required) RSmoking status Social History OVital signs Vital Signs (entries optional) O

We’ll take peek a the Problem section

Problem Section & Entries

This section lists and describes all relevant clinical problems at the time the document is generated. At a minimum, all pertinent current and historical problems should be listed.

Problem Section & Entries

Problem Section with Coded Entries Required

• Two types of Problem sections are supported, MU2 requires the use of coded entries.

Problem Section example

Problem Act Concern

Problem Act Concern

Problem Act Concern

Problem Act Concern

Problem Concern Act example

Problem Observation

Problem Observation

Problem Observation

Problem Observation

Problem Observation

Problem observation example

at the C-CDA sample

We will look at the sample

C-CDA

01/01/2011 46

Validation of C-CDA documents

• Two alternative techniques have been established to validate C-CDA documents.

• MDHT – JAVA validation code solution – Available on the Open Health Tools Web Site

• Trifolia – Schematron (xPath) solution– Available on the HL7 Web Site

Tools & Pending NIST testing

• The National Institute of Standards and Technology (NIST) provides a list of available validation tooling sites for interoperability specifications. NIST also provides tools for testing MU2 implementations.

• Validation: http://xreg2.nist.gov/hit-testing/

• Testing: http://healthcare.nist.gov/use_testing/tools.html

http://xreg2.nist.gov/hit-testing/

http://healthcare.nist.gov/use_testing/tools.html

Technique 1 - Schematron

.xml

CDA IG

CCD

.xsd

XPath validation of Implementation Guide requirements

Validates against generic CDA schema

<Section code=Plan>

.xPath, .xsl,SchematronTrifolia

Workbench

Technique 2 – MDHT Validation

Domain Model

MDHTModelDriven HealthTools

Add Custom Validations & Constraints

Java API(Source Code)

Validation CodeGeneration

Implementation Guide(s)

The JAVA code canparse, validate and provides an code able object model !

Identify useful resources

• ToC Quickstart: http://wiki.siframework.org/Transitions+of+Care+Quickstart+Page

• CDA R2 Product Brief: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7

• Consolidated CDA Product Brief: http://www.hl7.org/implement/standards/ product_brief.cfm?product_id=258

• HL7 FAQs: http://www.hl7.org/about/FAQs/index.cfm

http://wiki.siframework.org/Transitions+of+Care+Quickstart+Page

http://wiki.siframework.org/Transitions+of+Care+Quickstart+Page

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7

http://www.hl7.org/implement/standards/%20product_brief.cfm?product_id=258

http://www.hl7.org/implement/standards/%20product_brief.cfm?product_id=258

http://www.hl7.org/about/FAQs/index.cfm

Additional Tutorials

Available at HL7

Or consider a future HL7 Ed Summit or On-site Training.

Contact Mary Ann ([email protected]) to learn more about on-site training or to schedule on-site training for your organization.

mailto:[email protected]

For More Information….

• Contact us!– [email protected]

• HL7 C-CCD Implementation Guide– HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1 - US Realm

• S&I Framework – C-CDA Companion Guide– http://wiki.siframework.org/Companion+Guide+to+Consolidated+CDA+for+MU2

• Open Health CDA Tools: http://cdatools.org/

• MDHT: https://www.projects.openhealthtools.org/sf/projects/mdht/ – Validation: http://xreg2.nist.gov/hit-testing/– Testing: http://healthcare.nist.gov/use_testing/tools.html

• Trifolia Workbench: http://www.lantanagroup.com/resources/products/– Validation & CDA XSL Stylesheets: http://www.lantanagroup.com/resources/free-tools/


http://www.hl7.org/dstucomments/showdetail.cfm?dstuid=69

http://wiki.siframework.org/Companion+Guide+to+Consolidated+CDA+for+MU2

http://cdatools.org/

https://www.projects.openhealthtools.org/sf/projects/mdht/

http://xreg2.nist.gov/hit-testing/

http://healthcare.nist.gov/use_testing/tools.html

http://www.lantanagroup.com/resources/products/

http://www.lantanagroup.com/resources/free-tools/

Q & A Session

01/01/2011 54

Use Case 2

Update HeD UC2 Harmonization Progress & Decisions

Accomplishments to Date Completed HITSC Evaluation of Standards Evaluated Standards against the requirement of UC2 utilizing

the UCR Crosswalk Currently evaluating Implementation options and gaps in

standards Drafted relevant HL7 Project Scope Statements for anticipated

work products to be balloted

Next Steps Select Standards and determine Final Implementation approach Begin Implementation Guide development Submit

56

Update on Progress & Decisions:Viable Implementation Options

57

Implementation Option Transaction Service Organizer/

Container Payload Transport Notes/Rationale

3 II01 - Request DSS CCDA CCDA SOAP 1. Further discussion needed on utilization of vMR vs. CCDA and

SOAP vs. REST

4 II01 - Request DSS CCDA CCDA REST

1. Further discussion needed on utilization of vMR vs. CCDA and SOAP vs. REST

2. There is currently implementation guidance on DSS to be used with SOAP, not REST

5 II01 - Request DSS VMR VMR SOAP 1. Further discussion needed on utilization of vMR vs. CCDA and

SOAP vs. REST

6 II01 - Request DSS VMR VMR REST

1. Further discussion needed on utilization of vMR vs. CCDA and SOAP vs. REST


9 II02 - Response DSS HeD UC1

IG VMR SOAP 1. Consistent with UC1

10 II02 - Response DSS HeD UC1

IG VMR REST

1. Consistent with UC1


Update on Progress & Decisions:Non Viable Implementation Options

For the request transaction, vMR or CCDA should be used for both the Organizer/Container and Payload, instead of a combination of both. They are not meant to be separated in this manner. All implementation options that combined vMR and CCDA were eliminated

CCDA is not a commonly used standard for the response transaction, therefore any implementation option that had CCDA as the Item Payload standard was eliminated

Adoptability of HL7 Version 3 Order Set Standard for the response transaction was decided to be low, therefore any implementation option that had HL7 Version 3 Order Set Item Payload standard was eliminated

58

Update on Progress & Decisions:vMR Questions/Gaps

• VMR is a domain model and not an implementation model. We need to make sure the richness is not lost when it is translated into a message format. Who's going to propose an implementation or is that up to one of us.

• How well can VMR model a regimen as an addition to the record – capturing Temporal relationships, Conditional relationships,

• How well can a VMR model the alteration of a ACT, an ActAct Relation, or even part of a Regimen

• Can the VMR model the response from an Inference engine that uses the argumentation approach rather than just the simple if () then style of a rules engine.

Recommended First choice.... Do this

(pros and cons)

Recommended Second choice ... Do that

(pros and cons)

Etc. 59

Appendix

60

Use Case 2 – CDS Guidance Service Transactions

CDS Guidance Requestor

2. CDS Response(Clinical Data, Supporting Evidence, Supporting

Reference, Actions, Attribute-Value List, Response Metadata & Exceptions)

CDS Guidance Supplier

1. CDS Request (Clinical Data & Context)

INSERT SELECTED STANDARDS HERE

INSERT SELECTED STANDARDS HERE

Use Case 2: CDS Guidance Service Transactions - Standards per Transaction

# Transaction Service Organizer/Container Item PayloadsReference

Information Model

1CDS Request (patient data

and potentially context)

• Decision Support Service (DSS)

• Context Aware Retrieval Application (Infobutton)

• CDS Knowledge Artifact Implementation Guide (HeD UC1 IG)

• Consolidated CDA• Virtual Medical Record

(vMR)


• Virtual Medical Record (vMR)• Consolidated CDA (hL7 Clinical

Statements)• HL7 Version 3 Standard: Order Set

Publication, Release 1

• Federal Health Information Model (FHIM)

• HL7 v2.x• HL7 v3

2 CDS Response (guidance

and/or other response elements)

• Decision Support Service (DSS)


• CDS Knowledge Artifact Implementation Guide (HeD UC1 IG)

• HL7 Version 3 Standard: Order Set Publication, Release 1

• Consolidated CDA• Virtual Medical Record

(vMR)


• Virtual Medical Record (vMR)• Consolidated CDA (HL7 Clinical

Statements)• HL7 Version 3 Standard: Order Set

Publication, Release 1

• Federal Health Information Model (FHIM)

• HL7 v2.x • HL7 v3

Use Case 2: CDS Guidance Service Transactions - Standards per Transaction

# Transaction Transport Authentication/Authorization Encryption Vocab & Code Set

1CDS Request (patient data

and potentially context)

• SOAP• REST

• SAML • TLS • LOINC• SNOMED CT• CVX• Manufacturers of Vaccines (MVX)• OID• RxNorm• ICD-9-CM and ICD-10-CM• HCPCS• C80 - Clinical Document and

Message Terminology Component • NQF Value Sets

• ICD-10-PCS• UCUM• CPT• C154• NDC• FDA Route Administration• HL7 Vocabulary• Diagnostic and Statistical Manual

of Mental Disorders, Fourth Edition (DSM-IV)

2 CDS Response (guidance

and/or other response elements)

• SOAP • REST

• SAML • TLS • LOINC• SNOMED CT• CVX• Manufacturers of Vaccines (MVX)• OID• RxNorm• ICD-9-CM and ICD-10-CM• HCPCS• C80 - Clinical Document and

Message Terminology Component • NQF Value Sets

• ICD-10-PCS• UCUM• CPT• C154• NDC• FDA Route Administration• HL7 Vocabulary• Diagnostic and Statistical Manual

of Mental Disorders, Fourth Edition (DSM-IV)

CDS Guidance Request Transaction: Service Standards Rationale

StandardSummary of

Findings from UCR Crosswalk

Keep? Rationale

Decision Support Service (DSS)HITSC Rating:*M: 78.69A: 88.6SI: 33.33T: 72.71

(Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions

(P) Partially Fits: Response Metadata;

(N) Does not Fit:

Yes • One significant gap is DSS will tie to SOAP. There is significant industry movement towards REST.

• DSS has 2 levels, one is model of the service which is implementation agnostic. Could support standard with implementation based on REST, but it would have to be developed.

• DSS is designed to be able to support patient data, unlike Infobutton.

• Has broader scope than Infobutton•

* M: Maturity A: Adoptability SI: S&I Specific T: Total

Context Aware Retrieval Application (Infobutton)

HITSC Rating*M: 90.08A: 92.11SI: 47.62T: 82.07

(Y) Fits: Context; Supporting Evidence; Supporting Resource

(P) Partially Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response

(N) Does not Fit: Clinical; Actions; Attribute Value List; Response Meta Data

No

• Can send some patient data, but not designed to support rich patient data payload like DSS

CDS Guidance Response Transaction: Service Standards Rationale

StandardSummary of


Keep? Rationale

Decision Support Service (DSS)HITSC Rating:*M: 78.69A: 88.6SI: 33.33T: 72.71


(P) Partially Fits: Response Metadata;

(N) Does not Fit:

Yes • One significant gap is DSS will tie to SOAP. There is significant industry movement towards REST.

• DSS has 2 levels, one is model of the service which is implementation agnostic. Could support standard with implementation based on REST, but it would have to be developed.

• DSS is designed to be able to support patient data, unlike Infobutton.

• Has broader scope than Infobutton



HITSC Rating:*M: 90.08A: 92.11SI: 47.62T: 82.07




No

• Can send some patient data, but no designed to support rich patient data payload like DSS

CDS Guidance Request Transaction: Organizer/Container Rationale

StandardSummary of


Keep? Rationale

CDS Knowledge Artifact Implementation Guide (HeD UC1 IG)HITSC Rating:*M: 61.39A: 86.84SI: 35.71T: 64.62

(Y) Fits: (Sender) CDS Response; (Receiver) CDS Response; Clinical; Supporting Evidence; Supporting Resource; Actions; Attribute Value List;

(P) Partially Fits: Context; Response Metadata

(N) Does not Fit: Exceptions

No • UC1 is not designed to carry patient data

• If CCDA is chosen, would probably have to use related HL7 Clinical statements for the Item Payload bucket.

• If vMR is chosen, would probably have to use the vMR Clinical Statements for the Item Payload bucket

• External options may exist for transforming CCDA request into a vMR component

• Develop options for both CCDA and vMR


Consolidated CDAHITSC Rating:*M: 53.59A: 80.70SI: 33.33T: 58.48

(Y) Fits: Clinical;

(P) Partially Fits:

(N) Does not Fit: Context, Supporting Evidence; Supporting Resource; Actions; Attribute Value List; Response Metadata; Exceptions

Yes • Can transform CCDA request into a vMR component from the execution system

• Not everything from CCDA goes easily into vMR, but vMR is designed to easily accept CCDA components

CDS Guidance Request Transaction: Organizer/Container Rationale (continued…)

StandardSummary of


Keep? Rationale

Virtual Medical Record (vMR)HITSC Rating:*M: 78.06A: 81.58SI: 33.33T: 70.08

(Y) Fits: Clinical; Attribute Value List

(P) Partially Fits: CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Context; Supporting Evidence; Supporting Resource; Actions;

(N) Does not Fit: Response Metadata; Exceptions

Yes • Lighter weight than the other options• Developed specifically for clinical decision

support computability• Intended to be used for this initiative, and

has recently been enhanced in this respect


CDS Guidance Response Transaction: Organizer/Container Rationale

StandardSummary of


Keep? Rationale

CDS Knowledge Artifact Implementation Guide (HeD UC1 IG)HITSC Rating:*M: 61.39A: 86.84SI: 35.71T: 64.62

(Y) Fits: (Sender) CDS Response; (Receiver) CDS Response; Clinical; Supporting Evidence; Supporting Resource; Actions; Attribute Value List;

(P) Partially Fits: Context; Response Metadata

(N) Does not Fit: Exceptions

Yes • Fits Clinical; Supporting Evidence; Supporting Resource; Actions data requirements

• Attribute value list is not supported in UC1 schema, however the schema does allow extensions using XSD

• Would use subset of HeD UC1 schema that may require further modifications



(Y) Fits: Clinical;

(P) Partially Fits:


Probably No

• There is a profile in IHE that uses DSS and returns IHE as an output. But hasn’t been finalized within IHE

• Lacks the ability to group and organize things the way that UC1 does

• Do not anticipate using, unless modification or subset of UC1 approach does not work

CDS Guidance Response Transaction: Organizer/Container Rationale (continued…)

StandardSummary of


Keep? Rationale





No(Probably)

• Does fit this situation, however CDS Knowledge artifact may be the better option

• UC1 action would need to be modified to represent payload for UC2 regarding vMR

• May need a model agnostic response • Do not anticipate using, unless

modification or subset of UC1 approach does not work


HL7 Version 3 Standard: Order Set Publication, Release 1HITSC Rating:*M: 46.20A: 75.44SI: 33.33T: 53.31

(Y) Fits: Supporting Evidence; Supporting Resource; Response Metadata

(P) Partially Fits: Clinical; Context; Actions

(N) Does not Fit: Attribute Value List; Exceptions

No(Probably)

• Some vendors may want to support this as an option, however CDS Knowledge Artifact is the better option

• Adoption of this standard is low, so there is not a driving reason to extend support to it

CDS Guidance Request Transaction: Item Payloads Rationale

StandardSummary of


Keep? Rationale

Context Aware Retrieval Application (Infobutton)HITSC RatingM: 90.08A: 92.11SI: 47.62T: 82.07




No • The information that is contained in infobutton is already represented in vMR, or if not can be

• Can use infobutton as a reference to modify vMR or CCDA






Yes • The vMR has relevant information in a reasonable format

• The contents and scope of the vMR are aligned with the requirements of the Use Case

• Maintained by CDS WG• As a reference model, part of its purpose

is to provide exchangeable representation clinical information

CDS Guidance Request Transaction: Item Payloads Rationale (Continued…)

Standard Summary of Findings from UCR Crosswalk Keep? Rationale


(Y) Fits: Clinical;

(P) Partially Fits:


Yes • Several stake holders have a business need to have this supported

• A methodology is needed to be able to reflect changes, which currently does not exist






No • Order Set does not hold patient data, not suitable for request transaction

CDS Guidance Response Transaction: Item Payloads Rationale

StandardSummary of


Keep? Rationale






No • The information that is contained in infobutton is already represented in vMR, or if not can be

• Can use infobutton as a reference to modify vMR or CCDA






Yes • The vMR has relevant information in a reasonable format

• The contents and scope of the vMR are aligned with the requirements of the Use Case

• Maintained by CDS WG• As a reference model, part of its purpose

is to provide exchangeable representation clinical information

CDS Guidance Response Transaction: Item Payloads Rationale (Continued…)

StandardSummary of


Keep? Rationale

Consolidated CDA


(Y) Fits: Clinical;

(P) Partially Fits:


No • Several stake holders have a business need to have this supported

• A methodology is needed to be able to reflect changes, which currently does not exist

• However, CCDA is not a commonly used standard for the response transaction






No • Order set model contains recommendations for clinical actions, which is applicable to the types of outputs relevant in the Use Case

• Unsure of adoptibility of this standard in CDS Guidance

CDS Guidance Request Transaction: Transport Rationale

StandardSummary of


Keep? Rationale

SOAP



(P) Partially Fits:

(N) Does not Fit:

Yes • There is currently implementation guidance on DSS to be used with SOAP, not REST

• Has the capabilities and functions needed for this initiative


REST



(P) Partially Fits:

(N) Does not Fit:

Yes • Industry is moving towards using REST• Guidance could be written for DSS to work

with REST

CDS Guidance Response Transaction: Transport RationaleStandard Summary of Findings from

UCR Crosswalk Keep? Rationale

SOAP



(P) Partially Fits:

(N) Does not Fit:

Yes • There is currently implementation guidance on DSS to be used with SOAP, not REST

• Has the capabilities and functions needed for this initiative


REST

HITSC Rating:M: 100.00A: 100.00SI: 42.86T: 88.30


(P) Partially Fits:

(N) Does not Fit:

Yes • Industry is moving towards using REST• Guidance could be written for DSS to work with

REST

CDS Guidance Request Transaction: Authentication/Authorization Rationale

StandardSummary of


Keep? Rationale

SAMLHITSC Rating:*M: 100.00A: 100.00SI: 100.00T: 100.00


(P) Partially Fits:

(N) Does not Fit:* M: Maturity A: Adoptability SI: S&I Specific T: Total

CDS Guidance Response Transaction: Authentication/Authorization Rationale

StandardSummary of


Keep? Rationale

SAMLHITSC Rating:*M: 100.00A: 100.00SI: 100.00T: 100.00


(P) Partially Fits:


CDS Guidance Request Transaction: Encryption

StandardSummary of


Keep? Rationale

TLSHITSC Rating:*M: 100.00A: 100.00SI: 42.86T: 88.30


(P) Partially Fits:


CDS Guidance Response Transaction: Encryption

StandardSummary of


Keep? Rationale

TLSHITSC Rating:*M: 100.00A: 100.00SI: 42.86T: 88.30


(P) Partially Fits:

(N) Does not Fit: * M: Maturity A: Adoptability SI: S&I Specific T: Total

Solution Plan

• View the different combination of standards, across the different buckets, and determine the viability of each implementation option

• Decide which implementation option(s), and therefore combination of standards, is the best approach

• Document reasons why certain implementation options were chosen or not chosen

Solution Plan Next Steps

• Decide which implementation option(s), and therefore combination of standards, will be used as the approach in the IG and incorporated into the final design

Gap Mitigation Plan

• Identify any gaps for all standards under consideration

• Determine if the gap is for the request or response transaction, or both

• Document recommendations on how to close the gap (i.e. modification to existing standard)

Gap Mitigation Plan Next Steps:

• Pull out the standards which have gaps requiring modifications and document in the IG

• Contact the SDO to initiate modification needed

• Gaps that are related to a standard being utilized in a manner which it has not previously been designed for will be addressed and written into the IG

• Work Stream 1 – HL7:– Next HL7 meeting TBD– (see HeD Homepage wiki for meeting details: http://wiki.siframework.org/Health+eDecisions+Homepage

• Work Stream 2 – Pilots:– We continue our Pilot activities– Next Pilots meeting: May 20th, 1-2:30 pm EDT see HeD home page wiki

for meeting details: http://wiki.siframework.org/Health+eDecisions+Homepage – Updates on Pilot Activities, Review of Timelines

• Work Stream 3 – Use Case 2:– Data Elements and Standards Sub Work Group

• Next Meeting: May 22nd, 2013• Homepage wiki for meetings:


• All Hands Community Meeting– We will reviewing candidate standards – Next meeting May 23rd, 2013(see the HeD Homepage wiki for

meeting details: http://wiki.siframework.org/Health+eDecisions+Homepage

Next Steps






Questions?

Contact Information

• For questions, please contact your support leads– Coordinator:

• Ken Kawamoto: [email protected]

– Co-Coordinators:• Aziz Boxwala: [email protected]• Bryn Rhodes: [email protected]

– ONC Leadership: • Alicia Morton: [email protected]

– Project Management:• Jamie Parker: [email protected]

– Use Case 2:• Dave Shevlin: [email protected] • Virginia Rhiel: [email protected]

– Harmonization: • Lynette Elliot: [email protected] • Anna Langhans: [email protected]










Useful Links

• Wiki– http://wiki.siframework.org/Health+eDecisions+Homepage

• Use Case 1& 2– http://wiki.siframework.org/Health+eDecisions+Use+Case – UC 2: Use Case 2:

http://wiki.siframework.org/UC+2+-+CDS+Guidance+Service • Pilots

– http://wiki.siframework.org/Health+eDecisions+Pilots • HL7 Ballot Submission:

– http://wiki.siframework.org/Health+eDecisions+Reference+Materials#Ballot • UC 1 Harmonization and IG:

– http://wiki.siframework.org/Health+eDecisions+Harmonization+and+Standards+%28Implementation%29

• HeD Glossary – http://wiki.siframework.org/HeD+Glossary


http://wiki.siframework.org/Health+eDecisions+Use+Case

http://wiki.siframework.org/Health+eDecisions+Use+Case

http://wiki.siframework.org/UC+2+-+CDS+Guidance+Service

http://wiki.siframework.org/Health+eDecisions+Pilots

http://wiki.siframework.org/Health+eDecisions+Pilots

http://wiki.siframework.org/Health+eDecisions+Reference+Materials

http://wiki.siframework.org/Health+eDecisions+Reference+Materials

http://wiki.siframework.org/Health+eDecisions+Harmonization+and+Standards+(Implementation)




http://wiki.siframework.org/HeD+Glossary