FHIR Chat · US Core Jan 2021 Ballot · argonaut

Stream: argonaut

Topic: US Core Jan 2021 Ballot

---

Brett Marquard (Oct 15 2020 at 15:42):

Future block votes will be posted here

Brett Marquard (Oct 15 2020 at 15:45):

The Cross-Group Project Work Group (CGP) is Thursdays from 1-2 PM Eastern. The next call is 10/22/2020 where we plan to review Block Vote 1

CGP zoom information:
https://zoom.us/j/91506058769

Brett Marquard (Oct 22 2020 at 18:56):

The Cross-Group Project Work Group (CGP) is meeting next Thursday 10/29 from 2-3 PM Eastern. We plan to review Block Vote 2

CGP zoom information:
https://zoom.us/j/91506058769

Eric Haas (Mar 02 2021 at 22:02):

The Cross-Group Project Work Group (CGP) is meeting next Thursday 3/11 from 2-3 PM Eastern (meeting link). We plan to vote on Block Vote 2 on ballot comments. We have prepared proposed dispositions and the trackers are available for your review at the link above. If there are any items below that you would like to withdraw from the block vote for discussion please email me or respond on this stream.
Commenters

• @Sandra Mitchell
• @Keith Salzman
• FangCao
• MitraRocca
• @Molly Malavey
• @Carol Macumber
• @Pat Taylor
• @Gay Dolin
• @Eric Haas
• @Kathy Pickering
• @Howard Strasberg
• @Robert McClure
• @Lloyd McKenzie

CGP zoom information:
https://zoom.us/j/91506058769

Lloyd McKenzie (Mar 02 2021 at 22:12):

Would like to pull FHIR#29777. I need to better understand why there's resistance to at least setting a requirement that narrative must exist - even if there's currently silence about what's in it.

Lloyd McKenzie (Mar 02 2021 at 22:12):

A resource without narrative is a resource without a safety net.

Pat Taylor (Mar 02 2021 at 22:48):

Will you pull https://jira.hl7.org/browse/FHIR-30630. The statement ‘if the value set etc..’ is there for example, preferred, or extensible binding strengths but not for required binding strengths. When building the CARIN IG for Blue Button® we were unsure about what to do as the binding strength of our value set was required. The resolution does not address the gap.

Eric Haas (Mar 02 2021 at 22:55):

Pat Taylor said:

Will you pull https://jira.hl7.org/browse/FHIR-30630. The statement ‘if the value set etc..’ is there for example, preferred, or extensible binding strengths but not for required binding strengths. When building the CARIN IG for Blue Button® we were unsure about what to do as the binding strength of our value set was required. The resolution does not address the gap.

indeed it does .. you have no option for required binding if the DAR concept does not exist ....it is not conformant.

image.png

@Pat Taylor were you looking for something else?

we could add the line:

"if the value set does not have the appropriate “unknown” concept code you must use a concept from the value set otherwise the instance will not be conformant"

Eric Haas (Mar 03 2021 at 04:32):

There was a problem with the link to the Jira link to Block Vote 2: here is the updated public link to BLOCK VOTE 2: https://jira.hl7.org/issues/?filter=13914

Pat Taylor (Mar 03 2021 at 12:37):

However, I don't see where the guidance is called out for value sets with required bindings. There are situations where binding is required to an external code system; however, for certain types of transactions, the appropriate value is 'not applicable'

Eric Haas (Mar 03 2021 at 16:03):

See the definition for required bindings here in the FHIR core specification:

image.png

Eric Haas (Mar 03 2021 at 16:04):

AS you can see "required To be conformant, the concept in this element SHALL be from the specified value set." which means that any concept outside this is not allowed.

Eric Haas (Mar 03 2021 at 16:04):

Which means that IG developer should think long and hard about using required bindings.

Eric Haas (Mar 03 2021 at 16:16):

This is pretty established and we discussed this at length in this thread a while back on this Zulip thread that ultimately led to the US Core guidance on missing data and codes. https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/CodeableConcepts.20with.20required.20bindings

Also we have submitted a tracker to make clearer in the base FHIR spec as well: https://jira.hl7.org/browse/FHIR-31385

For more perspective on the issues surrounding code binding there is this current thread: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/USCDI.20US.20core

Eric Haas (Mar 03 2021 at 16:17):

Based on this background, have we addressed your concern or is there still something that is unclear or have we misinterpreted your issue?

Pat Taylor (Mar 05 2021 at 22:28):

@Eric Haas Hi Eric, No, this doesn't address the issue. I am comfortable with required bindings as it provides a quality product. In the CARIN IG, bindings are defined as required in order to conform to external code systems. Additionally, the CARIN IG is based on claims submission standards adopted by the Department of Health and Human Services. However, in the R4 EOB, there is a situation where if item is populated, then .productOrService must be populated. For Inpatient Institutional claims, .revenue is required. However, for the majority of the claims, .productOrService is not available and so we needed to add the Not Available code to the .productOrService value set so payers could provide accurate data. A ticket has been submitted relaxing the requirement in R5. @Paul Knapp @MaryKay McDaniel @Amol Vyas

Amol Vyas (Mar 05 2021 at 23:18):

Eric Haas said:

...
indeed it does .. you have no option for required binding if the DAR concept does not exist ....it is not conformant.
...
we could add the line:

"if the value set does not have the appropriate “unknown” concept code you must use a concept from the value set otherwise the instance will not be conformant"

Makes 100% sense. Given that the DAR concept can be key for a required binding to be conformant, my gut feel is that it would only be helpful for IG authors out there to have this explicitly laid out. @Pat Taylor , @Paul Knapp , @MaryKay McDaniel

Regards,
-Amol Vyas

Eric Haas (Mar 07 2021 at 19:59):

@Pat Taylor are you available to discuss this on this week's call at link above?

Pat Taylor (Mar 08 2021 at 13:12):

@Eric Haas yes. @Amol Vyas @Paul Knapp @MaryKay McDaniel @Carol Macumber

Pat Taylor (Mar 08 2021 at 16:01):

@Gail Kocher @Lenel James

Eric Haas (Mar 08 2021 at 19:14):

Lloyd McKenzie said:

Would like to pull FHIR#29777. I need to better understand why there's resistance to at least setting a requirement that narrative must exist - even if there's currently silence about what's in it.

Based on the feedback from this stream do you still want to pull or would you like to discuss on call?

Hans Buitendijk (Mar 09 2021 at 23:22):

Please pull:
• https://jira.hl7.org/browse/FHIR-30678 - if data is withheld for privacy reasons, "unknown" is not accurate while "masking" may be revealing too much. In those situations where the field is not required it should not be required to use "unknown".
• https://jira.hl7.org/browse/FHIR-30672 - It seems that whatever is in either the carrierAIDC or carrierHRF, whichever one is valued, should be made available in the appropriate fields that relate to the UDI-DI and UDI-PI elements. This needs more work.

Eric Haas (Mar 09 2021 at 23:40):

Hans Buitendijk said:

Please pull:
• https://jira.hl7.org/browse/FHIR-30678 - if data is withheld for privacy reasons, "unknown" is not accurate while "masking" may be revealing too much. In those situations where the field is not required it should not be required to use "unknown".
• https://jira.hl7.org/browse/FHIR-30672 - It seems that whatever is in either the carrierAIDC or carrierHRF, whichever one is valued, should be made available in the appropriate fields that relate to the UDI-DI and UDI-PI elements. This needs more work.

Re FHIR#30678 I agree if not required element should not be exchanged. see this discussion here and let me know what you suggest as an alternative resolution.

Eric Haas (Mar 09 2021 at 23:45):

Hans Buitendijk said:

Please pull:
• https://jira.hl7.org/browse/FHIR-30678 - if data is withheld for privacy reasons, "unknown" is not accurate while "masking" may be revealing too much. In those situations where the field is not required it should not be required to use "unknown".
• https://jira.hl7.org/browse/FHIR-30672 - It seems that whatever is in either the carrierAIDC or carrierHRF, whichever one is valued, should be made available in the appropriate fields that relate to the UDI-DI and UDI-PI elements. This needs more work.

FHIR#30672 Why are we not just sending the whole udi string and even requiring data sources to parse it out each time for each interaction is pure madness to me. So what do you suggest?

Eric Haas (Mar 10 2021 at 02:28):

Eric Haas said:

Lloyd McKenzie said:

Would like to pull FHIR#29777. I need to better understand why there's resistance to at least setting a requirement that narrative must exist - even if there's currently silence about what's in it.

Based on the feedback from this stream do you still want to pull or would you like to discuss on call?

Lloyd McKenzie said:

No, you can leave it.

Pat Taylor (Mar 11 2021 at 12:46):

If the populating the field does not make sense from a business perspective, the recommendation is to include the value 'not- applicable' from the Code System, http://terminology.hl7.org/CodeSystem/data-absent-reason, as part of the Value Set.

Gail Kocher (Mar 11 2021 at 14:35):

To add to @Pat Taylor 's comment, the situation is such that in US healthcare claim billing, not all inpatient institutional claims have a line item procedure code. They will only have a revenue code. The claim data content standards do not allow for a line item procedure code unless there are drugs/biologics (HCPCS) or HIPPS codes on the claim. Neither HCPCPS or HIPPS will have a value for when no code is allowed/needed because when either of those are required, the value must be an actual code value. The ability in these instances to indicate 'not applicable' is critical.

Eric Haas (Mar 11 2021 at 15:40):

@Pat Taylor Can you be more specific, which element and which valueset in US Core are you referring to?

Amol Vyas (Mar 11 2021 at 19:26):

Eric Haas said:

The Cross-Group Project Work Group (CGP) is meeting next Thursday 3/11 from 2-3 PM Eastern (meeting link).
...
CGP zoom information:
https://zoom.us/j/91506058769

Eric Haas said:

Pat Taylor are you available to discuss this on this week's call at link above?

Btw, the call is actually at 1-2pm ET. Found out (too late, unfortunately) that the HL7 Conference Calling center shows the correct time. @Pat Taylor

Pat Taylor (Mar 11 2021 at 20:02):

@Eric Haas I missed the call today. :( The Value Set in question is http://hl7.org/fhir/us/carin-bb/STU1/ValueSet-AMACPTCMSHCPCSProcedureCodes.html, on item.productOrService on the Inpatient Institutional profile, http://hl7.org/fhir/us/carin-bb/STU1/StructureDefinition-C4BB-ExplanationOfBenefit-Inpatient-Institutional.html @Amol Vyas

Michele Mottini (Mar 11 2021 at 20:14):

That's a CARIN BB value set - why can't you just add the 'not applicable' value to it?

Eric Haas (Mar 11 2021 at 20:20):

@Pat Taylor I don't understand, neither of those valuesets or elements are in US Core. Can you make the next call (Thursday 3/25 1pm Eastern) to discuss?

Pat Taylor (Mar 11 2021 at 20:30):

@Michele Mottini adding 'not-applicable' from the to the value set from Code System, http://terminology.hl7.org/CodeSystem/data-absent-reason, is what we are doing. Our ask in FHIR-30630 was different. When Amol and I reviewed US Core to see if there was guidance about missing data for coded, preferred or extensible bindings we found specific direction. However, guidance is silent when speaking to missing data, or in our situation not-applicable situations, for data elements with required binding. Our request to US Core was to provide that guidance for data elements with required binding. @Eric Haas yes, I can be there. @Amol Vyas @Gail Kocher @Lenel James @Corey Spears

Brett Marquard (Apr 01 2021 at 15:32):

The Cross-Group Project Work Group (CGP) is meeting next Thursday 4/8 from 1-2 PM Eastern (meeting link). We plan to vote on Block Vote 3 on ballot comments. We have prepared proposed dispositions and the trackers are available for your review at the link above. If there are any items below that you would like to withdraw from the block vote for discussion please email me or respond on this stream.
Commenters

• @Keith Salzman
• @Molly Malavey
• @Eric Haas
• @Kathy Pickering
• @Nick Radov
• @Hans Buitendijk
• @Yunwei Wang
• @Drew Torres
• @Saul Kravitz
• @Nathan Davis
• @Lisa Nelson

CGP zoom information:
https://zoom.us/j/91506058769

Eric Haas (Apr 01 2021 at 21:28):

• @Paul Knapp

Saul Kravitz (Apr 02 2021 at 14:52):

@Brett Marquard Thanks for the head's up.
Regarding https://jira.hl7.org/browse/FHIR-29681 - I'm happy that the proposed disposition, and I don't want to be a trouble maker, but....

If the goal is to enable Plan-Net to use US Core practitioner role, there are three other issues:
1) Plan-net PractitionerRole is based on R4 (not USCore) in part because of the cardinality of practitioner, but also because of the 1..1 cardinality of organization. See https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/StructureDefinition-plannet-PractitionerRole.html . Loosing the 1..1 cardinality constraint on BOTH practitioner and organization is needed. Plan-Net requires that one of practitioner, organization, location, or healthcareservice be defined for each instance.
2) There are two value set issues that I'm hoping can also be addressed. The first issue -- inappropriate use of NUCC Provider Taxonomy for Practitioner role -- was raised as a tracker against Plan-Net by @Gail Kocher https://jira.hl7.org/browse/FHIR-25353 , and we apparently forgot to retarget them against USCore.
3) The second value set issue is that the complete NUCC Provider Taxonomy includes codes that are inappropriate specialities for an individual or a group, and should not be included. Again, see Plan-Net to see the subset of the NUCC Provider Taxonomy that was included for specialty.

@smahoney10 @Dave Hill @Robert Dieterle

Yunwei Wang (Apr 02 2021 at 15:04):

@Brett Marquard I have a question about FHIR-31364. The resolution says

add element to must have have list

Should that be must support list?

Brett Marquard (Apr 02 2021 at 15:07):

1) Plan-net PractitionerRole is based on R4 (not USCore) in part because of the cardinality of practitioner, but also because of the 1..1 cardinality of organization. See https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/StructureDefinition-plannet-PractitionerRole.html . Loosing the 1..1 cardinality constraint on BOTH practitioner and organization is needed. Plan-Net requires that one of practitioner, organization, location, or healthcareservice be defined for each instance.

When we discuss https://jira.hl7.org/browse/FHIR-29680, I suspect we may also relax.

2) There are two value set issues that I'm hoping can also be addressed. The first issue -- inappropriate use of NUCC Provider Taxonomy for Practitioner role -- was raised as a tracker against Plan-Net by @Gail Kocher https://jira.hl7.org/browse/FHIR-25353 , and we apparently forgot to retarget them against USCore.
3) The second value set issue is that the complete NUCC Provider Taxonomy includes codes that are inappropriate specialities for an individual or a group, and should not be included. Again, see Plan-Net to see the subset of the NUCC Provider Taxonomy that was included for specialty.

did you have a proposed value set.

Brett Marquard (Apr 02 2021 at 15:07):

Thanks Saul

Brett Marquard (Apr 02 2021 at 15:08):

@Yunwei Wang The image on the tracker is incorrect, and I can't seem to remove....this belongsin the 'MUST HAVE' list It's 1..1. See pre-applied here: https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-documentreference.html

Saul Kravitz (Apr 02 2021 at 15:19):

@Brett Marquard I forgot that I submitted trackers on both of those....sometimes I surprise myself with professionalism.

Regarding the value sets, I've invited @Gail Kocher to chime in. The valueSets @Gail Kocher and @Robert McClure defined in Plan-net are:
PractitionerRole.role -- https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/ValueSet-PractitionerRoleVS.html
PractitionerRole.specialty -- https://build.fhir.org/ig/HL7/davinci-pdex-plan-net/ValueSet-IndividualAndGroupSpecialtiesVS.html

Brett Marquard (Apr 02 2021 at 15:21):

Did you get feedback on how well those are implemented today? When cooking up the NUCC approach it never felt quite right, and we (@Eric Haas and I) didn't have strong alternatives.

Saul Kravitz (Apr 02 2021 at 16:08):

@Brett Marquard -- @Gail Kocher is the authority.

Gail Kocher (Apr 02 2021 at 16:14):

@Brett Marquard the value set we developed for Plan-net for PractitionerRole.role is the values that payers currently use to define practitioner roles. The provider role, aka type, is used in provider contracting/credentialing for provider networks, e.g. physician, social worker, advanced practice nurse. The NUCC Health Care Taxonomy code set is provider specialty not provider role. In order for a practitioner to have a specialty within the physician section of the code set, the practitioner must first be defined as a physician. While the code values in the value set may be different from what payers use within their systems, the concepts are the same and can easily be mapped. For example, Plan-net has 'ph' for physician while our underlying database has 'A1' for M.D. and 'A6' for D.O.. One value in Plan-net is sufficient as the actual license degree is sent in qualifications.
Hope this helps.

Brett Marquard (Apr 02 2021 at 16:19):

While the code values in the value set may be different from what payers use within their systems, the concepts are the same and can easily be mapped.

Thanks @Gail Kocher . Do you know of anyone that has developed a mapping?

Saul Kravitz (Apr 02 2021 at 17:26):

@Brett Marquard are changes to the VS bindings for role and speciality in USCore still a possibility in this round of updates, or are we too late to the game? Thanks again for bringing this to our attention.

Brett Marquard (Apr 02 2021 at 18:52):

Getting late...but i think with a solid proposal we could consider it.

Brett Marquard (Apr 02 2021 at 18:52):

And if not now, US Core will go to ballot winter 2021-2022

Gail Kocher (Apr 02 2021 at 20:27):

@Brett Marquard mapping for what? The Plan-net role codes to what? You cannot map two things that represent two different things. The current value set in USCore is not an appropriate use of the NUCC taxonomy codes, which the NUCC has commented on several times. I make this statement in my role as NUCC Code Set Subcommittee Co-chair.

Eric Haas (Apr 02 2021 at 22:37):

@Gail Kocher

1) We responded to those concerns voiced in FHIR-27769 and removed the NUCC binding here:

Change binding for CareTeam.participant.role from NUCC to Care Team Member Function, replace the US Core Careteam Provider Roles Value Set with VSAC reference (FHIR-27769)

I am not aware of any other trackers regarding NUCC bindings.

2) You stated above

The NUCC Health Care Taxonomy code set is provider specialty not provider role. In order for a practitioner to have a specialty within the physician section of the code set, the practitioner must first be defined as a physician. While the code values in the value set may be different from what payers use within their systems, the concepts are the same and can easily be mapped. (emphasis mine)

If it is easy, then we are hopeful there is a mapping that can be referenced.

Eric Haas (Apr 02 2021 at 22:48):

Brett Marquard said:

Yunwei Wang The image on the tracker is incorrect, and I can't seem to remove....this belongsin the 'MUST HAVE' list It's 1..1. See pre-applied here: https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-documentreference.html

removed image

Caitlin Ryan (Apr 06 2021 at 15:00):

@Brett Marquard Has a decision been made about relaxing the cardinality for Organization on PractitionerRole? I am looking at the above mentioned JIRA ticket (https://jira.hl7.org/browse/FHIR-29680) that says Considered-No Action Required and at the Home page for the Current CI Build has no updates on this, neither does the profile. Is it the case that a decision has not been reached or the decision is to keep the cardinality 1..1?

Brett Marquard (Apr 06 2021 at 17:29):

We haven't formally discussed/voted yet.

Caitlin Ryan (Apr 06 2021 at 18:21):

Thank you @Brett Marquard . Would it be feasible to create an Organization object that all PractitionerRoles w/o an organization can point to that is active and uses the DataAbsentReason Extension at Organization.name, as a short term work around?

Brett Marquard (Apr 06 2021 at 20:42):

It feels a little extra 'creative' wonky. in the Tracker @Saul Kravitz states

' As such, the PractitionerRole will associate the practitioner to a healthcareservice, location, specialty, etc, but not to an organization.

Could we introduce a conditional requirement that if no organization present, then a location would be present?

Lloyd McKenzie (Apr 06 2021 at 22:22):

Is there a reason why having a practitioner with a known role but no location or org would be "wrong"?

Caitlin Ryan (Apr 07 2021 at 11:15):

Thanks @Brett Marquard and to @Lloyd McKenzie question- the issue we are facing is that in some cases, our client doesn't have the information @Saul Kravitz states above for their Practitioners/Roles. So that was the reason for the work around. I think we can come to grips on it being wonky as long as it works. :)

Saul Kravitz (Apr 07 2021 at 13:20):

Re constraints on PractitionerRole: @Brett Marquard @Lloyd McKenzie @Michael Mahony - for the purposes of provider directories, the constraint is "practitioner-or-organization-or-healthcareservice-or-location". A role associated with a healthcareservice with virtual delivery would not have a location. Our thinking is that absent one of those four fields, the practitionerrole instance would not be conveying any information, but combinations of one or more of those fields were meaningful.

Caitlin Ryan (Apr 07 2021 at 13:33):

Thanks @Saul Kravitz !
And my apologies/FYI- I don't think I specified that I'm focused on US Core and not the PractitonerRole profile in DaVinci PlanNet which I know is based on R4.

Saul Kravitz (Apr 07 2021 at 13:52):

@Caitlin Ryan the focus of my trackers against USCore and the above discussion are the reasons why Plan-Net couldn't use USCore -- the 1..1 cardinality constraints on practitioner and organization, and the inappropriate VS bindings for both specialty and role.

Brett Marquard (Apr 07 2021 at 14:39):

@Saul Kravitz Just to confirm, at least 1 one of those 3 must be present?

Saul Kravitz (Apr 07 2021 at 15:57):

@Brett Marquard one of the four:

• practitioner
• organization
• healthcareservice
• location

The expectation is that in most instances, practitioner, organization, and location would be present. There are clearly cases where one or more would be absent. The relationship with healthcareservice is less mature (IMHO), but we envisioned a case where a role would be associated with a service, so we left open the option of a practitionerRole that has only a healthcareservice.

Eric Haas (Apr 08 2021 at 20:03):

We will be discussing these remaining ballot items on the Cross-Group Project Work Group (CGP) which is meeting next Thursday 4/15 from 1-2 PM Eastern (call info).

1. FHIR#30109: Remove required binding on procedure and condition
2. FHIR#30328: DiagnosticReport for Laboratory Result Reporting issued should be optional
3. FHIR#30665: Clarify that developers and implementers will retain data visualization between DSTU2 to R4 upgrades.
4. FHIR#30672: To clarify this condition, additional text was added.
5. FHIR#31514: Add LOINC to procedure codes
6. FHIR#31553: Add HIPPS Code Set to US Core Procedure
7. FHIR#31514: Add LOINC to procedure codes
8. FHIR#31574  Correction to Observation.code in Oxygen saturation by Pulse oximetry

Eric Haas (Apr 08 2021 at 20:06):

(deleted)

Eric Haas (Apr 15 2021 at 18:24):

We will be discussing these remaining ballot items on the Cross-Group Project Work Group (CGP) which is meeting next Thursday 4/22 from 1-2 PM Eastern (call info).

FHIR#30109: Remove required binding on procedure and condition
FHIR#30328: DiagnosticReport for Laboratory Result Reporting issued should be optional
FHIR#30672: To clarify this condition, additional text was added.
FHIR#29680: PractitionerRole overconstrained for Provider Directory: Organization
FHIR#29826: $docref operation and DocumentReference (duplicate issue snafu)

Eric Haas (Apr 25 2021 at 15:36):

We will be discussing these remaining ballot items on a special Cross-Group Project Work Group (CGP) call which is meeting next Thursday 4/29 from 1-2 PM Eastern (call info).

1. FHIR#30328: DiagnosticReport for Laboratory Result Reporting issued should be optional: (discussed last week and the commenter agreed to withdraw, but due to technical issues with JIra need to disposition as not persuasive instead.)
2. FHIR#30672: To clarify this condition, additional text was added. ( rewrite of implantable device guidance )
3. FHIR#31957: NEW Update MedicationRequest.category to 0..1 MS

if time new non ballot trackers:

1. FHIR#31924: Inclusion of NullFlavor values for USCoreEthnicity
2. FHIR#31899: Write usage note for non-vaccination CVX codes

NOTE: This will complete this cycle of ballot comments and new trackers prior to publishing version 4.0.0 of US Core. We thank all the commenters and ballot reconciliation participants for their contributions. A preview of all the changes to US Core is ongoing and can be viewed in the Continuous Intregration (CI) Build is available for community review prior to publishing.

Eric Haas (May 20 2021 at 19:12):

Several Ballot un-resolved ballot comments were recently discovered. We willing be voting on their proposed resolutions in a Block Vote 6 at the Cross-Group Project Work Group (CGP) meeting next Thursday 5/27 from 1-2 PM Eastern (meeting link). We have prepared proposed dispositions and the trackers are available for your review. If there are any items below that you would like to withdraw from the block vote for discussion please email me or respond on this stream.

Commenters

• @Peter Muir
• @Gary Dickinson
• Emily Bagley
• Steve Eichner

Block Vote 6

Key Summary (Reporter) Resolution

1. FHIR#32658 US Core BMI Profile isn't linking properly (peter.muir) Persuasive
2. FHIR#32657 The various profiles (e.g., laboratory results reporting, immunization profile) may not meet requirements for current public health reproting. (steve_eichner) Not Persuasive with Modification
3. FHIR#32655 Have clinician burden and patient safety been considered? (gdickinson) Not Persuasive
4. FHIR#32653 Provenance should be for elements and not for a resource. (emily_bagley@bcbst.com) Not Persuasive (FHIR#32654 and FHIR#32656 are marked as duplicates)

NOTE: This will complete this cycle of ballot comments and new trackers prior to publishing version 4.0.0 of US Core. We thank all the commenters and ballot reconciliation participants for their contributions. A preview of all the changes to US Core is ongoing and can be viewed in the Continuous Intregration (CI) Build is available for community review prior to publishing.

Eric Haas (Jul 06 2021 at 15:28):

Note: US Core 3.1.1 (based on FHIR R4) is named in ONC Cures Update Certification regulation

US Core 4.0.0 is published!!

The changes in this annual update to US Core have been reviewed and commented upon by the public through the January 2021 HL7 balloting process. The resolution of the community comments has been agreed to and voted on by the members of the sponsoring work group HL7 International Cross-Group Projects.

The key changes are summarized below:

1. New Conformance Expectations page

• Defining different ways to implement and conform to US Core.
• Clarification of the Must Support definitions as it relates to various FHIR elements such a choice datatype and references.
• Publishing a set US Core Vital Signs independent of the FHIR core profile upon which it is based

2. US Core Vital Signs Profile

• US Core Blood Pressure Profile
• US Core BMI Profile
• US Core Head Circumference Profile
• US Core Body Height Profile
• US Core Body Weight Profile
• US Core Body Temperature Profile
• US Core Heart Rate Profile
• US Core Respiratory Rate Profile
  1.Linking terminology directly to the FHIR® Terminology Service for VSAC Resources (Value Set Authority Center (VSAC) - NIH) where applicable.

1. Migrating to the standard set of HL7 FHIR IG templates for publishing. Although we strove to minimize the differences between this version and the previous versions of US Core, these changes are notable:
2. Addressing over 90 January 20201 Ballot related trackers resulting in the followed detailed changes.

---

Last updated: Apr 12 2022 at 19:14 UTC