...
| Time | Item | Who | Notes |
|---|---|---|---|
| Concept Map | Reuben | Minimizing or removing challenges in updating ConceptMap
RD: could we create another resource and test with that. RH confirms we can take this approach. At some point we can make the swap. Precedent for this with CapabilityStatement. CC: could changes be made in June? GG: no. RD: the issue is the main build PJ: looking at the latest build, most of the changes are are in there? RD: yes, many of the changes are in the latest build. GG: adding new elements is not a breaking change, changing existing fields Davera G: how should we direct developers who want to use ConceptMap? RD: suggests that folks attend a Vocab call for guidance | |
| ConceptMap maturity level | ConceptMap maturity level There was a proposal to move ConceptMap to normative in R5. There has been some concerns about the maturity level in R5, which is 1. Some feel that the changes from R4 to R5 represent a regression or progression. Maturity is built with the implementer community. GG: it has become clear that the implementer community is required to drive maturity, but they also cannot be held back. acknowledges that documentation is not clear. Vocab should expect not to change/lower the maturity after R5. RD: Strategically what is the plan for resource maturity after R5 if there is not going to be another release? GG: it might not matter because the community will move. In some cases, more work is needed and the community is not ready for R5 to be the final. PJ: not a single implementer has implemented R5 ConceptMap so it cannot be normative. He contends that many of the key changes have been in place for some time, just not tested in a connectathon. National servers are mostly R4 versions. At the moment, this is a very immature resource. GG: Vocab incorrectly responded to community feedback to make the maturity level less mature. He feels that the maturity level can only be reduced if the scope of the resource changes. ConceptMap is still expressing relationships between concepts. RD: the question came down to the definition of maturity level 2 or 1. community members were in the meeting where the decision was made to lower the maturity level. For example - Michael Lawley RD: maybe we need to consider decoupling the maturity assertion from the specification GG: we tell people to look in the current build for the current build for the maturity level, and this is where people should look to evaluate. the committee should act like R5 will be normative in terms of how it prepares the resource. PJ: this could apply to many resources, and to R4. GG: acknowledges we are having that issue with R4 currently - maturity level lower than desired. Keeping the maturity level low sends a message to implementers that may not be desired. ConceptMap stands out as the last key resource that is not normative. Jean Duteau: are we not making it very difficult for owners of resources to make necessary changes to do so - push to R5 no matter what because that is the last release (e.g. some of the pharmacy resources) GG: its a combination of things, the committee exists to serve the community. The committee has to consider impacts to the implementer committee. They are trying to drive some consistency on understanding the relationship between the committees and the community. Changes to this resource are difficult and will be even more so after R5. It is difficult to find a balance. Committees are creating/changes resources - communicating with the community - driving maturity level based on connectathon response for example - at some point the maturity level slips out of committee control. PJ: is ConceptMap more of an issue because of the way the build runs, or because its Conformance or infrastructure? RM: the size of the implementer community has an impact on maturity. Is GG's point that if you impact early implementers you don't benefit the specification. When you are making a change to low maturity items, and you're trying things out, you're improving vs: fixing errors. In this case, we're fixing errors. The fact that initial implementers implemented something with errors, is the general issue. The Vocab committee feels that ConceptMap has been improved. GG: feels the maturity level should only be lowered if we change what is being done, not how that thing is done. RM: the meaning of the relationships between concepts has changed from R4 to R5. He agrees with JD's point - does the committee own the resource or not? He agrees that the committee must consider the implementers. As Vocab did. He provided the example of what is happening with allergies. RD: clarify that there is no opposition to ConceptMap - what we're debating is the maturity level. PJ: the messaging that the R4 ConceptMap is in error is not great. All agree that the committee has the responsibility for the decision. RD: is FHIR-I comfortable with a lower maturity level and considering R5 as normative even though technically it will not be normative. RD: we might commit to pushing up the maturity level. Andrea M: whatever the committee decides, we should make sure we review the definition of maturity levels, not the intention that is not documented. Is there an opportunity to review the guidance around maturity levels? Here are the 3 tickets that have been held up because of build issues: https://jira.hl7.org/browse/FHIR-28284 and https://jira.hl7.org/browse/FHIR-22129 and https://jira.hl7.org/browse/FHIR-31386 identified as high priority for completeness of ConceptMap tickets. | ||
| NamingSystem |
RH: described the proposal under consideration. RM: explained why he entered the ticket requesting that we provide better documentation for NamingSystem. Possibly, the original use was a light weight way to track identifiers for things. The need to track identifiers in a FHIR ecosystem is important, and it should be done one way, regardless of the resource. The same issue is going to come up with ValueSets. PJ: he is supportive of Rob M's contention that identifier management / history using NamingSystem is a good idea - but he is ok with adding the identifier metadata to each of the resources. RD: the idea of supporting the identifier metadata in a resource might be helpful to address issues with CodeSystem Summary: We would have the ability to use the $translate operation on CodeSystem and ValueSet if we add all the identifier metadata into the resources. TK: Having identifiers in a separate resource is handy for some uses, a collection of the "kinds" of NamingSystem resources can easily be used to update registries of identifiers. If distributed in CodeSystem resources, its useful for looking up a specific CodeSystem to have all the identifiers in the resource. RM: If we were to make the change, we need to make clear how doing bulk transactions could be accomplished. Key use case. If we can figure out someone can find all the updates that need to be processed, then we might be able to make this change and meet the needs. CC: can we hid the complexity? RM: what would be hidden is a lack of consistency - for some reason identifiers are not managed in CodeSystem - maybe we should consider how to manage the operational aspects of bulk operations RD: is there an issue with adding NamingSystem elements to CodeSystem (and possibly other resources) GG: OID registry doesn't distinguish between CodeSystems and IdentifierSystems. He likes NamingSystem because it gathers identifier requirements into one place. He doesn't think its wrong to add elements to CodeSystem - Discussion: to have the information in two places is dangerous. GG: He hasn't seen the kind of tracking with unique id (the degree of precision) be relevant or necessary for ValueSets. A list of identifiers with their validity period, other metadata. RM: all the value sets created in support of eCQMs, in VSAC, C-CDA. They are considering moving some or all to THO. A decision will have to be made on how to retain the history of the identifiers assigned by VSAC for value sets that are referenced in regulations. GG: code system identifiers appear in instances. value set identifiers appear in IGs and specs. some value set identifiers appear in some instances (eCQM sometimes) - not clear how these are used. RM: conformance testing impact, a future where we can imagine changes not occurring every year, and when we need to compare patient data across years (using different value set versions). RD: if one organization acquires another, and applies a different identifier (similar to moving VSAC to THO) RD: asks GG if he sees an issue with adding the uniqueID elements to CodeSystem (especially things like preferred or authoritative) GG: in CodeSystem, the url is the authoritative indicator, and use=official TK: reminds people that there are authoritative OIDs and urls GG: the only thing that isn't in the identifier data type is preferred - this will be controversial (long running discussion about this ) An extensions might be a better approach so we don't embark on a long, drawn out discussion. He is not proposing adding an extension to the identifier datatype, he is talking about an extension to CodeSystem and possibly ValueSet. We reviewed the proposed text in the ticket. It does provide clarification. GG: we could keep NamingSystem and bring the uniqueID elements into CodeSystem and ValueSet, possibly changing the identifier datatype. Conclusions: Wordsmith NamingSystem scope to explain how CodeSystems and ValueSets carry their own information UTG might not publish NamingSystems The extensions need to go into the base specification (R5 - can be pre-adopted) Remember - there is no IdentifierSystem resource to manage the project to move identifier systems from the FHIR core spec into UTG. Next steps: NamingSystem will remain as a resource, clarify its use we need to improve the description, and consider whether the value set for "kind" needs to be updated. Add extensions to CodeSystem and ValueSet to support preferred and authoritative. This will go into the continuous build so it can be pre-adopted. Clarify how bulk operations will be managed Identifier Systems and UTG support - not clear what decision was made for this. We did not discuss creating an IdentiferSystem resource. This topic needs further discussion, an evaluation of options (e.g. what problem are we trying to solve, is it worthwhile making a change now) etc. Vocab to discuss how to move forward. Post meeting discussion: Alexander and Reuben: there are some issues with identifiers that are specific to FHIR release - in part because of THO. How would these be managed? There are also issues with identifiers changing due to CodeSystem owner IP issues - this is why tracking identifiers is so critical. From Davera in the chat: We use value sets to support analytics in research the requirement being that the research / analyses are reproducible so there is a requirement for persisting value set resources and these are not currently in the VSAC or quality measure libraries. TSO there's an alternative use case |
...