FHIR Chat · Implementation Guide · CARIN Benefit Check IG

Stream: CARIN Benefit Check IG

Topic: Implementation Guide

---

Ryan Howells (Oct 30 2019 at 14:16):

Here is the beginning of a draft version of the #CARIN Benefit Check IG Implementation Guide. https://trifolia-fhir.lantanagroup.com/igs/lantana_hapi_r4/CARIN-RTPBC/index.html It is still a work in progress but should have a more complete IG by the end of next week. @Frank McKinney @Pooja Babbrah are helping us create it. Please let us know if you have feedback you'd like to provide to our team.

Josh Mandel (Oct 30 2019 at 19:05):

Thanks! I've shared some of this over email, but will include some thoughts here.

Josh Mandel (Oct 30 2019 at 19:08):

First off, getting more of the basic documentation out of images and into the resource-specific profiles pages will make review a bit easier. Adding examples for the end-to-end flow should be a top priority, since they'll probably help shape the profiles themselves.

Josh Mandel (Oct 30 2019 at 19:08):

What's the rationale for requiring MedicationRequest.reasonCode? (This is optional in US Core and other profiles I've seen.)

Josh Mandel (Oct 30 2019 at 19:10):

In general I'd recommend against "zeroing out" (prohibiting) elements unless there's a compelling rationale. This applies across the various profiles, like:

pasted image

Josh Mandel (Oct 30 2019 at 19:13):

https://trifolia-fhir.lantanagroup.com/igs/lantana_hapi_r4/CARIN-RTPBC/StructureDefinition-carin-rtpbc-request-Claim-definitions.html#Claim.provider documentation describes it as a provider, but the reference is to a "preferred pharmacy". I would have expected to find a prescribing clinician there (but instead the prescribing clinician is listed under https://trifolia-fhir.lantanagroup.com/igs/lantana_hapi_r4/CARIN-RTPBC/StructureDefinition-carin-rtpbc-request-Claim-definitions.html#Claim.careTeam.provider (which I think is complicating the picture).

Josh Mandel (Oct 30 2019 at 19:15):

https://trifolia-fhir.lantanagroup.com/igs/lantana_hapi_r4/CARIN-RTPBC/StructureDefinition-carin-rtpbc-request-Claim-definitions.html#Claim.insurance is a repeating field, but the profile fixes sequence to 0 for all entries, which looks like a modeling error. If the intention is to limit to a single insurance field, the cardinality should be restricted (and there's no need to restrict sequence). But better in my opinion to leave this as an open list, since some real-world use cases will involve multiple insurance providers (why prohibit those use cases at the level of the spec?)

Josh Mandel (Oct 30 2019 at 19:15):

I'm unclear on how https://trifolia-fhir.lantanagroup.com/igs/lantana_hapi_r4/CARIN-RTPBC/StructureDefinition-carin-rtpbc-request-Claim-definitions.html#Claim.item is being used; the docs don't explain this, but I do see some constraints.

Josh Mandel (Oct 30 2019 at 19:17):

(OK. that's some quick feedback on the outbound Claim -- request -- from https://trifolia-fhir.lantanagroup.com/igs/lantana_hapi_r4/CARIN-RTPBC/profiles.html. I haven't looked through the others in detail, partly because I'm not sure how they're used, and where/how the outbound request includes these various resources. Some narrative/examples/tutorial would be a big help.)

Pooja Babbrah (Oct 30 2019 at 20:10):

Thanks for the feedback @Josh Mandel - @Frank McKinney should be able to help answer some of these questions and address concerns. I know he is also working on moving everything to the build.fhir.org site which may help with the version tracking, etc. questions you raised through email.

Josh Mandel (Oct 30 2019 at 20:33):

Yes (well, managing source in github will provide that tracking; publishing at build.fhir.org is just a nice side effect).

Frank McKinney (Oct 30 2019 at 21:54):

Thanks for the comments/questions Josh! I appreciate the feedback

Re. the prescription reason/diagnosis... Good catch. I'm adjusting that now. The diagnosis can factor in to coverage (and is included in the NCPDP RTPBC spec), but we discussed in the CARIN WG and agreed that its reliability would likely be a challenge when provided by a patient (rather than the prescriber). So, is now 0..1 in the IG. Leading to your other point...

Re. making elements not-used (0..0). I wasn't sure what would be the right / conventional approach for clarifying what is expected to be populated in the Claim and ClaimResponse resources, since it's not immediately apparent what the different elements represent and when they're used. I think that folks in the benefits processing world like to 'lock down' what they're supposed to provide (and what they need to accept), but appreciate that FHIR has more of a 'don't constrain unless you need to' perspective. For the supporting resources (Patient, etc.) I agree there's no benefit in making elements unavailable... but I'm on the fence about the claim/response.

From our conversations with the Financial Mgmt WG folks, the meaning of Claim.provider is the party that would get paid due to the claim, so in this case, the pharmacy. Definitely not obvious. The prescriber then is captured as part of the care team that created the order. I've gone over the request mapping in some detail with Paul Knapp on the FM WG, but we haven't yet had a chance to review the mapping I've proposed for the ClaimResponse... was scheduled for yesterday but got bumped to next Tuesday.

Claim.insurance: Right.. that looks goofed up. Whether to restrict cardinality to 1 is the question, which relates back to earlier notes. I think a key determiner for questions like this is the extent we (especially the payers/PBMs) want this process to stay compatible with how they're performing provider-requested RTPBC, and preadjudication in general. My understanding is that coordination of benefits with multiple payers is seen as problematic... predicting what other payers might pay, etc.
- I think it would be good to get folks from the payer side together to discuss how much we want/need to align with their current ways of processing... so as to not create obstacles for them

Re the Claim.item, that's where the product identifier and quantity will go. I was fighting with Trifolia over this part last night and pulled out what I had... A complicating factor is whether we want/need to enable the product to be identified using an RxNorm in addition to an NDC... which is totally useful in clinical functions but basically never used for pharmacy benefits processing.
- Based on earlier discussions in the team, do you think it would it be reasonable to limit the product ID to NDC?

Thanks again... it's helpful to talk stuff over

Lloyd McKenzie (Oct 30 2019 at 22:30):

The recommendation is to only constrain maxOccurs (whether it's to 0 or 1 or something else) if it's an error for the data to be present. If it's data that will be ignored, just don't mark it as "mustSupport". For repeating elements, slice it and define the constraints that will allow you to extract the repetition(s) you care about from the larger collection. Always assume that the client will be exposing the same "maximum" interface to all possible consumers, filtering only based on access permissions, not on receiver preferences.

Frank McKinney (Oct 31 2019 at 02:12):

Thanks @Lloyd McKenzie , that's very helpful. I think we'll have a mix of "error" and "can ignore" in our use of the Claim.

Quick question: We're using Claim as a predetermination request where, instead of asking to get paid some amount for a service, the submitter is asking "how much would you pay for this service?". In this scenario, it wouldn't make sense to include pricing information in the request. Would this be an example where we'd set maxOccurs to 0 (e.g., on the item.unitPrice element)... considering it to be an error to populate it?

Thanks again!
@Josh Mandel @Pooja Babbrah

Josh Mandel (Oct 31 2019 at 02:14):

That sounds logical, indeed.

Lloyd McKenzie (Oct 31 2019 at 03:38):

It sort of depends. In a pre-determination, you've got two options - the client sends a pseudo-claim representing what they 'would' bill, but marks it as a pre-determination and the payer then adjudicates it as they'd expect to and indicates how much they 'would' have paid (and perhaps reserves funds). The benefit of that approach is that if the client is billing for less than the payer might be willing to pay, the payer doesn't automatically tell them what the max is. (Though smart clients will bump the billing numbers up to something unreasonable to find the max anyhow). The question is whether the inclusion of the dollar amounts means that the request can't be processed, or if they're just noise. I think in this case, they'd just be ignorable noise. Even payee (which wouldn't be relevant on a pre-determination) wouldn't be wrong. And could result in a response where you could indicate that you're not willing to pay that particular payee (e.g. you always pay the policy holder). The only one that's somewhat suspect as being a true 'error' would be 'encounter', as in most cases the encounter wouldn't have happened yet. However, if the pre-determination is for something when the patient's already admitted.

Lloyd McKenzie (Oct 31 2019 at 03:39):

Errors would be things like ordering a blood pressure and providing a specimen - that's obviously out to lunch. Or registering a new patient with a deceased date filled in (might be legitimate in some systems, but fine to say it's an error in a particular set of implementation circumstances).

Lloyd McKenzie (Oct 31 2019 at 03:40):

In other words, if the population of the data indicates the instance is clearly out to lunch or violates business rules, then prohibit it. If it's merely unnecessary for processing but could conceivably legitimately be present, don't yell.

Frank McKinney (Oct 31 2019 at 15:48):

Thanks @Lloyd McKenzie . It feels like the key determiner of how we evaluate whether something is an error or extra is whether we think of this profile as being "a predetermination" or "this specific kind of predetermination". I feel pulled to want to say "in this particular process, the stakeholders agreed that these were the only inputs that will be considered". @Josh Mandel @Pooja Babbrah

Frank McKinney (Oct 31 2019 at 16:01):

@Lloyd McKenzie . Since you're being so generous with expertise, I'm going to push it and ask a couple related profiling / cardinality questions...

(a) When constraining an element's cardinality, is it best practice to just constrain the "end" that doesn't match your needs? E.g., if the base is 0..1 and you need it to be 1..1, should the structure definition just include a min=1 for that element and not a max=1 (since it's already 1 in the base)?
(b) Similar, if you're making an element 1..1, is there a reason to also set it as Must Support?
I've seen cases where foks have taken a 'belt + suspenders' approach and included a max=1 when the base is already 1, and a Must Support on a 1..1 element... which seems redundant to me. Esp. the Must Support w/1..1

(c) When binding a codeable concept to a valuset and setting the codeable concept element itself to 1..1, is it also appropriate to set the children system, code and display elements to 1..1 (if you want to require that they're all populated)? Or does the parent codeable concept 1..1 apply down to at least the system/code, due to the binding?

Thanks again! and I'll stop bugging you now
@Pooja Babbrah @Josh Mandel

Lloyd McKenzie (Oct 31 2019 at 16:32):

A specification will always reflect what data is needed for a particular scenario. However, the implementation should ideally not have to be tied to only that scenario. If you create that tie, then you end up with a separate interface for each scenario, which creates additional development costs and ongoing maintenance costs. Therefore, specifications should try to allow, as much as possible, data to be present that is unnecessary for the design scenario but could potentially be relevant for others.

Lloyd McKenzie (Oct 31 2019 at 16:40):

a) Typically, you only declare what's changed.
b) 1..1 and mustSupport are orthogonal. If something is 1..1 and not mustSupport, then nothing stops the sender from populating the element with a fixed value (or even a fixed extension that says something like 'not supported'). And on the receiving side, a mandatory element not marked as mustSupport is free to be ignored and thrown away. mustSupport is what sets conformance expectations that the system must be able to store/display/"allow user entry of"/"consider in decision support"/"do whatever with" the element. So typically if an element is 1..1 it will also be flagged as mustSupport.
c) Setting an element to 1..1 has no impact on the cardinalities of the children. All you inherit is the base rule that at least one of the children must be present and at some descendant level there must be a value. It's possible the only child might be an extension. If you have a required binding, then that imposes an additional constraint that at least one of the Codings must have a value from the value set (which means, at minimum, code + system must be present). It has no impact on other Coding repetitions though so long as at least one includes a code + system and matches something in the value set.

Frank McKinney (Oct 31 2019 at 17:01):

Thanks a lot @Lloyd McKenzie for the direction. I appreciate it!

Lloyd McKenzie (Oct 31 2019 at 17:02):

No problem. That's what this community is for :)

Frank McKinney (Nov 01 2019 at 20:31):

Hi @Pooja Babbrah @Josh Mandel @Ryan Howells. I've got the draft IG on build.fhir.org now...
http://build.fhir.org/ig/HL7/carin-rtpbc/

Kind of ugly, but has the profiles framed up and an example request and response scenario. I'll be working on it over the next few days to get it better organized and fleshed out for review / refinement .

Have a great weekend!

Josh Mandel (Nov 04 2019 at 21:22):

Thanks! Are http://build.fhir.org/ig/HL7/carin-rtpbc/other.html the examples you mentioned? It'd be good to show a full bundle of request details / response details -- or at least, I'm assuming that you're planning to use a $submit operation with a Bundle. Is this correct? I don't see it documented yet.

Josh Mandel (Nov 04 2019 at 21:22):

Re: content, I wouldn't expect to see contained resources here, and I don't think the payor will have a way to reach back into the client for more details (e.g., to fetch resources), so a bundle or operation parameters will be necessary to send along the full details.

Frank McKinney (Nov 05 2019 at 22:18):

Thank Josh. I was thinking that containing might be appropriate since the patient, etc. are sent more for identification/matching than for consumption. I'm working on a bundle example and some associated guidance, which I'll get into the IG yet today

Frank McKinney (Nov 06 2019 at 10:14):

Hi @Josh Mandel . I added bundled versions of the request and response, along with related discussion in Table of Contents > Submit Operation.

I also left the Claim-with-contained-resources versions of the request and response... for discussion. The supporting resources (Patient, MedicationRequest, etc.) are very light... providing identifying/matching information to the insurer, rather than to be stored or used to update the insurer's info. It feels uncomfortable to me to reference them in the bundle like they're full resources. Is this a situation where contained resources might be appropriate?

Let me know what you think

@Pooja Babbrah @Lloyd McKenzie @Ryan Howells

Lloyd McKenzie (Nov 06 2019 at 18:10):

Contained resources are used when something isn't independently identifiable and can't have independent existence. The contained mechanism is not a transport packaging mechanism. If you send a resource with contained data, the general expectation is that the receiver will store the resource with the contained resources and will not resolve them to existing data structures. I don't think that's what's wanted here.

Frank McKinney (Nov 06 2019 at 19:35):

Thanks @Lloyd McKenzie, @Josh Mandel for weighing in. Hoping you have time for couple quick questions to make sure I understand...

- I wonder if the basic driver is "what is the _thing we're exchanging?" I tend to think of the Claim/predetermination submission as an entity unto itself, with its own, short existence. Sort of a point-in-time, non-evolving formulation of a question with pieces of information to be used when answering the question at the moment it is asked. From that viewpoint, the bits from the prescription, the coverage IDs, the the patient's name, etc. are just components of the request--not pointers to independent things that will live on after the claim's been processed.

We'd want the recipient to store off the request in their "submitted claims" file, and not try to update their member record etc. with the patient matching info it contained... since we know we're not giving them the full Patient, etc.

- With regard to the transport packaging aspect, the Claim $submit operation allows either a Claim or a Bundle as its parameter... and I understand they are both workable from a mechanical 'getting the information from here to there' perspective... but maybe there's more to be considered in that respect than I'm aware of.

---

If all this still points to Bundle, that's cool with me :) Just wanted to clarify what I think the information means in the process

Thanks again!

Josh Mandel (Nov 06 2019 at 19:38):

I think our methodology points to Bundle for conveying the auxiliary data needed by the $submit operation on the claim. (My own recommendation was to use a more tailored operation, taking its own named parameters -- but I think that ship has sailed.)

Lloyd McKenzie (Nov 06 2019 at 21:57):

In pure RESTful FHIR, there's no such thing as a 'submission'. There's just a bunch of creates, updates, queries, etc. As an example, when there's a patient admission, you'll see the creation or update of a Patient, the creation or update of a bunch of allergies, medication statements, observations, coverage and other information and the creation of an Encounter. On discharge, you'll see an update to the encounter and updates and creates of a bunch of other things. Those creations and updates might flow completely independently or they might be sent as one or more transactions. There's no notion of a "submission" though and there's nothing that tells the receiving system that the update to the Patient demographics is driven by an admission or discharge.

Similarly, if we were doing claims processing with pure REST, we'd capture all of the supporting information in whatever servers were appropriate, we'd create the Claim resource on the source system and create a Task asking for the Claim to be processed. The payer would retrieve the Claim and, as needed, any referenced resources from wherever they lived. At some point, the ClaimResponse would be created and the Task updated to point to it. Via subscription or other means, the provider would be made aware of the Task update and they could go out and query the ClaimResponse.

That's obviously different from how systems are used to doing such processing today - and different from how the X12/NCPDP back ends for a lot of this functionality. Thus the tendency to use operations to pass a collection of interrelated resources.

John Moehrke (Nov 07 2019 at 13:29):

Im with Lloyd, except that a Provenance of a Create or an Update can indicate Who/What/Where/When/Why including if it was because of an admit or discharge. This seems unnecessary to track this kind of comprehensive Provenance, but it can be done. So, as Lloyd has made clear we should be careful not to re-invent the old model for no good reason, while leveraging the FHIR models every benefit.

Josh Mandel (Nov 07 2019 at 14:39):

Lloyd, you're describing something "pure" but I'm not sure whether you're advocating it for this use use case, or what the advantages are (to offset the obvious additional complexity of adding tasks and subscriptions/polling, and so on). Can you clarify?

Lloyd McKenzie (Nov 07 2019 at 15:30):

The benefit is that the server's capabilities are not use-case-specific. You just expose the resources that can be manipulated and the client decides what to manipulate and in what order. Having a use-case-independent interface lowers overall costs and increases flexibility. However, it doesn't necessarily align well with existing back-ends. If there's tight control required over what resources must be shared, they must all be shared at a particular time and the relationships are known, then you're looking at either an operation or FHIR messaging. The latter uses a Bundle. The former can use a Bundle, but more typically has specific parameters. Using operations with Bundles limits your ability to clearly define exactly what must be present and what relationships can exist because operations don't give you an ability to use GraphDefinition to define your content.

Josh Mandel (Nov 07 2019 at 18:06):

The organizations building support for RTBC today (if I'm not mistaken) are basically trying to scaffold a FHIR interface for this specific purpose on top of existing infrastructure -- if I understand correctly. As such, I think a specific operation of some kind (whether "generic"/pre-existing $submit or something more tailored like an $rtbc-evaluate) fits the bill.

Frank McKinney (Nov 07 2019 at 19:03):

That’s true, Josh. The CARIN effort can be thought of as an adaptation of the existing provider-oriented RTPBC process for patient use. With the idea of tailoring content to the new context but enabling payers to leverage existing capabilities, to promote adoption

Frank McKinney (Nov 08 2019 at 14:24):

I really appreciate us having this conversation now... good to think this through

Bulleting a few things that are arising... and relating them to this particular CARIN rtpbc effort...

- A pure REST approach wouldn't collect and submit information to the payer, but instead would create a Claim and point the payer to the relevant resources wherever they reside. The payer would grab what it needs, generate a ClaimResponse and notify parties
>> w/respect to this effort (rtpbc): The "real" relevant resources (e.g., the prescription) aren't owned by the party (the 'app') creating the Claim/predetermination. The app also probably doesn't have the info to systematically access them. Instead, the app collects information elements about/from those resources from the patient. What the app collects has been pre-defined by the payer community to be sufficient for pharmacy predetermination

- To John's point, Provenances are used to track the reason, parties, etc. of a resource creation or change
>> the only resource being created/changed in rtpbc is the ClaimResponse (predetermination outcome). A couple things that might be considerations... the ClaimResponse itself captures the key who/what/where/why/when type info, because that's kind of the nature of the thing... a record of a determination based on particular inputs at a particular point in time
>> to that point, maybe a question is whether locking down the information element _values as they existed at the time of the request (e.g., whether the prescription allows substitutions) is more on-point than recording a reference to a possibly-changing resource (where the doctor might later adjust the prescription from 'dispense as written' to 'substitutions allowed')?

- if the fact that the party requesting the Claim/predetermination can't reference queryable input resources leads us to providing the input information in a Bundle parameter to a Claim operation... Lloyd mentioned limimations in specifying/validating the Bundle's content and relationships
>> is this where having a purpose-built operation like @rtpbc-evaluate comes in? Where we could specify separate Patient, MedicationRequest, etc. parameters rather than "a bundle" as allowed by Claim.$submit
>> [this is from my newness to FHIR profiling]: I was thinking our IG could constrain the content of the Bundle for this use, but maybe that's not possible. Can we profile a Bundle to state that it must contain entry.resources of the type RTPBC-MedicationRequest, RTPBC-Patient, etc.? E.g., 'one entry must be a Patient resource that conforms to RTPBC-Patient'?

Thanks again for helping us work this through @Lloyd McKenzie @Josh Mandel @John Moehrke. I'm also looping in @Paul Knapp who is leading some discussion with FM and PIE that's in the same territory
Frank

Josh Mandel (Nov 08 2019 at 14:34):

Hoping Lloyd will weigh in on the formal profiling piece. From my perspective, a couple of notes:

1. I wouldn't characterize "pure REST" as meaning that the PBM app needs to stand up its own FHIR endpoint so that PBM can come back to it for details. (Especially because in this use case, many of these details only exist ephemerally in a user's app session, and not as persistent state.) I think we are getting tripped up on a misconception of "purity".

2. Not everything we specify needs to be expressed in a formal StructureDefinition-backed constraint; the important thing is that our guide works and is easy for developers to follow consistently.

Lloyd McKenzie (Nov 08 2019 at 16:10):

Agree that the app doesn't need to have its own repository so long as it has permission to write stuff elsewhere. The key thing is the ability to query to find what data exists and the ability to point to records wherever they exist and expect other systems to be able to grab them "as needed". If you want to pass a collection of data and say "process this" where what happens to different records is determined by the receiver rather than the client, you're in operation/messaging space.

Josh Mandel (Nov 08 2019 at 18:29):

If you want to pass a collection of data and say "process this" where what happens to different records is determined by the receiver rather than the client, you're in operation/messaging space.

I think that's exactly where we are.

Frank McKinney (Nov 11 2019 at 14:53):

Thanks @Josh Mandel , @Lloyd McKenzie. Feels like the discussion set out the rationale for using an operation to accomplish the RTPBC request/response.
Josh: I agree it makes sense to establish an distinct operation, since RTPBC expects different behavior than the existing Claim.$submit, and nothing in the Claim explicitly flags it as RTPBC. Seems we need to tell the server what exactly we want it to do. Your suggestion of $rtbc-evaluate sounds good to me.
If we were to take advantage of the specific operation and break out the request information into separate input parameters, would you propose using a separate parameter for each resource that contains input information (patient, coverage, medication-request, practitioner, pharmacy-organization)?

Josh Mandel (Nov 11 2019 at 15:38):

Yeah, that's something like what I had drafted at https://gist.github.com/jmandel/fff82af95d2115497b5ccd74a42cfdb0

Frank McKinney (Nov 11 2019 at 17:08):

Okay, I see the earlier Connectathon thread where you proposed this. Sorry for covering this ground again

I see you were proposing that the parameters in the new operation's input and output would essentially replace the Claim and ClaimResponse... which _is pretty different than what the group ultimately pursued. It's attractive to think more greenfield and define just what's needed. Though I do think it's reasonable to consider RTPBC to be a flavor of predetermination as covered in the Claim/Response.

In the spirit of continuity and following the direction of the Fin'l Mgmt WG, I'm thinking it would be best to stick with using the Claim and ClaimResponse to represent the request and response.

But if we submit a Claim request using the existing $submit operation, how would the server know that our $submit operation is expected to be processed as an RTPBC request versus a vanilla predetermination?

Would it be reasonable to define a new operation that (a) specifically returns RTPBC results but (b) still uses the Claim/ClaimResponse resources?

Frank McKinney (Nov 14 2019 at 16:53):

Hi to the folks who will be implementing the consumer RTPBC… Hoping to get your feedback / input on the draft IG, especially the broad strokes approach...
- Use of the Claim.$submit operation (proposed in the Imp Guide). An alternative mentioned by the Financial Mgmt Workgroup is to post the request to the processor’s $process-message endpoint. Do folks have any preferences... especially on the payer/PBM/discount pricing source side?
- Population of the request and response bundles. Request content: anything that’s missing or would be difficult to process. Response: population of…
- the ClaimResponse.item (adjudication for the specific requested med + pharmacy)
- the .addItems (adjudication for alternative med + pharmacy combinations)
- the .processNote (linked to individual .item and .addItem, containing a summary of how the med is covered for the patient (e.g., Covered, Covered requiring PA, etc.). The list of values is in the Terminology menu, Coverage Summary Value Set

Thanks for reviewing and providing feedback

Lloyd McKenzie (Nov 14 2019 at 17:51):

My general leaning is that if you're passing in a Bundle and getting back a Bundle, $process-message is going to give you more control over the content of those bundles and will let you leverage generic messaging infrastructure.

Frank McKinney (Nov 14 2019 at 18:25):

Thanks Lloyd. I also like that that would enable us to state the expected handling in the request's MessageHeader.eventCoding (e.g., "rtpbc-request")

Frank McKinney (Nov 15 2019 at 16:27):

Updated the IG based on input from the thread and the Financial Mgmt WG, along with other refinements:

• Added discussion of submission/response using FHIR messaging to the Submission Method page (renamed from Submit Operation). Added examples of submission / response using messaging. Added an extension (isAlternative) to characterize ClaimResponse.addItem composites as independent alternative fulfillment options (based on feedback from the FM WG). Added a Security page under Guidance, to be further fleshed out through stakeholder discussion.
  http://build.fhir.org/ig/HL7/carin-rtpbc/

Josh Mandel (Nov 15 2019 at 16:40):

Can someone explain the benefit of sub-profiling a totally generic operation like "process-message" rather than defining our own? It seems to me like we're just tunneling one generic protocol (messaging) on top of another (FHIR operations) even though we have none of the routing/delivery requirements of messaging.

Josh Mandel (Nov 15 2019 at 16:40):

What's the advantage, to offset the complexity cost?

Josh Mandel (Nov 15 2019 at 16:41):

(In terms of defining the conformance resources / specifications, does FHIR even have a way to sub-profile an existing operation like $process-message?)

Lloyd McKenzie (Nov 15 2019 at 17:05):

I wouldn't recommend sub-profiling the operation. I would recommend using MessageDefinition to define the content to be sent (and returned back). Because MessageDefinition gives you much more control than OperationDefinition does.

Josh Mandel (Nov 16 2019 at 15:41):

But to be clear, Messages bring a lot of baggage to the table that aren't relevant in this "remote procedure call"-like use case.

Josh Mandel (Nov 16 2019 at 15:41):

(things like sources, destinations, asynchronous response patterns, and so forth)

Lloyd McKenzie (Nov 16 2019 at 19:18):

Yes, though they don't mandate support for asynchronous or routing. Those capabilities are simply available if needed.

Josh Mandel (Nov 17 2019 at 01:19):

And individual parameters can only be specified by their resource type, rather than by specific parameter names. like if you have multiple focus resources of type MedicationRequest, one representing a preferred prescription and one representing an alternate prescription, I don't see a way to label each of these with MessageDefinition.(though I might just be missing something in the modeling machinery).

Lloyd McKenzie (Nov 17 2019 at 02:57):

Right. If you're passing multiple named parameters rather than a Bundle'O'Stuff, then a custom operation makes more sense.

Frank McKinney (Nov 17 2019 at 20:11):

Josh: Do you see the operation's parameters taking the place of the Claim and ClaimResponse resources? In the approaches we've drafted, those resources/profiles characterize the referenced resources (based on the element that's doing the referencing and the target type specified in the profile)

Is this a different way to state what we're discussing... whether to use a custom operation's parameters, profiles of the Claim/ClaimResponse resources (or both?) to define the request and response content?

It feels like using parameters in a custom operation would overlap what the Claim and ClaimResponse do

Josh Mandel (Nov 17 2019 at 20:19):

Agreed there's overlap; I'm advocating for what I see as a more direct/explicit approach (one that for me at least is a lot easier to follow; I am interested to know whether others find these two approaches equally straightforward).

Frank McKinney (Nov 17 2019 at 20:28):

Yes... this is important to think through now versus later.
I'd like to hear what folks on the payer/pbm side think

Frank McKinney (Nov 18 2019 at 18:27):

An updated IG is available at http://build.fhir.org/ig/HL7/carin-rtpbc

• Added an Error Handling section under Guidance and additional material to support discussion of the use of FHIR Messaging versus $submit or a custom operation (Profiles and Extensions page... MessageDefinitions for the request and response, at the bottom of the page).

Josh Mandel (Nov 18 2019 at 18:42):

Thanks! The examples here are extremely helpful. My quick take in comparing the $process vs $submit operation is that they are nearly identical. I don't think the message header really adds anything, but neither does it complicate the situation very much.

Josh Mandel (Nov 18 2019 at 18:46):

In the example payloads, since the client does not necessarily represent a system that would be hosting resources online, it might make more sense to avoid putting "http://example.org"-prefixed fullUrls in the Bundle. Maybe do reference by uuid instead, to avoid the implication that the client would be hosting content?

Josh Mandel (Nov 18 2019 at 18:47):

For locations where a prescription can be filled, it might help to say something more about the expectations for how this is modeled. In other words, this approach uses organizations with street addresses for a particular place, rather than organizations representing a business (e.g., headquarters) plus Location resources representing particular spots where fulfillment can occur. (Either approach seems fine to me but we should pin down the expectations.)

Josh Mandel (Nov 18 2019 at 18:48):

Also, has there been thought about how to represent a virtual service that will mail out medications? I.e., how would this appear in the response?

Josh Mandel (Nov 18 2019 at 18:49):

Similarly, has there been thought about how to represent alternative medications like a generic, versus simply alternative locations to pick up a given exact prescription?

Josh Mandel (Nov 18 2019 at 18:49):

Another issue would be various kinds of hints that the client might provide indicating what sorts of pharmacies the patient wants to use. In dense areas there may be many more options than a PBM wants to individually generate prices for, so it would be good to constrain or filter this list based on patient preferences.

Josh Mandel (Nov 18 2019 at 18:51):

I think it would also be valuable to think about how this API can be used in an "anonymous" context -- in other words if we just want to ask the hypothetical question of how much a patient on a particular plan would need to pay for a particular drug, can this be done without providing full details about who the patient is and what their member number is and what their healthcare provider's identity is? it would be nice to make sure the API can be applied consistently between this anonymous use case and the full identified use case.

Frank McKinney (Nov 18 2019 at 21:05):

Thanks for reviewing, Josh. Great comments

• Good point that using URLs in fullUrl typically won't make sense...I'll change the examples to use uuids instead
• For the alternative dispensing options, I was thinking that the address in the referenced pharmacy Organization resource would be the physical store location (for retail pharmacies)... though I didn't state it... I will now.
• Regarding mail service pharmacies: The NCPDP message we're adapting contains more detail about each dispensing option, including the pharmacy type (mail, retail, specialty...), which we currently don't have in the spec. It wasn't part of the Connectathon content, but I think it would be important to the client... for example when interpreting pharmacy addresses (e.g., display addresses for retail pharmacies but not mail service). I'm going to bring this up on today's Pharmacy WG call... to see if there are any conventions for stating a pharmacy type... I'm thinking that we could define a value set and refer to it in Organization.type
• Re. flagging alternatives / generics. The spec currently would require a client to determine when an alternative (an .addItem) represents a different medication or a different pharmacy... which might not be the best. The NCPDP message uses a very structured, looping format that doesn't transfer well to the ClaimResponse (and also is probably more hierarchical than we need). One thought would be to include an extension that indicates the nature of each alternative option: alternative drug, alternative pharmacy, or both. What do you think?
• Re. tailoring the request to indicate alternative pharmacy preferences. That's a good idea: we can bring it up with the CARIN group (that's not part of the NCPDP message, and I don't know if the group's discussed)
• Re. an anonymous version, that's straying a fair distance from the patient-specific nature of the RTPBC (though that's not to say it wouldn't be useful). A challenge would probably be that the payer systems might be based on their claim processing infrastructures, requiring a patient and prescriber in order to run. But also something we can bring up with the group

Thanks again!

Frank McKinney (Dec 02 2019 at 04:03):

Made updates to the IG (at http://build.fhir.org/ig/HL7/carin-rtpbc)

Couple points where feedback would be appreciated...

• I attempted to create the terminology assets necessary to handle code and identifier systems for which there are no HL7/FHIR URLs (NDC-11.. for which a FHIR URL is in process, NCPDP proprietary code sets, Canadian province code). I created NamingSystem resources, which don't seem to be supported fully in the IG publishing process (they don't appear to establish URIs that can be referenced within the IG). To work around that, I created temporary placeholder CodeSystems and pointed ValueSets and coded elements to them. I put comments to that effect on the terminology pages in the guide... indicating that things would be trued up before publishing. Is that a reasonable way to handle these for balloting purposes?
• The ClaimResponse's addItem composite holds alternatives to the requested med/pharmacy combination. Currently, it doesn't explicitly state whether the addItem represents an alternative drug, pharmacy, or both. The expecation is that the requester can compare to what was requested and determine the difference. Do we want to add indicators to explicitly state what each returned alternative contains (e.g., “requested drug / alternative pharmacy”), or can the client determine on its own?
• Use of the FHIR messaging model would enable implementers to reuse common messaging components that they already have, and might be preferable to using the Claim $submit operation. The guide currently describes both. To our implementers... What are your thoughts, preferences?

Thanks!

Lloyd McKenzie (Dec 02 2019 at 13:06):

I wouldn't create temporary code systems or value sets for naming systems. If the publication tooling isn't working correctly, raise a change request to get the tooling fixed. Errors caused by tooling problems won't stop an IG from being published.

I don't think that addItem is intended to convey alternatives. On an actual Claim, that wouldn't make any sense. @Paul Knapp ?

Frank McKinney (Dec 02 2019 at 15:03):

Thanks @Lloyd McKenzie (also looping in @Paul Knapp )

Handling for proprietary code systems like NCPDPs was discussed in last week's Finl Mgmt call and I believe there's a call being set up for tomorrow morning (Tuesday @10 ET) to talk over with Vocabulary folks. My understanding from the call was that we'd need to use placeholders in the IG... though I could have got that wrong, or executed it wrong. I tried to find a way to create a placeholder that enabled the rest of the profile to validate without errors and look as close as possible to what we expect. I'll do whatever makes the most sense to folks

Re addItems... During a Finl Mgmt WG call we discussed using addItems to represent alternatives and arrived at an approach where we characterize the addItem as an alternative using an extension. That's specified here... http://build.fhir.org/ig/HL7/carin-rtpbc/StructureDefinition-carin-rtpbc-extension-isAlternative.html and here's an example of use... http://build.fhir.org/ig/HL7/carin-rtpbc/ClaimResponse-rtpbc-claim-response-03.html. Interested in your thoughts
Best

Lloyd McKenzie (Dec 02 2019 at 15:48):

If you're dealing with actual code systems, that's fine. I had understood that you were creating code systems for identifier systems - and that wouldn't be appropriate.

Frank McKinney (Dec 02 2019 at 16:08):

There are a couple identifier systems for which I created temporary CodeSystem resources, which I agree isn't kosher. I just couldn't think of an alternative... Is there a way to create an identifier system from scratch in the same way as a CodeSystem?
Thx!

Lloyd McKenzie (Dec 02 2019 at 16:35):

NamingSystem is the proper mechanism. If you're getting validation issues after doing that, then raise a tracker item.

Frank McKinney (Dec 03 2019 at 20:17):

Hi @Lloyd McKenzie . I was chatting with @Lisa Nelson and @James Shalaby this morning about situations where each of us are looking to define placeholder CodeSystems and NamingSystems within IGs we're working on. So I'm inviting them into this thread...

After talking with Lisa and Jim, I think I understand your last comments better ... Let me know if this is correct...

• It's okay to create temporary CodeSystems where a final/official code system URL isn't yet available.
  In the Benefit Check IG that I'm working on, I think an example of this is the 11-digit NDC, for which there's a tracker item currently being worked to create a HL7 url (http://terminology.hl7.org/CodeSystem/ndc-11). In this case, I created a CodeSystem resource, used the expected HL7 URL in the CodeSystem.url element, and then referenced that URL in the .compose.include element in a value set. Is that the right way to do it?

• Creating a CodeSystem to represent an external identification system isn't kosher, even as a placeholder

Thanks! Frank

Lloyd McKenzie (Dec 03 2019 at 20:30):

Technically, you don't need to define a CodeSystem. You can just accept that the proposed CodeSystem isn't official yet. No one should stop you from publishing because of that. For something that's totally a placeholder, make sure that the URL reflects that. E.g. "http://todo/CodeSystem/foo" so that it's pretty obvious to implementers that they should expect change in that space.

Frank McKinney (Dec 04 2019 at 02:05):

Thanks Lloyd. That's helpful

Regarding the publishing error I get when trying to use a NamingSystem to reference a licensed code system... here's an example:

I created a NamingSystem resource to reference an NCPDP pharmacy type code set. I set the NamingSystem.uniqueId element to "http://ncpdp.org/pharmacy-type" and created a value set with that url in the ValueSet.compose.include.system element. When I run the publisher, the QA log contains one error:

Path: carin-rtpbc-pharmacy-type-value-set
Severity: error
Message: Error from server: Unable to provide support for code system http://ncpdp.org/pharmacy-type (see Tx log)

The ValueSet html page still gets generated, but with the following text under Expansion: "No Expansion for this valueset (not supported by Publication Tooling)"... which makes sense since the code system's concepts aren't known to the terminology server. The publisher doesn't compain about the element I have bound to to the value set, and everything else looks like I'd expect.

It seems to me like the publishing process might be completing okay, but it's expecting the terminology server to know about the concepts in the code system defined in the NamingSystem resource (which the server doesn't)

I'm interested in whether you've experienced this, and how you think it should behave

Thanks again

Lloyd McKenzie (Dec 04 2019 at 02:07):

@Grahame Grieve This doesn't seem like it should be an error, but rather a warning?

Grahame Grieve (Dec 04 2019 at 02:09):

I'm not entirely sure I understand this. The server can't expand the value set, that's an error not a warning

Lloyd McKenzie (Dec 04 2019 at 02:11):

Why is that an error for the IG? You're pointing to a value set. The terminology server doesn't recognize the code system. There will be lots of code systems that exist that the TX server won't know about. It's only an error if you expect the TX server to recognize the system.

Frank McKinney (Dec 04 2019 at 02:12):

Hi Grahame. The value set that's causing the error is based on a code system referenced in a NamingSystem resource. (It's a licensed code system from NCPDP)

Grahame Grieve (Dec 04 2019 at 02:13):

The terminology server has been asked to expand a value set based on a code system it doesn't know. I can only return an error that it can't expand the value set

Frank McKinney (Dec 04 2019 at 02:15):

I think LLoyd's saying that it's appropriate for the terminology server to return an error, but the publishing process should expect that and ignore it since it's caused by a code system defined in a NamingSystem resource

Grahame Grieve (Dec 04 2019 at 02:16):

I don't understand the namingsystem thing. There's no reason that nominating some uri in a naming system will result in a value set being expanded

Lloyd McKenzie (Dec 04 2019 at 02:20):

The NamingSystem is unnecessary. It won't help the value set be expanded. But the failure to recognize the system when trying to expand the value set shouldn't be an IG error, just a warning.

Lloyd McKenzie (Dec 04 2019 at 02:20):

Only exception would be if the code system canonical had an HL7 base

Grahame Grieve (Dec 04 2019 at 02:22):

this assumes that the IGPublisher can magically determine which errors you think are only a warning

Lloyd McKenzie (Dec 04 2019 at 02:23):

If the IGPublisher doesn't know if something is an error, it raises a warning. Authors need to review the warnings and either suppress them (if they know they're not a problem) or fix them.

Lloyd McKenzie (Dec 04 2019 at 02:24):

If it raises an error, the only option is to fix the problem - and there's nothing to fix here.

Frank McKinney (Dec 04 2019 at 02:27):

To back up a step... We want to use the NCPDP code system in the IG, but it's licensed. My understanding was that we can make the code system known within the IG by using a NamingSystem. Where I'm sensing I went off track was that I thought I could then bind elements to a ValueSet that refers to the licensed code system.

I know that that wouldn't enable systematic validation of element values, but thought it would provide value in the documentation

Josh Mandel (Dec 04 2019 at 02:28):

In terms of the goals here, what does it mean to "use [NCPDP]... In the IG"? Does it mean reproducing a whole bunch of NCPDP content, or just referencing it? And what specific content?) How will this impact the usability of the guide itself?

Grahame Grieve (Dec 04 2019 at 02:29):

sure that provides value, it's just orthogonal to this problem

Grahame Grieve (Dec 04 2019 at 02:29):

If the IGPublisher doesn't know if something is an error, it raises a warning.

No, it calls it it an error. I'm really mystified why this is suddenly a big deal. It's not like this is the first time it's happened

Josh Mandel (Dec 04 2019 at 02:30):

Are we saying that US developers will need to independently seek a license for this content in order to support this IG?

Grahame Grieve (Dec 04 2019 at 02:30):

for the NCPDP part, yes

Frank McKinney (Dec 04 2019 at 02:31):

Grahame: How I thought that relates to this problem is that the publishing process could know that the underlying code system was defined in a NamingSystem, and use that knowledge to suppress the error

Josh Mandel (Dec 04 2019 at 02:31):

Hmm, and is that an essential part of the guide? How much NCPDP content are we depending on?

Grahame Grieve (Dec 04 2019 at 02:32):

the IGPublisher simply knows that it went to expand the value set, and it got an error back with an OperationOutcome, which it renders as text along with the note that it go an error.

Frank McKinney (Dec 04 2019 at 02:34):

Josh: The reject code set is one that the PBMs will likely want to keep... since their systems use it today and it has a lot of values (and would be the most work to swap out). I've been hoping for some feedback from that side, but we haven't got it yet

Josh Mandel (Dec 04 2019 at 02:35):

These are reasons for rejecting a query?

Lloyd McKenzie (Dec 04 2019 at 02:36):

@Grahame Grieve Do you think we should fail to publish IGs that include valuesets that the Tx server can't expand? Because our expectation right now is zero errors unless they're tooling issues that haven't been fixed yet.

Lloyd McKenzie (Dec 04 2019 at 02:36):

This, to me, is clearly not an error in the IG - so we shouldn't be treating it as such.

Grahame Grieve (Dec 04 2019 at 02:37):

actually, our expectation is that we review the errors. We've published several IG with this error on the grounds that we are ok with it. Of course we're not going to fail to publish it

Frank McKinney (Dec 04 2019 at 02:41):

Josh: Yes. We could conceivably build our own set... which I'd be open to. It would just increase the implementation work on the PBM side if they're leveraging their claim backend (which I believe most will)

Josh Mandel (Dec 04 2019 at 02:42):

I'm wondering if we could away with just two or three high level reasons. I don't have access to NCPDP to know what kinds of things are in there now...

Josh Mandel (Dec 04 2019 at 02:42):

(apologies if this is a totally naive question; I am naive to the domain :-))

Frank McKinney (Dec 04 2019 at 02:45):

Josh: Reasonable questions... I've just gotten used to trying to make things as easy as possible for the payers/PBMs in order to reduce barriers for them. But to your last point, if we could make the mapping from the full NCPDP set to our IGs errors straightforward, that would probably work fine for them

Frank McKinney (Dec 04 2019 at 02:46):

Thanks Lloyd, Grahame. I'm gathering that I can suppress this particular IG publishing error...

Grahame Grieve (Dec 04 2019 at 02:46):

yes

Frank McKinney (Dec 04 2019 at 02:47):

Thanks again everyone

Lloyd McKenzie (Dec 04 2019 at 02:50):

No. You can't suppress errors. You can only suppress warnings. (Which is why I'm arguing w/ @Grahame Grieve :) )

Lloyd McKenzie (Dec 04 2019 at 02:50):

Only exception is broken links.

Grahame Grieve (Dec 04 2019 at 02:53):

well, don't suppress it then

John Moehrke (Dec 04 2019 at 14:40):

Similar need is happening around ISO vocabulary... I am with Lloyd that failure to expand the vocabulary, which is properly defined with a codeSystem system, should be a warning not a error. I don't think this is just an IG problem, as I need to put two ISO vocabularies into AuditEvent and Provenance because the ISO vocabularies are used globally, but currently can't because ISO is not giving HL7 rights to do such. Thus these environments are forced to map to the vocabulary we can use in FHIR core. Thus making FHIR harder to use, not easier to use.

Grahame Grieve (Dec 04 2019 at 16:57):

I don't follow the logic here at all

Lloyd McKenzie (Dec 04 2019 at 18:03):

Pointing to external code systems that the terminology server can't expand will be an increasingly common thing. It should not manifest in the QA as an error - because it's not.

Grahame Grieve (Dec 04 2019 at 18:11):

The logic I didn't follow was John's logic.

Grahame Grieve (Dec 04 2019 at 18:12):

I follow your logic just fine. I just don't agree or don't know how to magic things to the state you want

Lloyd McKenzie (Dec 04 2019 at 18:20):

Don't see how magic is required. In the IGPublisher, a failure of the expand operation should be captured as a warning. In situations like this, where the problem is due to inability to find an external terminology we wouldn't expect to be found, the warning can be added to the suppress list. If it's a temporary thing (e.g. tx server misbehaving) then we leave it as a warning expecting it to soon go away. If it's something that should have expanded, we debug and figure out why it failed. When the FMG reviews balloting and publication requests, we look at the QA - including suppressed messages in making the determination of whether to allow the content to move forward.

I don't see any magic?

Grahame Grieve (Dec 04 2019 at 18:21):

there are multiple reasons why a value set might fail to expand. Unknown code system is one, as is transient errors. but mostly they are errors in the value set definition

Grahame Grieve (Dec 04 2019 at 18:21):

I am not going to call errors in the value set definition a warning

Lloyd McKenzie (Dec 04 2019 at 18:33):

Warnings are possible errors that require human review. Some failures will be true errors. Some won't. Raise them all as warnings and allow the humans to fix the ones that are true errors and suppress the ones that aren't.

Lloyd McKenzie (Dec 04 2019 at 21:21):

Warnings are possible errors that require human review. Some failures will be true errors. Some won't. Raise them all as warnings and allow the humans to fix the ones that are true errors and suppress the ones that aren't.

Grahame Grieve (Dec 04 2019 at 21:29):

that's a fantasy. warnings are ignored

Lloyd McKenzie (Dec 04 2019 at 23:00):

Warnings are not ignored by the FMG - which is the governance that applies here

Lloyd McKenzie (Dec 04 2019 at 23:00):

(We just demonstrated that by rejecting a publication request for an IG that contained resolvable warnings)

Lloyd McKenzie (Dec 04 2019 at 23:01):

Anything that's not fatal is ignored in the core publisher because there's no ramifications to ignoring them

Lloyd McKenzie (Dec 04 2019 at 23:01):

And we turn stuff that should be errors into warnings there because we can't afford for the build to fail.

Lloyd McKenzie (Dec 04 2019 at 23:02):

But the dynamics in that space are completely different from the IG publisher

Grahame Grieve (Dec 04 2019 at 23:08):

The build does not fail. FMG does not look at all guides - in fact, a minority

Lloyd McKenzie (Dec 04 2019 at 23:10):

Right - but the ones that the FMG doesn't look at, there's no penalty for errors or warnings, so it makes no difference.

Lloyd McKenzie (Dec 04 2019 at 23:12):

Either someone's going to look at the QA and deal with it, or they're not. Flagging things as errors that aren't is just going to make those who do look less trustful of the issues raised

Frank McKinney (Dec 10 2019 at 19:13):

Hi @Lloyd McKenzie . We started getting a bunch of new broken link errors in our IG after the IG Publisher was updated late Sunday night. I see in the commiter notification thread that others are getting these too. Prior to the updated publisher, we weren't getting any broken links

The link 'http://hl7.org/fhir/R4/"element-definitions.html#Element.id' for "id" cannot be resolved
Note the errant quote character after ...R4/

It's occurring only in the StructureDefinition page tree table for two elements in (id and extension) on four of our resources. (example: StructureDefinition-carin-rtpbc-coverage.html#/html/head/link/body/div/div/div/div/div/div/hr/div/div/div/div/table/tr/td/a at Line 475, column 903)

If you happen to be familar with this, I'd appreciate any info on how to debug this... or any info if its the publisher and not our IG

If not, where would be the right place for me to post something or otherwise get more info?

Thanks!

Lloyd McKenzie (Dec 10 2019 at 19:16):

It's not tied to the template. @Grahame Grieve, I can't see where in the publisher code this is coming from

Grahame Grieve (Dec 10 2019 at 20:46):

sigh. that's eclipse trying to be clever on me. fixed next release

Frank McKinney (Dec 10 2019 at 20:52):

Thanks Grahame, Lloyd

Josh Mandel (Dec 18 2019 at 21:37):

From today's fmg call, there are three outstanding build errors that need to be fixed if the guide is going to continue on to ballot:

1.  need to get rid of the lower of the two yellow boxes

2. need to update the hl7 logo, and
3. need to fix the footer

Josh Mandel (Dec 18 2019 at 21:37):

@Frank McKinney FYI

Josh Mandel (Dec 18 2019 at 21:38):

(these can be fixed independently or by switching to the standard template.)

Frank McKinney (Dec 18 2019 at 21:40):

Thanks for the heads up @Josh Mandel . I'll make the fixes

Grahame Grieve (Dec 18 2019 at 21:41):

note: switching to the standard template is probably not such a good idea to do at the last minute

Josh Mandel (Dec 18 2019 at 21:41):

Great. (@Pooja Babbrah joined the fmg call just now, FYI.)

Pooja Babbrah (Dec 18 2019 at 21:48):

any advice on what we can do to fix these errors if we don't switch to the new template? @Frank McKinney @Josh Mandel @Grahame Grieve

Frank McKinney (Dec 18 2019 at 21:53):

Hi Pooja. I think I can figure these out... I'll look at it this afternoon

Frank McKinney (Dec 19 2019 at 05:04):

I've made the adjustments identified in the FMG meeting today. If folks could take a look to confirm I covered the issues, that would be great.

@Grahame Grieve : Three unrelated errors arose with the current IG publisher (v1.0.27) that don't show up with v1.0.26...

/scratch/ig-build-temp-L0Z9JL/repo/source/resources/structuredefinition/carin-rtpbc-request-claim.xml
Path Severity Message

• Claim.careTeam.sequence error The fixed value has type 'integer' which is not valid (valid type: [positiveInt])
• Claim.insurance.sequence error The fixed value has type 'integer' which is not valid (valid type: [positiveInt])
• Claim.item.sequence error The fixed value has type 'integer' which is not valid (valid type: [positiveInt])

Here is one of the element definitions that are now causing an error. I believe the error is pointing to the fixed value below... which I think is correctly specified as fixedPositiveInt...

<element id="Claim.careTeam.sequence">
<path value="Claim.careTeam.sequence" />
<fixedPositiveInt value="1" />
<mustSupport value="true" />
</element>

Hoping you could take a look and let me know if I have a mistake I'm not seeing, or if the publisher might have an issue
Thanks

Grahame Grieve (Dec 19 2019 at 05:05):

yes it should be fixedPositiveInt

Frank McKinney (Dec 19 2019 at 05:17):

Thanks Grahame... that's how it's defined in the build that has the errors

Grahame Grieve (Dec 19 2019 at 05:20):

which IG is this? not carin-bb?

Frank McKinney (Dec 19 2019 at 05:26):

No, it's carin-rtpbc

Grahame Grieve (Dec 19 2019 at 05:27):

ok I'll look into it

Frank McKinney (Dec 19 2019 at 05:27):

Thanks again

Grahame Grieve (Dec 19 2019 at 06:22):

wooah. that's a version conversion error. I'll release a fix shortly

Frank McKinney (Dec 19 2019 at 16:33):

Republished using the updated IG Publisher (thanks again Grahame)

Frank McKinney (Dec 19 2019 at 17:20):

@Josh Mandel , @Lloyd McKenzie . I think I've made all the adjustments the FMG identified yesterday. If you could confirm, that would be great. Thanks!

Lloyd McKenzie (Dec 19 2019 at 18:00):

Only thing I see left is this:
History Page 'null' is wrong (ig.json#paths/history) - must be 'http://hl7.org/fhir/us/carin-rtpbc/history.html' or 'http://hl7.org/fhir/us/carin-rtpbc/history.cfml'

I think this is just complaining about the fact that you've got "www." in front of hl7.org in your canonical URL.

Frank McKinney (Dec 19 2019 at 18:28):

Thanks Lloyd. My ig.json was missing the paths/history reference entirely. Fixed now

Grahame Grieve (Dec 19 2019 at 18:29):

actually, it should be .html not .cfml now

Frank McKinney (Dec 19 2019 at 18:40):

Thx. Just changed to .html

---

Last updated: Apr 12 2022 at 19:14 UTC