Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Event Location

Saturday, September 14 9:00 am – 10:00 pm

Sunday, September 15 9:00 am – 5:00 pm

Atlanta Marriott Marquis
2655 Peachtree Center Avenue
Atlanta, GA 30303
+1 (800) 260-1523 phone

Facilitators

  • Lisa Nelson (MaxMD)
  • Jean Duteau (Duteau Design)
  • Joginder Madra (Madra Consulting)

Goal

  • Improve consistency and quality of information representation in C-CDA exchange documents

Sign in:   Attendee List

Agenda

Saturday, September 14, 2019

Q1

Workflow Workshop - prep content

Document creation workflows

Document consumption workflows

Q2/3

Encounter Documents

Q2:  Using C-CDA Document to support Quality Measurement

Creating and Consuming Encounter Documents

Review Representations for key sections and USCDI Elements

Q4

Rendering, being explicit about contained content and Human readability

Narrative text linking

Section Time Range

Consistent time

Multiple Content Views

When to assert template conformance

Q5Care Plan Documents, C-CDA on FHIR, and Pizza! - an informal discussion where implementers are encouraged to show and discuss their progress.

Sunday, September 15, 2019

Q1

Provenance

Generating consensus on Data Provenance and material presented in Basic Provenance IG - especially Use Case 2 and Use Case 3

Q2/3

Exploring representation of information as it changes over time: Creation of document that follows the progressing of Ted Leven's story.

Compare implementations of Clinical Notes, Care Teams and Care Team members

Explore use of Section Time Range Entry

Bonus: explore author, author/time, and persistent id's

Q4

C-CDA Rubric

USCDI Process

Parking lot topics from the two days

Attendance

2020.05.20 Virtual C-CDA IAT Attendee List

Executive Summary of the Event Results

IAT Report-out Executive Summary.docx

Participant System Roles

Role 1: Document Creator – A system that creates a specific type of document. (Note: this track focuses primarily on the creation of C-CDA Documents, but the material covered is relevant to Document Creators who make FHIR Documents as well.)

Role 2: Document Consumer - A system that receives a document and processes it in one or more of 4 possible ways:

  • (Required) Renders the document for human readers

  • (Optional) Imports the document into its system

  • (Optional) Imports the narrative information from one or more portions of the document (section(s)), into its system

  • (Optional) Imports the discrete data from one or more portions of the document (section(s)), into its system

Bonus Role (for Data Provenance Discussion, Sunday Q1)

Role 5: HIE Transformer- A systems that receives documents and processes the data in them to aggregate, de-duplicate and re-assemble information to be shared in document-based exchange

Bonus Roles (for Saturday Q5)

Role 3: Document Transformer – A system that converts a C-CDA document into a FHIR Document of the same type or a FHIR document into a C-CDA document of the same type following one of 3 possibilities:

  • (Required) Transforms the header and body of the document without transforming any machine-coded entries.

  • (Optional)Transforms the header and body of the document and transforms some by not all machine-coded entries.

  • (Optional) Transforms the header and the body of the document and transforms all of the included machine-coded entries.

Role 4: Document Registry/Repository – A system that offers a FHIR API for storing and querying/retrieving documents. Documents may be any type of document.

  • (Required) Supports DocumentReference resource for documents available to be queried.

  • (Optional)Supports DocumentManifest for documents available to be retrieved as part of a set of documents intended to be kept together as a collection.

Scenarios

Access the Ted Leven Patient Story to get the scenario information for document creation.

1.    Create/Consume a Patient Summary

Action: Create a CCD/Progress Note/H&P to summarize the patient’s completed annual visit to his PCP on 3/5/2018. (ok to use other dates if your system can't create data historically.)

-differentiate Patient Summary from Encounter Summary

-use Section Time Range Entry

-include Clinical Notes Section, Note Activity entry

-use many USCDI data elements

Precondition: none

Success Criteria: document is schema valid and has no schematron errors. The narrative note information is coded correctly, categorized appropriately. 

Bonus point: Document scores B or better under ONC Scorecard

Bonus point: Create the Referral Note that would have been created for the Endocrinologist.


2.    Manually inspect, Validate, Consume and Render the Encounter Summary

Action: Inspect, validate with ONC Scorecard, Consume (if possible) and Render the Encounter Summary Produced in Scenario 1.

Precondition/Trigger: Visit has completed or a request has come in for the document.

Success Criteria: Document renders successfully

Bonus point: Document is attached to the patient's record in the consuming system

Bonus point: Consume or inspect the Referral Note document and determine what id would need to be returned in the associated Consultation Note.


3.    Create a C-CDA Document with a Notes section or a Note Activity entry in an existing section

Action: CCD/Progress Note/Consultation to summarize the patient’s annual visit to his PCP on 2/11/2019. (ok to use other dates if your system can't create data historically.)

-include Care Teams Section

-use Section Time Range Entry

-include Clinical Notes Section, Note Activity entry

-include many USCDI data elements

Precondition/Trigger: Visit has completed or a request has come in for the document.

Success Criteria: Section Time Range entry is coded and rendered correctly. Care Team Section is present and renders correctly, some care team members are included in the associated machine entries. Persistence of id's seems to have been used appropriately. (Changes in Problem List items, Medications, Patient Address, and Social History.)

Bonus point: Add Note Activity information onto an existing entry and confirm the authorship of the note is clear and correct.

4.    Consume the Clinical Note Document produced in Scenario 3.

Action: Inspect, validate with ONC Scorecard, Consume (if possible) and Render the Encounter Summary Produced in Scenario 1.

Precondition/Trigger: Visit has completed or a request has come in for the document.

Success Criteria: Document renders successfully; LOINC code use for coded Clinical Notes Section is correct. LOINC codes use in Note Activity entries seem correct. 

Bonus point: Document is attached to the patient's record in the consuming system


5UPER BONUS - Considered during Saturday Q5.

5. Create/Consume a C-CDA Care Plan Document

Action: Create a C-CDA Document of the following type:  Care Plan

Precondition:

Success Criteria: Document scores B or better under ONC Scorecard

Bonus point: Transform document to a FHIR Document

6.    Create/Consume FHIR Document that conforms to the C-CDA on FHIR IG

Action: Create a Document that conforms to one of the document types profiled in the C-CDA on FHIR Implementation Guide

Precondition:

Success Criteria: Documents validates using FHIR Validation tools

Bonus point: Transform that FHIR document into a C-CDA document of the same type.

7.    Consume and Render a FHIR Document

Action: Retrieve and render a FHIR document

Precondition: Assumes the ability to receive a document or query for a document from a Document Registry/Repository.

Success Criteria: Visual representation of the document shows all the attested clinical content.

Bonus point: Implement one or more of the additional options for a Content Consumer

8.    Create/Consume an Unstructured C-CDA Document – C-CDA Header with embedded pdf

Action: Create a C-CDA Document of any type of C-CDA with an embedded pdf document.

Precondition:

Success Criteria: The non-xml body is coded correctly, and the document renders correctly with your stylesheet of choice.

Bonus point: Transform document to a FHIR Document

TestScript(s)

Testing will utilize the tools available at:

https://sitenv.org/home

One Click Scorecard can be accessed using a Direct

C-CDA Scorecard includes validation against CDA schema and C-CDA template, plus other C-CDA document “best practice” criteria.


Security and Privacy Considerations

Do not supply, test or post sample files that include any PHI that has not been consented to be shared for educational purposes. 

Event Notes 

Item

Notes

Workflow

Workshop Exercise

Dynamic Health IT

Eyefinity

Diameter Health

Allscripts

Epic    

Office Practicum

Symptomatic  Symptomatic2

Cerner

Optum

SSA

SSA Deferred Request



Using C-CDA Document to support Quality Measurement

NCQA discussion

Emphasis on importance to tracing information back to the source - this may relate to provenance discussion.  Related CDA concepts seem to be author and performer.  Question being considered by auditors is "does this service match and has the data been transformed along the way from the original source to the HEDIS report? " 

Quality considerations may end up with differentiation between "good" quality data and not-so-good quality data and may lead to concepts of trusted systems vs. systems that are not as trusted.

QI Core is a superset of US Core.

Perfect is the enemy of the good.  Concerns from the implementer community that quality goalposts regularly shift and new measures are introduced that cause issues with existing workflows and processes.


Encounter Documents

Example Walkthrough

  • effectiveTime without offset.  What do we make of this?  Can you assume context of the effective time if there is no offset provided?  Is it the timezone of the sender, receiver, UTC, or something else?
  • human-readable content - e.g. titles, values, etc. - do not have rules around capitalization and content consumers should not be placing rules around capitalization of this content - e.g. expecting to only receive mixed case, all caps, etc.
  • no known allergies.  Do not need "extra" information.  Information beyond stating there is no known allergies is not needed - i.e. CSM, MFST, SUBJ participations are not needed.
  • when both ICD and SNOMED codes are included - i.e. SNOMED CT code with its equivalent ICD-10 code - the ICD code should be presented as a translation of the SNOMED code.
  • When a nullFlavor is used, codeSystem should not be specified
  • When there isn't a lot number, one should not say things like "No lot number specified" in the lot number data element as "No lot number specified" can be interpreted as the lot number.
  • Generally speaking, instances where there is no information should follow the approach suggested by the Examples Task Force - http://cdasearch.hl7.org/examples/view/4625469228fa0758500a4a62afb17f585412e50b


Rendering, being explicit about contained content and Human readability

Narrative Text Linking

Suggest text.reference should be at the level of the whole item being referenced - e.g. <TR> level for items presented in a table.  Reaffirmation the originalText references should link to human-readable content.

Consistent Time

What happens if an effective time is received without an offset?  Some systems assume UTC, but this is not "safe".  Current C-CDA conformance statement (10081) is that it "...SHOULD include time-zone offset".  Recommendation is that an offset is always used - i.e. updated conformance statement (10081) is strengthened to say "...SHALL include time-zone offset".  

If no offset is known, the Content Consumer should treat the precision as if only the date was presented.  (Reviewed in SDWG on 9/19/2019. There is a danger in truncating information that may be relevant. The specification says you would assume the information is expressed in local time. The specification does not say what local time is. This is why best practice is you shall include the offset.

There are certain situations where a specified time should be treated as local time - e.g. take this pill at 9:00 am (wherever the patient is, they take this pill at 9:30 am). Based on datatypes information, it is always right to assume this is "local time". 

When to assert template conformance

CDA templates are equivalent to FHIR profiles.  One asserts conformance to an identified pattern by referencing templateID references.  One could reference conformance to multiple  templates by referencing more than one templateID. 

If one wishes to declare conformance to Template A (where Template A conforms to Templates B and C), once may simply include a templateID reference for Template A.  Conformance to Templates B and C are inferred.  One may also include templateID references for templates A, B and C.

Provenance

Other Ways to Describe Provenance

  • who do I call if I have a question?
  • who is the origin of this information?
  • Analogous to chain of custody
  • This information came from a claim, this information claim from an EHR, etc.
  • A way to put the patient's information in context

For Discussion - Once a person reconciles and/or accepts information into their system, for provenance purposes the person who makes the decision to accept information is the new author

e.g. Jane authors information about Tim and sends it to Bob.  Bob accepts this information into his system.  Should Bob send information on to Kathy, Bob is the author of Tim's information.  Authorship does not change if Jane's information about Tim is stored in Bob's system in its entirety.

What if Bob is not a person but a system?  It is important to note that Jane authored the information.  But if the information provided by Jane is extracted and reassembled by Bob (the system) and subsequently sent to Kathy, it is important to note that Bob (the system) assembled the information.  However, Bob (the system) might not be considered an author in the same sense that Jane is considered an author.

Question re: using authoring device to represent the software.  Reaffirmation that if it is important to note both the software that authors the information along with an organization, the authoring device would be the EHR software and the organization is populated with the entity that purchased the software.

    

Section Time Range

Section Time Range

Use of the section date and time range indicates all of the entries contained in that section occurred within that span of time.  It is possible for a section to have a different time range than is specified for the document.  The human-readable portion of the section time range is required...however, the values themselves for the section time range do not need to be populated.


Issue: there may an unintended consequence of specifying the section time range as it may be interpreted as a procedure or observation about a patient.

Care Team Templates

Quick Discussion

  • Purpose is to support care coordination - who is the next of kin, who is the primary care provider, etc.
  • Currently is text only.
  • Companion Guide and example from the Examples Task Force is using the wrong code for the Care Team section. Should be 85847-2.
  • Reiteration that narrative content should not conflict with what is presented as discrete data in the entries.  An example of inconsistent representation of the same discrete data is 38 different representation of medication data from certified systems using set test data:

image credit John D'Amore


Clinical Notes

John D'Amore demonstrated an approach that collapsed all notes into one section.  Entries include a LOINC code for "notes" along with a translation for each specific note type.

C-CDA Rubric

Matt Rahn provided a preview of the new scorecard UI.  This scorecard is intended to be user-facing (i.e. for the provider).  To see what the actual issues are identified, the instance example will need to be fired through the validator.

Q: What are the scoring expectations for a system that passes certification?  Is it an A?  A: The grade is a reflection of how a sample scores against checks in the scorecard.  The grade will be de-emphasized (and perhaps be removed) and the total issues and unique issues will be given greater prominence. 

USCDI

There will be a 30-day window for feedback/comment on what should be included in the next version of USCDI.  


Discussion: It may make sense to exclude sections required for certification that do not apply to certain professions - e.g. immunization is required by certification but it does not apply to an optometrist.  Should consider an exclusion for optometry systems.  However for feedback to be considered, there should be a comment submitted.



Action/Followup Items

Grouping

Item

Responsible for Follow-up
ExamplesObtain gold-standard/clean CDA examples from NCQA and SSALisa
Time Zone Offset

Follow up with SDWG to update the companion guide regarding IAT consensus recommendation regarding time zone offset in that an offset is always used if time is included "...SHALL include time-zone offset".  If no offset is known, one should treat the precision as if only the date was presented.  

Lisa
Representation of Local TimeFollow up with SDWG, there are circumstances where a specified time should be treated as local time - e.g. take this pill at 9:00 am (wherever the patient is, they take this pill at 9:30 am).  How should this be handled within C-CDA?Lisa
Need for Timestamp Precision Beyond DateFollow up with SDWG on the need for precision on timestamps beyond for effectiveTime.  E.g. Do you need to specify the time of that a care team is in effect?Lisa















  • No labels