|1||MustSupport Clarifications#DRAFT||Hans Buitendijk|
Mostly the discussion addressed the section titled "Draft." US Core has been published. The way some elements are interpreted is different than expected. Must Support flag was propagated down to the individual elements. Some language clarification might have helped. To be sure implementers are more aligned, until further clarification is available in the next version of US Core, it is important to have HL7 make a statement about the intent of Must Support. The discussion started in FMG. Basically the MUST SUPPORT is only on the attribute but not the underlying attributes. E.g., if Patient is an author - current status requires support of all Patient metadata - I.e., interpretation went much further than expected. Expecting feedback from FHIR-I, TSC and others for publication of the clarification that the level of detail interpreted is not what is expected. See link for the language. Another example provided by Ioana Singureanu - to use device may not require UDI and implementers were inserting some other type of data instead of UDI - such substitution is confusing. A "fake" value will appear as a real data item. Individual profiles will require specific discussions about what is meant by Must Support. While that work happens, the guidance will help with interpretation of the current published version of US Core.
What should the testing system do with a MUST SUPPORT flag - if the subsequent elements are not marked MUST SUPPORT, one cannot assume that sub-element is required - underlying systems will have whichever of these they support but they shouldn't be required to support these sub-elements unless they are listed as MUST SUPPORT. We need sender/receiver clarity. The DRAFT is a proposal should address US Core and "ANY" FHIR IG.
Rob McClure suggested that this DRAFT will help clarify. Motion: US Core will draft a document to live where US Realm Steering Committee determines appropriate - that is guidance about all of the MUST SUPPORT element with respect to what a sender should do and what a receiver is expected to do. Moved by Rob McClure, Seconded by Ioana Singureanu.
Discussion - A generic FHIR Core statement will address general guidance. This secondary guidance is specific to FHIR US Core. Cross-Project WG will recommend the statement and propose it to the US Realm Steering Committee. The statement will affect policy which is why US Realm Steering Committee has responsibility to approve the proposal.
Vote: 13 abstentions, 5 opposed, 18 approve
Lorraine Constable moved that CGP agrees in principle with the FMG clarification proposed by Hans; Ioana Singureanu seconded.
Vote: 8 abstentions, 0 opposed, 27 approve
|2||US Core path||Brett Marquard|
Brett showed slides of USCDI yearly release cycle and US Core as presented to US Realm Steering Committee on Tuesday, September 22: Draft in January, comment period and publication in July with Standards Vetting Approval Process (SVAP) for USCDI restarting in December. Brett further updated the slide deck after the meeting: US_Core_Release2020_Updated_24September2020
For US Core the vision is things that people have implemented (minimum of commitment and actual utilization). Road to US Core process still needs further definition. Coverage is one resource to be evaluated but it will also undergo major change between FHIR R4 and R5.
Discussion occurred about need to address how to handle the "leapfrog" between USCDI and US Core.
The January ballot will need to be limited due to timing and it can address MUST SUPPORT and some errata but not necessarily significant new items.
CGP will need to start addressing the Jira trackers on a more regular basis.
Brett Marquard moved to endorse the release plan as presented, Ioana Singureanu seconded.
Vote: 5 Abstentions, 1 Opposed, 23 Approved
|3||Military History||Ioana Singureanu||Update: Trying to re-use Occupational Data for Health (ODH) profile but it hasn't be easy due to the constraints. They created a new profile - Employment History Episode to handle military history - it is highly constrained to military employment and it is a sibling IG to ODH. The ODH pattern was useful for extending Observation to address employment data. The VA developer API can use a FHIR-based API with this IG.|
|4||Next Meetings||Jean Duteau / Floyd Eisenberg|
The Workgroup will have standing meetings on the 2nd and 4th Thursday of every month from 13:00 - 14:00 Eastern US Time.
For the next HL7 WGM, the group agreed to maintain the same time slot, Q3 on Thursday of the WGM (14:00 - 15:30 Eastern US Time for virtual meetings). Any other decisions about ad hoc or joint sessions will depend on progress over the next several months.
|5||Adjournment||The session was adjourned at 3:32 PM.|