Stream: implementers
Topic: mobile applications and PGD
Lauren Wolejsza (Jan 24 2017 at 17:43):
Hi! I am working on a government contract that involves implementing a FHIR API for multiple mobile applications that provide the capability for patients to enter their own health-related data. Given the existing FHIR standard in meant for EHRs, we are encountering a challenge in identifying what resource or field(s) make the most sense to identify the "source" mobile application for incoming patient-generated data and then ensuring this data attribute is maintained through data updates from the mobile application. Also, we want to ensure that is more than one mobile application provides the same patient the ability to enter the same/similar data points that we are able to differentiate the data for analytical purposes. Ideally, we want to be able to go to the database schema and pull together all the data generated for a patient or patients from one mobile application vs. another mobile application. Long-term, we look to integrate web-based applications and wearable device data as well. At this time, we are early in development and can make changes as necessary. Any advice you can provide would be appreciated and thank you in advance for your assistance!
John Moehrke (Jan 24 2017 at 19:49):
You should be able to identify the application as a Device.. Such as Observation.device. If further attribution is needed, then a Provenance record can link ANY Resource to the authoring device.
Lauren Wolejsza (Jan 24 2017 at 19:54):
Thanks! This is helpful. We were considering Provenance, but not entirely clear on how this works given it does not appear to be directly referenced in the JSON. Also, the data model team actually plans to have Provenance as a field in each collection yet their justification for this method of use for Provenance is clear as mud. If you are familiar with this method could you or someone else here provide some insight?
John Moehrke (Jan 24 2017 at 20:58):
Yes, I am one of the core people working Provenance. Provenance resource points at the resources it describes. So in order to find the provenance of any resource X, you ask for Provenance resources with target eq X...
John Moehrke (Jan 24 2017 at 21:00):
some blog articles of mine on the topic https://healthcaresecprivacy.blogspot.com/2016/03/provenance-vs-audit-it-is-not.html and https://healthcaresecprivacy.blogspot.com/2016/07/extending-fhir-standard-to-handle.html
Lauren Wolejsza (Jan 24 2017 at 21:09):
Thanks! Again, very helpful!
Lauren Wolejsza (Jan 25 2017 at 15:04):
@John Moehrke Another question based on the information in the first referenced blog. If Provenance only recording Create and Update, how do we ensure that any Read of data via FHIR resources is from one particular mobile application and not from multiple mobile applications? We would like to avoid the case where Patient A's data from App 1 appears in App 2 and vice versa. Is there something specific that has to be done to ensure the data integrity per source aka mobile application?
John Moehrke (Jan 25 2017 at 15:53):
Lauren, that would be access control rules. FHIR does not impose any security policy. Defining and implementing security (or any business rules) would be up to a service/application implementation/deployment. FHIR i just defining a data model and interaction model.
Lauren Wolejsza (Jan 25 2017 at 15:57):
Okay, this makes sense and helps with our refactoring efforts. We will be utilizing a combination of shared services and the HAPI FHIR API for each mobile application so we should be able to figure this out. Thank you!
Brian Postlethwaite (Feb 02 2017 at 22:08):
And the action of it occurring would be via AuditEvent resources
Lauren Wolejsza (Feb 03 2017 at 14:21):
@Brian Postlethwaite Thanks! However, we are not implementing all available FHIR resources for our patient-generated FHIR API and database. In our particular situation, we are not looking to include AuditEvent resources and only plan to use Provenance. Our challenge is gaining a clear understanding of Provenance, how the data gets stored, what if anything we need to include in the JSON requests for each mobile application applet, etc. We are early in our refactoring work to change the mobile application endpoints to HAPI FHIR API with a MongoDB database backend. The MongoDB will also be FHIR compliant with a governance process included as well. Any other insights you all have would be helpful as we continue this effort over the next few months.
Lauren Wolejsza (Mar 28 2017 at 12:46):
Good Morning!
Our team has done a great deal of research and still trying to solve this problem of patient-generated health data (PGHD) that is collected by mobile applications. We are using a HAPI FHIR API and have reconfigured it to use a MongoDB instead of the out of the box database server. This was done to stay in line with other existing shared services that the HAPI FHIR API cannot support that are necessary to various mobile applications.
Our challenge still remains to determine the best method to identify PGHD records with the mobile application from which it is collected. Provenance will not work as it does not support the necessary pagination we need in our applications nor allow us to filter every request appropriately.
Given this information, our next best option is to use the Identifier field (CodeableConcept array) and insert a coded concept to identify each mobile application for each PGHD record created/updated/deleted. It is our intention to use one HAPI FHIR API server and one MongoDb server to collect all the PGHD data from various mobile applications.
What are you thoughts on this approach? It appears to work for our needs and does not require additional development for our API. The only other option we have entertained is adding an extension to every FHIR resource to collect this information. We would prefer not to use extensions and stay as closely as possible to the FHIR DSTU2 standard as possible for data governance and compliance reasons.
Appreciate your thoughts on this!
John Moehrke (Mar 28 2017 at 13:04):
Lauren, Can you explain better what it is you want to do? I understand the that you have tried using Provenance, but I don't understand what you were trying to do that was not possible. You might have uncovered something we need to do to Provenance. It is possible what you want to do is in scope for tags - e.g. the Integrity vocabulary from security-labels? It is hard to know what it is you are trying to do.
Lauren Wolejsza (Mar 28 2017 at 13:16):
Hi @John Moehrke! More specifically, we want to be able to specify the source, aka mobile application, of the PGHD that is stored in the MongoDB. The reason for this is because we have an aggregating mobile application that will be displaying PGHD from other PGHD applications and we need to be able to filter. For example, patient enter glucose test results into Mobile App A and Mobile App B. Provider then wants to see only glucose test results entered by the patient from Mobile App A. Another example would be for the patient as we only want records entered by that patient within the given mobile application to be returned and not display all records of that patient across mobile applications. Without the ability to filter the records within a resource by "source", we cannot limit the amount of data that is returned to the provider or the patient in either example. Our HAPI API developers have identified issues with using Provenance in this way at each request level. Does this help? I will see if I can invite our lead HAPI API developer as I am uncertain if he uses the FHIR chat area. Thanks!
John Moehrke (Mar 28 2017 at 13:31):
Provenance can be used to record the provenance of any data, identifying which application the data came from. In that case the application identity would be included as a Provenance.agent. Either by pointing to a defined Device using whoReference; or where that application isn't defined in a Device then use the whoUri with some locally defined URI as a unique identifier. During search you can then filter on Provenance agent search parameter.
John Moehrke (Mar 28 2017 at 13:37):
so you want to do a query against something like Observation, for Observations recorded by Provenance.agent.whoReference==App-A.....
John Moehrke (Mar 28 2017 at 13:40):
you could do the Observation search using _revinclude=Provenance and then locally process the separation of App A from App B. I am not sure, ignorance, how you can add to your Observation search a Provenance specific search filter...
Lloyd McKenzie (Mar 28 2017 at 13:50):
The only way to filter on multiple resources simultaneously right now is with the filter search language, though that's not widely supported.
John Moehrke (Mar 28 2017 at 14:16):
Lloyd, I had hoped I as just not understanding http://build.fhir.org/search.html#revinclude properly... It is hard to read and grok.
John Moehrke (Mar 28 2017 at 14:17):
so, it seems Lauren could use filter search language? Thus add a requirement to their servers to implement filter? else do the filtering on the client as I uncovered.
Lloyd McKenzie (Mar 28 2017 at 14:48):
Right. Or not use Provenance. I agree that the documentation about _revinclude is a bit misleading as the inclusion of "&criteria..." makes it appear that you can apply criteria to the included resource, but that's not what that means. It just means additional criteria for the search on the primary resource. There's no sequencing to search parameters so whether the criteria come before a given _include or _revinclude or after make no difference to their meaning
John Moehrke (Mar 28 2017 at 14:52):
Third option, which is less good, is to define a set of tags for each App... And use the _tag search parameter.
John Moehrke (Mar 28 2017 at 14:54):
Might being able to specifically search by Provenance.agent be a useful enough capability that FHIR-I could add it globally somehow?
Lloyd McKenzie (Mar 28 2017 at 14:55):
You can do _has
John Moehrke (Mar 28 2017 at 14:58):
so in STU3 today the http://build.fhir.org/search.html#has does seem to support Lauren's use-case...
John Moehrke (Mar 28 2017 at 14:59):
GET [base]/Observation:_has:Provenance:agent=MyAppId
John Moehrke (Mar 28 2017 at 14:59):
right?
Lloyd McKenzie (Mar 28 2017 at 15:09):
yes, that should work
Lauren Wolejsza (Mar 28 2017 at 17:12):
@John Moehrke & @Lloyd McKenzie, Thank you for this insight! I will certainly share this with our developers. Are any of the options you provided supported in DSTU2? This is the version we are currently using until our client gives us the green light to move up to STU3.
Lloyd McKenzie (Mar 28 2017 at 17:17):
_has is not supported in STU2. _filter is, but as mentioned is not widely supported - and it's unlikely anyone will look at implementing it for STU2 now that STU3 is out.
Lauren Wolejsza (Mar 28 2017 at 17:21):
Understood. Does our current approach make sense? We are considering just using the Identifier field to identify the source mobile application as this field is available in all Resources. Although our use case may not be ideal to fit into Identifier, it appears to be a feasible option given it is already a filterable field for majority/all Resources we are using to date. Thoughts?
John Moehrke (Mar 28 2017 at 17:24):
the identifier of the clinical Resource? I don't think that is a good solution. The identifier is to be an identifier of that data, not the source of that data. I might recommend either an extension, or the _tag solution.
Lauren Wolejsza (Mar 28 2017 at 17:38):
Right. We agree it is not the ideal use case or purpose of Identifier, however, it is our least path of resistance at this time. Of course, we will further investigate these other options. We prefer not to do extension unless absolutely necessary but this of course may be an exception.
At some point in the near future, there are plans to eventually "merge" the PGHD and EHR data together thus making this need to identify the source of the information even more necessary. We do also fully appreciate we are trying to make FHIR fit for PGHD when it is meant to more formally support an EHR.
Lloyd McKenzie (Mar 28 2017 at 17:44):
It would be better to use an extension or a tag than to mis-use identifier
Lauren Wolejsza (Mar 28 2017 at 17:58):
Okay, I completely agree. I am reviewing tag as part of the meta data. Question: Where is this stored? For example, could an analyst query records from the MongoDB that contains the PGHD and filter on this meta data? My understanding was this meta data is not captured explicitly as the sited fields of each resource are in the standard specification. However, we are likely to use the API between applications.
John Moehrke (Mar 28 2017 at 18:15):
Tags are in the Resource http://hl7.org/fhir/DSTU2/resource.html . They are just common elements among all Resources. So they are just as much a part of the Resource as any element.
Lloyd McKenzie (Mar 28 2017 at 19:07):
Tags are often not part of the signature, so they work well for information that you want to attach in your local system distinct from what came in.
Lauren Wolejsza (Mar 28 2017 at 19:19):
Sounds good! Will let you know if I have questions.
James Butler (Mar 28 2017 at 20:59):
It would be a bit weird to use a tag to hold the source identifier, seeing as tags are Codings. In general, entities which can be identified get Identifiers, and concepts which can be enumerated get some kind of code/Coding/CodeableConcept. We used an extension for recording source info.
Grahame Grieve (Mar 28 2017 at 22:52):
So this sounds like all observation. What are you using Observation.device for?
Eric Haas (Mar 29 2017 at 00:31):
That is what I originally thought, but Observation.device is described as the device that "took the measurement" . Here it sounds more like a way to record and store it and send it. So if I enter what I ate into my phone's app does teh phone app count as the device? What about if entered a glucometer reading?
Grahame Grieve (Mar 29 2017 at 00:32):
right. I'm not sure. there's a grey zone here
Grahame Grieve (Mar 29 2017 at 00:32):
but this seems to come up fairly often in PGD - maybe we should add a core extension?
Eric Haas (Mar 29 2017 at 00:34):
What did you do in the mHealth mappings ? - I was looking for them before responding.
Eric Haas (Mar 29 2017 at 00:39):
GF#13144 logged to look at this
Grahame Grieve (Mar 29 2017 at 01:56):
I cna't find them
Lauren Wolejsza (Mar 29 2017 at 13:02):
@Eric Haas & @Grahame Grieve, Thank you for this insight! We would not store this in Observation.device as in future efforts we will need to utilize this field to capture the remote monitoring medical device information. We are looking for a solution for every CRUD operation request to capture/keep the mobile application source so we can differentiate which mobile application the patient entered which type of information. Our mobile applications vary in what they collect. The flagship mobile application provides patients the ability to enter everything from self-assessments, daily events, glucose readings, sleep tracking, food consumption, exercise activity, surgeries, planning for appointments, hospitalizations, medications, and much more. The idea is to capture a complete picture of a patient's medical history and ongoing events in one place and then this data be displayed to providers both within the VA and in the private sector.
I see the ticket you created so wanted to be clear about our use case. This PGD would include both remote monitoring medical devices as well as self-entered medical information.
Lauren Wolejsza (Mar 29 2017 at 13:06):
@James Butler Yes, we are considering the extension to each resource as an option as well. Our API developers are still reviewing so I am assisting in getting additional information of potential options.
Lauren Wolejsza (Mar 29 2017 at 13:11):
@John Moehrke & @Lloyd McKenzie The challenge I see with using Resource.meta.tag is it appears to be an attribute of all records within a Resource. Please correct me if I am wrong here. If this is true, this would not work as we would need to differentiate records within a resource by mobile application source. For example: App A collects only glucose readings and this would be stored in Observation. App B collects cholesterol, glucose, weight, sleep, and more and would also be stored in Observation. How do you differentiate between Observation records with the same LOINC/SNOMED codes across mobile applications aka source of PGD?
PS - I am still learning FHIR and schedule to take the fundamentals course next month. I am testing options in a public HAPI FHIR API server.
Thanks again!
John Moehrke (Mar 29 2017 at 13:22):
My thinking was that you would create a set of codes, one for each App. Each App would tag the data they create with their value. Thus for any code X, would only appear in resources that application X created. I expect you would manage elsewhere what each application can do. I might still not understand the full details of your use-case.
Lloyd McKenzie (Mar 29 2017 at 14:16):
@Lauren Wolejsza Resource.meta.tag is specific to each instance. Different Observations can (and will) often have different tags.
Lauren Wolejsza (Mar 29 2017 at 14:16):
@John Moehrke , One of our developers actually tried the tag option and it appears to be working. I must of had something incorrect. He is using PostMan and more easily able to manipulate the request URL.
Eric Haas (Apr 20 2017 at 18:24):
@Lauren Wolejsza Can you explain why the Provenance Resource is not being considered for recording the gateway appliance or mobile app? (too 'heavy', not able to easily search?, etc? I need to discuss GF#13144 to the work group and they have asked for more background on the use case.
Lauren Wolejsza (Apr 20 2017 at 19:59):
@Eric Haas - Based on the discussion in this thread and the fact that we are utilizing a Mongo-based HAPI FHIR API, we are unable to search on Provenance. As I understand it, the search capability for Provenance we would utilize is available in STU3, however, we are using DSTU2 right now. We are utilizing the resource.meta.tag for now and this appears to be working beautifully. Ideally, we would prefer to use Provenance as this is most appropriate, however, it does not work for our use case of tracking the mobile application where the patient is editing information captured by our HAPI FHIR API and MongoDB backend. If you need more details, please let me know.
John Moehrke (Apr 21 2017 at 13:16):
so... you are stuck at DSTU2...and could use STU3 Provenance if you were able to use STU3? Please keep us informed if you find problems with STU3 Provenance. I really encourage use and improvement.
Lauren Wolejsza (Apr 21 2017 at 13:23):
@John Moehrke - I agree that moving to STU3 would be better, however, its a government contract and we are confined to DSTU2 right now. I am actually going to do an impact analysis to determine the technical debt of moving from DSTU2 to STU3 which first and foremost would require us to develop a new HAPI FHIR API configured with a MongoDB backend.
Last updated: Apr 12 2022 at 19:14 UTC
