Stream: implementers
Topic: maintaining sequence of repeating fields
Simone Heckmann (Nov 04 2016 at 20:40):
Since the Thread about modelling HumanName.family got pretty long, I'd like to branch out to ask a question that came up during the discussion.
If a family is being split up into repetitions of the family element,
e.g. "Graf von Dracula" were to be represented as
<name> <family value="Graf"/> <family value="von"/> <family value="Dracula"/> </name>
is it safe to assume the sequence of the element reflects the correct sequence to display/reconstruct the name?
is it safe to assume that the correct sequence will be maintained when flipping from XML to JSON and back?
is it safe to assume that all systems/tools/parsers will read the elements in the same order?
Grahame Grieve (Nov 04 2016 at 20:42):
what we say is:
Grahame Grieve (Nov 04 2016 at 20:45):
When an element is allowed to repeat, the elements are ordered, and implementations must preserve order (note: the meaning of the order may not be known)
Grahame Grieve (Nov 04 2016 at 21:01):
there's a task in the system to clarify this to the effect that applications are not required to preserve the order, but that the order is potentially meaningful and changing the order may represent changing the meaning, and applications are responsible for that
Simone Heckmann (Nov 04 2016 at 21:04):
Ok, thanks!
Marc de Graauw (Nov 05 2016 at 13:16):
@Grahame Grieve wrote:
what we say is:
When an element is allowed to repeat, the elements are ordered, and implementations must preserve order (note: the meaning of the order may not be known)
In general that is right. However, when a resource contains a sliced list of Observations (say a DiagnosticReport contains a list of 1..10 test results with some LOINC code as discriminator), it may be unrealistic to expect a system which stores the Observations in an (existing) relational dbms to be able to retain order on reserialization. Same for order in batteries or panels of tests. Making this a MUST could mean that existing systems which cannot retain order can't be FHIR compliant w/o db redesign.
Lloyd McKenzie (Nov 06 2016 at 15:01):
We're not forcing systems to retain order. We're saying they're responsible for the consequences if they don't. So if you receive a diagnostic report that claims conformance to a profile that requires ordered slicing and you throw a way the order of the referenced observations, then when you subsequently expose the report, you're going to need to also throw away the declaration of the profile (or you're going to be exposing a non-conformant instance, which means your system is non-conformant).
Marc de Graauw (Nov 06 2016 at 16:55):
Sounds good. Practical and flexible enough.
Elliot Silver (Nov 07 2016 at 22:06):
Hmmm.
Case 1) A client system creates a resource which contains some order-sensitive elements, and saves it to a server, later retrieves it, and operates on the order-sensititve content. The client has no way of knowing whether the server reordered the elements.
Case 2) A server recieves a resource tagged with a profile, and stores it. The server saves the resource without further processing, and thus leaves the unknown profile tag on it. When it returns the resource to a client, the order of the elements has changed. The server wasn't aware that the profile required maintaining order.
The first case just seems dangerous. The second case changes my understanding of profiles. I had thought that a server could accept profile-tagged resources even if it didn't know the profile -- they were be a statement by a client that the content of the resource met certain requirements (and could be found by other clients that way), not that they would impose restrictions on the server.
Grahame Grieve (Nov 07 2016 at 22:32):
Elliot - in a perfect world, we would be able to make stringent requirements that made all behavior predictable. but doing so would exclude all existing EHR systems, which have real world constraints to deal with. From where we are, it would be a big mistake to change that. but it would certainly be good to document some of the limitations you're identified more clearly - can you create a task?
Elliot Silver (Nov 07 2016 at 22:39):
The first situation I accept, and agree that documenting it better should be sufficient.
The second seems troublesome. It implies that a server cannot safely accept a resource unless it knows the profile it has been tagged with. This defeats a certain amount of the usefulness of profiles for client-to-client communication.
Grahame Grieve (Nov 07 2016 at 22:49):
it implies that there might be trouble if (a) the server doesn't know the profile and (b) the profile implicitly assigns meaning to the order (bad) and (c) the clients don't know about it.
Elliot Silver (Nov 07 2016 at 22:52):
Is there a need to be able to declare support for ordering in the conformance? Or an equivalent of "mustUnderstand" for profiles? (Don't accept this resource unless you can support the obligations of the profile.)
Grahame Grieve (Nov 07 2016 at 22:53):
there's Resource.implicitRules. You're straying into that space
Elliot Silver (Nov 07 2016 at 22:53):
GF#12331 added.
Grahame Grieve (Nov 07 2016 at 23:00):
thx
Lloyd McKenzie (Nov 08 2016 at 03:03):
@Elliot Silver If you're going to change an instance in any way (including throwing away order), you ought to throw away all profile declarations you don't recognize. (Just as when you change an element containing an unrecognized extension, you ought to throw away the extension. And if you edit a resource, you should re-generate the narrative.) You should only retain unknown elements in an instance if you're relatively certain you haven't made any changes that could invalidate them.
John Moehrke (Nov 08 2016 at 14:44):
@Lloyd McKenzie that rule seems just as dangerous as one that keeps extensions and profiles that you don't understand. Should this be a runtime policy, not a core-standard policy?
Lloyd McKenzie (Nov 08 2016 at 14:51):
How is it dangerous? Removing profiles is always safe (if sometimes inconvenient) because profiles can't add any meaning to an instance - you can always test the data against a profile and re-assert it later. And extensions are always ignorable - systems can't have any expectation a receiver will retain any extension (or even any core element).
John Moehrke (Nov 08 2016 at 14:54):
So you re only applying that rule when receiving data and storing it locally? I would agree in a case where data is being transfered from one custodian to another custodian that this rule might not be dangerous. It certainly will mess with the 'integrity' of the data (so medically it might not meet records retention integrity). I thought you were expressing a use-case where a client retrieving current resource, changes that resource, and updating the server with the new data.
Lloyd McKenzie (Nov 08 2016 at 14:57):
It's not about storing. If I query an instance and then update an instance, the same principles apply. I'm responsible for the truth of the new version. So if there's content in the instance I don't understand that may have been rendered untrue by my update, I can't assert that it's true when I submit the update. (The server is, however, free to choose to not remove data I've removed in my instance and/or to re-assert profiles or assert new profiles that I haven't declared in my submission.)
John Moehrke (Nov 08 2016 at 15:56):
so is it a requirement that the are removed? What if I am a simple phone-number updating UI? I am only responsible for phone number within Patient. I am not aware of anything else and am happy to leave everything else alone? Again, I ask that this is not a core-requirement to remove extensions and profiles that I don't understand, but a recommendation with clear pro/con discussion.
Lloyd McKenzie (Nov 08 2016 at 17:38):
We haven't documented as a requirement, though I can't think of a reason why it wouldn't make sense to enforce it as a requirement
Elliot Silver (Nov 08 2016 at 18:31):
@Lloyd McKenzie "change an instance in any way (including throwing away order)": but I'm going to argue that this isn't a change. I would have thought a "change" means a change to an element value (or add or remove an element). Does modifying whitespace outside of a value also constitute a change?
Lloyd McKenzie (Nov 08 2016 at 20:11):
@Elliot Silver Order is always significant - changing it is a change. There's a proposal to differentiate which elements order is significant for. If we accept that, then most orders will drop to non-significant, but dropping a "significant" order would still have to be treated as a change - it changes the meaning of the instance.
Elliot Silver (Nov 08 2016 at 20:37):
OK then, I think the summary is: Order is significant, but systems aren't required to preserve order. If a system can't guarantee it preserves order, it has to treat the resource as changed. If a system changes a resource, it has to throw out profiles which it doesn't know are still valid.
Regardless of a profile tag, if a remote system has given content to my system, it is implicitly asserting that the order can be treated as meaningful, and "assumes liability" for the order of the content (whether it has preserved the order or not).
Grahame Grieve (Nov 08 2016 at 21:15):
"If a system changes a resource, it has to throw out profiles which it doesn't know are still valid" - I'm not sure about "has to" in that sentence. Should... is advised to... probably a good idea... but has to has no grace, and we don't know what all the ramifications are...
Lloyd McKenzie (Nov 08 2016 at 22:24):
I'd say "if it doesn't, it's at risk of producing non-conformant instances". Sometimes that's a risk a system is willing to live with. (And the corollary is just because you see an instance declaring conformance with a profile, that doesn't mean you should trust the declaration without verifying)
Thomas Lukasik (Nov 10 2016 at 02:02):
As I'm reading through this thread, I can't help but wonder how many implementers -- other than a handful of veteran FHIR list server and FHIR chat denizens -- will ever be able to build correctly behaving FHIR clients and servers.
Who is going to know (or even think that they need to know) stuff like: "If I query an instance and then update an instance, the same principles apply. I'm responsible for the truth of the new version. So if there's content in the instance I don't understand that may have been rendered untrue by my update, I can't assert that it's true when I submit the update. (The server is, however, free to choose to not remove data I've removed in my instance and/or to re-assert profiles or assert new profiles that I haven't declared in my submission.)"
I'm not trying to be negative or a downer -- it's just a realistic concern based on experience with countless HL7 bespoke interfaces over the past 20 years.
Grahame Grieve (Nov 10 2016 at 03:51):
that's why I pushed back against mandating behavior here.
Grahame Grieve (Nov 10 2016 at 03:52):
but I think you're being overly negative - you can be sure that most programmers who do interop have run into order/sort issues, and have had it's importance hammered into them in the most painful of ways
Elliot Silver (Nov 10 2016 at 17:15):
Another issue around sequencing is that a system which does not maintain order, (a) must use a different version number for each retrieval of the resource, and (b) cannot provide history, since there is no way to guarantee that (a) two retrievals, even if the content is otherwise unchanged, will have the same order of contents, and (b) you won't be able to guarantee the order of previously returned content is the same.
Thomas Lukasik (Nov 10 2016 at 18:38):
"..but I think you're being overly negative"
And I might accuse you of being overly optimistic, @Grahame Grieve ;-)
This sort/order related conversation is just one of countless similar threads that raise the same concerns when I review them. But using just this one case as an example, without access to this kind of guidance, is the average developer expected to intuitively implement the correct behavior that @Lloyd McKenzie described? Or are they more likely to just do whatever makes sense to them -- which may be based on good practice, but colored by their individual experience and/or site specific thinking?
Of course, if we tried to retro-fit all of this vital implementation information into the core FHIR standard specification it would not only camouflage the critical specification details, it would also expand that documentation a point where it would become unusable.
The only remedy I can think of for this would be to parse out and capture the conclusions, lessons and guidance that gets buried within all of these deep chat and list server conversations, and compile them into a comprehensive and highly indexed "living" adjunct resource that responsible developers can reference quickly and easily.
And yeah.. that would be a huge and perpetual task, but IMHO, if we don't want to see FHIR implementations devolve into an HL7 v2 situation, where "if you've interacted with one FHIR server you've interacted with one FHIR server", then I think we'll need to do something to prevent that from happening other than simply expecting developers to do the right thing because they can or should be able to.
That's not negative at all.. it's just being realistic.
TJL
Grahame Grieve (Nov 10 2016 at 19:05):
Elliot: you've jumped from 'can't maintain a particular order' to 'can't maintain any order'
Grahame Grieve (Nov 10 2016 at 19:05):
that's quite a big jump indeed.
Grahame Grieve (Nov 10 2016 at 19:07):
Tom, well, as I said, I agreed that it is too much, but it's an issue that does come up. and you're right about the problem. FHIR is a *interoperability* solution, and such, will always be imperfect. We do what we can
Elliot Silver (Nov 10 2016 at 19:32):
@Grahame Grieve Ok, I'll give you that it is a jump, but I'd say it is a subtle one, and a distinction likely to be lost on many developers (including myself until you pointed it out). Isn't it better to provide guidance or normative language to avoid cases like that?
Thomas Lukasik (Nov 10 2016 at 19:59):
@Grahame Grieve .. we probably need to take this sub-conversation to a different thread, or offline, but I just wanted to say one thing more.
RE "FHIR is a interoperability solution, and such, will always be imperfect." <= Of course you and I and 100's of other folks that are in the trenches know this well. But unfortunately the hype surrounding FHIR has set the expectations of Healthcare IT executives (and even IT folks who are yet to engage with FHIR) in a way that never happened with v2.x -- so that reality is going to be more highly visible and have a much greater impact that it did the last go-around.
Can we avoid that completely? Probably not. But I believe that we can reduce or minimize the problem by taking a few steps to free the knowledge and information that emerges 24/7 from these ongoing conversations and package it in a way that developers (a/k/a implementers) who are new to FHIR have a fighting chance of not making terrible mistakes simply because they haven't been privy to the chatter over the past 4 or 5 years. There's a ton of seminal information hidden within that chatter that should be digested and made available to developers, which IMHO could greatly improve consistency and compatibility between FHIR implementations.
Lloyd McKenzie (Nov 10 2016 at 20:13):
@Thomas Lukasik There's nothing stopping anyone from taking on such a task if they want to (other than how daunting it is), but it's beyond the bandwidth of those who are currenly eyebrow deep in developing the spec.
Thomas Lukasik (Nov 10 2016 at 20:19):
I agree with all of that, @Lloyd McKenzie.. but I think that it could make a significant and positive difference in the quality and acceptance of the resulting resource if the undertaking were somehow recognized, sanctioned, reviewed and/or otherwise under the purview of the HL7 FHIR community. That's the only reason that I've burdened this discussion with my thoughts. I was hoping for others to chime in with theirs -- as you have.. thanks!
Lloyd McKenzie (Nov 10 2016 at 20:25):
Well, I'd say the order of operations is: 1. someone starts throwing something together; 2. the community looks at it and says 'this looks good, we bless the effort; 3. The content hits a point where a review is appropriate/warranted; 4. We try to figure out how we're going to maintain the thing now that it exists . . .
Grahame Grieve (Nov 10 2016 at 22:02):
I'd certainly love to see this happen, and have even tried to raise money in the past for someone to have exactly this role. But money is hard to come by, and getting harder
Last updated: Apr 12 2022 at 19:14 UTC
