Stream: implementers
Topic: Which FHIR resource contains medication solution (ex: NS)
Sylvia Freeman (Jun 28 2018 at 18:01):
Hello, I am looking for some validation on which FHIR resource to use for a medication solution such as Normal Saline. I believe it may be
the ingredient in the Medication resource. If this is the correct resource, is the solution always the last ingredient? Thank You
John Silva (Jun 28 2018 at 18:36):
It will be interesting to see the answer for this. In the HL7 V2.x world this would come from the RXC-1 (Component Type) field marked as 'B' (Base) typically. I'm wondering how people map this to FHIR Medication ingredient[x]? The HL7 v2 Mapping (http://build.fhir.org/medication-mappings.html#v2) on the FHIR Medications page doesn't seem to help with this.
Lloyd McKenzie (Jun 28 2018 at 18:38):
There is no fixed rule for what order the ingredients are listed in. You can use ingredient.inActive = false to indicate that it's not an active ingredient but, at present, there's no standard way to differentiate the 'base' from any other excipient ingredient. @Melva Peters @John Hatem thoughts?
Jose Costa Teixeira (Jun 28 2018 at 19:33):
MedicationKnowledge is expected to have ingredient role as a property.
Lloyd McKenzie (Jun 28 2018 at 19:34):
The notion of "base" is most relevant with compounds and custom IVs. And in both of those cases, there probably wouldn't be a MedicationKnowledge resource.
Jose Costa Teixeira (Jun 28 2018 at 19:39):
I'm wondering that since medicationknowledge has an ingredient role, medication.ingredient.isActive could actually become medication.Ingredient.role.
Jose Costa Teixeira (Jun 28 2018 at 19:41):
But yes if we have the need to convey whether something is an excipient or a solvent vs adjuvant or active substance, this is medication.ingredient.isActive
Sylvia Freeman (Jun 28 2018 at 19:48):
Thank you very much for the responses! I will use the medication.ingredient resource for the solution and the medication.ingredient.isActive to indicate whether it is a medication or a solution.
John Silva (Jun 28 2018 at 21:45):
@Lloyd McKenzie @Jose Costa Teixeira -- aren't there other uses besides compounds and IVs that have a non-active (non-medicine) ingredients? For example, the elixir in cough syrup is some kind of 'sugar/water' syrup that is only used for the delivery of the medicine but is not the active ingredient. If the Medication resource is truly used to represent all 'stuff' in the formulary, will it need to represent all of these ingredients? (I suppose there might be cases where some non-active ingredient is something that a patient is allergic or have a reaction to, e.g. a diabetic to a sugar based elixir. Is the active property sufficient for this? Aren't there some 'drug databases' that have fully enumerated lists of ingredients for the drugs in the DB?)
Jose Costa Teixeira (Jun 28 2018 at 22:27):
@John Silva yes there are other use cases. The medication resource is not intended to represent all stuff in formulary, but yes it will also need to support these ingredients. e.g. magistral preparations. No, the "active" does not seem sufficient for all this but it was there from the initial 80% scope initially defined. We can consider bringing this to Pharmacy but perhaps later as the medicationknowledge (which is really a medication Definition) becomes more mature.
And yes, there are drug DBs and for those the MedicationKnowledge exists
Melva Peters (Jun 29 2018 at 02:33):
If you are prescribing, dispensing, administering or recording usage statements, then the Medication resource is the appropriate one to represent the medication. There are examples in the MedicationRequest resource where the medication is compounded such as an IV bag. The MedicationKnowledge resource is intended to be used to "drug information" type content. You can represent Normal Saline in this resource too with the ingredient attributes, but the context for the resource is different than for Medication.
Melva Peters (Jun 29 2018 at 02:34):
It is possible that some of the attributes that are added to MedicationKnowledge may be added to Medication (such as the "base" notion), but no decisions have been made at this time. We will work on harmonization as part of the second phase of the project.
John Silva (Jun 29 2018 at 03:01):
@Melva Peters - how is a system going to maintain the "linkage" between the prescribed Medication and the dispensed and the administered drug without having a unique identifier to tie them all together? As Jose pointed out, the prescribed Medication would not yet have a serialNumber or lotNumber, only the resource.id, which isn't something the source (CPOE/PIS/EHR) knows about.
John Silva (Jun 29 2018 at 03:15):
As an exercise -- I went through all of the "top-level" resources listed on the FHIR page under Administration, Clinical, Diagnostics, Medications and Workflow and ALL except the Medication resource have an (external) identifier property; curious as to why Medication is the only one that doesn't. (didn't go to the 2nd level page under each of the top-level resource types)
Lloyd McKenzie (Jun 29 2018 at 06:04):
Medication linkage is generally by code - and then it's not a direct linkage. For example, the prescription might be for Tylenol (a kind) and the dispense might be for Tylenol 100mg capsules (also a kind). To confirm the link, you need a terminology service. The same thing can happen in the device space (e.g. ordering syringes)
John Silva (Jun 29 2018 at 09:58):
Are you saying the the terminology service in this case is going to know about all the drug kinds in your pharmacy? Is this really an interface to the formulary system or a drug database? What I'm still having a problem with is that if the order and dispense are both pointing to a drug (kind) then the administration has to point (reference) a drug (instance), how can it do that when the admin system only knows about 'external identifiers" (i.e. not the resource.id created by the FHIR server) yet the FHIR server only has the code (kind) identifier? This also seems to be a problem in the device space where patient-level traceability is required, e.g. by UDI (an external identifier) in the case of a device recall (but device does have an identifier property.)
Lloyd McKenzie (Jun 29 2018 at 10:15):
Administration will point to the order by id. But the drug pointed to by the order and the drug pointed to by the administration won't be the same. The only linkage between them would be in a terminology system. Drug recall wouldn't be driven by the order records, they'd be driven by the administration and dispense records and they'd look at drug code and lot number.
Jose Costa Teixeira (Jun 29 2018 at 11:02):
Device is hopefully going to address this issue of linking instance to kind, perhaps we should take an example between medication and devices and see what to do from there
Lloyd McKenzie (Jun 29 2018 at 11:04):
You can't have instance link to kind
Lloyd McKenzie (Jun 29 2018 at 11:05):
The instance could link to 30+ different kinds - because the order could specify all sorts of different levels
Lloyd McKenzie (Jun 29 2018 at 11:07):
I don't understand why OO is proceeding with the split of Device in the first place.
Jose Costa Teixeira (Jun 29 2018 at 15:31):
How would an instance link to more than one kind?
Lloyd McKenzie (Jun 29 2018 at 16:56):
"Lot 152347 Tylonol 100 mg caplets" is an instance of Tylenol, Tylenol 100mg, Paracetamol, Paracetemol Caplets and a whole bunch of other concepts - any one of which might have been prescribed, or possibly dispensed.
Jose Costa Teixeira (Jun 29 2018 at 17:05):
Aaahhh. I see it as : Lot 152347 (Tylenol 100 mg caplets), where (Tylenol 100 mg caplets) is the commercially available product. The rest is a chain of concept descriptions. There is no "lot xxx of Tylenol" .
Lloyd McKenzie (Jun 29 2018 at 17:07):
But the point is that any one of those concept descriptions could be the ordered med. You have no idea which one to point the "instance" to.
Lloyd McKenzie (Jun 29 2018 at 17:07):
Which is why it makes sense to just leave it to the terminology - no need to establish any linkage at all - except perhaps on the "knowledge" side of things.
Jose Costa Teixeira (Jun 29 2018 at 17:08):
We can prescribe Acetaminophen and dispense Tylenol 100 mg caplets and yes, the link resides somewhere in that terminology.
Lloyd McKenzie (Jun 29 2018 at 17:08):
That's how existing systems handle it - figuring out relationship between different levels of medication products is always handled by the terminology server.
Lloyd McKenzie (Jun 29 2018 at 17:08):
No need for instance to point to kind. (And not clear it's advantageous or appropriate to split instance and kind at all.)
Jose Costa Teixeira (Jun 29 2018 at 17:10):
Yes, agree there. In an administration you would capture an instance of the "commercially available" product, the rest of the links are somewhere.
Lloyd McKenzie (Jun 29 2018 at 17:12):
Maybe. Or you might just point to a kind because you don't track the instance detail and you use the same instances as were in the prescription
Lloyd McKenzie (Jun 29 2018 at 17:13):
I'm trying to understand the push to separate kind from instance in Device and Medication - because I can see both concepts being used throughout the order/event lifecycle.
Jose Costa Teixeira (Jun 29 2018 at 17:14):
My preference for the approach taken by Device is this:
Jose Costa Teixeira (Jun 29 2018 at 17:16):
Applied to this medication, we capture the baecode of Tylenol 100 mg caplets lot 152347. This actually means scanning a string that says : product xxxyyyzzz (which is a code that identifies a kind) and instance data (lot and expiry)
Lloyd McKenzie (Jun 29 2018 at 17:19):
Maybe. But you can also have systems that just point to the same med instance as was in the prescription. And even if they do capture a code, there's no guarantee there'll be any instance data.
Jose Costa Teixeira (Jun 29 2018 at 17:24):
Agree. Instance data is not guaranteed. But you still want to capture "I just scanned one instance of xxyyzz", and I don't give details about which instance
Jose Costa Teixeira (Jun 29 2018 at 17:25):
If you say ' I just gave one paracetamol to this person because that is what was requested', you can but you are simply inheriting what was in the order
Jose Costa Teixeira (Jun 29 2018 at 17:30):
Systems need to support the case of identifying a product (kind and optionally instance) unrelated to the ordered product
Jose Costa Teixeira (Jun 29 2018 at 17:32):
Point is: order product X, dispense product Y. Instance data is of product Y. If product Y is matching product X, that is another question
John Silva (Jun 29 2018 at 20:57):
And there is the traceability aspect when it comes to an instance -- for controlled substances or 'custom mixed drugs' there might need to be an instance notion that is more precise than lot (hopefully serial number can perform that role).
I have another related question, coming from the HL7 V2 Order workflow, but I want to formulate (pun intended) my ideas first -- hopefully with a diagram showing the different parts of the workflow in an attempt to understand how FHIR Med-resources address/fit this workflow. (i.e. the difference between ORM/OMP, RDE, RDS (dispense?) and RAS -- but for another day)
Jose Costa Teixeira (Jun 29 2018 at 21:32):
OMP=medicationrequest (+patient+...+medication)
RDE=same as OMP
RDS=medicationDispense (+patient+...+medication (possibly with instance info))
RAS = medicationAdministration (+patient+...+medication (possibly with instance info))
Jose Costa Teixeira (Jun 29 2018 at 21:34):
Patient specific preparations would get a lot or serial number (depends if we need to distinguish each one, or only to the level of each batch)
Lloyd McKenzie (Jun 30 2018 at 00:27):
I just don't understand the reason to have two resources - what implementation requirement is driving that choice?
John Silva (Jun 30 2018 at 11:10):
Thanks @Jose Costa Teixeira -- some additional thoughts
OMP (un-encoded order, could even be 'free text' -- therefore the drug ordered would be a Kind, e.g Tylenol, in RXO-1 or RXO-6 , RXO-9 allow substitution)
RDE (encoded order, the drug is Kind but closer to instance, e.g. Tylenol 100 mg tablets, in RXE-2, RXE-9 - allow substitution)
RDS (dispense encoded order's drug, drug seems to be an instance now, e.g. could be Acetaminophen 100 mg caplets (generic from a specific drug company, with lot info, possibly even serial number for 5-rights tracking, especially if controlled substance!!, this instances of a drug could already be in a lock-cabinet with intention of administration for a specific patient at a specific time) RXD-2, RXD-20 indicates if drug was substituted, RXD-18 lot number, RDX-20 -> RXD-24 indication drug manufacturer and package info, RXD doesn't seem to have serial number though, maybe RXD-25 - supplementary code?)
RAS (actual admin'd drug, drug is definitely an instance now, RXA-5, RXA-15 lot#, RXA-18 manufacturer info, doesn't seem to have serial number though, maybe RXA-2 = admin sub-id counter?)
So, the $64,000 (or $1 million) question is --- how to map all of this to FHIR Med resources? What happens with the drug codes in each of the V2 messages (RXO-1, RXE-2, RDS-2, RXA-5)? How are these to be posted in FHIR bundles, with only drug codes (no 'business identifiers')? In other words, the sending system (V2) doesn't know about internal FHIR resource.id's so typically uses the ifNotExists with the identifier so that the FHIR server can resolve the external 'business identifier' to the FHIR internal resource.id. If the bundle contains the ifNotExists with the code, then the resource reference within the bundle can be resolved between the MedRequest's medicationReference and the Medication within the same bundle. But later on, when the MedAdmin comes in with it's medicationReference that could be using a different instance of the Medicaiton (drug)? Is this handled by having that MedAdmin bundle simply not use the ifNotExists so that it always creates a new Medication that is uniquely tied to the MedAdmin (by resource.id)?
Andrew Gledhill (Jun 30 2018 at 12:00):
I attach a UK IV infusion prescribing (Medication.request) dataset which 'might' be useful for FHIR server testing and possibly clarifying the important detail in this thread.
In UK secondary care (hospitals) the prescriber will either prescribe by:
1. Medication (generic) product name
or
2. Medication active ingredient(s) only
or
3. Medication active ingredient(s) + Form
When the nurse administers the medication then the manufacturer + batch number + expiry date of both the medication_product and the iv_diluent are recorded.
IV-infusion-dataset-HL7-FHIR-test-resource.xlsx
Lloyd McKenzie (Jun 30 2018 at 14:22):
If you don't have an existing Medication to point to, you have the option of a contained Medication
Lloyd McKenzie (Jun 30 2018 at 14:22):
That's what you'll typically use when you're not pointing to something explicit from a formulary
Lloyd McKenzie (Jun 30 2018 at 14:22):
(The formulary could be instance-specific (listing lot and/or expiry) or not when dispensing or administering)
John Silva (Jun 30 2018 at 15:34):
@Lloyd McKenzie Huh? The MedAdmin and MedRequest only seem to have the possibility of using a full medicationReference (pointing to a FHIR instance of a Medication, resolved by the bundle post) and a medicationCodatableConcept -- but that doesn't have full 'instance info' from what I can see, so how can you use that?
Jose Costa Teixeira (Jun 30 2018 at 15:52):
You can have contained resources
Jose Costa Teixeira (Jun 30 2018 at 17:06):
From what Lloyd tells, in a dispense or administration you can point to a resource that represents an "instance".
Jose Costa Teixeira (Jun 30 2018 at 17:09):
If the server has a medication resource for our Tylenol 100 mg tablets, named med001,
Jose Costa Teixeira (Jun 30 2018 at 17:09):
You prescribe med001
Jose Costa Teixeira (Jun 30 2018 at 17:10):
If you administer 1 tablet of Tylenol 100 mg, with lot a123, then either:
Jose Costa Teixeira (Jun 30 2018 at 17:12):
a) you have a resource in your server called med00101 which represents the physical Tylenol with that lot, and in the administration you point to med00101 and NOT to med001 (otherwise you lose traceability)
Jose Costa Teixeira (Jun 30 2018 at 17:13):
b) you get the data from med001, you"append" the lot number to it, and thus data is a new resource called "med00101" which you can contain in the Administration resource
Jose Costa Teixeira (Jun 30 2018 at 17:15):
Possibly this is what @Lloyd McKenzie means when he says that the formulary can be instance-specific. Although I would rather call that "inventory" because we are then talking about quantities, positions...
Lloyd McKenzie (Jun 30 2018 at 17:44):
In a dispense or administration you can point to a resource that represents an "instance" or a "kind" or you can just specify a code.
I didn't call it inventory because there's no requirement that you track inventory quantities in order for the system to know that particular lots are avaailable
Jose Costa Teixeira (Jun 30 2018 at 20:27):
Yes, "inventory" may be overloaded. I don't mean inventory control, but simply inventory items. Agree there is no need to track quantities. And indeed in dispense or admin we can point to kind, to instance or just mention a code.
Melva Peters (Jul 01 2018 at 18:29):
If you look in the MedicationRequest examples, you'll see examples that include a code only (e.g. RxNorm, NDC, etc), or a contained resource where you may want to include additional attributes about a medication (like in the case of extemporaneous medications and IV bags, etc
John Silva (Jul 01 2018 at 23:06):
@Melva Peters - thanks, a little hard to find which of the set of the example MedRequests had a contained resource, found this one: http://build.fhir.org/medicationrequest0322.json.html (I didn't realize the concept of 'contained' resources; however, even with the contained med resource, the FHIR server is going to replace the ' "id": "med0317" with the server-generated id (random from the perspective of the ordering system and a V2 message feed.) I'm still stuck with the problem of how does the source V2 system know which Medication resource on the server is associated with the MedReq it sent in without a 'business identifer'?
Lloyd McKenzie (Jul 01 2018 at 23:40):
I'm not really understanding the question. We don't generally use business identifiers for reference even when they exist. References are done by URL. In the case of a contained resource, it's a local reference. If you're converting to v2, you'll grab the request and the referenced medication and populate the v2 segments accordingly.
Andrew Gledhill (Jul 02 2018 at 10:57):
I have updated the IV infusion spreadsheet with FHIR 'timing' descriptions/information which should also be of use as a FHIR Medication.Request training resource.
IV-infusion-dataset-HL7-FHIR-test-resource.xlsx
John Silva (Jul 02 2018 at 11:24):
I suppose I'll have to post samples V2 RDE and RAS messages to illustrate the problem. (It's the conversion from V2 to FHIR, not the other way around. Remember, most legacy systems are V2 not FHIR so the need is to convert from V2 to FHIR.) Actually, the same thing occurs with ORU messages converted to FHIR Observations; but at least there we have an identifier property (business identifier) that we can control from the V2 mapping process to allow us to later on update an existing FHIR Obs resource, e.g. when there's a corrected lab value. The V2 world doesn't know about FHIR references and FHIR internal ids so using the identifier gives us a way (with the ifNotExists in bundle messages) to provide the linkage between the V2's identity and the FHIR's identity.
John Silva (Jul 02 2018 at 11:45):
RDE^O11 - Order message (note ORC-2 (Placer#) and RXE-2 (Give Code):
MSH|^~\&|CPOEs^172.3.2.44^DNS|Facility^172.3.2.45^DNS|||20101207133655||RDE^O11|MC-ID-1|P|2.4|
PID|||456789||Jones^Mary||20040328134602.1234-0400|F|
ORC|XO|PN-1234|FN-1234||IP||12^TID&0430,1230,2030^D4^20101207133655^20101211133655^S^^^^^^12||20101207133655||||||20101207133655|
RXE|12^TID&0430,1230,2030^D4^20101207133655^20101211133655^S^^^^^^12|1234-ABCD^Acetaminophen^NDC|750||mg^milligrams^ISO+|
RXR|PO^By Mouth^HL70162|
So, without an identifier available for the FHIR Medication resource the only thing I can code is the RXE-2 as the FHIR Medication.code. The problem is that because that Medication.code is a Kind or might have been an instance Medication that was created by a previous order from another patient!! If I use the bundle ifNotExists it would pick up whichever one the FHIR server happens to have. If, on the other hand, the Medication resource had an identifier property (business identifier) the V2 mapping used the combination of the ORC-2 and RXE-2 to create a unique identifier for this drug that would then create (or use) the Medication instance on the FHIR server specifically used by this MedicationRequest Order. Also, later on when this Medication is administered (assuming for argument sake that it was the same NDC code/drug that was administered) the RAS message would be able to refer to the same Medication by identifier since the RAS message would have the same ORC-2 and RXE-2 values and then the ifNotExists would find the same * instance * of the Medication (w/o needing to know the FHIR server's internal id). Notice another benefit, there would be traceability to the specific Kind of drug ordered, encoded, dispensed and administered, in the case where the specific drug used changed during the medication workflow, i.e. from 'Tylenol' (OMP ordered) to 'Tylenol 100 mg tablets' (RDE encoded) to 'Acetaminophen 100 mg caplets' (RDE dispensed) to 'Acetaminophen 100 mg tablets' (RAS administered)
RAS^O15 Administration message: (Note: same ORC-2 (Placer#) and RXA-5 (Admin Give Code) )
MSH|^~\&|CPOEs^172.3.2.44^DNS|Facility^172.3.2.45^DNS|||20061012013000.1234-0500||RAS^O17|MSG001|P|2.4|
PID|||456789||Jones^Mary||20040328134602.1234-0500|F|
ORC|NW|PN-1234|FN-1234||IP||12^TID&0430,1230,2030^D3^20061012050000-0500^20061016050000-0500^S^^^^^M5&&ISO+^48||20061012050000-0500||||||20061012050000-0500|
RXA|1|1|20061012013000.1234-0500||1234-ABCD^Acetametophin^NDC|850|mg^milligrams^ISO+|||||||||||||CP|
RXR|PO^By Mouth^HL70162||||^routing instrs
Lloyd McKenzie (Jul 02 2018 at 11:54):
Right. So in both of these cases you'd use a contained medication because there's no "identity" information in the v2 instance that would allow you to determine that multiple messages talking about the "same" medication are in fact pointing to a shared maintained formulary entry. I.e. the information you have about the medication isn't enough to create a stand-alone resource because v2 doesn't have an "identifier" for the medicaiton.
John Silva (Jul 02 2018 at 12:10):
So, if I understand you correctly, in the MedicationRequest (and MedAdmin) the contained Medication resource will NOT create an actual Medication resource on the FHIR server,is that right? OK, that might work.
However, a similar situation happens in ORU messages, but I don't think the contained 'trick' will work there. If I have an ORU message I can use the OBR-2 (Placer#, aka Accession#) along with the OBX-3 (Obx Identifier) and the OBX-14 (Date/time of Obs) to provide a FHIR identifier that can be used with the ifNotExists so that later on, when there is an update for this specific value, the bundle would use the same identifier in the ifNotExists with request=PUT (update).
BTW, this is one of the things we were interesting in learning more about at FHIR DevDays, but I'm not sure if these more complicated mapping topics were discussed. In the FHIR spec web pages the V2 mappings are somewhat sparsely populated (and sometimes completely missing) to give guidance for those of us working with V2 interfaces. Mapping from the "legacy V2" world seems like it should have more "traction" in the FHIR community since to bring the "existing HL7 world" into the FHIR world, it's going to happen from two main paths --- the legacy V2 path and the new 'green field' FHIR apps path. (I'm ignoring the V3 path, not sure there was ever much of a footprint of V3 in 'production environments')
Jose Costa Teixeira (Jul 02 2018 at 12:19):
Right, the contained medication resource will not be stored on the server.
Lloyd McKenzie (Jul 02 2018 at 12:19):
I'm not understanding what you'd be creating with the ORU/OBR/OBX. If you're creating an Observation, then that's fine - I'd expect you to have enough information in a v2 message to do a create. Though the "if not exists" is going to need to take into account corrections too. That wouldn't change the date/time of Obs, but could mean a need to replace the existing instance.
John Silva (Jul 02 2018 at 12:30):
Yes, the ORU message, with combo identifier from OBR-2, OBX-3 and OBX-14 would be used as the identifier for the FHIR Observation identifier and the URL for the ifNotExists. The first time the specific ORU's OBX is mapped the FHIR Observation would be created because the request=POST would be used. If, later on a correction, e.g. to a lab result, came in, the same OBR-2, OBX-3, OBX-14 would be used for the identifier (would be the same as the original one) and ifNotExists URL, but with request=PUT to cause the FHIR server to update the specific instances of the FHIR Observation. To put it more precisely, with the example RDE message I showed above it would end up creating this URL for the ifNotExists: (NOTE, if the OBX-14 doesn't exist HL7 V2 rules imply that the date/time is the same as the OBR-7 and that's what's used - JSON snippet)
"request"="PUT"
"ifNotExists"="Observation?Identifier=PN-1234_ABCD_20101207133655"
Lloyd McKenzie (Jul 02 2018 at 12:39):
If you can trust that order of events is enough to confirm you should update, then that will work.
John Silva (Jul 02 2018 at 13:50):
Or we can use request=PUT every time since the FHIR rules (if I interpret them right) for bundle processing say that a PUT will do an add if the resource in the ifNotExists doesn't already exist.
Lloyd McKenzie (Jul 02 2018 at 13:53):
PUT requires that you specify the id - and that the server allows the client to decide on the id.
John Silva (Jul 02 2018 at 14:03):
Is this the one cases (exception?) where the client is able to 'influence' what the FHIR server uses for it's internal id or are you talking about something else. (I guess I need to go back and read the bundle REST processing rules page again.) I thought that on any add operation the FHIR server always creates the internal id so it is guaranteed to have a unique id.
In https://www.hl7.org/fhir/http.html#transaction it seems to imply that it is not safe to allow the client to control internal ids:
"When processing a batch or transaction, a server MAY choose to honor existing logical ids (e.g. Observation/1234 remains as Observation/1234 on the server), but since this is only safe in controlled circumstances, servers may choose to assign new ids to all submitted resources, irrespective of any claimed logical id in the resource, or fullUrl on entries in the batch/transaction."
Ah, interesting, reading further in that same section it describes the V2 problem I'm asking about:
"When constructing the bundle, the client may not know the logical id of a resource, but it may know identifying information - e.g. an identifier. This situation arises commonly when building transactions from v2 messages. The client could resolve that identifier to a logical id using a search, but that would mean that the resolution to a logical id does not occur within the same transaction as the commit (as well as significantly complicating the client). Because of this, in a transaction (and only in a transaction), references to resources may be replaced by a search URI that describes how to find the correct reference:"
Lloyd McKenzie (Jul 02 2018 at 14:05):
On a POST the server sets the id. On a PUT to a non-existent location, the server MAY allow the record to be created there. However, giving clients control creates the risk of collisions, so typically this will only be allowed if the server uses GUIDs as ids and the client PUTs a resource with a GUID for its id. (Though if there's a single dedicated client or you're cloning records from another server, you might not be limited to only GUIDs.)
John Silva (Jul 02 2018 at 14:09):
Yes, but our V2 clients and the V2 messages are not going to have GUIDs for uniqueness so we need to ensure that using the identifier approach. (Yes, the V2 mapping agent could create/keep its own mapping table between V2 identifiers of some kind to a GUID and use that, but that overly complicates things.)
I guess this has gone outside of the original question (yeh, for sure); should I really move this thread to the 'v2 to FHIR' stream? ( https://chat.fhir.org/#narrow/stream/32-v2-to.20FHIR ) Are there others who are interested in these V2 mapping questions? It seems like there are lots of corner cases that make it non-obvious and sometimes not tractable to provide a way to map V2 to FHIR. Argh!
Lloyd McKenzie (Jul 02 2018 at 14:16):
Moving probably makes sense. And there will absolutely be places where mapping v2 to FHIR REST will be difficult or impossible.
Last updated: Apr 12 2022 at 19:14 UTC
