This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

20181002 US Realm SC WGM

From HL7Wiki
Jump to navigation Jump to search

back to US_Realm_Steering_Committee
back to US_Realm_Steering_Committee_Conference_Calls

US Realm Steering Committee WGM Agenda/Minutes

Location: Frederick

Date: 2018-10-02
Time: 7 AM Eastern
Co-Chairs Ed/Brett Note taker(s) Anne
Attendee / Name
x Calvin Beebe Keith Boone x Hans Buitendijk
Lorraine Constable x Johnathan Coleman x Ed Hammond
Regrets Tony Julian Paul Knapp x Austin Kreisler
x Brett Marquard Ken McCaslin x Nancy Orvis
Brian Pech x Wayne Kubick x Christol Green
Sandra Stuart . Pat Van Dyke x Craig Parker
x Danielle Friend x Eric Haas x Jenni Syed
x Steve Posnak . David Susanto . John Roberts
Visitor/ Name
Rob McClure
Quorum: Chair + 7

Agenda

Administrivia

Minutes

  • Review items
    • Vital Records Mortality and Morbidity Reporting FHIR IG
      • External work coming out of CDC. AMS generated this but is not present. Might encourage them to pick up more states to move it along. Discussion over why it wasn’t presented earlier as this work has been going on for some time. Reports that a version was floating around last year. Section 3.i. needs to be a URL, not a sentence.
        • ACTION: Ask Project Services to change “location” to “URL”
      • Eric notes that it looks like they have people receiving information but not sending. What does it mean when a state is using this? Should advise the group that in the future, submissions this late won’t be accepted for the current cycle. Will need ARB review for external content.
      • Okay with approving it today, but ask AMS to next call to discuss.
        • MOTION to approve subject to clarifications: Wayne/Sandy
        • VOTE: All in favor
        • ACTION: Invite AMS to upcoming call
    • US FHIR Core Update to FHIR R4
      • Brett presents. Eric: We currently have a publication request for R3. Brett: It should be published soon. Discussion over FHIR IG publication process. Nancy: Why do we have a US Realm for clinical notes? Brett: We should be doing a secondary profile for generic UV realm clinical notes. We’re using LOINC codes for classification. Wayne: This came up in TSC. We have a lot of things that are defined US Realm because there aren’t any other countries involved but are applicable elsewhere. We should be elevating some of these items to universal. Ed; It’s complicating a matter that shouldn’t be so complicated. Wayne: We need to clarify this for people because they’re continuing to be confused. Jonathan: It seems to vary by product family as well. Wayne: You don’t want to slow it down while you look for international implementers. Ed: If we could just promote it internationally, that would be a good step. Discussion over engaging at the board level. Rob: Does this mean that US Core terminology for clinical notes doesn’t use anything that is US specific? Brett: It’s using LOINC. Discussion over whether LOINC is really US specific. It’s not always clear where the boundary is. Rob: One solution for something that you want to see going universal is to relax the bindings. But once you relax the binding, once someone wants something US specific, then they have to make another profile. Argonaut name is not on US Core, but that’s what it is. Not going to have parallel world of Argonaut 3 and 4. Steve; Ultimately there will be specs that will be available to people that would be the next en masse shift upgrade of FHIR in the US Realm. Is there going to be an Argonaut stamped implementation guide? Brett; It should really go through a standards process to become official. Steve: These are investments we’d like to be a patron of so they get done. If the next version of the IG for profiling for US Realm implementation, we want to make sure our investment is in the right place. Brett: Argonaut so far hasn’t balloted anything. Steve: What’s the normal STU trajectory for this stuff? Brett asks Jenni and Danielle about what they’re doing with R3. Danielle: One of the biggest annoyances with MU3 was that they didn’t regulate a specification, but they couldn’t because we didn’t have a good profile to regulate on. Steve: We have a rule at OMB right now that could require more alignment based on proposals outside of this project scope statement. Conclusion that R4 needs to be stable, then we get US Core R4 out. Steve: Is the SMART app authorization guide working? Eric: Josh has a publication request out. The link will be updated assuming that gets published.
      • This would ballot this winter and publish in May. Austin notes that this is another example of behavior we’re trying to change. Brett notes that this is just a maintenance PSS that Dave wasn’t even sure was necessary. Ed suggest they put an algorithm in the form that sets the dates automatically.
        • MOTION to approve: Jenni/Danielle
        • Wayne suggests we submit a master PSS for this work instead of starting over every time. Calvin: Do we need to have a roadmap for US direction so vendors, etc. can see down the road further? Rob asks how you’re going to maintain terminology. Steve: Outsiders might be under the impression that there’s going to be another argonaut labeled version, but that’s not going to happen. Something that shows the trajectory would be useful.
        • VOTE: All in favor
  • Discussion:
    • Process to deal with terminology maintenance
      • Rob: In general, my understanding is that this group is responsible for managing things that are US Realm. Managing the terminology is the responsibility of this group. Structured Docs is learning that, for the things that it publishes the code systems and value sets have to be updated on a regular basis. With SNOMED we are responsible for updating things -they demand that we don’t put anything in a published standard older than 5 years. We have also found a lot of errors. When you have over 100 value sets in C-CDA, you have to constantly look at comments, errors, etc. You have to have a process for managing that. There are things that land here; if you want the activity to happen in the WGs then you have to have a process to make sure they’re doing that. The Vocab group doesn’t know the impact of normative resources in R4. What does it mean when we make a value set definition normative? I hope it doesn’t mean we have to go to a new ballot to introduce a new version. If a code system is normative you can’t change the code system. Ed: The WGs are not specifically US Realm. Austin: For the US Realm, it would be US Core specifically that we’re responsible for. Rob: There’s a code in regulations about smoking that has a SNOMED identifier, but the description says the opposite. It’s code that in SNOMED means you’re a smoker, but if you look at the definition it says the status is unknown. This is a US Core/US Realm responsibility to fix it. Calvin: Thinking that we need to bring the product family management groups in. If it’s more than just US Core, they span all the products in their family and all the committees that touch those products. It goes down to the committee that owns that thing but has to come out of some kind of administration. Rob: There’s still some specific things that live in US Core. Brett: We will fix this particular issue in ballot. Ed asks Rob to provide a document on what he wants us to act on. Nancy: It sounds like one thing is errata management. If there’s an error it needs to be part of the ballot.
  • Adjourned at 7:53 am Eastern

Meeting Outcomes

Actions
Next Meeting/Preliminary Agenda Items


© 2018 Health Level Seven® International. All rights reserved

Retrieved from "https://wiki.hl7.org/w/index.php?title=20181002_US_Realm_SC_WGM&oldid=162070"