Stream: implementers
Topic: Claim Resource
James Agnew (Apr 03 2016 at 14:04):
Why does the claim resource use the weird pattern of
patient[x]
* patientIdentifier
* patientReference
I don't get why you can refer to another resource by identifier (as opposed to ID) in Claim. This seems to go against the pattern that is used everywhere else in FHIR where you use an ID reference, with a contained resource if you don't have enough information to create a freestanding resource.
James Agnew (Apr 03 2016 at 14:05):
And to the point of how I discovered this, claim also defines a search parameter on the patientIdentifier field, and uses it to provide membership in the Patient compartment. Surely this shouldn't be allowable.
John Moehrke (Apr 03 2016 at 14:29):
good point.
Paul Knapp (Apr 05 2016 at 10:37):
Hi James: Several questions here so I'll try to parse and respond to each:
We are not referring to resources by identifier, you can only directly refer to a resource by id, we are providing the choice of including a reference to a resource which contains information about a 'thing' OR the business identifier of the 'thing'.
We are providing the business identifier directly in the resource rather than requiring the creation of a contained Resource who'se only purpose is to contain the business identifer (which was our prior approach) as Grahame indicated oit was allowable and has proven to much more efficiently model and implement many use cases especially where the Patient, Provider, Insurer have well know business identifers such as in jurisdictional or national coverages. Grahame probably didn't expect that we would apply it as widely as we have but we did where it was appropraite and useful and not where it wasn't.
Please see the Claim SOA example with and without identifiers for the comparison and impact. I expect juristictional profiles would map out one or the other of the choices to suit their actual market needs.
We allow search on the business identifier for a Patient, and often other content for which we allow the direct capture of the business identifier, as that would be useful. If you think that declaring the search parameters places an undue burden on implementers then please raise that and we can consider removing (especially since any implementer can add their own search parameters if they wish).
Regarding the patient compartment, perhaps only id's should be used in the compartments, if that is the case then we should remove all elements which are not resource.id.
James Agnew (Apr 05 2016 at 13:09):
Well, I wouldn't say it's any undue burden, it's more just weird that we follow a different pattern here from everywhere else. Maybe that's because of the problem domain though; I know next to nothing about financial stuff. Do 80% of systems which process claims know only the patient's business identifier and no other information about them? If so, that's a reasonable justification.
Regarding the compartment part though, I just plain think it doesn't make sense to use a non reference parameter to provide membership in a compartment. The only way a compartment can exist is if its owner has a resource ID (e.g. Patient/1) and if the owner has an ID you should use that ID to provide membership to its compartment. If you're using a business identifier to provide membership than it means the patient doesn't have an ID, so it can't have any compartments for someone to belong to.
Simone Heckmann (Apr 05 2016 at 14:12):
...and also: "missing teeth" is IMHO not in the 80% ;-)
Paul Knapp (Apr 05 2016 at 17:11):
How many of the existing systems already refer to the FHIR resource id? (0%) How many of the systems refer to your PHN.
For compartment I had added the elements which refered to the indicated notion and when they changed to a choice I editted with the choices. Now that you raised the issue I expect what I did was wrong - it is not a table of Patient etc. elements, it is a table of Patient etc. ids so everything which is not an id should be eliminated.
Agree that missing teeth isn't in 80%, but neither for example is prescription, yet for the disciplines for which those elements apply it is in the 80% or more of their space. It is a consequence of putting all of what were disipline specific claim formats into one claim format. Unfortunately no discipline or individual claim format is more than 40%.Sometimes there are values which justify not applying the 80% guideline in a rigid manner - like having animal in patient.
Paul Knapp (Apr 05 2016 at 17:18):
If its a system which uses national patient, provider or insurance organization identifiers for those items they just use the identifier. In some cases they may want some checking information such as name, gender, birthdate. Where there aren't known identifiers or they need more thanjust the identifier then a resource, real or contained, is required to hold the additional information.
Given that you need to develop profiles to clearly articulate requirements this allows jurisdictions to create profiles which are optimal for them: choice of resource or identifier, resource only, identifier only.
Lloyd McKenzie (Apr 05 2016 at 17:53):
FHIR presumes a particular architecture. There's also 0% of systems that are using a URL to identify U.S. SSN, but if you want to do FHIR, you have to do that. I don't see anything different in the financial space around how identifiers are used that would justify a divergence of the standard mechanism of just having a resource reference to Patient. At the base level, the resources should work the same way regardless of domain.
Paul Knapp (Apr 05 2016 at 17:55):
The resources do work the same way - you have a reference to them.
Lloyd McKenzie (Apr 05 2016 at 17:56):
Right - and no resource outside of the financial space allows a patient identifier in-line. No reason for that difference.
Lloyd McKenzie (Apr 05 2016 at 17:57):
Or if we were to push for that difference, it should be a global decision that we'd reflect in all resources. It doesn't make sense for the financial resources to have one approach while other resources do something different when the underlying nature of the systems isn't any different.
Lloyd McKenzie (Apr 05 2016 at 17:58):
The use of claims to support multiple domains is a tricky piece and there's been lots of back and forth about it. Right now, we're leaving it to the implementer community to identify their comfort level with the approach - and to confirm that those specific elements that have been called out (e.g. missing teeth) are in fact global in nature, at least within their respective domains.
Paul Knapp (Apr 05 2016 at 18:02):
Well I'd thought that was the pattern too which is why we didn't do this before but Grahame indicated that this was valid. So is the pattern that FHIR espouses is that you don't directly contain an element if contained within a domain (or whatever the right term is) resource. For example if Patient contains birthdate then you don't create an element in another resource to hold the equivalent of patient.birthdate?
Paul Knapp (Apr 05 2016 at 18:12):
I'm happy to leave it to providers who specify Bridges, oral prosthetics which provide for gaps in dentition, or the insurers who pay for them to indicate whether knowing which teeth are missing is necessary for their work.
Lloyd McKenzie (Apr 05 2016 at 19:49):
It's certainly valid to have a choice of a reference to a resource or local information. We do that commonly with things like Reference(Medication)|code. It's also possible to not have a reference at all (e.g. just an organization name rather than a reference to Organization). My point is that the commonality of just having an identifier isn't limited to the financial domain - it occurs in many places. So we shouldn't have a variation in approach for the financial resources when compared to the clinical and administrative resources. Either everything should have only Reference(Patient) or everything should allow a choice of Identifier.
Lloyd McKenzie (Apr 05 2016 at 19:50):
(Or at least that's my position.)
Paul Knapp (Apr 06 2016 at 06:42):
Ok so your issue isn't with having a choice of a resource or content which would normally be in that resource . Your issue is then either with the fact it is the identifier element or that a consistent pattern has been applied in financial resources which the other resources haven't adopted. We have adopted many of the same choicea and naming pattern which are used elsewhere, perhaps we should given other committees and implementers time to consider the pattern to see it it works for their use cases and comment on whether it creates a burden if they don't use but others do?
Lloyd McKenzie (Apr 06 2016 at 15:36):
Well, this particular use of reference vs. Identifier has very significant architectural impacts. If you use an identifier, it means you can't use compartments, you can't use $everything, the "standard" way of managing access control doesn't work, _include doesn't work, etc. I'm definitely on board with the idea of asking implementers their opinion, but in the end - ideally before STU 3 gets published - we should be consistent across all resources about how this is done or we should have clearly understood for criteria on when each approach is done. I think variation purely because of designer preference would be a bad thing.
Paul Knapp (Apr 06 2016 at 16:17):
By "it means you can't use compartments, you can't use $everything, the "standard" way of managing access control doesn't work, _include doesn't work, etc." you mean I can't use those things with the resource I don't have, right? I can still use them all with the resource I do have for example Claim.
Simone Heckmann (Apr 06 2016 at 16:40):
+1 for consistency
Lloyd McKenzie (Apr 06 2016 at 19:53):
@Paul Knapp Nobody "has" a patient resource. We expose our data using resources. The ability to expose data as stand-alone resources is based on whether you have enough information to uniquely identify an instance. And if you've got a unique business identifier, then presumably you have enough information to expose a resource with a unique id - even if that resource doesn't happen to have much information on it.
Chris Grenz (Apr 07 2016 at 20:38):
I'll chime in for @Lloyd McKenzie 's position - this is a dangerous inconsistency in terms of intra-server relationships. This is closely related to the conversation on #Conditional Reference - how to relate data when a non-FHIR identifier is known.
Grahame Grieve (Apr 07 2016 at 20:41):
I used to wonder when this would come up - I've always wondered whether we might need a logical reference instead of a literal reference.
Grahame Grieve (Apr 07 2016 at 20:42):
but adding it raises many issues
Grahame Grieve (Apr 07 2016 at 20:42):
I agree it's related to the conditional reference thing
Grahame Grieve (Apr 07 2016 at 20:43):
what we've said is that we prefer architectural consistency, but only where the underling requirements are actually consistent. We won't impose consistency where the domain requirements are not consistent
Chris Grenz (Apr 07 2016 at 20:43):
Working on messaging puts this in your face quickly!
Grahame Grieve (Apr 07 2016 at 20:44):
however in my view, the differences in the financial resources are not related to domain requirements, but to solution architecture. The financial resources are clearly developed to a different set of architecture principles than the rest of FHIR
Grahame Grieve (Apr 07 2016 at 20:45):
I believe that this is a problem. But for now, I'm happy to see where these resources go in connectathons - and I encourage anyone who's concerned about this to take part in the relevant connectathon streams
Paul Knapp (Apr 08 2016 at 11:57):
How so? You may use them within an organization as a persistance model, which seems to be where much of the FHIR discussion is focussed, and as a model for exchange between organizations. The primary focus of eClaims, the Financial Claims and Reimbursement side of Financial Management (FM), is exchange between parties, whereas the Accounts and Billing side of FM is within and organization focussed. The eClaims related resources have been demononstrated at Connectathons using a variety of exchange paradigms: FHIR REST, TCP/IP, HL7 over HTTP (RPC using HTTP), Web Services (SOAP/HPTTP), etc..
They have been revewied by parties who live in the domain, have for decades and process millions to billions of domain content model per year. FM would be happy to here of what domain requirements we have missed so that we may address them.
The issue of a choice of a reource.element (just the needed content) or a Resource.id (reference to the actual or creation of a contained resource) is the choice of a design pattern - we chose to provide efficientcy. If it is determined that that pattern should not be used then we can revert on the resource.identifier choices just added and then we can all remove all of our other uses of that pattern: always send or create contained BodySite, Procedure, ReferralRequest, precriptions, orders, locations, Patient etc. ) if that is to be the pattern. We can all do that.
We just found it to be more efficient and the arguments of what capabilities are given up, detailed by Lloyd above, do they actually apply to contained resources - if we go back to contained resources are any of them regained?
Lloyd McKenzie (Apr 08 2016 at 13:33):
If you've got an identifier you shouldn't need a contained resource. Contained resources aren't about "don't have a lot of information", they're about "don't have enough information to uniquely identify".
Paul Knapp (Apr 08 2016 at 21:09):
Isn't a contained resource if for where you don't have an id?
Lloyd McKenzie (Apr 09 2016 at 02:39):
You create an id. Generally speaking with FHIR, you have to create an 'id' for whatever resource you expose - and figure out how to map that to your internal database. Contained resources are for where you don't have enough information have an independently identifiable instance. For example, a medication or a practitioner or organization where all you've got is a name.
Paul Knapp (Apr 09 2016 at 14:18):
The financial resources have always supported the FHIR REST exchange pattern. You can specify the Resource reference.
Lloyd McKenzie (Apr 09 2016 at 14:40):
Right. But the question is why use "contained" when you have enough information for an identified instance. I'm not seeing how the financial space is any different from the clinical or administrative spaces when it comes to patient references, so the modeling ought to be the same. Referencing patient by identifier breaks a bunch of things, so we should only do it if we absolutely need to. (And if we do, we should be consistent across FHIR.) Thus far, I'm not hearing a reason why reference by identifier is necessary from a restful perspective, though it's possible I'm not understanding.
Paul Knapp (Apr 10 2016 at 05:31):
You raise several issues which I'll try to separate and address:
1) Specification of resource elements outside of the logical parent resource
This issue is not related to REST.
We do this elsewhere in the FHIR specification, for example bodySite (use the code element only) and patientName (use the name element only), and FM has now used the identifier element only. I think the common pattern is that that is the only element of the resource which is needed in the exchange, so while a local or contained resource could be created to contain that single element it is though by the implementers to be less efficient.
In some situations you want the richness of the BodySite resource, in others the brevity of the bodySite code. Similary one may need to convey all of the definitional information of the provider, or just the provider's national identifier.
If it is determined for FHIR that that should not be allowed then as I said above we just need to articulate that and revert or clean up the current resources not just the FM ones.
Also, following that logic whereever we have an element where the data type is Identifier and it is not the Identifier of that resource, then are we missing a resource and should we create the Resource and replace with a reference to that resource? Or should we be more pragmatic.
2) FHIR Resources may be used over many exchange paradigms not just FHIR REST
The FM resources, and hopefully all resources, may be used across many exchange paradigms and transports. We want to be able to support the implementers, so while the resources must support FHIR REST, they should not preclude use in other paradigms otherwise we arbitrarily limit their utility. To date FHIR hasn't required that the resources only be used with FHIR REST, are you suggesting they should only be used with FHIR REST?
3) You have to create an id for exposed resources
In order for resources to be effectively used over FHIR REST, referenced resources must have an id and be accessible to receivers of resources which contain such references. However, when a GET is not supported, or the exchange paradigm used is not FHIR REST, such as WSI Web Services, or when a resource model is being used to convey a subset of information but not create or update a receivers information model, then a contained resource without an Id may be used.
Lloyd McKenzie (Apr 10 2016 at 14:34):
@Paul Knapp You are correct that we do allow for local inclusion of data elements that could be found in another resource either as a choice with or sometimes as an alternative to having a reference to that other resource. My concerns are two-fold:
1. I don't think the requirements that have been expressed by FM are exclusive to FM. Therefore whatever pattern we adopt for dealing with patient should be consistently followed in all patient-specific resources, not just the financial ones
2. Not including a patient reference has a significant architectural impact, particularly REST. This must be taken into account before we change the paradigms for everything.
If you are doing REST, then I agree if you're going to have a non-contained resource, it must have a stand-alone unique id within the server & resource type and should be available for query with a GET. (I don't think we've ever said SHALL to this, but it would certainly confuse people/add complexity to systems if this wasn't the case.)
However, if you're doing messaging or documents, then it's perfectly fine to simply assign a UUID to the resource and package it as part of the bundle without any means of querying it using a GET. You would not use contained resources. Contained resources are intended for use when the content cannot stand alone as a uniquely identifiable instance, not as a handy way of packaging things
In any event, the question here isn't around contained resources. It's about a situation where the patient resource is clearly independently identifiable (we have a unique patient id), but we're not exposing that fact as a resource. And I think that's problematic from both a REST and a messaging point of view.
Paul Knapp (Apr 10 2016 at 16:29):
Lloyd:
1) patient isn't an FM resource, it is a PA resource. Are you suggesting that if 1 resource calls out a particular element that all resources which must do the same, for example that all resource which reference bodySite must allow a choice of a code and the resource?
2) The issue is that the element is an 'Identifier'
I think what you are saying is that given that the element being called out is a resource.identifier one could create an instance of that resource (logically if not physically) which has that .identifier. And then resources which reference that resourcewould only use the resource.id. The referred to resource could then be obtained by the receiver of the referring resource using a GET or be packaged into a Message (or other composite) as a full fledged resource. Like we demonstrated in Sept 2013 using Workflow (a copy of Order) and in 2014 using MessageHeader.
For efficientcy I expect communities are likely to infer that Alberta drivers licences are at http://deptofmotorvehicles.ab.ca/1234456. Where the number is the License number.
Lloyd McKenzie (Apr 10 2016 at 20:01):
@Paul Knapp This issue is the resources making the reference, not the Patient resource itself. I would expect all resources to have the same referencing behavior unless there's something domain-specific that requires a difference. And the justifications provided here don't seem to be something that's specific to the financial domain. So one of the following should be true:
a) we don't need the choice on the financial resources
b) we need the choice on the financial resources and everywhere else too; or
c) there's something different about the financial domain that I'm missing
Lloyd McKenzie (Apr 10 2016 at 20:02):
You're correct in terms of the approach that the other domains have presumed. I'm not sure I'm following your comment about AB drivers licenses.
Paul Knapp (Apr 11 2016 at 18:00):
I don't think the FM resource are different, for example if the NHS has a national patient identifier then it could be supplied as a local resource.patientIdentifier on any resource without the need to wrap it in a Patient resource, or we could all wrap those identifiers in a Resource and reference the resource - the efficientcy concern is the same for any referring resource.
Grahame Grieve (Apr 11 2016 at 18:10):
as I said, this is architecture, not domain
Last updated: Apr 12 2022 at 19:14 UTC
