|1m||Roll call and agenda check|
- Call started at 12:08PM EST with quorum reached.
|5m||Review of status ||Ted/Jess|
- Josh working on the solution to the GitHub/BitBucket sync issue
- He is off this week, completion status unknown. Will touch base with him next week.
- We need to categorize the open tasks with who (Apelon, Ted, Lloyd, or Grahame) so that the funding for 2020 ONC stuff.
- Ted will work with Carol on this to prepare what Wayne needs
- We need to figure out the deal with the ONC Interoperability conference. ONC wants a short update om the project. Jess with reach out to Matt.
- Jess planning to go, but unknown if the demo will occur or not due to other federal items still in flux
|20m||Implementation Of The Versioning Solution||Carol/Jess|
The design for versioning was decided on previous calls and the main Vocabulary WG calls (see older minutes for details). We now have to dtetemine the implementation of the design vis a vis the obects having existing versions from the 3 product families (V2, V3, and FHIR)
- We will implement a 3 part versioning identifier: major versions, minor version, error patch/technical correction. Confluence discussion of this can be found here
- Each of the 3 clauses will be an integer (e.g. 2.1.0)
- Classification of UTG versioning changes by resource (major, minor or technical correction) and by product family as specified in #2 in the UTG versioning discussion page
- Value Set Refinements continued from last call
- Any meaningful change to definitional elements means a new Value Set Definition (not version). This includes scope and immutable. Also any change to the Defining URI and OID both.
- Major number increment with change to URI or OID without changing the other, ... TBD
- The UML model of the VSD and the UTG value set resource design and fully understand the impact on versioning of change in <compose> or other header metadata.
- For all non-definitional items in VSD that the VSD spec is silent, changes to these will cause an increment to the minor number. This may not be workable though.
- Next step: Ted will list all of the Class.attribute items and we will walk through them one by one on the next.
- out of time
- Code System version implementation
- FHIR and FHIR servers have chosen their own means of version assignment in the past years
- FHIR has released R4 using the HxID versions IDs for the V3 objects
- FHIR has used the release version for the v2 ballots for the versions for the v2 code systems (ie "2.9")
- If we do simple things in UTG, this may break the FHIR implementations in the community
- If we just do the simplest - setting the UTG Code System version to all start at 2.0.0 - the FHIR releases will sort as a later version than the UTG objects, which is probably not good. In order to get the FHIR sort to work properly, we should start all the versions at 1500.0.0, which seems silly. Any suggestions?
- We could set all the major numbers to "2019" to set UTG as the latest versions for everything, and let the internal extensions with. the HxID for v3 and the old versioning for v2 hold the historic information
- Carmela suggests and Ted concurs that we use the current V2 code system version (single integer value published in Chapter 2c for 2.9 and all of the past 3 years ballots) with a '1' for the minor number flagging the enhancements to the metadata for representation in UTG. So for instance, Message Type will be 12.1.0
- We need to discuss with FHIR-I to see how this will affect FHIR since R4 was published with v2 code systems versions set to 2.9
- How does this affect the v2 community, considering that most are using the 2.5.1 vocabulary so i8f they are using versions at all, they are "2.5.1"
- Existing v3 code systems have their versions set to the release date from the last harmonization cycle, ie "1452-20191215". This is not an integer so does not fit into our 3-clause modified semver design of integers separated by decimal points.
- The existing version IDs for v3 code systems in the MIF only have 'release version' which is the version ID as carried in the filenames of the DEFN files; this is not aa 'real' version ID. It appears currently that all are the same, and are updated every release.
- To find the 'real' semantic version for the v3 code systems would involved weeks of detective work on historical records to determine the changes over time.
- Ted suggests for simplicity that we make all the UTG v3 code systems have the same UTG version ID, maybe like "2.0.0".
- If we do this, it is unclear how that will affect the v3 implementer community; note that the v3 datatypes for CD and its specialization uses ST.SIMPLE as the datatype for version so we would be ok on the syntax
- Unclear how this would affect the FHIR implementation community since they are using the old data format for released version converted to a date, e.g. "Version: 2018-08-12". This version date appears to the the release versions of the coremif that Grahame imported to the FHIR site, or could be the date he did the import; unknown.
- All of the HL7 created and published value sets refer to code systems for content without specifying the version in the CLD.
- It appears that FHIR sets the version when it generates a release of the spec; e.g. all of the code systems that are FHIR internal have their versions set to "4.0.1" in the R4 spec. "Current" has a them set to "4.1.0" (all of them), and we assume this will be changed to "5.0.1" when R5 is released. This indicates that the <version> in <CodeSystem> holds a publishing release, not a content version update, and thus is confusing.
- Plan the TSC demo
- Plan the Sydney dog-and-pony show
- Plan the message for the cochair dinner in Sydney
- Improve verbiage and documentation for rendered pages. Folks to help are being solicited.
- Follow up with CDA Mgt group on review/examination of the content being rendered
- Still need to have the discussions about the VSAC material esp. in light of the recent email chains about code "NP" in NullFlavor
- Redesign of the page generation and publishing
- Document how publishing must work now
- Dig up Grahame's link for the publishing instructions
- Design and plan the coremif generation integration
- Ted needs to open dialogue with Lynn on this; will start next week
|20m||Fall 2019 Planning||Ted/Jess|
- TSC in-depth demo on January 20th during TSC call
|10m||Other longer term items||Ted|
- We need major QA on the content
- Cleanup the V2 and V3 content for the initial live rollout
- Complete the cleanup of the CDA content
- Figure out what needs to be done for the FHIR content (ie the stuff being cleaned up on the FHIR 'Internal' tab)
- Ask the product line management groups to look at the content in UTG and let us know if there seem to be obvious errors and what those errors are so we can fix them before Sydney. Maybe ask next week.
- Put list of what will be needed in Sydney together for the go/no-go decision the first week of January by the project team
- Need to setup the list NOW for the immediate items that must be addressed as soon as we go live
- Editing of manifests
- We have a running list on Confluence of these. Update it! Open Issues and Deficiencies in UTG Tooling
- CIMI/SOLOR (Keith Campbell)
- LOINC value set definitions interface for IGs
|New business||Rob McClure|
- Recommended URIs and how references to such external terminologies so FM can get their IGs built.
- Did not get to this on the last call in terms of decisions; it has been referred to HTA (Carol M. to follow up?)
- Did not discuss on this call either, the entire call was used for versioning. We may have decided that this is out of scope for UTG.
|Call adjourned||Ted||Call adjourned at 1:04PM EST when quorum was lost. Next call is scheduled for two weeks from now on January 7, 2020, same call logistics. |