Day. That was a good break. That was a that was a good topic. Break, yeah,
let's see. Can you guys see my screen, the slide deck? Yep. Link to the slide deck chat and Brett's here too.
Brett with a T, with single T.
Oh, sorry, Brett, Single T. Brett, Brett, he'll
you All right, so we'll get through, here's here's what I was hoping to cover. We have a block vote, and then just a heads up that we'll have a new block vote in the works. And then we have discussion topics. We have two or three, depending on how the timing goes. And let's see, do we have, can we go till eight? Or do you guys have too much stuff we should try to end sooner?
Oh, sorry, I'm not sure. Yeah,
what's that? I go, Yeah, go ahead, take your time tonight.
All right. So first thing would be block vote three. And you know, we posted this on December 30 during the break, so people have definitely had over a week, but because of the holidays, you know, it's up to you, up to you folks, if we're ready to vote on this. It definitely has been out there for over a week, through the list serve and through through Zula, and I don't find these comments to be particularly controversial, and we've discussed John's comments and Rob's comments with them, And then the other ones we're just finding persuasive. So Are folks comfortable going forward with the block boat today?
I am. Anyone have any objections? I look, I mean,
John, can you explain what where your comments gonna go, or what the debt this presentation of the link for the third one.
You mean the fourth one,
this one here,
sorry, I'm on the presentation. Wait, oh, shoot, that's not in your presentation. I'm sorry. Never mind. Okay.
Okay, so the other ones, I think of her discussion. So you're okay with this number five.
I mean, I haven't had a chance to look at these, but it's probably fine. I
did you want more time? Did you want to withdraw that one? And I doubt
it. I just I, I try to skim really quickly when I hear that it's been out for a week and I haven't seen it, especially when it was a new year, but it's
mostly, do we think you should give it another week? Or what do you want? I
don't need to slow it down. It's fine.
Are you sure? Oh,
my goodness, you want to push it? Yes, I want a week.
No, I will tell you, Benjamin, I don't think that these are particularly controversial this, this one here is just asking us to include more guidance, and the guidance we write would be vetted with the committee again. Anyhow,
perfect. Okay, okay,
I agree.
That's not con. I think that's,
I mean, I think this. It's totally fine. I just was curious if,
yeah, the guidance will be, well, we'll have a chance to vet the the actual guidance that's written. Obviously
sounds good. I would, I would entertain a motion to approve the,
approve the block vote.
Would anyone like to make a motion?
Oh, yeah, go ahead, Lisa. I'll second all motion. Yeah,
all right. We have a motion from Lisa, a second from John, from John. Would any? Is there any further discussion? Okay, hearing none is any Would anyone like to abstain? Oh,
would anyone like to oppose? Okay, hearing none motion carries with
12, 00,
11, 00.
Don't count. Benjamin's
note taker here. Okay, all right, 11, 00, thank you
for pointing that out.
Okay, so that's that one.
Can we get that list? Or, I guess in justgrants This,
this link right here on the slide deck, takes you to the spreadsheet. Oh, okay, yeah. Or actually, way to be better, I got it, yeah.
Okay, so moving on. We were starting to queue stuff up for the next blockfo, which we'll probably try to post next week. We have a couple from Rob. We talked to Rob yesterday about these, so we know that he's okay with this. This one from John is the one that we talked about before the holidays, about the ID, Id ref thing, and the next slide is going to actually show what we're proposing. So I'm going to just jump to that, and then we have another discussion topic. We think before the holidays, we had looked at a comment from pons, and our thinking has changed a little bit in speaking to Hans and speaking to the tiger team about that one. So the discussion topics we have queued up are this one related to a valid comment from John, and John just interrupt me, or do you want to give an introduction, or should I just kind of go through it?
I know you can, you can run through it. I mean, it's essentially that we should link to narrative, just kind of like we do in CDA.
And to me, the tricky part for this one was, you know, if you any other so the ballot comment was, we need some way to link between narrative and entries, similar to how we do it in CDA. And John has, you know, been working with, I guess, a lot of folks, including Graham, to come up with a mechanism. And the mechanism that they've kind of landed on, which we're trying to replicate here is to use XML ID, Id ref. The little bit of a caveat, which I hadn't really realized until all of this, was that, you know, a resource has an ID, but every element has an ID as well. And interestingly, in the generation rules, when you generate stuff in JSON format, both of these IDs come out looking the same, but when you generate these things in XML format, this ID the element looking as an XML attribute, which is great, and I can illustrate that a little bit more here. So here's here's an ID ref. In this one is in JSON format, in the narrative block, and then in XML format, here's an ID ref. And if we look in, if we look in, if we look in XML, we can see that that automatically, in XML format gets generated as a XML attribute. So that's good news, because the rules from the W 3c, XML and Id ref has to has to be the target of the XML ID ref has to be an XML ID. So that works out. So anyhow, that I'm rambling a little bit. But the idea is that you'd put an XML, you put an ID ref in the narrative block, and it would point to an ID, but not just any ID. Specifically, we're recommending a should constraint that it should wreck that it should point to the bundle entry ID. So I thought that this was important enough to let everyone see what we're proposing. This would be the new linking mechanism that we would use, and this is aligned with
Bob. Why did you make that so high level like we have the ability right now to you know, think about how big an entry is. An entry could have take, like a structure like consent, the consent resource is massive in why not have more granular abilities to point back and forth between spots in the in the RE is there no way to have an ID deeper into the resource itself? Is that? Is that as close as we can get?
Well, you actually can put an ID on anything whatsoever, and it will when you and it'll manifest in XML as an XML ID. So anything, any element ID, can serve as a target for this ID. Ref. I think the concern that was discussed was, if it can just be arbitrary anywhere, will people be confused? And would it be better to say, you know, well, you should point to this level, you know, if you really need to point elsewhere, go ahead you
can. Yeah, yeah, I'm good with that. You want, you want alignment at the entry level, for sure, that's your first place of, you know, making sure that things are square. But I wouldn't limit it to that. And if there's something that, if you could add a sentence that says, if you if there's a reason for doing it, lower that that's okay. It's because sometimes people freak out and you give them permission to do one thing and they think you can't do something else, just because you're silent about it. I agree.
Okay, so John, any and you
may this, and you may do that, give us some kind of a May, so that you open people's minds to the idea that that the the ref, the text referencing, can be more granular than just here's a whole entry that matches with this whole chunk of text. Good luck. Yeah,
I know. I'm totally I'm totally good with that. And also, just to give you a little bit of context too, and what we found in IPS around using ID, Id ref, and is that when we're talking to implementers, there's a big desire, because they're already exchanging and sending around and using fire resources for lots of things, of when they package it together in a document to not edit the individual resource by adding new extensions, or kind of adding a lot of new IDs. Doing this when you create the bundle and using the entry ID logic, essentially here works out really well, because essentially you have to make the composition when you're creating a summary. Creating a summary. So essentially, you're kind of creating when you're making the summary. You're not editing or changing the resources that go into the summary. You're just really creating composition in the bundle, and then the entry IDs of the bundle on the bundle entry IDs, but then reference the human generated text, because a lot of these narratives at the composition section text level didn't exist before you created that specific summary. So it kind of is, it's a nice pattern, and we kind of found that actually everybody wanted to, when we had this at the September connected on. Everyone wanted to use the ID, Id graph. We brought up the idea of using extensions and other things as well. So,
John, I do you think that in fire r6 the extensions should be deprecated? Or is that just out of scope for us? Because we don't I
wouldn't try to address that as part of this topic. I think that I don't know, I don't know how I actually don't know how I think about that maybe so
in I haven't been, you know, involved in those bigger discussions. I mean, I think this is a great solution. I'm just, I'm curious when people say, Oh, the XML ref, or ID ref, you know, mandates that it must be to an ID attribute. And we say, well, when fire is in XML, this works great, because it obeys that rule. Is there, like an assumption or an allowance that if you're exchanging in JSON, this also works, even though, in that case, there is no ID element in an XML document, like the narrative itself, will would then be invalid because there is no ID attribute.
So here, there, so here, here's an example in JSON, here's the narrative block, and here's the ID ref. And if we look for this, it still shows up, so it's still there,
yeah, I mean, I agree it's there, and I think this works fine, but we keep pointing to this, this rule of what Id ref means, and we're sort of skirting around this requirement that there shall be an ID attribute in the document somewhere that matches it. I'm like, well, but not if you're there won't be if you're building a JSON. So is there any concern about that? Has there
been any solution only works if it's XML,
no, no, I don't. I mean, I mean, frankly, to be candid, I think most people are going to be doing this in JSON, because it's kind of the more common pattern that people are doing fire and, you know, IPS documents and things like that for it, you Benjamin, I kind of, I get your kind of idea, but then, you know, that kind of goes back to, you know, something you know, was a kind of design decision a long time ago from Graham in. Kind of the pattern that was adopted for ID ref internal ID references has been part of fire for for a while. So I think that until that base level guidance changes, because right that this, what you're saying, applies not just in the context of a document. It applies in the context of an individual resource as well, too. Yeah, yeah. So until, until any of that, that might be an interesting piece of feedback for, you know, the base fire, but I probably would say until the base of fire kind of picks a different convention. This seems to be the most logical thing to do within the context of documents. And
again, I'm not on our radar for our six feedback.
Yeah, I'll drop them. I'll drop a link to the what it says for internal ID references, and fire here for everybody, too. And
again, I'm saying, I'm not against it. I think it's great, but I just get a little squirrely when we say, well, we're doing this because the rules say, when you have ID ref, you shall have an ID somewhere. And this works like, well, but it doesn't work if it's doing JSON, so you're either skirting the rules
or, I mean, it's like, it's not really an, yeah, a
lot of fallacy in here. I don't know the name for it, but it's like, you're defending something with a rule, but then that rule doesn't apply. So
yeah, and that's that was, I'm
all for breaking the rule,
but I'm
missing something. Ben, can you? Can you say, maybe in a simpler way, why this is a challenge in JSON?
Because, if so, so my thought is that the first suggestion when, when someone said, Oh, use ID ref. Someone else said, Oh, well, you can't use ID ref, because there's this rule that if you have ID ref in XHTML somewhere, then the rule is that there has to be an ID element in the document. And then they said, well, as long as you're rendering this in XML, there will be and then everyone said, Okay, great. So we can use, well
actually it's a little bit more than that, because it's not the ID element. It's because there's gonna be an ID element. Yeah, you know, id attribute is specifically what's kind of needed there for the ID refor.
And the problem is, in JSON, you can't make an ID attribute.
I mean, Jason's not XML, so it kind of doesn't exist, but you're referencing it inside of, you know, X HTML. So then you're kind of like in this weird limbo state where there really isn't a definition for that in the context of a non XML document.
I mean, technically, then your XHTML block there is invalid, but so that I care.
This is also a little bit inaccurate, right? Because here, the ID attribute has to be unique within the resource. But, you know, correct me if I'm wrong, but in an XML document, the ID attribute has to be unique within the document. So it's a little bit of a follow the spirit of this guidance, but recognize that a technical implementation, there's a few nuances that weren't quite addressed here.
I think that there's a lot of improvements that could be made to even just clarifying because, like, the first time I skimmed over this and saw internal ID references, I didn't, wasn't thinking about narrative linking.
Bret, did you have your hand up?
You're good. Keep going, please. Okay, Bob,
what's the best way the PowerPoint that you were showing? Would that be attached into the minutes? Because I'm still struggling to try and even make this work in my stuff, I can't figure out how to do it, and I can't explain it to my engineers, because I don't understand yet myself how to do it. Who could help me get caught up?
Do you guys have exam? I mean, I'm just kind of pulling a few examples. I think examples will help MISA and others. Do you have both there? Okay, there's a link to examples in Jason,
these examples here, Brett, are these?
Okay, perfect. And then the and we also had some
examples from the fire connect a THON, too. I'm actually just going to bring that up and I'll drop that link in there. That's just a mic.
I think what I hear Lisa saying, though, is that, like, I don't, and I'm maybe there's a nuance here. Is like, I Benjamin keeps magazine is like concern, but maybe Bob take a crack at it. Dolin, you know, state stayed very clearly. The concern that you hear Benjamin stating that isn't sinking in.
Oh, well, yeah. I mean, technically, we're not really using XML ID, Id refs, and when you publish in JSON format, right? And so that's, that's a little bit weird. And then this sentence is a little bit weird because it kind of conflicts with a W, 3c, XML rule. Okay,
perfect. So it's like, we're using this, like JSON, xchml, to embed this attribute, linking to this ID thing. It's not really the same thing as XML,
I think so I'm going to study these totally. Will you guys be covering this at connect a THON? Because maybe I can come to your track and get more hands on experience. There we
have a, I think, a 10 no 11am session on Tuesday on IPS examples. And this would be a great topic if you want to come
in. Okay, thank you. I will.
So with the caveat that we would add the May. Idea about may use other IDs we had anticipated this is going to be in the next block vote, unless folks think that they want to play with it a little bit more, think about a little bit more. But after studying it, you know, you know, at least I'm comfortable with this. And then possibly we want to do something in fire our six to clarify that those paragraphs in fire core, is anyone uncomfortable with with this resolution? I mean,
I mean, I guess I feel more comfortable. I'm sorry, Bob, just like poke back for a second here. Do we have a corresponding tracker to improve that text in the base fire specification?
What we we don't right now, but what we had said we would do is, as part of ballot reconciliation, we're going to compile a list of things that we think might be things, targets in firearms, six we would present them to the committee, then committee members could individually take those and use them in their own balloting. And so this, this would be on that list.
Did Benjamin have a tracker on this? Well, we have a tracker on this one, but I thought that Benjamin also had something going I guess
I'm saying is like this would benefit, but I think we've spent, you know what, 30 minutes on this, and Lisa is going to talk about Yes, and like this is going to churn. And I think you put it in a list is awesome. But I think directly putting the tracker that you know, even if it's not fully baked, Bob just saying, hey, the text Manager ID preference is wrong. Here's three bullets why it's wrong. Please fix in our six and then linking it into this, I think would be beneficial to folks.
It would certainly elevate the issue Bob to have more pressure from multiple directions. And then the other stuff that you're doing that allow individuals to add perspective, all that will be good together. But I think we need, like an anchor ticket to sort of stick a stake in the ground here and say this is a spot that has to be improved.
Oh, okay, so you're saying, create a new jury ticket for this?
Yeah. So it's not on you to resolve it's not on you to chase Bob. It's more of like, you know, you're putting a pin that needs to be fixed and linking to it to at least capture the discussion. And you maybe Benjamin will do for, I don't know, just, just something to keep it clear,
you know, one of the things that we could do, Brett, if this works, is, you know, we were going to give you a list of, here's all the things for our six we could, you know, we could potentially create corresponding tickets for all of those that are on
And then people can reference those so that the like a the community response could center around these pins that you put in.
Yeah. I mean, that's even more than I was asking for Bob, and I would accept that, but that was
all right, so then the proposed resolution needs to have that stated on it. Is that right?
I mean,
okay, yeah, I can add that. Brett, yeah.
And to Brett, I guess my preference is that it's actually created and added to this tracker as like, in the comments section, or even in the resolution to say, you know, we recognize further work needs to be done to refine our six here's the tracker where that would take place.
Yeah, Brett. Brett asked me on the side for it, but there is a tracker that I've got in fire around ID, Id ref, but it doesn't have all the details that Bob said. So I think it would be maybe even good to have a have a new one for that. I'll drop that in chat for people. So there is something there in fire r6
as a decade. Okay, that's the 48338, yep. So basically, we'll link this response to 43348338,
yeah, and, but you might want to add another one, because honestly I didn't. I think Benjamin's brought up some you have brought up a good point about the contradictions, and Benjamin brought up a good point too. So it might be better just to have another one too. Okay, okay,
short of that, though, the proposed resolution, folks are comfortable this will show up in a block vote in two weeks, and then we'll make sure that we are also figuring out what we need to do with our six
I think this is great, yeah, I think it's great. Great progress.
Then this next topic. This is just a it's a big topic, but I would, I wanted to just, hopefully, in the next couple of minutes, just ask one question. So Hans's comments are basically challenging or raising the question, do we need a structured way to differentiate a fire clinical document from a run of the mill fire document. So while I may, as the document creator, say, You know what, I've decided that this is a fire clinical document, and I'm going to conform to the IG and I'm going to send it to you. When you receive that document, you're going to know that it's a bundle of type document. But you're not necessarily going to know that my intent was to create a fire clinical document. And so in discussions with the tiger team, the kind of the sense was, well, possibly the way that Hans had proposed, may not fly, but despite that, we probably do want to have a structured way to differentiate or to capture the intent of the Creator that that there's some way for them to assert that this, in fact, is a fire clinical document just not just a run of the mill bundle of type equals document. And so not to get into all of the details here, but I was kind of wondering if we could get a sense of folks. You know, do we agree that we need a structured way to differentiate those so that the recipient knows that the sender was sending them not just a arbitrary fire document, but the sender was sending them a fire clinical document, and then the technical solution for how we implement that, we'll come back with that solution. But this was just first, yep, we better figure something out, because we do need to be able to differentiate
and asserting the profile is not enough. No,
we felt that asserting the profile wasn't enough because of the guidance in FHIR core that servers aren't required to retain profile metadata. Got it? Yeah, and kind of sort of, we're leaning towards using a category, but I thought well before we get into the potential technical solutions, it'd be nice to know if we all initially at least agree that we got to do something, and at least the tiger team. The consensus from the tiger team call was, yeah, we should do something. Probably not what Hans is proposing, because that might be too radical. But So yeah,
anyone have any so, you know, my feeling is, yes, you know, we do need something, whether it's a category or something, anybody disagree with that?
I disagree with it being a profile, but Right? I just believe that, just like long standing knowledge in CDA, that the existence of template IDs inside artifacts does not have semantic meaning, and I, I'm, I think you're everything. I agree with everything else that you said. It's just, I just don't see those as complimentary alternatives. The having some sort of a coded, structural way of of encoding this fact is very different from saying, Oh well, we'll just assert a certain profile, and then, based on the presence of a profile, you'll know some meaning about this artifact. I don't think that's right,
okay, but I mean, at least in general, we do agree that we need a structured way to differentiate them, and we'll keep