Skip to end of metadata
Go to start of metadata


Date: 2019-10-10

Facilitator:  Anthony Julian

Note Taker: Anne Wizauer  

Attendees


Name

Affiliation

XConstable Consulting Inc.
xMayo Clinic

Parker Digital Health Computing 
xHL7 CTO
xDuteau Design
xCANA Software and Service Ltd
xDeontik Pty Ltd
xCigna Healthcare
RBlue Wave Informatics


Guests


Name

Affiliation


AEGIS

Accenture

ICode Solutions

PKnapp Consultin
xAmol VyasCambia Health

Create Decision from Template

Agenda Topics

Agenda Outline
Agenda Item
Meeting Minutes from Discussion
 Mover/SeconderVote
ManagementMinute ApprovalMOTION to acceptLorraine/Jeff6-0-0
MethodologyCARIN Review

Please use : CARIN BB ARB Review

Lorraine found items that she hopes the project will work through with the sponsoring work group (WG) as they prepare to ballot, but nothing that would hold up approval. Jeff and Zoran agree with that assessment. Amol agrees to work the the FM WG going forward. Amol notes that they been coordinating in the CARIN WG (Note from Anne: CARIN is a project, not a work group). Lorraine notes that's not enough; decisions must be on formally convened, official FM calls under the WG's documented decision making practices. Andy notes that CARIN is not an HL7 work group with formal designation, published decision making practices, etc. Lorraine agrees; it's a project team, and there is nothing wrong with that, but it is not a formal work group. Amol: In terms of meetings and calls, are we talking about two calls - one would be the usual weekly FM WG call and making Blue Button a component of that call, and then the CARIN Alliance project call? Is that a good structure? Lorraine suggests asking FM with how they would like it to work. Each WG has a different style. Some projects are announced on the list, have agendas sent out, and have a co-chair and quorum on the calls; then it is considered an official WG call - then they bring decisions back to the WG as a whole. Others have project team calls with draft decisions, then take material and decisions back to a main WG call for formal review and approval. Should coordinate with FM on how they want to manage it. The decisions just have to be made according to the formal decision making practices of the organization. Amol agrees to work with the FM cochairs to figure out the best way to model this process for CARIN Blue Button.

Reviewed content on http://build.fhir.org/ig/HL7/carin-bb.

  • The current proposed implementation date is listed as January 1, 2020 and should be updated as we aren't going to ballot until January.
  • Lorraine notes that it is difficult to navigate. It is difficult to find the mappings and the table of contents. Might be helpful to put some background on the main page and a more user friendly layout.
  • Amol notes they're using Trifolia on FHIR tool to publish and may have to work around some limitations
  • Profiles were name CARIN Blue Button. But when we get down to value sets, it may be wise to keep them the same for Blue Button as Da Vinci. Creating separate value sets could be problematic and should be discussed with FM. Would be important for interoperability. Amol notes that some of the decisions are based on what is allowed; we're required to use what is declared by the base resource. Lorraine: The Blue Button Patient is identical to US Core Patient. One constraint is it's making identifier mandatory. Amol: If US Core does the same change there, then it is probably an oversight. There is likely no need for a separate profile.
  • FMG will have some concern about limiting extensions. Amol reports that this was discussed at Connectathon. The aim will be to not constrain anything except the elements or concerns that are required by CARIN. 
  • Related Claim Relationship Code System: Needs a more specific description of the code system. Amol notes it's a Trifolia artifact; we do have the codes identified in that environment, but the publisher tool doesn't seem to have access to this code system and its values.
  • Lorraine notes there are numerous references to external code systems, and the copyrights and IP statements have not been captured. Should make sure those are captured in QA review. Amol agrees and states they are working on some of these in the FM calls. The general approach is if there is no FHIR friendly terminology, we use the existing patterns being used by either V2 or V3. Lorraine: HTA has copyright statements we are required to use for external code sets to ensure giving proper credit.
  • CPT/HCPCS Procedure Codes Value set: The code sets are not clickable. This may be a tooling issue. Amol notes they've tried to point to the landing pages. Lorraine: For some, it's an image of a link as opposed to an actual link.
  • No content in CapabilityStatements. Amol states that a couple of sections are still being populated.
  • Amol: We are balloting for STU. Our understanding is that there can be things that are not complete. Lorraine states there is a quality checklist that FMG uses to gauge completeness, and items that appear there that aren't complete will block material from going to ballot. Also the WG has to be comfortable with the quality of the materials. An STU ballot should be substantially baked enough that people can go off and implement it/test it. Andy states they need to highlight to the WG what is not ready for ballot. If not enough is ready, they may suggest you downgrade to a comment ballot; however, FMG Is discouraging comment ballots. 
  • Lorraine asks about ExplanationofBenefit. It states that no extensions are defined. Amol: There are a lot of extensions we are proposing that have been added to the information structure. Lorraine states that they need to talk to FMG about that as it is not
    • MOTION to approve the external content for this PSS, provided that the team works with the FM WG to address the identified issues
























Lorraine/Jeff
























5-1-0

MethodologyReview FMG Policy on Breaking Changes

Link doesn't work.

Anne will contact Lloyd and add to next week's call.

Updated link from Lloyd: Proposed Policy for Breaking Changes



ManagementMeeting TimeTony proposes moving back to 4:00 pm Eastern. Wayne has a conflict next week but could do that afterwards. Will change to 4pm Eastern time starting on 10/24

Management Next agendaProject Review
Health Services References Architecture Project Review: Tentative for 10/24


 Adjournment
 Adjourned at 5:59pm Eastern

Supporting Documents


Open JIRA:

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Loading...
Refresh

Action items