FHIR Chat · US Core Errata Release · argonaut

Stream: argonaut

Topic: US Core Errata Release

---

Brett Marquard (May 08 2020 at 19:40):

@Eric Haas and I are planning a US Core errata release in the near future. The current list of items under consideration are available in this JIRA filter. Let us know if you have something that truly is an errata and should be considered. The Patient Reported Meds issue is what triggered this planned update. Discussions will occur in Cross Projects WG under co-chairs @Jean Duteau and @Floyd Eisenberg

Eric Haas (May 08 2020 at 20:15):

We are proposing these 4 items as a Block vote-1 for the next CPG call (Thursday May 21) . If you would like any of these items pulled for discussion email me or Brett. There is also an opportunity on the call to pull an item as well. :

Issue key Summary (Reporter) Resolution

1. J#26840 various technical corrections (ehaas) Persuasive
2. J#26679 Fix ValueSet-us-core-procedure-icd10pcs (michelemottini) Persuasive
3. J#25455 Clinical Notes Guidance need fix wording for DiagnosticReports (yunwwang) 1. Persuasive
4. J#25249 Data Absent Reason on Patient.name conflicts with Invariant us-core-8 (jwalonoski) Persuasive with mod

---

...and FYI these items have been auto-approved as technical corrections:...

Issue key Summary (Reporter) Resolution

J#27001 fix invalid json snippet (ehaas) ****
J#25536 duplicate URL causes validation failure. (ehaas) ****
J#25529 Remove duplicate URL in valueset-us-core-encounter-type.xml (bkaney) ****
J#25459 "US Core Observation Lab: Invariant for ""An Observation without a value, SHALL include a reason why the data is absent unless there are component observations, or references to other Observations that are grouped within it"" is wrong" (minigrrl) ****
J#25213 Link to LOINC LP29708-2 is broken in US Core guidance (michelle.m.miller) ****
J#25182 Dead link to US-Core versions directory (wardweistra) ****
Thanks,

Eric

Lee Surprenant (May 09 2020 at 02:23):

FYI I got "The requested filter doesn't exist or is private. Try logging in." when clicking the JIRA filter link.
Today we opened FHIR#27065 and I think it should be considered for the errata release.

Lloyd McKenzie (May 09 2020 at 02:27):

Yeah, that's a known issues. Filtering by specification, artifact, page and version seem to require the user to be logged in - it's not clear why.

Lee Surprenant (May 11 2020 at 14:31):

Also opened https://jira.hl7.org/browse/FHIR-27086 for an example fix.

Jenni Syed (May 11 2020 at 16:12):

@Eric Haas @Brett Marquard just noticed this one too: https://jira.hl7.org/browse/FHIR-27096

Eric Haas (May 22 2020 at 23:18):

We will be looking at a couple of US Core Errata trackers on the next CGP call:

Jira Issue key Summary (Reporter) Resolution

1. J#27549 Pediatric vitals should include referenced growth chart (Brett.Marquard) Persuasive
2. J#27542 Missing USCDI vs Head Occipital-frontal Circumference Percentile (Birth - 36 months) (Brett.Marquard) Persuasive
3. J#27158 CLIA should not be must support for organization (atorres) Persuasive

Eric Haas (Jun 23 2020 at 19:36):

Several more issue were brought to our attention and we will be looking at these US Core Errata trackers on the next CGP call:

1. Jira Issue Summary (Reporter) Resolution
2. J#27867 add reaction to allergies (ehaas) Persuasive
3. J#27857 Add Reference to US Core Patient in Vitals Signs Profiles (Brett.Marquard) Persuasive
4. J#27846 US Core Pulse Oximetry Profile: observation.value and component.value constraints are different (emmanurse) Persuasive with Modification
5. J#27836 Expand Procedure Codes Value Set to include ICD-10 PCS codes (ekivemark) Persuasive
6. J#27117 ICD-10-PCS: Note owership and availability for Use. Include Codes. (saul_kravitz) Persuasive with Modification
7. J#27116 Change Description of ICD-10-PCS Value Set (saul_kravitz) Persuasive

Brett Marquard (Jun 24 2020 at 18:37):

+8 J#27876 - Remove Must Support References to non US Core Profiles

Drew Torres (Jun 24 2020 at 18:40):

I am curious... BY removing them does that mean we can't use them at all?

Brett Marquard (Jun 24 2020 at 18:41):

great question. I would love @Grahame Grieve to weigh in because we don't want to 'exclude' them from use, but also don't want to make them 'must support'

Jean Duteau (Jun 24 2020 at 18:43):

why would you remove them? If you remove them in the profile, then you are saying that you can't send those. You're constraining that element to only have the references that are listed. If US-Core doesn't have a profile for RelatedPerson/Device/PractitionerRole, then referencing the core spec resources seems entirely reasonable.

Brett Marquard (Jun 24 2020 at 18:44):

Thanks Jean -- how do we include them and not mark them 'must support'?

Eric Haas (Jun 24 2020 at 18:45):

We have been exploring this but have not found any answers see: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/slicing.20non.20repeating.20reference.20elements.20by.20profile/near/201872848

Jean Duteau (Jun 24 2020 at 18:45):

you can't. must support is on an element not on the list of types.

Brett Marquard (Jun 24 2020 at 18:45):

so, if you support one in the list you are compliant?

Brett Marquard (Jun 24 2020 at 18:46):

that's not how I interpret it my friend...

Jean Duteau (Jun 24 2020 at 18:47):

no, i'm saying that MustSupport is on the element, so someone would need to support the different types that are listed.

Drew Torres (Jun 24 2020 at 18:56):

The way regulators are interpreting it is that all of the referenced resources must be supported.

Eric Haas (Jun 24 2020 at 18:57):

The technical validation level and a regulatory level are at odds. If we can profile this so a subset of allowed types are must support - great. But haven't discovered how. In any case - we need to address the regulatory level.

Jean Duteau (Jun 24 2020 at 19:03):

so what is your expectation if a sender sends a Resource with a reference to a Device as the author?

Lloyd McKenzie (Jun 24 2020 at 19:53):

You can slice by type and declare different mustSupport on each slice if you need distinct conformance behavior by type.

Jean Duteau (Jun 24 2020 at 19:53):

can you do that if the element doesn't repeat? (it does repeat in this case, but there are other elements that don't where this might apply)

Lloyd McKenzie (Jun 24 2020 at 19:54):

You can for non-repeating polymorphic elements only

Eric Haas (Jun 24 2020 at 19:55):

there is the rub.... these are not polymorphic.

Eric Haas (Jun 24 2020 at 19:56):

e.g. .subject Ref(Group|Patient)

Jean Duteau (Jun 24 2020 at 19:58):

yeah, that is the rub. we should treat those as polymorphic though. They are really Ref(Group) | Ref(Patient). the type is Reference in each case, but it's a different flavour/restriction of Reference.

Grahame Grieve (Jun 24 2020 at 20:43):

you can't differentiate between must support on the list of types or target profiles. I can see that this would be a valid thing to want to differentiate. I don't see anything else on the element definition where you would want to do that?

And I know that this makes experienced slicers want to slice, but it seems to me that addressing the issue more directly would be a better way to approach this

Eric Haas (Jun 24 2020 at 20:45):

And I know that this makes experienced slicers want to slice, but it seems to me that addressing the issue more directly would be a better way to approach this

what is a more direct approach?

Grahame Grieve (Jun 24 2020 at 20:47):

marking specific types and target profiles as must-support and getting the IG publisher to render that

Eric Haas (Jun 24 2020 at 21:34):

does that means an extension on Element Definition?

Lloyd McKenzie (Jun 24 2020 at 22:08):

The only way to do it would be with an extension. I don't see why we'd treat this differently than any of the other things we might want to say - these two need to be contained, this one is a reference; these two have specific comments or usage notes or mappings. We'd have to slice for those. Why add a special extension for this one use-case?

Lee Surprenant (Jun 30 2020 at 13:28):

Not sure where we're at in terms of the errata release, but we just opened another one that would be good to consider: FHIR#27887

Robert Scanlon (Jun 30 2020 at 16:22):

I was wondering how my team dealt with the above issue Lee came across, and came across two others in reviewing our test generator tooling. I created FHIR#27892 and FHIR#27893

Eric Haas (Jun 30 2020 at 19:24):

@Lee Surprenant @Robert Scanlon I appreciate you all catching this since is a definitions file version thing that I would have never thought to check.

Eric Haas (Jul 02 2020 at 16:50):

2 more last minute Errata for the Next CGP Call on July 9th

Jira Issue Summary (Reporter) Resolution

1. J#27897 Clarify token search syntax (yunwwang) Persuasive with Modification preapplied for review
2. J#25778 Add ability for DocumentReference to have multiple attachments (jenni_syed) Persuasive preapplied for review

Eric Haas (Jul 14 2020 at 22:22):

US Core ver 3.1.1 Technical Errata Release For Community Review

This update addresses several technical corrections and errata and clarifications listed below on the home page. Note that comments for review of this errata release are limited to these items. They have been reviewed and voted on by the members of the HL7 International Cross-Group Projects WorkGroup which is sponsoring this errata release and reconciliation of the comments. To make a comment against a particular errata click on the tracker link (for example, FHIR-27975) and post a comment.

There are several outstanding ig publishing qa issues for this release which are summarized here. These are currently being resolved in cooperation with the FHIR ig publishing team.

Robert Scanlon (Jul 20 2020 at 15:22):

I noticed a minor inconsistency w/the fix that removes references to MedicationStatement, but was unable to comment on the relevant ticket (FHIR#26840) because there is no 'Comment' option on this ticket for me. Should I be able to comment on that, or am I misunderstanding the above instructions?

Vassil Peytchev (Jul 20 2020 at 15:29):

(deleted)

Lloyd McKenzie (Jul 20 2020 at 15:45):

Only managers can comment on issues once a decision has been made on them. (That's because comments generally get ignored once an issue is resolved.) If you have feedback about a resolved issue, you need to raise a new issue.

Eric Haas (Jul 20 2020 at 15:52):

really!!! - thats sucks because I don't want to chase down a bunch of new trackers

Eric Haas (Jul 20 2020 at 15:53):

a good deal more maintenance and cost for me

Lloyd McKenzie (Jul 20 2020 at 15:54):

Once an item has been resolved - and especially once it's been applied or published, a comment can't really drive any change.

Lloyd McKenzie (Jul 20 2020 at 15:55):

If you want change, you need a new item.

Lloyd McKenzie (Jul 20 2020 at 15:55):

Or you need to engage with the work group to get them to re-open the existing one (which can't happen once you've gotten to 'published')

Lloyd McKenzie (Jul 20 2020 at 15:56):

Commenting on a closed issue is a bad way to get the work group to re-open (because few work groups actively monitor issues to see they've been commented on).

Eric Haas (Jul 20 2020 at 15:56):

so new comments for old comments ad infinitum..

Lloyd McKenzie (Jul 20 2020 at 15:57):

If you're going to raise a new issue, you need to have something new to say. If you do, yes, it's a new issue. (It can and should reference the old one.)

Eric Haas (Jul 20 2020 at 15:57):

thank you for the extra overhead.

Lloyd McKenzie (Jul 20 2020 at 15:58):

How is that extra overhead?

Lloyd McKenzie (Jul 20 2020 at 15:58):

In what situations is it useful for a non-manager to add a comment to something already resolved (or applied or published)?

Eric Haas (Jul 20 2020 at 16:02):

well Im trying to give the community a chance to review the errata and instructed them to comment on the specific trackers listed - since that seemed the simplest route. It is now apparent that was a mistake. I will provide new instructions.

John Moehrke (Jul 20 2020 at 16:49):

That workflow is handled with a proposed resolution. Lloyd is talking about once the committee approves A resoluiton.

John Moehrke (Jul 20 2020 at 16:50):

im with Lloyd, it is far better to require an individual that wants to question a committee resolved issue by starting with creating a new one. The flow forces them to be persuasive. a comment on a close issue is not a good process for that.

Robert Scanlon (Jul 20 2020 at 19:59):

I created a new ticket: FHIR#28102 that references the other. I think it makes sense to create new tickets at this stage -- and this minor change request is likely sufficiently different than the intent of the other ticket anyhow.

Douglas DeShazo (Jul 22 2020 at 13:06):

Will the new US Core address the just released USCDI errata as well? I may have missed that already in this stream.

Eric Haas (Jul 22 2020 at 16:30):

I reviewed the errata and there were no changes needed to US Core to address them. Here is the link to the USCDI Errata: https://www.healthit.gov/isa/sites/isa/files/2020-07/USCDI-Version-1-July-2020-Errata-Final.pdf page 3 lists the changes.

Douglas DeShazo (Jul 22 2020 at 18:05):

Thanks @Eric Haas

---

Last updated: Apr 12 2022 at 19:14 UTC