Stream: implementers
Topic: Financial Management: Claim
Brian Kaney (Apr 20 2016 at 14:27):
We have a case where we would like to build a claim (in our case pre-authorization) where we need to send clinical data, including Observations and an OrderSet. Also would love to include an actual Condition resource (instead of a diagnosis code). Has anyone else worked in this area and could share some ideas on how to use existing resources or extending (so we aren't doing this in a vacuum)?
Paul Knapp (Apr 20 2016 at 15:11):
Yes. can you give me a bit more of the business case?
Brian Kaney (Apr 20 2016 at 15:28):
Hi @Paul Knapp -- yea, we need to send over the Condition, labs and bio-markers, and an order template (for chemotherapy) to get a pre-autorization to start chemo.
Brian Kaney (Apr 20 2016 at 17:03):
We are thinking about using an extension to Claim that would be a reference to a Composition document of qualification resources (for the OrderSet, Condition and n-number of Observations)
Paul Knapp (Apr 20 2016 at 18:14):
I suggest instead that you send a Pre-Authorization and we change Condition 0..* coding to condition[x] 0..* coding | Reference(Condition), and that you send the supporting resources via a DocumentManifest where the Attachment.content.pReference 0..* Reference(Any).
Paul Knapp (Apr 20 2016 at 18:16):
You send the Pre-Auth first, then send the Documentmanifest referecing the pre-auth adn the supporting resources. And if they need more supporting resources you can send another DocumentManifest refering to more documents, images, resources etc.
Paul Knapp (Apr 20 2016 at 18:17):
See teh only DocumentManifest example which shows how to reference a Claim and included or referred to artifacts.
Paul Knapp (Apr 20 2016 at 18:18):
DO you want Condition as a code or as the resource?
Brian Kaney (Apr 20 2016 at 18:56):
@Paul Knapp I see, I think I understand what you are proposing, and will put together an example just to confirm. I was thinking we would need the full condition, as we can include staging information more simply (alternatively, it could be part of the supporting document, but may loose some of the semantics without directly connecting to the Condition).
Paul Knapp (Apr 20 2016 at 19:00):
that's why I suggested that perhaps the claim needs to have condition modeified to be the choice of a code or a resource just like we do with bodySite and a few similar cases.
Paul Knapp (Apr 20 2016 at 19:05):
sorry for clarification, look at the current build not DSTU - it is diagnosis which would be a choice of a coe or the Condition resource.
Paul Knapp (Apr 20 2016 at 19:14):
or you could just add condition to the list of resources to share via DocumentManifest
Lloyd McKenzie (Apr 20 2016 at 21:49):
Why would you need to use a DocumentManifest? Most places there's a need to send supporting resources we just link to the resources directly.
Lloyd McKenzie (Apr 20 2016 at 21:50):
For example, with ReferralRequest, you just link to whatever allergies, conditions, past procedures and other clinical history is relevant.
Paul Knapp (Apr 21 2016 at 08:36):
The DocumentManifest references the supporting resources, external or internal documents and references the resource which those materials are supporting.
Lloyd McKenzie (Apr 21 2016 at 13:46):
But there's no need to have it. Just reference the supporting resources or documents directly. If you need metadata for an external document, then use DocumentReference.
Paul Knapp (Apr 22 2016 at 09:04):
Are you redesigning the business with the content model and exchange pattern you have in mind?
FM isn't, we are supporting the existing business with the technology we are creating and not deciding for the business what their exchange pattern must be.
The difference applies to your comment above. I think that what you are saying above is that a provider would create, for example, a Claim and include in that references to supporting resources (which would contain or reference the actual supporting content) and send that (Create, Send, etc.) to the Insurer. The Insurer would then either retrieve the referred to materials from the client, or other servers, or the supporting resources would be packaged with the Claim for submission.
If the Insurer needed more information then the Claim could be modiffied with new/different references and the Claim (or Claim plus supporting resources and content) be Updated or re-submitted.
Paul Knapp (Apr 22 2016 at 09:14):
@Brian Kaney Are you sending all of that clinical information to an Insurer or to a licensed party to make a clinical determination to initiate treatment?
Lloyd McKenzie (Apr 22 2016 at 14:35):
DocumentManifest was created specifically to support the XDS notion of "Folder" - an ability to retrieve a particular pre-packaged set of documents that have no other grouping justification. For a Claim, the grouping mechanism is the claim itself, so there's no need for an intervening resource. Whether you're using DocumentManifest or not, from a pure REST perspective, you'd be creating and maintaining all of the resources with independent transactions. If you're doing messaging or documents, you can bundle all of the related resources together with no need for DocumentManifest.
Lloyd McKenzie (Apr 22 2016 at 14:35):
(Or at least, I don't understand the use-case for adding it in the middle)
Paul Knapp (Apr 22 2016 at 15:25):
Well that is not how the business works. We had created an Attachments resource (SupportingDocumumentation) to model the business then we were told it was redundant with DocumentManifest, which is wasn't, but the owners kindly modified DocumentManifest so that it was redundant and we then dropped using it in favour of DocumentManifest.
Lloyd McKenzie (Apr 22 2016 at 17:02):
Attachments are a document architecture. But in REST, there's no need to think of attachments as documents at all. Just attach all of the resources that are relevant. We don't want to force adherence to a document-centric architecture when moving to FHIR.
Scott Robertson (Apr 22 2016 at 18:12):
But, "attachments" in the claims processing are very specific. The document form may be important. Granted, the resources are would contain the required information, but payers and processors can be very particular.
Paul Knapp (Apr 23 2016 at 06:50):
Attachments, or the SupportingDocumentation resource, which FM had proposed was not-document centric - it supported the provision of resources, files and references to files - and it was the FHIR core team who said we had to use DocumentManifest not the resource we proposed - and then we had to ask the overseeing committee to change DocumentMAnifest as it could not support the actual inclusion of a file!. It was clear at that time DocumentMAnifest and DocumentReference were build for a completely different purpose - so why is that suddenly an issue for you now?
So if you think we should fall back to what we had proposed in the first place then say so. - but the notion that people will submit a new claim or update the claim because the payor asks for some addition supporting information is a non-starter. If you would like to discuss this in committee in Montreal I'd be happy to coordinate a time.
Lloyd McKenzie (Apr 24 2016 at 03:05):
I'm not clear on the need for a wrapper at all - why not just reference CarePlan, Condition, Procedure, FamilyMemberHistory, Binary and whatever other information is relevant directly.
Lloyd McKenzie (Apr 24 2016 at 03:05):
That's what we'd do for referrals
Paul Knapp (Apr 24 2016 at 11:59):
You should check with referrals that you aren't redefining their business as well. If they consider the referral to be immutable or the target of the referrral may request additional information after the submission of the referral then that approach may not allign with their business or be found by them to be efficient. I understand the model you are proposing, but its up to the business to determine whether it is efficient for them.
Lloyd McKenzie (Apr 24 2016 at 14:59):
If the referral is immutable, then you wouldn't add links but instead would simply supply additional resources as needed (linked by the Task or MessageHeader that solicited the information). No need to treat the information as being a "document".
Paul Knapp (Apr 26 2016 at 05:35):
You are considering DocumentManifest and DocumentReference to be document centric, by document do you mean 'CDA and variants' or 'CDA/.doc/.xls/.pdf (etc)' or 'CDA plus any file format including images'? I expect you don't mean 'and resources'.
I am raising this as it increasingly appears that the use and intention of the Document* resources is more about documents and document repository management which does not align well with the concept of the provision of 'supporting materials' which is A) independant of the sender and receivers static information management technology (and doesn't preclude the use of) and B) broader in terms of supported information types - files, references to content, resources, actual provision of file and content-model contents, content format to any standard and marked up in any standard.
Therefore the decision to collapse SupportingDocumentation into DocumentManifest may have been wrong for both communities, less efficient overall and if so should be reversed.
Lloyd McKenzie (Apr 26 2016 at 15:26):
Sending related information as an "attachment" is an architecture choice. That shouldn't be baked into FHIR. I.e. You should be able to send related conditions, allergies, medications, family history, etc. without ever thinking of them as attachments or using any infrastructure that behaves that way. However, we definitely need to provide a means to enable that support where that is the architecture (and I recognize that in the financial space, it may currently be the predominant architecture). To enable that, I'd expect the model to allow direct linkage from Claim to the supporting clinical resources. I'd also expect DocumentManifest to allow linkage to those. If it was important to communicate the claim, the clinical details and the packaging mechanism that was used to deliver those clinical details, then I'd expect all of the resources to be present in the bundle. On the RESTful side, I'd expect there to be an operation that allowed you to submit a DocumentManifest together with the stuff it was referencing that would establish the linkage from the Claim (or CarePlan or ReferralRequest or whatever) to the content being referenced. You may be right that DocumentManifest isn't necessarily the right resource and we may need a distinct infrastructure resource to convey a bundle of things that are intended to be associated with another resource (if we find that OperationDefinition and/or MessageHeader aren't enough). But I really don't think it's appropriate to force that "packaging" structure to have to exist or to appear between the Claim/CarePlan/Referral and the supporting resources.
Paul Knapp (Apr 27 2016 at 05:35):
Given that the 'things' being referred to are distinct from the 'thing' doing the referring there must be some means of doing that referral and holding those references - that is the architecture.
You are suggesting an architecture where the content model doing the referring, eg Claim or Referral, hold all the references. That would be fine if: A) the referring content model is not immutable or C following; B) the referring content model submission is not prone to error; and C) the creator of the resource knew all of the supporting information to include and D) the receiver cannot request and the creator cannot subsequently supply additional information. Your architecture would require the creator to resubmit (update, send, etc) the referring content model should the referred to information change.
The business of the finanacial domain treats content models as immutable - once it has been said it cannot be unsaid. This is why accounting systems do not permit edits on posted entries, they require reversing entries to change a fact so that there is a trail of actions. Yes, your architecture provides history on content models (resources) but you shouldn't assume that the financial industry will stop what they do so they can rewrite their systems to do what you are proposing.
The reality in eClaims, and I expect referrals as well, is: A) supporting information is typically significatly larger than the content model they are supporting; B) supporting information tends to only be supplied once (per endpoint) and only for the content model it is supporting; C) content models are considered to be immutable not amendable; D) supporting information is often requested and supplied in multiple occurrences and after the submission of the content model. The approach, architecture if you will, used in Financial Management is to recognise these realities and support implementers in addressing them.
The architecture which I think you are proposing could be viable if the financial world worked that way. And if that business space wanted to adopt that model they could have decades ago - they didn't need to wait for these content models or http. I expect they haven't as they don't find it to be net beneficial.
I have gone back and reviewed the SupportingDocumentation content model and find it to be more targetted and efficient that Document*. I think it is worth a reconsideration and prefer that we don't create or define even more complex ways to get stuff from A to B or to convey the association of A with B.
Lloyd McKenzie (Apr 27 2016 at 11:11):
Hi @Paul Knapp. The referring thing cannot be immutable. At minimum, it'll have a status that must evolve. The version submitted may be immutable. And in some submission paradigms, the submission "package" may be immutable. But from a business perspective, if you did an internal query of a claim after supplemental information is submitted and said "what information is associated with this claim now?" or after payment and said "what's the status of this claim now?", the answer would be different. It's fully appropriate to be able to expose this over the RESTful interface. I'm not saying implementers must do this, but I'm suggesting that the resource design shouldn't prevent it.
You can think of a prescription as an "immutable" object too. But the resource is definitely updatable. And in the base FHIR spec, there's nothing to stop you from changing the drug, the prescriber and even the patient. What changes are permitted in a given context will be driven by business rules and/or implementation guides - because there are definitely changes that are permitted, in at least some situations. For example, changing the end date, changing the status, etc. That doesn't change the immutability of the original version - you still know exactly what the original prescription said, but the object itself evolves.
The resources, when created, need to support a wide variety of architectures, including architectures that may never have been used for the content. Constraining what architecture gets used in a particular environment is done through profiling and implementation guides and is based on the context. The base resource needs to be context-independent.
Paul Knapp (Apr 27 2016 at 11:43):
Lloyd, the immutability depends on the location and purpose of the resource. Clearly while something is in the client system while they are composing it the contents change - and I'd suggest it isn't a 'prescription' until the edits are done.
If you give a prescription to a pharmacy you can't change what you gave them after submission. You may be allowed to cancel but not change. If you still feel that you actually can change it then you must have advised the parmacy that they must elsewhere record the Id of the prescription and the Version on the label and any other records of the dispense as what you are saying is that they cannot rely on the 'prescription' as being a stable thing or that multiple reads may not result in the same thing - only versioned reads will.
Therefore the systems you are interacting that way MUST support versioning of resources and they MUST record the versions they acted on - are you being explicit in that requirement?
I seems that you are favouring a persistance architecture over an exchange architecture.
If you'd like to discuss in committee then I'd suggest Tuesday Q2 in Attachments. I don't know that they have agenda time, but this is 'bread and butter' for them and they could provide valuable input.
Lloyd McKenzie (Apr 27 2016 at 12:34):
@Paul Knapp You absolutely can change a prescription after it's been given to the pharmacy in some paradigms. A prescriber can suspend or even abort a prescription after it's been given to the pharmacy. It's not an immutable object. And in some cases, it's legitimate to change the end date or do other things. Certainly the ability to change may result in a need to manage versions. The exchange architecture interacts with the persistence architecture. From an exchange perspective, I'm passing around different snapshots of the business object at different times. Whether older snapshots are accessible and how they're manipulated will vary by architecture. My key point is that the architecture decisions should not impose on the fundamental resource design. The attachment approach needs to be supported, but it should not be forced as part of the resource design. It should simply be one option among many.
Paul Knapp (Apr 27 2016 at 12:56):
And I will reiterate that the FM resources are not limited by architecture. You would need to include those elements, if you wish them, as extensions as we are not aware of anyone doing what you suggest - so that doesn't meet the 80%.
Lloyd McKenzie (Apr 27 2016 at 13:49):
@Paul Knapp All systems are linking claim information to supplemental health record information. Therefore that's in the 80%. Linking it via "attachments" vs. not is architectural and shouldn't be baked into the resource design (just as it's not baked in for referrals or anything else).
Paul Knapp (Apr 27 2016 at 15:12):
I agree, I'd though you had said you wanted the link IN the claim - that's architecture isn't it.
Lloyd McKenzie (Apr 27 2016 at 17:40):
Well, the link either needs to be from Condition/FamilyHistory/Observation/etc. to Claim or vice versa. Pointing from Claim makes sense per FHIR rules that the thing created second does the pointing. Doing that in no way keeps you from doing the attachment approach.
Lloyd McKenzie (Apr 27 2016 at 17:41):
You can send the claim once. Keep a frozen "Version" of it. Receive a bunch of "attachment" submissions and never expose a version of the Claim that has the linkages that are implicitly created by those submissions
Brian Kaney (May 11 2016 at 18:48):
Yes, the clinical information is part of the determination of prior authorization
Brian Kaney (May 11 2016 at 18:56):
@Lloyd McKenzie were you thinking of a new attribute of Claim that would be a polymorphic 0..* reference to any of Condition/Observation/etc.
Lloyd McKenzie (May 12 2016 at 01:54):
I was thinking of something similar to "supportingInformation" on ReferralRequest and DiagnosticOrder
Brian Kaney (May 16 2016 at 20:37):
Question about http://hl7.org/fhir/2016May/valueset-claim-type-link.html -- what type would an in-clinic infusion for say chemotherapy be?
Andy Stechishin (May 16 2016 at 20:42):
I think it would be a professional claim
Andy Stechishin (May 16 2016 at 20:43):
It is coming up to midnight for Paul, he will chime in when he gets up
Brian Kaney (May 17 2016 at 13:50):
@Lloyd McKenzie we are going with just that, a supportingInformation extension to Claim. It could be considered common enough to add it to the resource down the road.
In cases like this, is there a way in FHIR to specify what the requirements would be for this information ought to be? e.g. observations of codes in a value set, conditions for the patient, careplans, etc.
Paul Knapp (May 17 2016 at 16:45):
@Brian Kaney : Are you sending this Claim to a US insurer?
I reviewed, again, exactly the pattern which I have described above in Montreal with the HL7 Attachments work group which, again, confirmed the pattern of: sending the Claim followed by the supporting materials which in FHIR REST would be creating the Claim Resource and then creating the supporting resources on the target server OR sending/creating a Bundle (Transaction) containing all of the resources.
If you wish to replace diagnosis with an extension containing Condition resources you may with the agreement of the receiver do that.
Question? How do you know that is the required information and that no further information will be required?
Brian Kaney (May 17 2016 at 18:37):
@Paul Knapp This is what I was thinking -- http://goo.gl/MXwW7H -- When you say "sending the Claim followed by the supporting materieals...creating the Claim Resource" are you talking about two HTTP requests, the first a POST and then the second a PATCH to update the resource with the supporting info? Or do you mean include the supporting info in the initial POST?
Paul Knapp (May 17 2016 at 19:00):
Are exchanging this information with an actual insurer?
If there was a modifable list of referenced resources within the claim and the claim was modifiable then a POST of a each of the supporting resources and a POST of the Claim (PATCH isn't approved yet).
Brian Kaney (May 17 2016 at 19:03):
It's a financial entity that will be able to pre-authorize treatment. Not sure how you would semantically relate the initial series of supporting resources to the eventual Claim resource.. Seems to have that semantic relationship from Claim 0..* Ref->(any) is more intentional.
Paul Knapp (May 17 2016 at 19:06):
Have you spoken with that financial entity? Have they told you that claims are immutable? Or is this a proprietary system which you are setting up, in which case you can do whatever you want?
Brian Kaney (May 17 2016 at 19:06):
Yes, I am working with the financial entity. Once submitted with the supporting information, the claim is immutable.
Brian Kaney (May 17 2016 at 19:08):
I might be misunderstanding you, but it seems like you are proposing POST'ing /Observation /Condition, etc. as the "supporting information" then eventually a POST to /Claim. How would you draw the semantic relationship that the prior supporting information ought to be considered supporting the claim?
Brian Kaney (May 17 2016 at 19:08):
It seem like the pattern in ReferralRequest.supportingInformation is exactly what we would like to have
Paul Knapp (May 17 2016 at 19:20):
I was echoing back what you seemed to be presenting, not what actually ocurrs in the claims industry. One of the difficulties with your model is how you would know when the claim is complete.
For example: you send in 3 supporting resources then the claim and figure it is complete, the payor review the supporting material and wants more so now it is incomplete? So how do you send more info without making the Claim immutable - not immutable - then immutable again - which isn't the definition of immutable.
I have described how this works in the financial space several times above. You send in the Claim, which stays immutable, then a DocumentManifest (ignore the 'document' word it is misleading) which contains or refers to any type of content, not limited to FHIR Resources, and refers to the Claim. If they want more info you send in another (Create) DocumentManifest and related resources). The DocumentManifest resources perform the linkage between objects.
If the Pre-Auth has been supplied the supporting info there would be no need to send it again with the claim, you would have the CLaim refer to the Pre-Auth.
Paul Knapp (May 17 2016 at 19:27):
There are several other issues here. In FHIR the last resource in points to the prior resources,so the supporting resources should refer to the resource being supported. Typically insures want to receive all of the information associated with a 'processable set' not gragments where they can't tell if they have all arrived, or when to purge fragments from incomplete submissions, so a Bundle with all of the resources would suit their busness better if you are using REST rather than a Request-Responce protocol.
Brian Kaney (May 17 2016 at 19:33):
I see, so instead of submitting all at once with a Claim + extension, you are proposing two FHIR requests, one for a Claim, and a subsequent for the information (with a reference to the Claim). Is this appealing because the Claim would be immutable, but you could change the supporting documentation? We would rather submit it all at once...
Paul Knapp (May 17 2016 at 19:35):
no your supporting documentation is typically immutable too, but you could send in several DocumentManifests all referring to the pre-auth or Claim.
Paul Knapp (May 17 2016 at 19:35):
Use a Bundle (transaction) to correctly send it all in at once.
Lloyd McKenzie (May 18 2016 at 01:27):
@Paul Knapp There's a few alternatives to dealing with supporting information in REST:
1. If the initial fulfillment request for the claim is rejected due to missing information, either update the claim and resubmit or create a new claim containing references to all of the needed information.
2. Add the additional information as "inputs" to the Task resource that is seeking fulfillment of the Claim.
Either of those patterns could be used with a referral request. (While in the messaging world, financial requests might be treated as immutable, they don't necessarily have to be fully immutable in the REST space.)
Sending content in a transaction doesn't tie anything together - each step in the transaction is processed independently, so there'd be nothing to tie the supporting information to the claim.
Lloyd McKenzie (May 18 2016 at 01:28):
@Brian Kaney you can profile the claim and slice "supportingInformation" to identify exactly what types of resources you expect to be included for a particular profiled version of Claim.
Paul Knapp (May 18 2016 at 05:46):
@Lloyd McKenzie: You are taking or creating a particular architecural viewpoint and imposing it on teh business rather than using the technology (in a FHIR REST or non FHIR REST exchange) to meet the business needs. This will require that implementers make all of the following changes:
1) change to the FHIR content models for information
2) change to the FHRI REST exchange protocol and behaviour
3) change their business and information flows to suit your design
You are free to bring that design and other designs to the FInancial Management or Attachments committeess for discussion with people well versed in the business, but promoting here a design which doesn't meet the business requirements, or which hasn't been reviewed by the domain, isn't helpful.
You may also wish to build demonstration clients and servers to flush out your design and to illustrate the efficiencies and how the industry could transition from the current business flow (which has been successfully implemented using paper and a variety of electronic standards for both content models and content exchange) to your model.
Others have implemented claims exchange using REST and FHIR REST and you and they may wish to compare approaches and outcomes.. I expect that REST itself dictates little of the business model being proposed.
The DocumentManifest ties he resources together, just as the SupportingInformation Resource did before it.
Lloyd McKenzie (May 18 2016 at 13:33):
@Paul Knapp I'm attempting to remove all architectural viewpoints. FHIR shouldn't force systems to do things any particular way. I'm not saying that systems have to change to REST. If they want to stick with a services or messaging approach, they can. But, the design must support a RESTful approach and the RESTful approach should be consistent across all types of resources - clinical, administrative and financial - so that when you learn how to do FHIR REST, you can be confident of it working the same way regardless of domain. In the RESTful space, there's no need for supporting information to be tied together because the Claim would be updated. The challenge is that the messaging paradigm is trying to be applied to the RESTful space and that doesn't work. It may be that nothing from the financial space will ever use REST. And that's ok. But if REST is used, it should be used consistently.
Andy Stechishin (May 18 2016 at 15:16):
@Lloyd McKenzie whether or not you can update the Claim is completely irrelevant to the use of REST (FHIR or otherwise). The challenge has nothing to do with applying a messaging paradigm to REST. The proposed approach is completely RESTful. This disagreement has nothing to do with REST, both approaches would meet the full criteria of the International REST Certification Board (sarcasm).
Paul Knapp (May 18 2016 at 17:36):
@Lloyd McKenzie: If you wish to add an extension to hold your list then fine the specification supports that, and given that we can't identify any existing systems which do that it must not be in the 80%. You may use UPDATE if you wish, you may allow the client to DELETE if you wish, the specification supports that. The business doesn't support these notions but that doesn't mean you can't.
Lloyd McKenzie (May 19 2016 at 00:43):
My point is that the need for using the notion of "attachment" shouldn't be baked into the design of the resource. It's perfectly fine to *support* an attachment approach, but we absolutely shouldn't *require* an attachment approach.
Andy Stechishin (May 19 2016 at 01:59):
So you are advising that we abandon the 80% of implementers that are asking for this approach and instead make them change their business practices to follow a design that doesn't support the 80%?
Lloyd McKenzie (May 19 2016 at 03:50):
Not at all. It's perfectly possible to support attachments without requiring their use. It means the initial Claim submission should be able to reference resources directly rather than forcing them to be sent as separate Attachment submissions. It doesn't mean forcing any change on anyone, but does mean allowing for supporting information to be included directly as is done with all other FHIR resources where it's relevant.
Andy Stechishin (May 19 2016 at 03:57):
Where it is relevant, your words. No one is FORCING anyone to do separate attachment resources, why do you keep using loaded language. All of the busniess experts that we have communicated with so far have REQUESTED to do separate attachments. This is the way it is done in the X12 processing. This is the way it is done in every use that we have been able to research. Please bring your examples of the use cases where it is done according to your model. I just can't see why we would insist on designs that only support the 0% of current application, that is not like you Lloyd. And we certainly don't want to create something for a possible future use case that no one has identified, that is not the FHIR way, we want to do things the FHIR way
Last updated: Apr 12 2022 at 19:14 UTC
