Stream: argonaut
Topic: US Core STU Update
Eric Haas (Sep 04 2019 at 03:05):
The Standard for Trial Use (STU) update of US Core version 3.0.1 , which is based on FHIR R4, is available for your review and commenting.
- The STU comment period is open: 9/3/2019 – 9/17/2019.
- Please log all comments in the GForge Tracker items under the Specification “US Core”.
- Since this is an STU update, only a few key portions of the specification are open for comment. To help commenters find those sections, the specification includes an introductory section with links to updated sections, which are all marked in a light pink.
-After the comment period closes, @Brett Marquard and @Eric Haas will review and begin disposing of comments on the 9/26/2019 HL7 Structured Documents Working group teleconference 11 AM ET. - Please let us know if you have any questions.
Eric Haas (Sep 05 2019 at 16:07):
FYI on the STU Update Comment Process:
-
The STU Update for US Core using Gforge does not have 'negative' or
'affirmative' comments. Commenters may indicate in the narrative they believe
this comment must be resolved prior to publication. -
Under the guidelines published by the TSC, the working group is required to
consider all comments submitted. Structured Documents intends to consider all
comments submitted and will follow SD decision making practices. This is more
rigorous than the STU Update requirements set forth by the TSC and GOM which
does not require formal dispositions to all comments. -
A formal publication request to HL7 International will be required prior to
publication.
Eric Haas (Sep 05 2019 at 16:08):
The relevant text from the HL7 International GOVERNANCE and OPERATIONS MANUAL
(GOM):
TSC Policy and Guidance to Work Groups on DSTU Updates vs. DSTU Ballots
(relevant section):
Note that GForge is the current equivalent of wiki based informal comment review
* Once the work group(s) has completed making the changes to the DSTU for
the DSTU Update, the revised version of the DSTU should be vetted by
one of the following processes:
i. Wiki(1) based Informal Comments - this method can use a
simplified version of the familiar ballot comment spreadsheet, or
informal comments entered directly on the wiki. The wiki format is
suggested for Work Groups doing the majority of their work on the
HL7 wiki who are familiar with wiki editing. It may also be useful
to centralize comment collection on the wiki. Details on the
format/location of the wiki access will be determined by each
project team.
ii. Peer Review process[1] - this method collects comments
using a variety of simplified forms[2], with an individual, or task
force, reviewing/applying updates.
iii. Comment Only Ballot - Use the Draft for Comment ballot
process to gather comments.
* Once the WG has vetted the updated DSTU and has voted to approve the new
publication package for the DSTU update, a Publication Request form
SHALL be submitted to the TSC along with the new publication package
requesting publication of the DSTU Update
i. As part of the publication request the work group(s) SHALL
document the type of review process used to validate the changes
made to the DSTU as part of the DSTU Update.
ii. As part of the publication request, the work group(s) may
request an extension of the DSTU period. If an extension is being
requested, a rationale for the extension SHALL be provided
(1) Note that GForge is the current equivalent of wiki based informal comment review
Eric Haas (Sep 05 2019 at 16:12):
Note all this is repeated here for your convenience. It has been formally announced on the HL7 international's .
Eric Haas (Sep 19 2019 at 19:45):
We appreciate all the comments we received for the US Core STU Update. We have reviewed them and disposed of several at the HL7 Atlanta WGM. Brett and I have proposed dispositions for the 37 comments and prepared a US Core Block Vote #1 for this Thursday's September 26th 11-12 AM ET HL7 Structured Documents call.
if you want to remove an item from the block vote to discuss on the call or if there is a particular comment you want to make regarding a proposed disposition, please contact either @Eric Haas or @Brett Marquard
Eric Haas (Sep 19 2019 at 19:45):
Comment Submitters
- Brett Marquard
- Cooper Thompson
- Craig Newman
- Danielle Friend
- Emma Jones
- Eric Haas
- Floyd Eisenberg
- Jay Lyle
- Jenni Syed
- Linda Michaelsen
- Michael Padula
- Pascal Pfiffner
- Paul Knapp
Eric Haas (Sep 19 2019 at 19:47):
Line Items
1. GF#23912 US Core meds and other profiles should include status guidance in examples (Jenni Syed) Considered - Question Answered
2. GF#23973 SpO2 method restriction (Jay Lyle) Considered - Question Answered
3. GF#24686 US Core Condition - Quick Start documentation for optional search parameters is incorrect (Emma Jones) Considered - Question Answered
4. GF#23899 US Core search with invalid parameters should be a 400 (Jenni Syed) None
5. GF#23922 US Core ProvenanceC remove custom include param (Jenni Syed) None
6. GF#24103 Constrain LOINC on Diagnostic Report Notes to only use Document LOINC7s (Linda Michaelsen) Not Persuasive
7. GF#23852 Allow one to many provenance records from the HIE. (Brett Marquard) Persuasive
8. GF#23854 remove custom search parameter for _revinclude (Brett Marquard) Persuasive
9. GF#23888 US Core Language still has link placeholder (Jenni Syed) Persuasive
10. GF#23909 US Core medications should return entered-in-error (Jenni Syed) Persuasive
11. GF#23910 US Core all medications example and unknown status (Jenni Syed) Persuasive
12. GF#23923 US Core MedicationRequest doesn7t agree with the Medications guidance (Jenni Syed) Persuasive
13. GF#23925 US Core Med req search parameters (Jenni Syed) Persuasive
14. GF#23928 US Core Med request intent and status search (Jenni Syed) Persuasive
15. GF#23971 Provenance specific guidance Summary text and structure annotations differ (Jay Lyle) Persuasive
16. GF#23972 Medication guidance assumptions (Jay Lyle) Persuasive
17. GF#24069 Change Vital Signs Reference to explain where superceded by US Core Profiles (Linda Michaelsen) Persuasive
18. GF#24070 Section Numbers are not appearring in the US Core FHIR Implementation Guide (Linda Michaelsen) Persuasive
19. GF#24089 add required search for all DiagnosticReports (Eric Haas) Persuasive
20. GF#24090 add _include parameter to syntax in quck start for pract-role (Eric Haas) Persuasive
21. GF#24107 US Core Provenance Must Support wording (Craig Newman) Persuasive
22. GF#24108 US Core Condition - example documentation for optional search parameters is incorrect (Emma Jones) Persuasive
23. GF#24119 Make it more explicit that self-prescribed will be %E2%80%98order%E2%80%99 (Eric Haas) Persuasive
24. GF#24446 Condition search example is not quite accurate (Danielle Friend) Persuasive
25. GF#24616 Remove HIE Transformation use case (Brett Marquard) Persuasive
26. GF#24631 Add preamble discouraging requiring (Eric Haas) Persuasive
27. GF#24646 StructureDefinition-us-core-pulse-oximetry guidance (Michael Padula) Persuasive
28. GF#24653 add invariant for 7Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.7 (Eric Haas) Persuasive
29. GF#24656 Don7t rename global elements at the profile level (Paul Knapp) Persuasive
30. GF#24657 Remove 7Supported7 and alter explanatory text (Paul Knapp) Persuasive
31. GF#23855 Confirm definitions in Provenance (Floyd Eisenberg) Persuasive with Mod '''In Person'''
32. GF#23930 US Core Med Req searching on date (Jenni Syed) Persuasive with Mod
33. GF#24088 Duplicate statements in DSTU2 %E2%86%92 R4 guidance (Pascal Pfiffner) Persuasive with Mod
34. GF#24118 update guidance for when required codes missing and no code for unknown (Eric Haas) Persuasive with Mod
35. GF#24450 Add a little more narrative for No Known Allergy scenarios (Cooper Thompson) Persuasive with Mod
36. GF#24636 Provenance Profile (Brett Marquard) Persuasive with Mod
37. GF#24655 Move extension to higher in the hierarchy (Paul Knapp) Persuasive with Mod
Michael Donnelly (Sep 20 2019 at 14:36):
@Cooper Thompson @Danielle Friend
Cooper Thompson (Sep 20 2019 at 15:08):
I likely won't make the call, but I'm happy with the proposed disposition for GF#24450.
Eric Haas (Sep 23 2019 at 10:44):
FYI : I have preapplied changes where possible and provided links in the proposed dispositions
Eric Haas (Sep 23 2019 at 18:17):
We will be discussing the remaining outstanding trackers (7) on this Wednesday R4 data query call.
Eric Haas (Sep 23 2019 at 18:19):
I will post them on this stream with proposed resolutions which are really straw men proposals for preview and discussion
Drew Torres (Sep 23 2019 at 18:33):
Is the call 1 or 2 hours on Thursday?
Eric Haas (Sep 23 2019 at 18:46):
(deleted)
Eric Haas (Sep 23 2019 at 18:47):
(deleted)
Brett Marquard (Sep 23 2019 at 19:09):
Thursday is 11-12 PM eastern!
Eric Haas (Sep 23 2019 at 19:13):
To clarify the HL7 Structured Documents Call is 1 hr Thursday 11-12 PM eastern!
Eric Haas (Sep 23 2019 at 19:14):
my apologies for the confusion
Drew Torres (Sep 23 2019 at 20:48):
I knew that, but when I look at the HL7 call it is listed for 2 hours.
Drew Torres (Sep 23 2019 at 20:49):
HL7 calendar*
Drew Torres (Sep 23 2019 at 20:52):
Might be a syncing issue. The link looks good.
Brett Marquard (Sep 23 2019 at 22:45):
HL7 SD is 2 hours, they give us the second hour!
Eric Haas (Sep 25 2019 at 15:32):
FYI GF#24616 has been removed from the block vote for additional discussion.
Eric Haas (Sep 26 2019 at 16:36):
US Core STU update Comments Block Vote for Thursday October 3rd HL7 Structured Documents Call
We appreciate all the comments we received for the US Core STU Update. Brett and I have proposed dispositions for the 5 comments below and prepared a US Core Block Vote #2 for this Thursday's October 3rd 11-12 AM ET HL7 Structured Documents call.
f you want to remove an item from the block vote to discuss on the call or if there is a particular comment you want to make regarding a proposed disposition, please contact either @Eric Haas or @Brett Marquard
Commenters:
- Jenni Syed
- Susan Matney
LIne Items
- GF#24639, Need to document room air on oxygen delivery amount - (considered - no action taken)
- GF#23917, US Core version discoverability confusion (persuasive with mod)
- GF#23900, US Core clarification on status field - (persuasive with mod - proposed disposition preapplied in CI Build)
- GF#23896, US Core clarify how to make language available in Narrative (persuasive)
- GF#23892, US Core Language - Servers should use the translation extension to translate to requested lang (persuasive)
Eric Haas (Sep 26 2019 at 18:03):
this item has been pulled for further discussion:
GF#24639, Need to document room air on oxygen delivery amount - (considered - no action taken)
Eric Haas (Oct 03 2019 at 14:32):
note the call in coordinate for this block and other topics has been moved to https://redoxengine.zoom.us/j/354774685 today at 8
Yunwei Wang (Oct 08 2019 at 14:12):
@Eric Haas @Brett Marquard I am wondering what the status is for GF#14492. I don't see the update in STU3.0.1. And I don't see it in the block votes. Will that be in STU3.1.0?
Brett Marquard (Oct 08 2019 at 14:15):
Continuous build for US Core includes this tracker.
Brett Marquard (Oct 08 2019 at 14:15):
This will be included when 3.1.0 is published.
Yunwei Wang (Oct 08 2019 at 14:17):
Thanks.
Emma Jones (Dec 12 2019 at 16:55):
US Core MedicationRequest.intent is 1..1 and must support. The valueset binding is required and does not contain an Unknown value. The US Core Profile General Guidance seem to limit the guidance to status elements. Does the guidance apply to the Intent element as welll?- Per the US Core Guidance: required binding strength (CodeableConcept or code datatypes):
use the appropriate “unknown” concept code from the value set if available
For the following status elements no appropriate “unknown” concept code is available, therefore the element must be populated:
AllergyIntolerance.clinicalStatus
Condition.clinicalStatus
DocumentReference.status
Immunization.status
Goal.lifecycleStatus
If one of these a status code is missing, a 404 http error code and an OperationOutcome SHALL be returned in response to a query for the resource.
Eric Haas (Dec 12 2019 at 17:43):
The guidance you reference applies to the intent element as well. One of the intent status needs to populate the element or the resource is invalid per the FHIR spefication. We missed it but should have added it to the list since it is a required binding without an unknown value. I believe I have a pending tracker for adding 'unknown' to the intent valueset. I need to follow up on that.
Lloyd McKenzie (Dec 12 2019 at 17:48):
Would be curious as to the usecase for a system not knowing if something is a plan or an order
Emma Jones (Dec 13 2019 at 19:00):
Looks like the assumption is that all systems always capture interventions.activities that are not ordered/prescribed as "plan".
Eric Haas (Dec 13 2019 at 19:27):
Who has made that assumption? The request pattern authors?? In our discussions in us core we didn’t not talk about specific assumptions beyond patient initiated medications where we suggest is an order.
Lloyd McKenzie (Dec 13 2019 at 19:33):
Patient-initiated medications would not fall within the scope of 'order'. They can be 'plan' or 'proposal', but not 'order'. They can also be statements of action (which uses a different resource entirely).
Eric Haas (Dec 14 2019 at 22:59):
well ... I know you don't agree with it but we discussed this at length and are using intent='order' and MedRequest in US Core. The only way to say a patient is self-prescribing weed for 'anxiety' is with intent = "order" ... so it is written (and published.) But that is beside the point. Your question is a good one ...
Would be curious as to the usecase for a system not knowing if something is a plan or an order
I'd like to know that as well as the basis for Emma's assertion above :-)
Lloyd McKenzie (Dec 15 2019 at 02:05):
That's not the only way to say a patient is self-prescribing weed.
Brett Marquard (Dec 16 2019 at 13:56):
...and that is the problem, and why we made it clear to use ONE way.
Last updated: Apr 12 2022 at 19:14 UTC
