Skip to end of metadata
Go to start of metadata



 Click here to expand...

Gay Dolin RN MSN - Host

Susan Langford -

Jared Dardano -

Thomson -

brian -

Dave Carlson (NMC) -

Emma -

Jeff -

Becky Gradl (Academy of Nutrition and Dietetics) -

Chris Kundra

Martin Rosner -

Benjamin Flessner - Host

Brett -

Calvin - Host

Andrew - Host

Joe Quinn (Optum) -

Joe Lamy -

Lisa -

George -

Rita -

Scott Brown -

Rob -

Chris Kundra

Lindsey Hoggle -

Eric -

Danielle Friend -

Behnaz Minaei -

Becky Angeles -

Ioana -

Drew Torres -

Terrie Reed -

Jim Grue -


  1. Call to order
  2. Business Updates (10 min)
    1. Additions/modifications to the agenda
    2. HL7
      • RIM (AKreisler)
      • Steering Division / TSC (AKreisler)
      • CDA-MG (Lisa/Brett)
      • Vocab (RHausam)
      • Pub facilitator (AHenket)
      • Electronic Services and Tools (AStatler)
      • Patient Care (Emma)
      • Example Task Force (Brett)
  3. External Updates - ONC and others
  4. Project Updates
    1. CDA R2.1 Project
    2. Value Set Issues (Next VSAC Release Package - June 2019)

    3. C-CDA value set review
    4. Cross-WorkGroup CDA Template Review
    5. CDA IG Quality Criteria Project update
  5. Additional Items
    1. Discuss PSS for C-CDA R2.1 Update (20 minutes) (Lisa)
      1. Consolidated CDA STU 2019 Update
    2. STU Comments (if there’s time, and if not, move to following week)  1700, 1752, 1757, 1758, 1760 (20 minutes) (Lisa)
      1. STU Comment Page
  6. FHIR Tracker Items
  7. FHIR US Core Block Vote and Discussion (Starting at 11 am Eastern)
  8. Adjournment


  1. Call to order - 9:03 called to order. Gale is chair.
    1. Announcements
      1.  4:00pm EST Extensions - Questionnaire Form template review
      2. Uses SD template and is not formalized. One of three documents that have not been reconciled for SD.
  2. Business Updates (10 min)
    1. Additions/modifications to the agenda
    2. HL7
      • RIM (AKreisler)
      • Steering Division / TSC (AKreisler)
        • PSS and Provenance are on to TSC for approval.
      • CDA-MG (Lisa/Brett)
        • CDA needs to start and it is up for discussion. It is on the agenda later to discuss the PSS.
        • CDA Implementation-a-Thon on Fridays. We will have a September Implementation-a-Thon that will be part of the FHIR Connect-a-Thon. We won't have anything in May.
      • Vocab (RHausam)
        • Nothing here.
      • Pub facilitator (AHenket)
        • Nothing here.
      • Electronic Services and Tools (AStatler)
      • Patient Care (Emma)
        • Social Determinants of Health Whitepaper - Tuesdays at 5:00pm EST.
          • Will consider Evelyn's project as a use case.
          • Statements specific to Patient Care. Many people are working on this subject.
          • Social Determinants and how it fits into the Care Plan Model.
          • Social Determinants on Tuesdays at 5:00pm EST.  
          • Care Plan is discussed on Wednesdays at 5:00pm EST  
          • The PSS for this will be reviewed on Monday (  )
        • Representation of physician's licensure and the function they play on the C-CDA care team.
          • There are two places in C-CDA for this information. This creates inconsistency. When you look at different areas.
          •  Tuesday 4:00 pm LHS call.
        • Dates and agendas are in the Confluence Space. LHS is Learning Health Systems and is different from Patient Care.
      • Example Task Force (Brett)
        • , we will restart these sessions.
        • No call today (  )
  3. External Updates - ONC and others
    1. Rule is in the Federal Register - countdown to May 5?
    2. Policy task force comment - CQI, patient care, and others contribute.
    3. SD may have some contributions to this. We should discuss next week about message use of Raw format in the rule.
  4. Project Updates
    1. CDA R2.1 Project
      1. Meeting this week. Identified some of the broken links. They were not included, but were in previous ballot.
      2. 3 minor edits that needed to go in. Andy is also getting the missing pieces included.
      3. Meeting this week or next week to look at the final results.
    2. Value Set Issues (Next VSAC Release Package - June 2019)

      1. Goal is to be done with our work at the end of May. Lisa is hoping this will happen in culmination with May WG.
      2. Capability in VSAC to move Value Sets to having proper intentional definitions. That set will be the focus where there is activity.
      3. Linginering problem is that we have STU comments.
      4. Between now and then, there will be a couple of things.
      5. 3 lines where this work can come up.
      6. Value Set Issues related to UTG.
      7. Value Set review and the STU Comment process could be merged together.
      8. b. and c. could be combined. b. is really the update on the project.
      9. Lisa would like to hear the operational definitions. Until we get extensions, it doesn't really help us.
      10. UTG, and how will it help us.
      11. Rob H or Rob M would be the person to comment on this.
      12. Lisa thinks this only effects SNOMED, but could affect NDRDT or other drug ones.
      13. principal across the org, we want our tooling to have each of our product families to point to the same ValueSet when creating new ValueSet content.
      14. Tracking progress and issues to know where we are at.
    3. C-CDA value set review
      1. Keep this brief and work through comments in the STU comment area. 
      2. Eliminate c. in the template. The tactical stuff in the STU comment area.
      3. 4.b (subitems - Operationalizing UTG capabilities, progress on shared ValueSets across Product Families.)
    4. Cross-WorkGroup CDA Template Review
      1. Lisa - progress was stalled with launching for Financial Management. Linda Michaelson has picked up the lead on that. The goal is the Payer information CDA vs. C-CDA as compared to the ability to share Payer in FHIR.
      2. Patient Care group is looking at the problems around problem concern and allergy concern. Problem Concern Entry is going well. Shifting to Allergy concerns and seeing if the Problem Concern approach works there.
        1. Mapping or highlighting the issues in the EHRs is an issue because the EHRs don't do this.
        2. The recommendation is to back the problem section off from using a problem Concern unless the EHR is recording data that way. EHR should only be using it when they track concerns as the design suggests. The Problem Observation should be used as point-in-time.
          1. Problem section should allow for either type of entry.
          2. Who is tracking the Concern across time and has an Author. If EHR has data organized this way.
          3. Flat list of issues should just be Problem Observation - these are problems that are handled more or less at the Encounter/Visit level and should only be Problem Concern if they are managed across Encounters.
    5. CDA IG Quality Criteria Project update
      1. Lisa and Calvin have been attending. They got through the list. There are just a couple of things that need to be clarified. At some point we will get a call about these results.
  5. Additional Items
    1. STU Comments (if there’s time, and if not, move to following week)  1700, 1752, 1757, 1758, 1760 (20 minutes) (Lisa)
      1. STU Comment Page
        1. 1700 - There is discussion about changing the conformance statement for EncounterTypeCode in the Encounter Activity Entry. We don't want to require an ATcode in the document if we don't have to. This will be Persuasive With Mod. 
          1. Lisa motions to accept this as Disposition of Persuasive with Mod. Ben Seconded.
          2. 19 For, 0 Against, 0 Abstain
        2. Andrew Statler will copy additional comments to next week's agenda.  
    2. Discuss PSS for C-CDA R2.1 Update (20 minutes) (Lisa)
      1. Consolidated CDA STU 2019 Update
        1. Brett - Jan WG - Future of C-CDA publication. Difficulty with the standard and how we manage the publication. STU comments create challenges.
          1. PSS for getting this done this year. We will seek a vote next week.
          2. We will focus on Scope first. USCDI elements in the C-CDA. Guidance for Medications, Demographics and other things. Not new design, but pulling forward the items that are in the USCDI elements. Well-used items (USCDI or member suggested items).
          3. Diagnostic Imaging Report is part of a sister publication and has been deprecated.
          4. Will need clarification about what now new design means. - If Patient Care has a recommendation to add problem observation template, is that considered new design work?
            1. Maybe it is about allowing design work on items that are in the scope of USCDI.
          5. Brett would like more time next week to consider scope. 
          6. Lisa added based on implementer feedback.
          7. Andrew - what about removing the hard out of scope comment for something more general.
          8. There are also concerns about the ONC rule timeline where it becomes Final in 2020 event though we want this created before the end of the year. 
          9. Lisa - chicken or the egg scenario - USCDI is looking for stuff in the standards.
          10. Brett - make a note of some plan for final rule. comment about new design outside of USCDI is outside of scope. Could take this line out and put in a comment that may create a bar of what qualifies.
          11. Lisa - will finalize some comments and get on the listserv for people to look at. Can the rule specify something in the process of being born?
            1. Brett - we've talked about it. We will take this into consideration.
            •  Lisa R. Nelson to send this link to the Confluence page where the PSS is. Under development and will vote on next Thursday. There may be changes.
  6. FHIR Tracker Items
    1. Nobody here to represent the FHIR tracking items.
  7. FHIR US Core Block Vote and Discussion (Starting at 11 am Eastern)
    1. posted Feb 28 for review. Reasonable changes. Not persuasive. We wanted to make them consider for future use, but not allowed to do that with Negative.
      1. Motion by Rob H to accept the block vote. second by Brett.
      2. Additional Discussion - any need to pull any of these.
      3. 0,0, 25 For
      4. Motion Carries
    2. 13 tracker items
      1. 20025 -
        1. regulatory requirement is to support the devices.
        2. query is to return all devices and is not sufficient to get implanted devices.
        3. There was discussion with ONC to get a list of codes for internal.
        4. The VA is also interested in a scenario for retrieving the prosthetics. It is a generic profile API, but would like examples on how to return a subset based on criteria such as Implantables, Prosthetics, DME, etc. Currently it just returns all. Would like the option to submit a query to return what you are looking for.
        5. Since the DSTU version that these came out with, there is also the device definition. this list could be the list to get the items, and the device definition could be used to retrieve the list of specific devices. Generic Device profile needs a way to separate it out to a more narrowed list.
        6. Lindsey Hoggle is questioning if we need a device_type valueSet?
        7. needs to be some kind of collaboration on how to use this as a generic list.
        8. New requirement for the vendors on the phone. Add a requirement to return by Device.type.
        9. Timeline to have a ValueSet by  that includes the list of device.types. Ideally, this is a list that is maintained in VSAC.
        10. VA has a vested interest in this. There is an implantable device hierarchy in SNOMED.
        11. Is there consistency in FHIR of use of category vs. the use of type?
          1. Andrew Torres is agreement that type is way too granular. Category would be better.
          2. There is not a category available for the device.
        12. Brett - we are close. Will expect the ValueSet by April 4.
        13. Is the plan to make this an external ValueSet and put it in VSAC?
          1. right now it is not an external ValueSet, it is an HL7 ValueSet.
          2. Let's look at the ValueSet first. If it is complex, then an external ValueSet would be better. If we can handle through predicates, that may be able to do this.
        14. Andrew Torres - clarification is SHOULD support?
          1. The element is required to be included. When we add new searches, we are adding them as Recommended or SHOULD.
          2. only the text is required.
          3. If it will be a required element, then we may not support this.
          4. The requirement for the API was to return the UDI.
          5. In the viewable data, you know if something is implantable.
          6. For certification, the API is only required to return the UDI. The application may do a bit more. The only thing we have is the UDI.
        15. Motion by Lindsey to accept as is. Ioana second.
        16. 2 Against, 21 For, 0 Abstain
        17. Eric will put the related items in a block. for next week.
      2.   20029 - differentiation between mandatory and must support.
        1. How does this work for the implementer?
        2. There are no invariants here or in the source resource.
        3. The text summary reflects DSTU2.
        4. As an implementer, we aren't sure what needs to be done.
        5. This was not carried forward correctly. This requires a string at list.
        6. The UDI at least.
        7. The comment recommends we add MUST support or ADD...
        8. Need to make clear that the UDI Device.udiCarrier.carrierHRF should be Mandatory.
        9. may be misreading the profile. You need the extension or one of those two things: the carrierAIDC or the carrierHRF. 
        10. The text summary says carrierHRF because there was no carrierAIDC before. The text needs to be updated.
        11. udiCarrier was a string, now it is an element.
        12. The carrierHRF would correspond to the previous version. Make carrierHRF mandatory. Then fix the Text Summary.
        13. What about patient stated or situations where you don't have the string?
          1. put in the data absent string and call it a day?
          2. make Device.udiCarrier.carrierHRF as Must support rather than mandatory.
          3. Also need to consider this for other types of devices besides the implantable.
          4. also make Device.udiCarrier.carrierAIDC to Must Support.
        14. There are other parsed out elements and we need the case of why we must support other elements. If this is tied to the regulatory, then this does not require the parts in the UDI.
          1. There is work to make the elements required elements. 
        15. device-crn got more specific. We are re-using every profile except device because device doesn't support these elements. 
        16. Eric Haas motion, Ioana Singureanu to second
      3. 20028 - 
        1. Motion by Eric to approve, 2nd by  Ioana
      4. 19907 - spot in spec on core PractitionerRole.
        1. In medication, we use the include parameters to make the Practitioner and Endpoint as Include. In this we are saying Mandatory, so we are inconsistent.
        2. Cerner does not have the concept of Practitioner and does not support this in the context that FHIR mentions. The practitioner is attributed to an organization via an external system. The physician is the closest. The physician is related to the organization and has a position. The physician is a pediatrician. Cerner does not identify this as a provider offering Pediatric services through the organization.
        3. Will finish this next week.
  8. Adjournment