sds & harmonization hed leadership agenda
DESCRIPTION
SDS & Harmonization HeD Leadership Agenda. Solution Plan Discussion HeD Standards Selection Risks Timeline review Detailed Data Requirement Analysis Follow-up on discussion with Dave Shields IG Update Conformance Verbs Data Model Approach Functional Interaction Types - PowerPoint PPT PresentationTRANSCRIPT
SDS & Harmonization HeD Leadership Agenda• Solution Plan Discussion• HeD Standards Selection Risks• Timeline review• Detailed Data Requirement Analysis• Follow-up on discussion with Dave Shields• IG Update
– Conformance Verbs – Data Model Approach– Functional Interaction Types– Vocab & Codeset inclusion into HeD UC2 IG: update from HL7?
1
SDS & Harmonization HeD Leadership Agenda• Solution Plan Discussion• HeD Standards Selection Risks• Timeline review• Detailed Data Requirement Analysis• Follow-up on discussion with Dave Shields• IG Update
– Conformance Verbs – Data Model Approach– Functional Interaction Types– Vocab & Codeset inclusion into HeD UC2 IG: update from HL7?
2
Discussion Points and Activities for Week of 5/20
Solution Plan Discussiono Presentations on vMR and CCDA held last week
o Decisions on Standards must be made ASAP• Specifically the selection of vMR vs CCDA/QRDA, • SOAP vs. REST
o Meetings with EPIC and Partners Healthcare being held to help facilitate discussion
3
CDS Request Options
Request Service: DSS Request ElementRequest Items Organizer/Container: CDA Based Container (CCDA, QRDA)
Request Item Payload: vMR Clinical Statement
Request Service: DSS Request ElementRequest Items Organizer/Container: vMR/GELLO
Request Item Payload: vMR Clinical Statement
Request Service: e.g., DSS Request ElementRequest Items Organizer/Container: CDA Based Container (CCDA, QRDA)
Request Item Payload: CCDA
Option #3: CDA/CCDA
Option #2: vMR/vMR
Option #1: CDA/vMR
CDS Request OptionsType of Impact
vMR C-CDA/QRDA
Implementation Guidance
IG would need to clarify how vMR is used to support CDS request
IG would need to clarify how C-CDA and/or QRDA is used to support CDS request. This includes which template(s) would be used to support which types of requests (e.g. based on type of clinical intervention needed).
Standards Development
vMR will potentially need to be extended to support additional context items, including Care Setting, Initiating and Receiving Organization and Person information, Request ID.
Vocabulary binding harmonization with other standards (e.g. C-CDA/QRDA)
New templates or changes to existing C-CDA/QRDA templates will most likely be required to support varying intervention types.
EHR Vendors EHR vendors would need to extend capabilities to support export of data into vMR format.
EHR vendors would need to extend capabilities to support export of data into new or updated template formats. They would also need logic to inform the template selection based on intervention type.
CDS Response Options
Option #2: vMR/vMR
Option #1: HeD Schema/vMR
Response Service: DSS Response ElementResponse Items Organizer/Container: HeD Schema
Response Item Payload: VMR Proposal
Response Service: DSS Response ElementResponse Items Organizer/Container: vMR/GELLO
Response Item Payload: VMR Proposal
CDS Response OptionsType of Impact
vMR HeD UC1 IG?
Implementation GuidanceStandards DevelopmentEHR Vendors
CDS Options Summary
Implementation Option Transaction Service Organizer/Container Payload
1 II01 - Request DSS CDA Based Container (CCDA, QRDA) vMR
2 II01 - Request DSS vMR/GELLO vMR
3 II01 - Request DSS CDA Based Container (CCDA, QRDA) CCDA
4 II02 - Response DSS HeD Schema VMR
5 II02 - Response DSS vMR/GELLO VMR
SDS & Harmonization HeD Leadership Agenda• Solution Plan Discussion• HeD Standards Selection Risks• Timeline review• Detailed Data Requirement Analysis• Follow-up on discussion with Dave Shields• IG Update
– Conformance Verbs – Data Model Approach– Functional Interaction Types– Vocab & Codeset inclusion into HeD UC2 IG: update from HL7?
9
Discussion Points and Activities for Week of 5/20
HeD Standards Selection Riskso vMR vs. CCDAo SOAP vs. REST
• Update from Pilots Call on SOAP/REST• Information on use of SOAP today?
10
Health eDecisions (HeD) Standards RiskvMR vs. C-CDA vs. QRDA
Background• vMR, C-CDA and QRDA could support the payload of the request for CDS guidance
• C-CDA is in wide use today within EHRs and is cited in regulation, but there is currently no template specifically for CDS use, and existing templates may require population of data that is non-essential to a CDS guidance request
• QRDA is used for quality reporting; it leverages the C-CDA construct, but may not be as strictly templated• vMR is used more heavily for clinical decision support and was the basis for the HeD UC1 solution, but there may
be push back from EHR community if we require another format for export of data• The community is torn and is unsure which solution would be better for sending a request for CDS guidance to a CDS
service
Risk • The HeD community is currently exploring the option of writing Implementation Guidance for both vMR and C-CDA and
using pilots to determine which solution would be better for HeD. • Community time and support team resources would be spent developing implementation guidance that may never
be used (depending on which standard is selected after pilots)
Ongoing and Planned Mitigation Actions• C-CDA and vMR overview presentations will be given to the community this week in order to give them a better idea of
how it could be used to support a CDS Guidance Request• HeD Leadership is considering developing vMR as its primary implementation guidance, and developing C-CDA guidance
only as time and resources allow• Another option that is being considered is the use of a C-CDA-to-vMR transform, which would allow EHRs to continue
using C-CDA alone but still utilize vMR within the CDS Guidance Request
11
2 of 12
Health eDecisions (HeD) Standards RiskvMR vs. C-CDA (continued)
IG OptionsID Description Pros Cons
A vMR aloneG • This solution would most likely support the full scope of HeD UC2 and would be consistent with HeD UC1
• EHRs would have to build in new logic to support vMR, even if they already support C-CDA
NOTE: EHRs will already have to be required to support import of data in vMR format due to response being in vMR format
B C-CDA alone • This solution would require no additional standards cited in regulation
• This would not be consistent with HeD UC1• It is unclear how well C-CDA can support HeD
UC2 requirements as-is, and at minimum may require new C-CDA template(s) and EHRs will have to
C QRDA alone • This solution would require no additional standards cited in regulation
• This would not be consistent with HeD UC1• It is unclear how well QRDA can support HeD
D vMR, C-CDA and/or QRDA guidance in HeD UC2 IG; selection made at a future point in time
• This solution would allow us to thoroughly investigate both standards before determining which to go with, therefore giving more weight to a decision either way
• This would require more work than a single-standard approach
• Time and resources would be spent developing implementation guidance that would never be used outside of pilots
E vMR with C-CDA-to-vMR and/or QRDA-to-vMR transform specified as an appendix within IG
• This solution would have all of the benefits of all above options, without having to use resources for guidance that may never be used
• This would require more work than a single-standard approach
• C-CDA may still require new template(s) to support a transform to vMR
12
3 of 43 of 12
Health eDecisions (HeD) Standards RiskSOAP vs. REST
Background• SOAP is widely used in the industry today; REST is considered to be the future standard for the industry
Risk • The HeD community would like to develop Implementation Guidance for both as different vendors may have a preference
for one vs. the other• However, if the use of SOAP vs. REST varies from vendor to vendor, ultimately this would necessitate EHRs and/or CDS
Service Suppliers to support both, which would be a burden on implementers
Ongoing and Planned Mitigation Actions• We are raising this risk to the HeD Pilot community to get there input on how much of a burden this would be, and if they
would instead prefer either SOAP or REST (and which one)
Solution Options
ID Description Pros Cons
A SOAP alone • SOAP is in wide use today • Vendors have stated they will not pilot if REST is not included
B REST alone • The industry seems to be moving towards REST
• Vendors which currently support SOAP alone for other interfaces would have to develop a RESTful interface
C SOAP and REST in Implementation Guidance
• Vendors with a preference of SOAP vs. REST would be able to pilot whichever they are more comfortable with
• Would require more time and resources to develop IG• Could result in burden on implementers to support both
13
4 of 44 of 12
SDS & Harmonization HeD Leadership Agenda• Solution Plan Discussion• HeD Standards Selection Risks• Timeline review• Detailed Data Requirement Analysis• Follow-up on discussion with Dave Shields• IG Update
– Conformance Verbs – Data Model Approach– Functional Interaction Types– Vocab & Codeset inclusion into HeD UC2 IG: update from HL7?
14
HeD UC2Proposed Harmonization Timeline
Task Status Target Start Date
Target End Date
Duration Dependence
Solution Plan In progress 4/14 5/24 6 weeks Gap Mitigation Plan
Gap Mitigation Plan In progress 5/5 6/7 5 weeks Solution Plan
Data Requirements Table In progress 4/21 6/14 8 weeks Solution Plan
Data Model Approach In progress 5/12 6/7 4 weeks Solution Plan
Modify Standards Not started 5/26 7/12 8 weeks Data Requirements Table, Gap Mitigation Plan, Solution Plan, Data Model Approach,
Implementation Guide Not started (internal progress only)
5/26 7/12 7 weeks Data Requirements Table, Gap Mitigation Plan, Solution Plan, Data Model Approach, Modify Standards
Examples Not started 6/16 7/12 4 weeks Solution Plan, Data Model Approach, Modify Standards, Implementation Guide
IG Consensus Not started 7/14 7/26 2 weeks Solution Plan, Data Model Approach, Modify Standards, Implementation Guide
Ballot Package Not started 7/26 8/19 3 weeks Implementation Guide, Modify Standards
HeD UC2Proposed Harmonization Timeline: Solution Plan Impact
Task Status Target Start Date
Target End Date
Duration Dependence
Solution Plan In progress 4/14 5/245/31
6 weeks7 weeks
Gap Mitigation Plan
Gap Mitigation Plan In progress 5/5 6/76/13
5 weeks6 weeks
Solution Plan
Data Requirements Table In progress 4/21 6/14 8 weeks Solution Plan
Data Model Approach In progress 5/12 6/76/13
4 weeks5 weeks
Solution Plan
Modify Standards Not started 5/265/31
7/127/19
8 weeks Data Requirements Table, Gap Mitigation Plan, Solution Plan, Data Model Approach,
Implementation Guide Not started (internal progress only)
5/265/31
7/12 7 weeks6 weeks
Data Requirements Table, Gap Mitigation Plan, Solution Plan, Data Model Approach, Modify Standards
Examples Not started 6/16 7/12 4 weeks Solution Plan, Data Model Approach, Modify Standards, Implementation Guide
IG Consensus Not started 7/14 7/26 2 weeks Solution Plan, Data Model Approach, Modify Standards, Implementation Guide
Ballot Package Not started 7/268/2
8/19 3 weeks2 weeks
Implementation Guide, Modify Standards
SDS & Harmonization HeD Leadership Agenda• Solution Plan Discussion• HeD Standards Selection Risks• Timeline review• Detailed Data Requirement Analysis• Follow-up on discussion with Dave Shields• IG Update
– Conformance Verbs – Data Model Approach– Functional Interaction Types– Vocab & Codeset inclusion into HeD UC2 IG: update from HL7?
17
Discussion Points and Activities for Week of 5/20 (Continued…)
Detailed Data Requirement Analysiso Review approach to complete document
• Possible to block off 3-4 days to complete?
o Should we be using the data elements from the schema instead of in conjunction with the elements from Use Case 2?
• SDC team noticed that the Actions section had additional elements in the schema that weren’t in the Use Case
18
SDS & Harmonization HeD Leadership Agenda• Solution Plan Discussion• HeD Standards Selection Risks• Timeline review• Detailed Data Requirement Analysis• Follow-up on discussion with Dave Shields• IG Update
– Conformance Verbs – Data Model Approach– Functional Interaction Types– Vocab & Codeset inclusion into HeD UC2 IG: update from HL7?
19
Update on Conversation with Dave ShieldsTransactional Layers
20
Transport and SecurityResponse Service: e.g., DSS Response ElementResponse Items Organizer/Container: e.g., HeD Action Groups Element Response Item Payload: e.g., VMR Proposal
Transport and SecurityRequest Service: e.g., DSS Request ElementRequest Items Organizer/Container: e.g: VMR or CCDARequest Item Payload: e.g., VMR Clinical
Statement
The response needs to include context elements (e.g., patient) that were not part of the HeD UC1 spec.
The request and response should have parallel approaches
The response wrapper would be in a class/complexType called CDSOutput
• This type would incorporate appropriate pieces of the HeD schema (e.g., actionGroup, actionSentences, etc).
To not have a two-way dependency between vMR and HeDS (HeD schema from UC1), we will move the current CDSInput and CDSOutput types from the vMR namespace into a new namespace
• The cdsInput and CDSOutput will continue to be part of the vMR specification and project
So the response will look like this:
DSS Response Element
Contains
CDSOutput (new name space, new type that imports HeDS types)
Contains
vMR Clinical Statements (in vMR namespace; further CDSOutput will be designed so that clinical statements from other types can be incorporated (e.g., FHIR), but this is out of scope for HeD UC2)
SDS & Harmonization HeD Leadership Agenda• Solution Plan Discussion• HeD Standards Selection Risks• Timeline review• Detailed Data Requirement Analysis• Follow-up on discussion with Dave Shields• IG Update
– Conformance Verbs – Data Model Approach– Functional Interaction Types– Vocab & Codeset inclusion into HeD UC2 IG: update from HL7?
21
Discussion Points and Activities for Week of 5/20 (Continued…) IG update
o Have determined which sections will be populated internally, and which sections will be community homework. Have also drafted a timeline for completion of each section.
• Internal team beginning to populate the Introduction section• Begin Implementation Approach Sections?
Pre Conditions Constraints
o Should Conformance Verbs include the full HL7 v3 list or to cut out the May/Need Not per ONC’s direction?
• SHALL: an absolute requirement• SHALL NOT: an absolute prohibition against inclusion• SHOULD/SHOULD NOT: best practice or recommendation. There may be valid reasons to ignore
an item, but the full implications must be understood and carefully weighed before choosing a different course
• MAY/NEED NOT: truly optional; can be included or omitted as the author decides with no implications
o Data Model Approach• Talking point at HL7 Patient Care/SD/CDS WG Joint session: the XML format of HeD
schema/expression language is not as useful/valuable as a more generalizable model (e.g. UML) would be
• What’s useful to an implementer?• What’s in our purview?
22
Discussion Points and Activities for Week of 5/20 (Continued…) IG update (continued…)
o Functional Interaction Types• How many should we focus on?
– Drug Dosing Calculation– Immunization Forecasting– Disease Management – Quality Measure Evaluation– Transition of Care Support– Prediction Rule Evaluation – APACHE score, AHRQ Pneumonia Severity Index, etc.– Severity of Illness Assessment – Charlson index, etc.
• Will these be included in the main IG document, or can they be submitted as examples (allowing them to come after the other materials)
o Vocab & Codeset inclusion into HeD UC2 IG: update from HL7?• How will we leverage Vocab & Terminology WG/work
o Scrum calls have been reinstated on Fridays from 3:30 – 4:00
23
Appendix
24
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)
• Context Aware Retrieval Application (Infobutton)
• 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)
• Context Aware Retrieval Application (Infobutton)
• CDS Knowledge Artifact Implementation Guide (HeD UC1 IG)
• HL7 Version 3 Standard: Order Set Publication, Release 1
• Consolidated CDA• Virtual Medical Record
(vMR)
• Context Aware Retrieval Application (Infobutton)
• 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
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 no designed to support rich patient data payload like DSS
CDS Guidance Request Transaction: Organizer/Container Rationale
StandardSummary of
Findings from UCR Crosswalk
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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
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
Findings from UCR Crosswalk
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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
CDS Guidance Response Transaction: Organizer/Container Rationale
StandardSummary of
Findings from UCR Crosswalk
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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
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
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
Findings from UCR Crosswalk
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
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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
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
Findings from UCR Crosswalk
Keep? Rationale
Context Aware Retrieval Application (Infobutton)HITSC RatingM: 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 • 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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
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 • 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
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 • 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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
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 • Order Set does not hold patient data, not suitable for request transaction
CDS Guidance Response Transaction: Item Payloads Rationale
StandardSummary of
Findings from UCR Crosswalk
Keep? Rationale
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 • 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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
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 • 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
Findings from UCR Crosswalk
Keep? Rationale
Consolidated CDA
HITSC 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
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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
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 • 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
Findings from UCR Crosswalk
Keep? Rationale
SOAP
HITSC Rating:*M: 100.00A: 100.00SI: 100.00T: 100.00
(Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions
(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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
REST
HITSC Rating:*M: 100.00A: 100.00SI: 42.86T: 88.30
(Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions
(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
HITSC Rating:*M: 100.00A: 100.00SI: 100.00T: 100.00
(Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions
(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
* M: Maturity A: Adoptability SI: S&I Specific T: Total
REST
HITSC Rating:M: 100.00A: 100.00SI: 42.86T: 88.30
(Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions
(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
Findings from UCR Crosswalk
Keep? Rationale
SAMLHITSC Rating:*M: 100.00A: 100.00SI: 100.00T: 100.00
(Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions
(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
Findings from UCR Crosswalk
Keep? Rationale
SAMLHITSC Rating:*M: 100.00A: 100.00SI: 100.00T: 100.00
(Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions
(P) Partially Fits:
(N) Does not Fit:* M: Maturity A: Adoptability SI: S&I Specific T: Total
CDS Guidance Request Transaction: Encryption
StandardSummary of
Findings from UCR Crosswalk
Keep? Rationale
TLSHITSC Rating:*M: 100.00A: 100.00SI: 42.86T: 88.30
(Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions
(P) Partially Fits:
(N) Does not Fit:* M: Maturity A: Adoptability SI: S&I Specific T: Total
CDS Guidance Response Transaction: Encryption
StandardSummary of
Findings from UCR Crosswalk
Keep? Rationale
TLSHITSC Rating:*M: 100.00A: 100.00SI: 42.86T: 88.30
(Y) Fits: (Sender) CDS Request; (Receiver) CDS Request; (Sender) CDS Response; (Receiver) CDS Response; Exceptions
(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