Extending FHIR profiles

eric: When someone extends a profile, and someone extends it in shex, how to represent that?
... Two approaches: 1. not reusing the HL7 code. 2. loftier goal express your profile, combine the shex with the hl7 shex and work from there.
... We have hl7 profiles, such as for patient. You can import them in your FHIR app. You import into your app and work with it. That's the simple use of fhir.

rob: by "profile", you mean structure def?

eric: Yes.
... Everythign that is falsifiable: core stuff -- structure def, value sets. If you follow fhir interop guidance and use profiles and make more restrictions, then you profile down for more precision. There would be a shex for that also. What is the relationship between that and the core shex for the resources?
... One possibility: no relationship. When you build from the profile, you import the base and add more restrictions.

rob: forge tools

eric: Take the forge tools, restrict them down, add constraints. When you do that you import a half gig of resource defs, and you emit all the original plus some your extra restrictions.
... There are two forms: differential and snapshot (which has everything).

rob: Snapshot is optional. Some tools generate it.
... Harold's tool works with the snapshots, right?

harold: right.
... It is intertwined with the FHIR commital build. Don't know how much can live on its own.
... Trying to get the RDF code into HAPI server, but we also need to get shex generation into the things that generate profiles.

ISSUE: Need to get shex genersation into the tools that generate profiles

eric: in theory, if someone makes a profile they could use harold's code.

harold: it uses the shex template prior to the official AST model (or whatever it is called). At some point it should be switched to use the AST model.
... Python implementation generates pretty readable output not.

eric: Minimum would be to capture the profile restrictions in the shex. Nicer would be that the increments that someone puts into the profile could be expressed directly in shex to validate those resources in shex.
... If the shex worked with incremental, then we take one step toward reusing core resources when profiling.
... Other thing needed for that, is that all the reuse stuff that is implicit in the ability a structure def, the same semantics needs to be available in shex.
... e.g., when you extend a profile def, you implicitly import it and meet the combined constraints.
... So to reuse the core resource shex, then the incremental shex needs to have the same functionality, to import and extend/restrict.

david: what is needed to accomplish that?

eric: Harold and others and I had a long chat a few weeks ago. Arrived at something that would allow shex profiles that exactly capture semantics of fhir structure defs.
... Right harold?

harold: Yes, but need to prove it. That's one reason why I foughjt so hard against extensions that invalidate the core. Anything valid in the profile should be valid in the base.

eric: Not sure that is true. Slicing.
... Max cardinality could be violated.

rob: You cannot do that with just the profile, but you can with an extension.
... No, in FHIR extensions are automatically valid, though it might not know what to do with the extension.

eric: What if I said there are two components, then give it three?

rob: The extension could add a third, so it does not collide with the base.

eric: I thought that with slicing, you could extend the base.

rob: The extension does not change the base.

eric: if I have a slice on an Observation component, a BloodPressure resource, with exactly two components.

rob: The base allows as many components as you want. A profile might limit it to two components.
... Profile of a profile?

eric: Want to break down two components into pieces.

rob: Depends on how you set up your slicing. If you restrict to max components 2, then you are stuck with that down the chain. But if you do slices, then downstream you can add whatever yuou want.

eric: If you build a structure def that has a slice on a component with max cardinality 2, then you are stuck. But if you say you have at least 2 components, then you can add more.
... That means that whenver we write slices, we need to think hard about how to write them, allowing for more components.

harold: The premise i run under is that in the FHIR constraint world, things are monotonic. Something must conform to the base. Once you get to the differential notation that is essential.

david: Harold expressed the monotonicity well: anything valid to the profile must be valid to the base.

harold: Patient has a bunch of values and a bunch of tagged elements. Only modifier extension violate that.
... In extension, you can restrict the cardinality and types of the base, but you cannot take a required field and make it optional.

eric: Then when we do anything with slicing, anytime we're turning fhir into shex, and we see a slice, we have to use a shex construct to say extra, and whatver the slice says, to allow for additional component.
... BP profile on Observation, and it's expecting systolic and diastolic, and I give it one with an extra component, so it won't reject it.

rob: If you do open slicing then you can do that. With closed slicing you cannot.

eric: that's different than putting a max cardinalityu on?

harold: Correct.

eric: whenever you an openn slice on component, and I'm expecting two components, if you give me a resource that has 3 components and 2 are systolic and diastolic, I would reject it?

rob: correct
... If you had set in your systolic slice a max cardinality 1, and you gave it 2, it would be rejected.

eric: The way to express that in shex is to allow extra components that do not match systolic or distolic. You do that with EXTRA in shex -- the extras cannot match the ones you specified.
... Any gotchas?

rob: I'm running into stuff with discriminators. Not supported in the tooling. But basic rules are pretty solid.

eric: shex does not have a notion of discriminators. Discriminators allow a code to determine which rules are used.
... If you have a discriminator on component.type, and it is systolic with a foo property, the value must be a particular data type.

rob: Java validators tools are available for this.

harold: In xml, a lot is done in schematron, but not getting much attention anymore. Validation is in server code.
... Should pay attention to valuesets soon. Tooling is getting rigorous on that, looking for valid LOINC codes.
... The extensible fields and big valuesets can't be done by enumerating values. Need to link with an API for external validation.
... FHIR terminology services is moving along. Another possibility is just to have things masquerade as shex validators that determine through riules whther a URI is in a list. Need a clean separation between shex validatoin and code validation services.

eric: Terminology server would be a subset of shex validator

ADJOURNED

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/validation services/code validation services/
Succeeded: s/would a/would be a/
Present: EricP Harold_Solbrig Rob_Hausam David_Booth
No ScribeNick specified.  Guessing ScribeNick: dbooth
Inferring Scribes: dbooth

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)