Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

accessors by key properties Identifier.system, Telecom.system, Telecom.use #8

Open
yogthos opened this issue Jun 20, 2017 · 20 comments
Open

accessors by key properties Identifier.system, Telecom.system, Telecom.use #8

yogthos opened this issue Jun 20, 2017 · 20 comments

Comments

@yogthos
Copy link

yogthos commented Jun 20, 2017 •
edited
Loading

Problem

Currently, telecom is structured using unordered collections:

{"telecom":
  [{"system": "phone",
     "value": "(416) 946-2223",
     "use":"work"}]}

This makes it difficult to address elements within the structure. If we needed to select the work phone, we would need to do one of the following:

  1. transform the structure into one that can be navigated by path
  2. search through the list of elements each time we need to address a particular element

Solution

The solution is to use nested maps to represent the structure:

{"telecom":
  {"work":
   {"phone": [{"value": "(416) 946-2223"}]}
  }
}

It's now possible to select specific types of elements without having to transform it.
@niquola
Copy link
Member

niquola commented Jun 20, 2017

Almost, everybody who developed UI for FHIR server wants this!
The concern, I see, is that such transformation is very application specific.
Approach could be some declarative transformation, which could be configured
for the specific application:

PUT /Transformatin/easy-telecom
{
  id: 'easy-telecom',
  resourceType: 'Transformation',
  path: ['telecom'] , 
  transformation: {indexBy: ['use']}
}

GET /Patient?_transformation=easy-telecom

@lmckenzi
Copy link

A few considerations:

  • what would it look like when use is unspecified? (use is optional)
  • Will this approach make sense for places where telecom is used for organizations, locations, etc. where use is unlikely to be used? (Telecom actually appears in a lot of resources and the notion of 'work' vs. 'home', etc. is only relevant in a small few of them.)
  • For this (and for all JSON-related proposals), will there be any issues with the XML representation? (I think it could work, though it'd be a bit noisier)

@yogthos
Copy link
Author

yogthos commented Jun 20, 2017

I think it would make sense to have a catch all key for use such as unspecified with this approach. Then, any contact information that does not have a specific use could be grouped there.

I don't know if makes sense to try and keep JSON and XML representation in sync. They both have different limitations and very different idiomatic usage. As long as both map to the same underlying semantic model, I think it makes sense to leverage these formats to their best potential as opposed to trying to find the lowest common denominator.

@lmckenzi
Copy link

lmckenzi commented Jun 20, 2017 via email

@grahamegrieve
Copy link

grahamegrieve commented Jun 20, 2017 via email

@yogthos
Copy link
Author

yogthos commented Jun 20, 2017

@lmckenzi

On the other hand, designing the format in a way that makes it difficult to access the data pushes the cost of using it down to all the users of this format. I also agree that these kinds of decisions should be community driven. Have any surveys been conducted to see what challenges the user community is facing, and what are common pain points are?

As far as I'm aware there's no transparent way to track proposed changes to the spec, or what percentage of users would be in favor of any particular change. Zulip is not very discoverable, and it doesn't provide any tools to effectively track and rank issues.

@grahamegrieve

I see a general pattern in FHIR that it uses collections of maps to represent data elements. This is idiomatic when dealing with XML nodes, however it's not the way JSON data is typically structured. Any view of the data will have a trade-off. However, I fail to see how representing data idiomatically, and in a way that it can be easily addressed, is a net negative.

Pretty much in any use case where you actually have to use the data in the payload, you will need to be able to address it efficiently. I think that it's reasonable to expect that the format should be designed with this use case in mind.

Currently, the first thing you have to do with the data received from FHIR service is to transform it into a more usable form before you can work with it. This means that every user of FHIR services has their own ad hoc parser for the format, and this is extremely error prone. I think this has a direct impact on data quality and ultimately patient safety.

@grahamegrieve
Copy link

grahamegrieve commented Jun 20, 2017 via email

@lmckenzi
Copy link

lmckenzi commented Jun 20, 2017 via email

@yogthos
Copy link
Author

yogthos commented Jun 20, 2017

I guess the question here is which use case is the more common one. In either scenario a data transformation would be required for one group of users. This goes back to my question of how it's decided which use case is the more common one.

I do agree that graphQL can help here. If that was part of the FHIR server specification, that would provide the clients with the flexibility to select data in a view that's appropriate to them.

I have looked at gForge, and seems like it is more appropriate as tracker for existing issues as opposed to a forum for feature discussions. Looking forward to trying out the new tool for this once the move happens though.

@lmckenzi
Copy link

lmckenzi commented Jun 20, 2017 via email

@grahamegrieve
Copy link

grahamegrieve commented Jun 20, 2017 via email

@yogthos
Copy link
Author

yogthos commented Jun 21, 2017

The reason I proposed the change is due to the fact how UIs will represent the data. The most common scenario is that you would group your contact information by work/home/etc in the UI. Ultimately, the data has to be shown to the users at some point, so UI representation needs be consideration when designing the data model in my opinion.

As I mentioned earlier, you're necessarily increasing complexity for a particular group of users with either approach. It sounds like you're advocating for the lowest common denominator that's least opinionated. However, if one use case is much more common than the other, it would make sense to favor it. It's difficult to make a call on this without having the numbers available.

Note that I'm not advocating optimizing for a specific EHR, but rather for making the general use case easier.

@grahamegrieve thanks, I'll take a look at the GraphQL docs.

@lmckenzi
Copy link

lmckenzi commented Jun 21, 2017 via email

@niquola
Copy link
Member

niquola commented Jun 21, 2017

@lmckenzi - we started this repo aka incubator for proposals, some discussed and matured ideas definitely will be posted to gForce.

The idea of simplified accessors is a sugar and could be implemented as a library with an informal specification, without moving to FHIR standard directly.

@grahamegrieve
Copy link

grahamegrieve commented Jun 21, 2017 via email

@yogthos
Copy link
Author

yogthos commented Jun 21, 2017

@lmckenzi
I'm not making any assertions regarding what the general use case is. I'm basing the proposal on the fact that it's an issue for me as well as other people I interact with. However, this is clearly anecdotal and only represents my personal understanding of the situation. I have to assume that you're making decisions empirically based on the feedback you collect from the users as opposed to simply using personal judgement.

@grahamegrieve
Copy link

grahamegrieve commented Jun 22, 2017 via email

@yogthos
Copy link
Author

yogthos commented Jun 22, 2017

I agree, GraphQL adds a lot of flexibility for the clients allowing them to select precisely the parts of the resources that they need.

@brianpos
Copy link

brianpos commented Jul 6, 2017

With that suggested representation you'd need to make that representation an array also, as I know lots of people that have multiple mobile numbers for work (and the rank was introduced in STU3 to permit supporting the preference of use).

@niquola
Copy link
Member

niquola commented Apr 12, 2018

Here is the best description of problem and solution I’ve ever seen - https://json-ld.org/spec/latest/json-ld/#data-indexing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@niquola @yogthos @brianpos @lmckenzi @grahamegrieve