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

(extract from Skype, 5th of september 2013)

• Josh Mandel (JM): But the real I'm really worried about is profiles :) Is there a mapping between profiles and RESTful URLs? Or how do I say "get me all diagnosticreport resoruces that conform to the Cholesterol Panel profile"?
• GG: do you mean, get me all the diagnostic reports that do conform to the cholesterol panel, or do you mean, all the ones that claim to?
• JM: Let's start with the latter. Seems easier.
• GG: why would you care? Why not get all the ones with the right loinc code?
• JM: Well, I want 5 LOINC codes, and I want the right units, say. It's a way for me to declaratively state my expectations about the payload. Otherwise my client has to check and convert units on every value -- whereas if the profile fixes the units, I shouldn't have to worry about them. (Units are a pretty trivial example, but they make the point as well as anything.)
• GG: well, we could define a search parameter that specifies the url of a profile the matching resources have to conform to.
• GG: not that I'm in any hurry to try supporting that on my server
• LM: Well there's two possible behaviors there:
• LM: - I give you nothing because none currently comply (even though I have relevant data), - I don't recognize the profile so I give you nothing
• JM: Haha. Yeah, but that's a fair start. Another missing piece, which would be easier (and maybe already exists): how do I say, when I return a result, which profiles it claims to fit?
• LM: - I convert the data to the profile (that's 3 actually)
• GG: why would you make any claims at all?
• LM: I suspect you want #3, but not sure many servers will be enthusiastic about undertaking that on behalf of arbitrary clients
• JM: What's the point of profiles if you can't declare comformance to a profile and you can't ask for data that fit one?
• JM: When I fetch a report, if it claims to fit the "Cholesterol Panel" profile, I'd like to know it so I can treat it as one.
• LM: Choosing what systems to purchase? Conformance testing?
• GG: what difference does declaring a profile make?
• JM: Maybe I have a special viewer for those. and I want to route each diagnosticreport to the appropriate visualization. I mean, what do *you* see profiles as being good for?
• GG: the server can validate a reosurce against a profile. so can the client. there's all sorts of non-runtime uses for them, but let's focus only on the runtime usage, yes?
• JM: How does the server know when to try? Is there a way for the client say at POST time that it's posting a "Cholesterol Panel"? Yes, runtime.
• GG: why would any claim that the client makes be meaningful to the server?
• LM: Uses: Servers can identify what data they'll accept, defines "good practices", used in RFPs to define desired behaviors, etc.
• GG: should the server trust the client?
• JM: jcmandel: Not trust! Just a hint.
• GG: hint for why?
• JM: So let's say a server has 1000 profiles for diagnossticreport and the client POSTs a new resource that happens to be a Cholesterol Panel. Does the server just try all 10k and see which ones fit? er, 1k
• GG: wel, it could. but that claely wouldn't be practical on a production server
• JM: Right.
• LM: What likelihood is there that a given client posting data will have any awareness of what profiles you care about or will bother to assert them?
• GG: so the client tells it which on. it's more than a hint then, the server must trust....
• JM: I was imagning that, in real FHIR implementations, most things would be profiled. The base resoruces leave so much optional that I can't see things any other way.
• GG: actually, the server can index the profiles, and know which ones might apply
• JM: Nono, it's just a hint: ther server *checks* and throws an error if the client's claim is false.
• GG: client tells the server to use the wrong profile.....
• JM: Client says "This is a cholesterol panel". Server looks and sees, "wait, there's no LDL" and rejects the POST.
• GG: but saving computational load on the server is one valid use case we have previosuly agreed on
• JM: It's also about making things explicit, to catch errors the client *thought* it had a Choleseterol Panel to send, and it was wrong. If it hadn't said "here's a cholesterol panel" and instead had just said "here's a bag of data," it would never have learned that it was wrong.
• GG: it's also, based on experience, and past discussions, about tagging a resource with scret knoweldge know explicit in the resource but only known to insiders....
• LM: Problem is that the client didn't necessarily originate the data and doesn't necessarily know what profiless it's valid against or not, nor does it know what profiles the server cares about. Far easier for the server to just check the data against relevant profiles if it cares.
• JM: The client knows which profiles the server cares about: that's in conformance. The instance data *need* a way to declare profile conformance. I think that's my point here.
• LM: It knows what you *support*. That's different from what profiles you expect to be declared.
• GG: "The instance data *need* a way to declare profile conformance. I think that's my point here" I'm far from convinced.
• JM: That's fine.
• GG: so far, you've established that it would be useful for the client to tell the server when it submits....
• LM: You can say "here's what I can understand about a LabReport". You can't say "I support these 200 lab report profiles"
• JM: Lloyd: why can't you say "I support these 200 lab report profiles" in a conformance statement?
• GG: do you mean, why can't or why shouldn't? cause you can't right now. only one profile
• LM: Well, technically you could. You could repeat the same resource 200 times each with a different profile id, but that'd be an abuse(we should add a constraint)
• JM: I thought it was multiple cardinality: conformacne/rest/resource is multiple
• LM: rest is intended to be unique by mode. Resource is intended to be unique by type.
• GG: right now, the idea is that the server declares it's based profile - technically, the hull of it's actual profiles
• LM: Neither is enforced. I'll make a ballot comment.
• GG: I'm aware that there's a usecase for specifying inner profiles
• JM: So a server can't support Cholesterol Panel and CBC as two different profiles of diagnosticreport?
• GG: what do you mean, support? but what is highly unclear, and why I have studiously reisted acting on this , is what all the use cases are
• JM: I will tell you *my* use cases :)
• GG: so far my resistance has been enough to keep it out. But I still want the use cases
• JM: 1. Make it clear to clients what they can expect. I want to write an app that fetches cholesterol panels and trusts that they have the units, codes, etc. described in a profile defining that panel. It simplifies app logic tremendously to have that kind of convention.
• GG: k. I'll add that to the list of use cases
• JM: 2. Allow a server to preform smarter validation by knowing what the client *meant* to be submitting (i.e. which profiles the client thought applied to the data).
• GG: I had that one on the list
• JM: Awesome
• GG: though I remain suspicious of that - in the general case, how can the server trust the client on this? typically, the server will have to end up trying all the profiles anyway in order to support your first use case
• JM: I don't think there's any trust required on the server side.
• LM: Also, versions of profiles can change. And the client might declare a bunch of profiles the server doesn't care about.
• JM: I'm not extremely anxious about "missing" resources that "just happen" to conform to a profile.
• GG: really? then I think you haven't thought it through
• LM: Useful perhaps in testing, but we can create a tag for that purpose or something.
• GG: because otherwise you'll end up with completely balkinised data, and no reuse
• JM: There are certainly opportunities for going over the data later, in the background, to catch any conformance that may have gone undeclared. But mostly, I don't think data will accidentally meet profiles just by chance. (Not detailed profiles, anyway.)
• GG: depends on the context. The kind of profile you first described - cholesterol results in mg/mL with loinc code "x" - very likely that lots will conform to that
• JM: Fair enough, but I don't think that's argument against explicit declaration in either direction.
• GG: I think it's a strong argument against acting in the absence of a clear view of the goals and consequences of actions. My day job - which I'm supposed to be doing right now - is CDA expert for the australian national program, and I spend much of my time working with CDA templates, and consequential implementation issues. so I'm hyper-aware of what we do and don't get for all the effort we put into templating CDA
• JM: I'll let you go! (But I'm fascinated about CDA -- do you look for documents that meet but don't declare template conformance?)
• kwboone: Good. Tell SD why another 500 pages of text isnt useful right now...
• GG: on the contray, Keith, I think it's extrmemly useful right now
• GG: but I'm quite awaret hat my goals there are not yours ;)
• kwboone: Hmmm, you'll have to explain elsewhere.
• GG: Josh, right now, conformance is based on the claim made in the XDS submission, not in the document. The documents are full of claims with are ignored.
• GG: Keith, I'm in favour of FHIR not CDA, so things that make CDA more obviously harder....
• kwboone: That's an interesting approach.
• kwboone: AHHHHHH!
• GG: and CCDA is not on my mission critical list of things to worry about
• GG: lol
• GG: I would never say this anywhere else, of course
• JM: I appreciate the explicit priorities, at any rate!
• GG: it probably sounds as the documents aren't checked, but that's not true. The documents are cehcekd extremely closely, but the templateid in the document is ignored, even though it's there and must be correct
• GG: I am the final cehck in the conformance process. It's literally amazing what kind of egregarious errors can make it through all the other tests and get to me
• JM: And you mean literally you, with a text editor?
• kwboone: No it isn't, speaking with a voice of experience.
• GG: yes, me, with notepad++ and experience.
• kwboone: Read his blog post on the topic, yes he means him
• GG: see my post here:
• JM: I mean, based on what I've seen, that's not at all surprising
• kwboone: Great post BTW
• JM: the surprising thing is that there *is* a you in the loop
• GG: http://www.healthintersections.com.au/?p=1678
• GG: ta
• GG: the great thing about that is that many people submit, umm, *fictional* documents to me
• kwboone: He does what you and Bob just did w/ smart project, only for real.
• GG: they are hand massaged after coming out of their systems
• brett.esler: aahhh the tick seems more important than the feature... don't get it unless you plan on never using that feature...
• JM: Ah, thanks for the link -- fantastic!
• GG: you should watch my blog ;)
• brett.esler: 2.5 years of back catalog is good value!! Cheque is in the mail.
• JM: Ah, I should follow you on twitter. (Done.)
• GG: I don't announce my blog postings on twitter- Keith does it for me. Follow Keith
• kwboone: Yes you should. His blog is on my tweet it before looking list, the content is that good.
• kwboone: Really? You should fix that. Check out twitterfeed.
• JM: I do follow Keith. But when my head is down, I don't manage to read twitter or blogs :)
• GG: k. signed up with twitter feed - thanks for the link
• EK: Hi Josh, nice discussion about profile declarations. This discussion at this link here might sound familiar: http://wiki.hl7.org/index.php?title=FHIR_managing_profile_identification. I've had the same discussion with Grahame and I see what he's saying. And certainly when this comes from the CDA experience. But I do wonder myself why, at least for run-time purposes, I would bother with profiles at all. Even if I do a nightly run as a server validating new and changed instances against all 10.000 profiles I know about, I still cannot make any of that public, since there's no profile identification on an instance. Even if the client is sure and can help me out validating by communicating a statement (which I as a server might check), it can't communicate it and I have no way to point out to him where he's wrong, even when he asks me to validate it using REST.
• EK: So maybe we should make it explicit
• EK: Add a parameter to the validate operation to indicate that you want the server to validate whether the instance complies
• EK: Heck, there might be "validation" servers brought up by national HIE's just to let you validate your instances against the national profiles.
• EK: And I am sure if we don't add profile identification to resoures, we'll soon see people use tags to do just that. But that would be the wrong reason to add it, no ;)
• GG: I think your logic is circular - it's not worth doing because it's not able to be done?
• GG: We do need a parameter to allow validation against profiles. Since I can already validate, I've been meaning to get to that. Then there's no need for national hies to do it, since the test servers can
• GG: I'm currently thinking that tagging for profiles is the right way, it's already possible, and not prohibited.
• EK: Well, yes, you could even go out and fetch the profile if you don't have it and validate it, sure. I just think national HIE's will want to do that too.
• EK: And as for tags & circular reasoning. I tried to say that having/not having profile identification on an instance is going to be a non-discussion: our users will add it on instances using tags.
• GG: Ah ok. And currently I think this is the right solution, though we have not described this tag usage
• EK: But I agree on your main objection: tags / profile id's will be used to implicitly communicate data that should be in the instance. Sooner or later someone will come around and ask: "Hey, if we are putting these profileids on this observation, I can already see it's a blood pressure...why bother putting SNOMED codes in there?"
• EK: And I guess, you have more examples from the australian CDA project.
• GG: This is a long running thing in v2 and v3, and it does erode exchange. The driver is because it's to hard otherwise, which means that what we worry about is letting the design get too hard