FHIR managing profile identification

(extract from Skype, 23rd of may 2012)

• EK: I have been thinking about conformance and profiles and the way we use it both for a) asserting that we conform to the constraints set out in a profile when we communicate a resource and b) as a kind of label on (a group of) resources that is used to add semantic meaning not explicitly present in the instance data. We shouldn't use b). Grahame talked about this when he said he wanted to query resources based on their stated conformance. The problem is that I believe conformance is really a promise between sender and receiver at the time of communication. Resources may lose their conformance at any time after they have been received by a system. Most obviously, this happens when a resource is subsequently changed. It might not conform anymore, unless we enforce the rules of the stated conformance before we allow a change. This means that once a resource has a stated profile in a system, it can never be changed anymore to not conform to that profile. And I don't think we want that. It seems like conformance to a profile is bound to a specific version of a resource, but is not a long lasting thing. Maybe that last statement is a question: "do we want that?". So: If a resource conforms to a profile, can we change that resource so it does not conform to that profile anymore?
• GG: well, clearly you can do that. but also, clearly, you might not want to do that. If you change a resource, it's profile conformance needs to be re-assessed.
• EK: Well, there's two ways we can do that: the receiving system must check that, or the changer must restate the profile conformance when sending the change.
• GG: we agreed that profile id is associated with a resource as a computational convenience right? Well, if the server merges the source when it gets an update - rather than replacing - then it would have to reassess conformance. and the client might be lying anyway right? But we can't solve all these problems. We mustn't try to. If we do, we'll end up like v3. In this area, we are provifing a framework, not a solution.
• EK: All we have to do is not use conformance to add semantic meaning beyond what is in the instance of a resource. If you do, you might want to use this conformance statement to query resources. For example you might want to query for lab reports conforming to the lipid profile. But since we made it explicit in the instance as well (Labreport.name) we don't need that profile as a semantic label. So we can use conformance only in the context where it seems to make sense: to declare conformance for communication.
• GG: well, there's a way around this. you do what we did in Australia for CDA. We keep all this conformance stuff right out of the CDA document. you put a code in every instance. You say that the conformance profile always identifies itself with a code. The code is fixed - the intent of the resource. I think this is not a scalable solution to the problem. Not so much because there is many templates for meaningful code, but because there are many resources for which there is no logical code, and the code <-> conformance relationships collapses, and you haven't gained anything. And I want to call attention to something that you said that is dangerous: "not use conformance to add semantic meaning beyond what is in the instance of a resource" - which is the absolutism of v3 - and we have to let people do exactly that - the wrong thing - mix semantics and conforrmance, because that's what they know how to do. What we have to be careful of is to not prevent people from doing things properly.

One thing I'm considering, btw, is to add a little to profile to allow it provide definition - meaning - as well as rules. This is both very dangerous and very powerful, because then it will lock in that conformance provides meaning, except it is not meaning. It is definition of course, this violates the precepts I have put above. But if I don't, there will be lots of proto resources providing meaning that also provide rules as part of that meaning.

• EK: You said "We keep all this conformance stuff right out of the CDA document. you put a code in every instance. You say that the conformance profile always identifies itself with a code. The code is fixed - the intent of the resource" I think this is what I was saying: if a Resource can be categorized and this categorization is important enough to query on (thinking about the lipid labreport agin), put the category in a resource using a code.

But you mention you tried this in practice and it breaks down. Because even though you have a relevant resource categorization of some sort, there is not always a natural way to code this into the resource. So you require the use of a profile to provide a categorization that is not apparent from the data. Is that a correct formulation? Can you give an example resource where this fails?

I said "not use conformance to add semantic meaning beyond what is in the instance of a resource" This might indeed be a bit too strong. I do not believe the absolutism of v3 that the instance provides all you need to interpret it. You need the definition on the Resource page too. You need the "definition" column in the Profile too. I really wanted to state what I have restated above: if you have to query resources based on their profile, I (for now) believe that you should add something to the resource to do that query on instead.

• GG: the problem is the many <-> many relationships between semantics and conformance rules, or codes and profile ids. A single profile id covers multiple codes, and a single code covers multiple profiles. Profiles can be though of as semantic denomalisations. As for the code problem, lets assume that you have multiple profiles for person. Now, you're going to put a code on person for the kind of person...wait, the role of the person? What coding system are you going to use? snomed and loinc etc are no help. You're going to make your own up.... might as well use profile id
• EK: Now, back to this update problem. You said: "we agreed that profile id is associated with a resource as a computational convenience right? Well, if the server merges the source when it gets an update - rather than replacing - then it would have to reassess conformance. and the client might be lying anyway right?" I think what you're saying is: the profile is just a label. Which means that a conformance statement would degrade to saying "This instance once conformed to a profile, but might not anymore. Or maybe has never". Indeed the client may be lying. The server might be reckless and not validate. There are no guarantees. But under normal circumstances the client knows what it is doing, and the server will validate when receiving a resource associated with a profile. Luckily we never have merging to do: a resource is treated as a whole and conformance is stated on a per-resource basis. Aggregation profiles define what resources are in the aggregation and which profiles are relevant for each included resource. So per-resource.

Now, my update problem boils down to this: A client is sending a resource with an associated profile. And then that same client (or another) is sending a changed version of that resource. But now there is no conformance statement anymore. What to do? I think logically the task is up to the client to state conformance and the server to check it. So if the client sends an update without stating a profile, the instance loses its conformance.

Consider these scenario's: There is a labreport with a lipid profile, and then there's an update adding a non-lipid result. Scenario 1) the client acknowledges this and drops the conformance and changes the Profile.name. It will no longer show up in your queries searching for a lipid labreport. 2) the client drops the conformance but does not change the Profile.name. You will still find the labreport based on its name, but it conforms no longer to the lipid profile (correct). It is logically incorrect (because of the name) but no rules are broken c) the resource keeps the conformance (because of the client or server). You can still find the resource on its name of profile, but both will actually have no relevance to the real situtation anymore. What would we prefer?

• GG: actually, discussion with Lloyd earlier on the subject, we verred towards and profile set id - but if you make it a profile category id, then maybe this is the thing. Well, the server can find out whether the updated resource still meets it's profile, the right thing would be for it to drop the profile link, or to reject the update the client claimed it conformed. The problem isn't testing a resource against a single profile, the problem is testing a resource against all known profiles.
• EK: The person example is a nice one. Now it looks like we are moving to a kind of "categorization" profiles. Which are empty profiles, like flag interfaces in Java. You'd have true conformance profiles which must be (re)stated by a client and revalidated by a server. You'll have categorization profiles which stick, whatever update is done to it.
• GG: Well, that wasn't what I had in mind. I had genuine conformance profiles in mind, but yes, you could have flag ones. Though I don't think I've seen them anywhere in the community, we still use codes.
• EK: I think you are saying that requiring a client to restate conformance on update is not a solution, because the resource may conform to other profiles that a client is not aware about. But we also agree that the server cannot possibly recheck al the instances and be actively involved in maintaining the list of conformance statements.
• GG: I think the client could do that - restate conformance on an update.
• EK: Some of the statements present might not be known by the client. So it cannot restate them after changing the data, since it could then by lying. The empty profile might be a solution for categorization of persons, where there is no natural coded field to do the categorization.
• GG: perhaps, but that brings us in a circle, does it not. by this logic, the profile is clearly data.
• EK: Yes. I feel conformance statements have to aspects: the "rule" part, which we can computationally verify and restate, the "meaning" part, which can only be stated by a client because it knows what the data is. But I am curious for the others to react. And see their answers.
• GG: the thing that I found doing the definition part of the assessment scale - it's a profile - the rules - with meanings why. Which I found appealing connected to my RDF problem. The RDF things I have seen have simply been a restatement of the rules, without, so far as I can see, the meanings
• EK: RDF (or rather OWL), states the rules by which you classify instances. It would never give "validation errors", instances would simply no longer classify as an "assessment scale" if you "break" the rules. So it is defining a classification, not the meanings of the fields in an instance.
• GG: right. so I thought. But the fragments I saw in Vancouver had the same kind of information as the class models - but why?
• EK: Actually, any OWL spec of the RIM just says: "If some thing has a 'code' and a 'value' and an 'effectiveTime' and...and.. and.... then it belongs to the class of Observations". But you can go on saying "Any Person with an administrativeGender of 'M' belongs to the class of MalePersons'
• GG: right, it seems as though the follow up stuff that it doesn't say are the things that are interesting about it
• LM: I'm going to throw something else interesting into the mix: Profiles can declare constraints based on "concept domain". But different locations might use different codes for the same concept domain. So a given instance is a valid instance of a profile in one system and not in another system even if the instance hasn't changed one bit. On the other hand, using templates for query is most commonly used for observation results - where there's a wide variety of possible results, but they're almost never updated and it's also rare to throw away information received. In those cases, querying by profile is perfectly reasonable.

I think we make the statement that systems may only persist a profile id if they persist a resource unchanged or if they're capable of validating that the profile still applies with the changes. If we do that, then profileId as queriable metadata is safe and it can easily be used for the typical use-cases without introducing the danger of retaining profileId even after data has changed.

• EK: Agree that keeping profile id on a resource must mean that the instance still conforms to that profile. So, you either lose it when you cannot guarantee, or you should actively verify it. It is hard for a client to verify all statements of conformance. It is possible for a server to verify all statements. It might induce unexpected behaviour however: a client and a server have been happily working together. For some time this client has updated a Person resource without problems. From one day to another this fails. It turns out that inbetween another client has also updated the person resource, and has added additional profile conformance statements that our first client is not compatible with. This conformance statement must now be removed before our original client can continue to do its work.
• LM: That's a circumstance where the server does a merge instead of a proper update. Which is risky at best. And if it's doing that, the server accepts the responsibility of deciding what profiles to keep. It shouldn't reject the inbound instance.
• EK: I don't know if it's a merge: the client that came "in between" could just have updated the metadata so the list of conformance profiles includes this new profile.
• LM: If a new record comes in that doesn't specify those new profiles and the server attempts to applly them anyhow, that's a merge.
• LM: If the client queries the record and applies changes and doesn't validate that the profiles identified on the old version still apply before resending them on the update, that would be non-compliant.
• EK: That's why the original client failed. The resource that it was able to modify happily for weeks, is now suddenyl enriched with a new profile conformance statement it dit not know about. It cannot verify this new profile and there fore a) cannot change the resource anymore, b) drop the unknown conformance assertions or c) post it anyway and receive a server validation error.
• LM: It does (b). That's the expected behavior. And if you're doing updates in that sort of environment, querying by profile is not going to be terribly useful.
• EK: No, querying is going to be terribly unreliable.
• LM: You'd either have to require that all clients supported validating the "relevant" profiles as part of your agreement to talk to them, or you wouldn't allow updates. Querying will be highly reliable - for the right things. A profile on a blood pressure will be fine. No one will ever update the record Other than perhaps the original source system). Same thing for lab results. Or creating a referral.
• EK: Well, that is true.
• LM: Or any kind of document. And those are the places where profile/template is typically used for query. You *don't* see it done for Person or Allergy or other records that are typically updated by many systems. If we enforce the rule I identified, then query by template will work fine for the places it has typically worked fine in the past. It'll work badly (but predicatbly and safely) for the places it isn't typically used.
• EK: Well, Grahame specifically gave an example for Person as having no natural way to categorize them except for by profile. And labreports and observations on the other hand will generally have a natural categorization by code. Unless we envision that profiles are also used for tagging like 'put profile X on an observation if we want to flag it as deserving immediate attention'.
• LM: Blood pressure has a LOINC code (4 or 5 actually). But probably 30+ profiles. Profiles tell you how much extra stuff you capture, what units you use, etc. Profile for "Person" is a different beast. It's not typically done now. But right now we have CMETs that enforce the constraints. And I presume the same thing will happen with FHIR. Your aggregation profile will tell you what you must send or can't. And as sender, you'll *have* to support that profile if you want to talk to the server.
• EK: So, I said: "Now, my update problem boils down to this: A client is sending a resource with an associated profile. And then that same client (or another) is sending a changed version of that resource. But now there is no conformance statement anymore. What to do? I think logically the task is up to the client to state conformance and the server to check it. So if the client sends an update without stating a profile, the instance loses its conformance." True?

Or

"You'd either have to require that all clients supported validating the "relevant" profiles as part of your agreement to talk to them, or you wouldn't allow updates."

• LM: yes to both.
• EK: Which means that the client may drop a conformance statement it doesn't know about during an update. It depends on the server configuration (which is static) for that type of resource whether it will still accept that resource if it is not carrying the statement.
• LM: right. Or not complying with it. It has 3 options - reject instances that don't declare profile X, reject instances that aren't valid according to profile x, or accept whatever.
• EK: Right. The last case meaning that it accepts unprofiled Resources, which just have to comply with the base FHIR specification.
• EK: So, also true: "The problem is that I believe conformance is really a promise between sender and receiver at the time of communication."
• LM: Sometimes.
• EK: Only thing wrong is that it is not a problem. Updates may result a resource to lose (part of) its conformance statements
• LM: Sometimes the receiver doesn't care about the profile. But other retrievers will.
• EK: Yes, but if a) the server allows it and b) the client doesn't care or know about the profile then probably the resource will lose that conformance statement
• LM: Depends on the type of resource.
• EK: Does it depend on the type of resource because the server has its conformance requirements defined per resource, or do you see a clear distinction between the types of resources which naturally will mean the way profiles are handled are different?
• LM: The division is essentially: Is this resource likely to ever be updated by someone other than the creator?
• EK: But do you whish for us to define the treatment of conformance profiles (e.g. losing them on update) per resource in the FHIR spec, or is this something you configure in the conformance statement of your specific FHIR server?
• LM: You don't configure it at all. And we certainly wouldn't define it per resource. You just follow the rule of "if updating a resource, you only include the profiles you know to remain true". If a sender of a lab result declares profile X, and they subsequently revise the result, they'll know whether to continue to declare profile X. So that use-case works just fine. If the server requires "Identified contactible Person" in the aggregation profile for a message, then it'll validate the instance to ensure it conforms to that, regardless of who it gets the data from. So that use-case works just fine.
• EK: I think we're saying the same thing. Only you are looking at it in practice, and I am looking for the corner cases.
• LM: In the corner cases, profile information will get lost. But that's driven by system capabilities, not the FHIR design.

(Extract from Skype, 26th of june 2012)

• JD: i have a question about profiles - is there an intent that they be used at runtime for validation purposes or query purposes? Can I receive a resource that states it conforms to a specific profile at runtime? I can see how, at design time, I can state that I need resources that conform to a specific profile. But is there some purpose of stating that in the resource instance?
• GG: First yes, of course you can do that
• JD: i can't see how - the resource metadata doesn't contain the profile definition.
• GG: Second, no, theres no way at present to claim that you conform to a profile. We had a long discussion about this earlier
• JD: ah, so your "yes" was that I could profiles for validation purposes.
• GG: We generally agreed that you need to be able to do this - to save a server having to check all the possible profiles to see what you conform to - so its a computational shortcut. But we couldnt agree whether it was in the instance, or metadata. And we couldn't agree whether more than one was necessary. So it's unfinished business. Yes, you can enforce conformance without having the profile explicitly declared in the instance.
• GG: The use case for (a) not knowing which profile should apply and (b) needing to force compliance anyway... What is that?
• JD: our use case is that we have three different uses of the Person resource and thus three different Resource Profiles. So when you send a Person resource, we need to know the profile that you're conforming to, so that behind-the-scenes, we can a) verify that it conforms to the stated profile and b) know what purpose we can use the given resource. A Client resource profile is different from a Relation resource profile, but they are both Persons.
• GG: So why do you need the resource to actually declare that? Why not jut find out for yourself if it conforms?
• JD: i guess I'm missing the point of the Profile actors in the connectathon then. Why would I go looking up a profile from some other server unless it was to get the profile definition so that I could then do validation or something with that definition? So the declaration of the profile is not a computational shortcut, but rather a means to provide further information to the server.
• GG: But what further information? You haven't answered the question about why you care about the profile if you didn't already know about it. The point of the profile actors is that you can get the profiles and reason with them. You're making an extra link - that the resource has t declare what it conforms to so you can do that, and I'm not convinced. The only use case I know where its useful is in infrastructure provision, where you want to make routing/retrieval decisions about the resource, and you don't care what profile it conforms to, but the decisions do. I.e. subscribe to all updates involving haem lab tests.
• GG: Ewout has argued that it should therefore be metadata, but hasn't proposed metadata locations for it. And I think we could put it in atom, but I don't see it going in http headers anywhere
• JD: but why do I want to get the profiles? of what possible use is that to me?
• GG: Design time.
• JD: hmm, then why does the Person Demographics Author also have to play the Profile Consumer role?
• GG: Ummm, you think that the connectathon actually has to make functional sense?
• JD: yes?
• GG: Actually, I think of that work flow like this- I'm an author, I'm going to submit my instance to a server. I ask the server for its Conformane profile.
• JD: the system that we're building will support the Person Author/Consumer/Server actors and LabReport Server/Consumer actors (possibly the LabReport Active Tracker except that we may not get enough time to implement this). We see no reason to support the Profile Consumer actor.
• GG: This identifies a resource profile it supports. I retrieve the resource profile from a server, and check that my resource conforms to it.
• JD: but what if it supports multiple profiles for a given resource?
• GG: Well, so what?
• JD: then your workflow doesn't make any sense
• GG: I'm sympathetic to not needing to support the profile actors. Rene just wanted them supported.
• GG: How doesn't it make sense?
• WB: What the "sender" knows, and the "receiver" needs to know is not whether it conforms, but to which profile ("kind" of resource) it is intended to conform. Then its "purpose" as Jean says can be known.
• GG: Ahhhhhhhh. See, this is the problem. A profile is a a statement of constraint, not a statement of purpose. I believe that you are confusing two very different notions. I don't need a resource to tell me what it conforms to - I can find that out for myself. This is much more robust. But if you're carrying higher order meaning,.... That's different. But don't do it by profile declaration. No
• JD: actually, I started out with that (requirement that you tell me the purpose of the resource), but I see how that will work without. You send me a Person resource and I go through my list of profiles to see which ones it conforms to. I then note that in my resource store. Then, later on, when you send me a reference to a Person and I've stated in my implementation guide that it has to be a Person that conforms to the Relation profile, I can verify that. But I've done that all on my own. Since you can't tell me - at runtime - what profile you're conforming to, there is no way or even need for me to know about other profiles besides my own. I don't have a use case for that requirement, so I'm fine with that. :)
• GG: What do you mean, I can't tell you? Of course I can
• JD: how? we just agreed that, right now, there is no way to indicate in the resource instance, what profile it conforms to.
• GG: No,not in the instance, but you can ask the system. You still haven't described an actual reason why the instance should declare what it conforms to, other Than that the connectathon implies that it can.
• JD: how do i ask the system? and i'm fine with not declaring the profile. but we need to fix up the connectathon, since my system will not have anything to do with the profile actors. We have no mechanism for me to ask the system what profiles it supports for a resource type nor what profile a given resource conforms to
• GG: conformance statement. there is a mechanism - look at conformance statement - it connects a system to functions. You can see my one here: https://hl7connect.healthintersections.com.au/svc/fhir/conf?format=text/html. Or you can get it as a resource by doing an http options on here: https://hl7connect.healthintersections.com.au/svc/fhir/. And you can update the connectathon page, but it's not like we're going to be issuing genuine pass/fail things at the c-a-t
• JD: ah, we hadn't made it to conformance yet. we need to update the c-a-t page to pull in conformance into it. i can see using that in a generic sense like service discovery.
• GG: right
• JD: a new question - can i create a profile on a resource that states the profie that a contained resource must conform to? i.e. a Patient profile that not only restricts the subject element to a Peson but to a Person with a certain profile?
• GG: yes, in your profile, you can reference another profile
• JD: ah, i just saw how.
• GG: k. You can also put it in the same profile - a profile that constrains both patient and person
• GG: * I know that we'll need to be able declare conformance to a profile for an instance. * I don't know whether that means *in* an instance
• I don't know whether more than one * I think that there's the ulterior motive of declaring purpose, and I don't want to overload the use