Meeting minutes
FHIR R6
ken: Continuing efforts w Eric Jahn, who recommended that I attend.
ken: Company MDIX, solutions for exchanging data in healthcare market.
… CLinical healthcare, FHIR, v2, CDA models.
… Also other clinical areas, x12.
… Also in healthcare interop -- not just clinical care, but also social care. Provide interop btwn different exachange formats.
jim: U of NC, bio ontologies. Worked on the FHIR RDF serialization.
garuav: Also work w Jim at Renaissance research institute at U of NC.
… Working on IRI stems, and getting IRI prefixes registered.
tim: Worked w ontologies in the past, now working for FHIRly, hoping to use FHIR RDF in the future.
tim: https://
… https://
There are plans for the R6 version. W each version, they update the maturity level of everything in the spec, based on how its being used in the real world to reflect its maturity.
… In this next release, I learned that they want this next version to only include parts of the spec that are at the last level of maturity.
… They're removing everthing that is not completely mature, which sounds like RDF and most things in the FHIR spec, but for many things they'll skip ahead many things to keep them in the spec.
… So they did this analysis, and I think it would include RDF. Most things that are at least at level 3 they'll keep.
… The things they're taking out, they'll put in other impl guides (IGs), or in an "Additional Resources" part of the spec.
… Anything at R6 should not introduce breaking changes going forward.
… For RDF R6, that means there cannot be any breaking changes going forward.
… So we should review all issues that are still affecting R5. Anything new would have to be in by Nov.
… But if we do add something, as long as it's not a breaking change going forward, then it's okay.
… They're still working on how this will work.
tim: Maturity level: https://
… This defines what they mean by forward and backward compatible.
… There are things in shex that doesn't fully represnet valueset bindings.
… So to make it reflect how those valueset bindings work, I don't think it would be a breaking change, but making it more consistent w other parts of FHIR.
… They really want R6 to be more stable, and forward compatible.
… We're also fixing a few things w R5, and I assume that would be okay. But I've also proposed some things to into R6, and I hope we can finish those by Nov.
ken: My opinion: there's been lots of talk over the last couple years. Business motivation is to get more of the FIHR resources normative in R6, and that's an effort to move people off of 4.0., which is 5 years old. Motivation is to get people to have more normative resources.
ACTION: DBooth to reveiw R6 criteria and issues list
Issue 175:
Slash notation should be defined in a notation key at the beginning of the Built-In Functions section
python/
tim: Currently we gen OWL for every resource in the spec. But many profiles are use. Want to gen OWL classes for those profile resources.
… as a subclass of the original resource.
… Want to do that as a piece of code the people can use to gen that OWL.
… Some of these profiles are in the main spec, some are in IGs.
… E.g., want to create owl for heart rate profile: https://
… Also should gen shex for the profiles in the main spec, but also make that code available.
… Because if someone wants to validate, they'll want both OWL and shex.
… Profiles can add more constraints.
… IDK if it should go into R5, but I'd like it for R6.
ken: It's a lot to do this. In a profile, there are constraints, but also different rules, like different terminology bindings, new data concepts that don't exist in the base resource.
… Cardinality issues. Do you anticipate covering those issues?
tim: A lot of that would already be covered, because right now we have a process to translate a structure def to an OWL class.
… And we have bindings to valuesets in shex, but there's another issue that we don't fully represent them for codeable concepts. Still need to do that, even for the current RDF and shex. But if we fix that, I think profiles would work the same way.
dbooth: I think the OWL and shex are informative, rather than normative, so not subject to maturity levels.
tim: US Core is a very important IG -- required by all in the USA.
… It has its own namespace
dbooth: Why? Are there name clashes?
tim: Because there could be clashes between IGs.
… Not sure there is an automatable way to determine the IRI prefix for a given profile.
dbooth: Next steps?
tim: We should def them for profiles that are in the main spec.
… This would enable people to use RDF the way FHIR should be used.
ADJOURNED