Stream: smart
Topic: Patient Launch And The Distributed Patient Record
Brian Forbis (Jul 30 2020 at 19:24):
Sort of a X-Post from a topic I put in implementers https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Distinguishing.20Patient.20Record.20.22types.22.20within.20Patient.2Elink
Though this question is specific to SMART standalone launch.
The Patient resource allows for patient records to be distributed using patient links of "seealso". These links solve problems where a patient record might be operating multiple working copies based on the structure of a hospital's organization (eg: One org might deal with clinical data, another one with billing data, and yet another one with behavioral health information).
So if a standalone patient launched app launches with just a single patient ID (rather than an MRN identifier which might link multiple patients together), should that app only be able to be used to retrieve a single org's details at a given time, or would the patient/* scopes also allow for the app to follow patient links to other distributed records? Is there guidance on this per the SMART spec, or is that totally up to the implementer?
Isaac Vetter (Jul 30 2020 at 21:46):
Hey Brian, there is not guidance in the SMART spec. There's a number of ways you could break this down, though:
- Is there really a single authorization server, such that it can authorize the app for access to each distinct record on each FHIR server?
- Can the FHIR patient id "link multiple patients together" / be known by each system, in the same way that your proposed MRN is?
Brian Forbis (Jul 31 2020 at 20:07):
- Is there really a single authorization server, such that it can authorize the app for access to each distinct record on each FHIR server?
Yes, in my case the authorization server can give access to all records and each record can be linked together (via Patient.link, or by following other references in returned resources). They are also all ultimately part of the same FHIR resource server, though are divided up among different managing organizations within the bounds of that resource server.
- Can the FHIR patient id "link multiple patients together" / be known by each system, in the same way that your proposed MRN is?
Any patient within the distributed patient set would be known, which is how the Patient.links can be built. Though I don't think an individual Patient ID has the same purpose as an MRN, if that is what you are suggesting.
For example, you may have a distributed patient set with ids 1,2,3. To get the union of all Observations for those patients, you could do
- GET /Observation?patient=1 (Get observation JUST for patient 1)
- GET /Observation?patient=2 (Get observation JUST for patient 2)
- GET /Observation?patient=3 (Get observation JUST for patient 3)
Or, more simply you could just do:
- GET /Observation?patient.identifier=https://some.system.mrn|12345. (Get observations for all patients with this MRN, just so happens to be 1,2,3)
I suppose what I'm asking about is whether directing app developers to follow patient links and perform queries against each linked patient ends up breaking interoperability some way? If a generically written smart patient app (write once, run everywhere) does all of their queries using something like GET /Observation?patient=123 because that is the ID they were launched with, but that doesn't provide the full collective patient record, it seems like this puts that patient launched SMART app at a disadvantage. They need to know to follow the links to get the full record.
So in this scenario, does it make sense to instead do a standalone launch against an MRN identifier, rather than against a single patient record? I don't think this type of launch really exists, as all launches are around specific resources, not around identifiers.
Michele Mottini (Jul 31 2020 at 22:43):
If you are in the US your server will work differently than all the common ones and not be US Core compliant. If you'll have developers targeting specifically your server that would be probably OK, if you'e expecting general apps to connect (eg AppleHealth) they would just not work correctly
Cooper Thompson (Aug 03 2020 at 13:12):
On issue to consider when taking the union of Observations, is that you may need to account for de-duplication if any of your systems communicate (for example) lab data with each other. Just doing a naive union may be dangerous for some data sets. For example, if one system has a "No Known Allergies" allergy, and another has the actual allergy data, then taking the union means you are presenting ambiguous information. Similarly, if you have two Condition resources that represent the same issue, one which is marked as resolved, and one which is marked as active, if you just union, then it isn't clear what the status of that condition is.
Last updated: Apr 12 2022 at 19:14 UTC
