Stream: ihe
Topic: Barcode Supplement
Michael van der Zel (Oct 05 2017 at 11:02):
I am working on a barcode supplement, anyone have experience with Barcodes and FHIR? The scope is scan a barcode and get a populated FHIR Resource based on the barcode. The challenge is that a barcode can be a Device, Patient, Medication, Food. So my first thoughts were to define an operation that figures this out. Thoughts?
Jens Villadsen (Oct 05 2017 at 11:46):
Not being entirely sure on what you want, but according to spec you can do the following: GET [base]/?_type=Device,Patient,Medication&_id=[barcode] ... is it something like that you're looking for?
Jose Costa Teixeira (Oct 05 2017 at 11:46):
the barcode is not a resource id
Jose Costa Teixeira (Oct 05 2017 at 11:46):
so you cannot use &_id for the barcode, so you cannot query
Jose Costa Teixeira (Oct 05 2017 at 11:47):
(well, actually that could be a way out)
Jose Costa Teixeira (Oct 05 2017 at 11:48):
i find comfort in the idea of defining an operation. Normally we profile interoperability. Depends on what your supplement is for, but I think I know what supplement is that :)
Jose Costa Teixeira (Oct 05 2017 at 11:49):
may want to check zeora.net/blog
John Moehrke (Oct 05 2017 at 11:55):
Im not sure I understand why it is hard to query the various Resources that you know how to process. It is simply code. You put it on the front, or the back. By requiring it be on the server, you are asking for a special purpose server. By doing the processing in the app, you are able to work in many environments.
Jens Villadsen (Oct 05 2017 at 11:55):
well ... I guess that depends. The barcode could be the ressource id and in that case it would be correct.
Jens Villadsen (Oct 05 2017 at 11:56):
@John Moehrke - special purpose server == some server that fulfills some standard?
John Moehrke (Oct 05 2017 at 12:02):
yes, the special purpose can be a Profile or IG, and thus special in that the Profile or IG is declared as being supported. However 'special' means it is in a population of solutions that is smaller than non-specialized. Thus the body of existing FHIR Servers, non today support your special case.. This is my point indeed. Sometimes a Special purpose server is the right solution, sometimes it isn't. I was just indicating 'Im no sure...' for this use-case. As it seems to me one would want to have this barcode app broadly usable, not tied to a smaller population of 'special purpose' servers... just my opinion on the use-case, not my condemnation of special purpose severs.
Jose Costa Teixeira (Oct 05 2017 at 12:54):
so, searching for the barcode could work if:
a) the server assigns resource IDs for each barcode and you search the _id as you mention
OR
b) there is a common "barcode attribute" for all the resources you mention (if it is not a common attribute, one single query will result in error)
OR
c) the client queries each resource like patient.identifier, medication.code, device.udi.carrieraidc
Jose Costa Teixeira (Oct 05 2017 at 12:55):
problem with a) : how does that work for items that have the same barcode? It's not the same item, should it be the same resource? your inventory managemetn possibilities would become limited because of a technical trick
Jose Costa Teixeira (Oct 05 2017 at 12:56):
problem with b) - not really, simply requires us to harmonize (we're working on it)
Jose Costa Teixeira (Oct 05 2017 at 12:56):
problem with c) - the initial problem we had was that we have a dumb barcode reader, so i would put as little logic there as possible
John Moehrke (Oct 05 2017 at 13:13):
Barcodes should be simply an optically encoded identifier. Any system that doesn't make truly unique identifiers will cause collisions. That is a identity management problem, not a technical or standards problem.
John Moehrke (Oct 05 2017 at 13:14):
If your barcode reader is so dumb, then it won't be able to process the resulting FHIR Resource... thus that barcode reader couldn't be part of this discussion. The discussion is about how to search the FHIR resource space for relevant resources with the identifier given in a barcode. Thus the 'client' that is doing the searching, has some ability to process the resulting FHIR Resource...
John Moehrke (Oct 05 2017 at 13:16):
If that code can process a FHIR Resource, then it has the ability to LOOP through a set of Resources. where that set of resoures is the set of resources that it is programmed to be able to process.
Jose Costa Teixeira (Oct 05 2017 at 18:42):
From my guessing hat: The transactions that Michael is looking at are the following 2: a) dumb app/ barcode reader says "i have something here, i don't know what it is, please decode it; b) the server responds to the app/barcode reader AND/OR eventually sends to the next guy the notice "hey, someone was using a device, with a GTIN number X, with a serial number Y...."
Jose Costa Teixeira (Oct 05 2017 at 18:44):
agree, @John Moehrke that the code can do a loop, but the idea (see the blog post) is that it'd have to loop across resources using different attributes: patient.identifier, then device.udi.carrieraidc, medication.??? (doesn't exist yet).
This has given some ideas, namely harmonize how medication/devices/... use barcodes, because the barcode is a simple way to transmit information. And that information can be a code, an indentifier, or a more complex string
Jose Costa Teixeira (Oct 05 2017 at 18:46):
the requirement from the barcode folks was that the system that sends the barcode may not be the only one that receives the decoding result
Jose Costa Teixeira (Oct 05 2017 at 18:46):
http://zeora.net/blog/2017/09/14/querying-different-items-from-their-barcode/
Jose Costa Teixeira (Oct 05 2017 at 18:48):
the premise that the client that does the search can process the result is not always true (at least as it is defined in the supplement)
Jose Costa Teixeira (Oct 05 2017 at 18:49):
anyway, this lacked some context. These things were discussed in the supplement calls already, and I guess @Michael van der Zel wanted to probe for additional input.
Michael van der Zel (Oct 06 2017 at 06:58):
Yes. I was looking for more input. Thanks @Jose Costa Teixeira for the blog.
My use-case is about interpreting the barcode. If I go the query route there will only be results if the endpoint has some instance of a resource for that barcode. So that won't help me. That is why I think the operation is the only way for my use-case.
Michael van der Zel (Oct 06 2017 at 07:01):
@Jose Costa Teixeira I have a question about the PDQm on your blog. It says you can either send just the patient identifier or the whole barcode. But that means you have to add that whole barcode as an alternate identifier for the Patient right?
Jose Costa Teixeira (Oct 06 2017 at 07:24):
Correct, @Michael van der Zel - the functionality might only be possible if you have an operation. We can go that route, but when you mention "supplement" I think I know the scope, and we are working on transactions, and not functionality.
On the other hand, we can profile an operation as part of a transaction, so i look forward for more discussion on that
Jose Costa Teixeira (Oct 06 2017 at 07:25):
and Yes, if you stick to barcodes as identifiers, the Patient identifier case does require the barcode is assigned as an identifier for the patient resource.
Jose Costa Teixeira (Oct 06 2017 at 07:29):
for operation, are you thinking of smth like " $decodeBarcode?aidcString=012345678 "?
Michael van der Zel (Oct 06 2017 at 07:34):
Yes! Actually "$decode-barcode?aidcString" :-) That looks more consistent with other existing operations.
By the way is "barcode" the most generic name since it could also come from rfid?
Jose Costa Teixeira (Oct 10 2017 at 10:13):
@Michael van der Zel you mean $decode-barcode?<value of the aidc String> or $decode-barcode?aidcString=<value of the aidc String>
Jose Costa Teixeira (Oct 10 2017 at 10:13):
i think the latter,right?
Michael van der Zel (Oct 10 2017 at 10:27):
Yes. The latter.
Jose Costa Teixeira (Oct 10 2017 at 10:40):
and can we have operations across resource types? or we have to define an operation for device, another for medication...?
Jose Costa Teixeira (Oct 10 2017 at 10:42):
in practice: i am a dumb barcode reader. How do I say "I have no idea what this is, i just have the barcode".? surely I can't send a resource... and what is the response?
Michael van der Zel (Oct 10 2017 at 11:36):
My thoughts are that the barcode device sends the barcode to the consumer (some application) that then uses the barcode processor to decode the barcode into a resource. So the consumer is the actual application that does the FHIR request.
Jose Costa Teixeira (Oct 10 2017 at 11:38):
ok, that is covered and if that were the initial scope, it would have made our life a lot easier.
Michael van der Zel (Oct 10 2017 at 11:39):
Then the barcode consumer can fill all the other fields, like Device name, Manufacturer name, reference to patient (when the barcode is something else than patient ;-), etc. etc. Or it can request for an existing Resource based on the decoded fields.
Jose Costa Teixeira (Oct 10 2017 at 11:39):
idd. scope-wise, we want something very small: Just decode the barcode string
Jose Costa Teixeira (Oct 10 2017 at 11:40):
do we send the barcode string in raw form? or base-64? at this moment I am leaving that open, i.e. readers can send whatever they want and the operation has to be defined to support that.
Michael van der Zel (Oct 10 2017 at 11:42):
The datatype for aidc in FHIR Device is Base64.
Jose Costa Teixeira (Oct 10 2017 at 11:42):
:) i know, it was a lot of work to make it so.
Michael van der Zel (Oct 10 2017 at 11:44):
The operation should detect what form is used. How do barcode(rfid) readers normally do this?
Jose Costa Teixeira (Oct 10 2017 at 11:45):
but can we expect a barcode reader to be able to push base-64 content ? and do we limit ourselves to that?
in some cases the barcode string is just ascii
Jose Costa Teixeira (Oct 10 2017 at 11:46):
afaik, rfid readers can be just a unique number, or can actually contain some data. Don't know how they provide the "string"
Michael van der Zel (Oct 10 2017 at 11:48):
Can we expect some device driver that handles that. The Consumer then gets the ASCII barcode from the Reader through the driver? So the Consumer uses the ASCII HRF for the query.
Jose Costa Teixeira (Oct 10 2017 at 11:48):
consumer is not in this picture. the one that gets the raw string is the barcode processor
Michael van der Zel (Oct 10 2017 at 11:54):
In FHIR terms I see the processor as being the Operation implementation, right? It receives a barcode and decodes it and returns the appropriate Resource.
Jose Costa Teixeira (Oct 10 2017 at 11:56):
yes
Michael van der Zel (Oct 10 2017 at 12:04):
Sorry. I am a bit lost I think..
We want to use the operation. That means that there is an endpoint that gets queried trough a REST query with the barcode in the parameter and a resource as response. That is the way it works. The current transactions look more like MESSAGING (HL7 v2). That is a different paradigm.
Jose Costa Teixeira (Oct 10 2017 at 12:04):
yes, sorry, we had that discussion some time ago.
Jose Costa Teixeira (Oct 10 2017 at 12:04):
the idea is:
Jose Costa Teixeira (Oct 10 2017 at 12:05):
sometimes you send a resource and you do require a response (if you are a smartphone app)
Jose Costa Teixeira (Oct 10 2017 at 12:06):
but other times, if you are just a cashier, or an inventory dumb barcode reader, you say "i found this, not sure who cares"
Jose Costa Teixeira (Oct 10 2017 at 12:06):
that was the assumption we made for scope
Jose Costa Teixeira (Oct 10 2017 at 12:07):
in case 1, which is the most common, the barcode reader and the consumer are the same system
Michael van der Zel (Oct 10 2017 at 12:18):
You could use FHIR in a messaging fashion, but that feels odd. Cannot we define a difference sequence in the FHIR REST case?
Jose Costa Teixeira (Oct 10 2017 at 12:19):
the point is not about messaging or not. The idea is how do we support that the barcode reader may not be the final destination of the content?
Jose Costa Teixeira (Oct 10 2017 at 12:32):
if we have an answer to that, our life may be much easier
Michael van der Zel (Nov 01 2017 at 07:28):
I was wondering if there are minimal requirements for an Implementation Guide? For example if you define a new Operation, say decode-barcode. You need a couple of artifacts to fully describe what it does. In FHIR terms these are OperationDefinition, OperationOutcome, some Profiles, a CapabilityStatement so that you can check if a server implements this operation, and then you wrap all these things in an ImplementationGuide.
Jose Costa Teixeira (Nov 01 2017 at 19:03):
At this moment, even the ImplementationGuide is (wisely, i'd say) out of scope of IHE deliverable packages.
Jose Costa Teixeira (Nov 01 2017 at 19:04):
we are defining what should be the implementation materials
Michael van der Zel (Nov 03 2017 at 13:08):
Yes. You are right. I meant the "Implementation materials". I did a first pass at them. Were shall I put them?
Jose Costa Teixeira (Nov 03 2017 at 13:09):
if you mean a first pass at a list: here(?)
if you mean a first pass at the actual resources: here? mail? here is ok, i guess
Jose Costa Teixeira (Nov 03 2017 at 13:09):
in any case, thanks! we need to get onto an agreed set of deliverables.
Jose Costa Teixeira (Nov 03 2017 at 13:10):
John is creating a folder structure in the FTP site
John Moehrke (Nov 03 2017 at 14:53):
Hi Michael. See my instructions to IHE profiles on fhir http://wiki.ihe.net/index.php/Guidance_on_writing_Profiles_of_FHIR
Michael van der Zel (Nov 03 2017 at 15:54):
I am working on the IHE UBP profile FHIR artifacts here: github.com/mvdzel/ihe-ubp-fhir
My point was that the OperationDefinition is not mentioned on your instruction page.
There is also a partial demo impl on top of HAPI for it.
John Moehrke (Nov 03 2017 at 16:27):
understood... i added mention, that we don't yet have lessons learned to convey.
Michael van der Zel (Nov 26 2017 at 08:41):
@John Moehrke At the last FHIR DevDays we created a TestScript for running in Touchstone. I think it makes sence to also include TestScript and related resources in the Guidance on writing profiles page. Do you agree?
Michael van der Zel (Nov 26 2017 at 08:42):
I think IHE should also publish the FHIR artifacts in Simplifier since that is the place were the FHIR community will look.
John Moehrke (Nov 26 2017 at 17:39):
Hi @Michael van der Zel the guidance I have published does have the conformance resources published through Simplifier to the FHIR Registry. As to TestScript, I would agree that they should be developed and also published. I would consider TestScript resources just as critical to an IHE Profile (FHIR Implementation Guide) as the other conformance resources. I am surprised that TestScript resource is not within the conformance group on the FHIR specification.
Last updated: Apr 12 2022 at 19:14 UTC
