Stream: social
Topic: LOINC codes supported
Apra (Sep 25 2019 at 14:17):
I have an app A that can give blood pressure. I want to integrate this with another app B.
Apra (Sep 25 2019 at 14:18):
Now, when the app A is first installed on the device, I want A to register with app B and tell it what LOINC codes it can give. In this case, blood pressure
Apra (Sep 25 2019 at 14:19):
what resourceType should be sent from app A to B?
Apra (Sep 25 2019 at 14:30):
And once app B knows the LOINC codes it can get from app A, it needs to tell app A what type of request it will send. (in this case, a serviceRequest) How can app B inform A about this during initial setup?
Gino Canessa (Sep 25 2019 at 14:42):
This is a bit outside my area, but from browsing around I would guess that the Device and/or DeviceDefinition would suit for describing the capability of App A to App B.
That said, what is the registration you are referring to? If it is an out-of-band registration process, I would assume that the registration process needs to know about the capabilities. At minimum, App B would need to know how the capabilities are defined, since just posting a resource wouldn't link anything between the two, and there is no guarantee that an arbitrary App B even supports a given resource.
For your second question, the CapabilityStatement includes resources and which ones are supported, though it's not the same workflow you are describing. An endpoint (e.g., App A) has a CapabilityStatement and App B can check to see if the operation it wants to use is supported. This makes sense, because if App A does not support serviceRequest, there is no negotiation which will add that during registration.
If you are developing both apps (A and B), then I think those resources should work. If you are asking about a generic procedure, I don't believe there is one (yet).
Ewout Kramer (Sep 25 2019 at 16:38):
It would be best to move this discussion to the implementers stream!
Gino Canessa (Sep 25 2019 at 16:47):
lol, I didn't even notice which stream it was on (default view is 'all' for me =). Guess I should watch for that. Is there a process for moving topics, or is is just a matter of starting one on the new stream?
Grahame Grieve (Sep 25 2019 at 19:25):
The key resource here is ValueSet which actually specifies the list of codes. The others are glue to establish context for the value set
Apra (Sep 26 2019 at 08:11):
The key resource here is ValueSet which actually specifies the list of codes. The others are glue to establish context for the value set
Thanks Graham. This does look useful. I see we can send supported LOINC codes here. However, in addition, we also need to tell additional stuff to app B - ex: app B has to send an intent call with the right intent name. So, app A also has to inform app B of the intent name. Ex: com.test.appA
Apra (Sep 26 2019 at 08:11):
It does not look like ValueSet can help with this. or can it?
Apra (Sep 26 2019 at 08:19):
The key resource here is ValueSet which actually specifies the list of codes. The others are glue to establish context for the value set
Thanks Graham. This does look useful. I see we can send supported LOINC codes here. However, in addition, we also need to tell additional stuff to app B - ex: app B has to send an intent call with the right intent name. So, app A also has to inform app B of the intent name. Ex: com.test.appA
Maybe we could use useContext->valueQuantity and code to indicate intent name and its value. I see an example in the FHIR doc page where they include age here
Apra (Sep 26 2019 at 09:42):
In addition, I want app B to tell app A the format in which it will send a FHIR message
Apra (Sep 26 2019 at 09:43):
I guess StructureDefinition should help here?
Grahame Grieve (Sep 26 2019 at 11:20):
Well, StructureDefinition or operationdefinition sets the context for the value set. But it’s not clear to me what you mean by your context
Apra (Sep 26 2019 at 11:40):
@Grahame Grieve : I use something called Android intent to have app B communicate to app A. For this, app B has to know the name of the intent. It has to send this while sending a request to A.
Apra (Sep 26 2019 at 11:41):
So, app B basically needs to know the following: the intent name (for reasons I just mentioned above) and the LOINC codes supported.
Apra (Sep 26 2019 at 11:42):
I thought using useContext->valueQuantity and code may help here. I could send valueQuantity as the intent name.
Apra (Sep 26 2019 at 11:42):
If that is not the case, pl let me know.
Apra (Sep 26 2019 at 11:44):
The description for useContext also says: "The context that the content is intended to support"
Grahame Grieve (Sep 26 2019 at 22:54):
hmm. we haven't really talked about how to use FHIR content in places like Android intents. I've never done any actual mobile development, but iOS has something similar, right? Is there enough interest to do standardization work in this space?
Apra (Sep 27 2019 at 07:28):
@Grahame Grieve , I think iOS also has something similar to Android intent, but not too sure. Never done iOS app development before.
Apra (Sep 27 2019 at 07:30):
To begin with, I'm a little new to FHIR. When I went over the description of the various fields in ValueSet, I thought using "useContext" would help us send the intent name.
Apra (Sep 27 2019 at 07:32):
If you think the above cannot be used for the use case I am targeting, then how do we proceed? Do we need to introduce new fields or do something so that this use case is addressed
Apra (Sep 27 2019 at 07:32):
Pls suggest
Josh Mandel (Sep 27 2019 at 14:14):
I'm confused about the requirements here. Why does app B need to tell app A ahead of time what kinds of requests it will send in the future? Why not establish the details of what app B needs inline, when app B is actually making a request to app A? In other words, you could have B start A with something like startActivityForResult, and define a generic intent like "Request FHIR Data" with an Bundle (er, Android Bundle, not FHIR Bundle) that conveys the details. You might even model this after the FHIR REST API, where the intent bundle has data like:
{
"query": "Observation?category=vital-signs&code=8480-6"
}
Josh Mandel (Sep 27 2019 at 14:15):
(Apparently I too am failing to take this away from #social.).
René Spronk (Sep 27 2019 at 16:46):
(to me social is like announcements: a must read - so please take this topic to implementers. No talking shop on this channel, please)
Josh Mandel (Sep 27 2019 at 18:20):
To check on expectations: I think the Social channel is definitely not designed to be must-read (but I agree this topic belongs on #implementers ;-))
Lloyd McKenzie (Sep 28 2019 at 01:59):
I think @René Spronk is just really #social ;)
Last updated: Apr 12 2022 at 19:14 UTC
