Stream: implementers
Topic: Person Patient Practioner attributes overlap
John O'Gorman (Jun 03 2018 at 17:06):
Relatively new to FHIR. I wss wondering why there is such a large overlap between the attributes for Person, Patient and Practitioner.
I am using a model that separates Person from Role (and Location(Coordinates) from Location(Place) from Physical Asset(e.g . 'Calgary Children's Hospital' but let that go for now) and it seems that under the current model there are some risks on the data quality front.
My question is: Would it not be better to keep 'Address' information in one place and associate it primarily to the Person resource and then, depending on the context, associate it that same 'block' to Person(Patient) and/or Person(Practitioner)?
Grahame Grieve (Jun 03 2018 at 20:07):
this is partially a question of denormalization. Should we force all systems to use person, and for all clients to fetch person as well as patient/practitioner? The current arrangement has been debated several times, and denormalization is something that generates continual debate and is quite hard to land. But there's also the fact that across healthcare, people collect and treat data for different roles differently (and legislation like GDPR is making that more pronounced, not less). In fact, very healthcare applications have the some data for both - Person would be an artifical construct. We defined it for the few systems that are actually person repositories.
John O'Gorman (Jun 03 2018 at 21:10):
Thanks Graheme
"... across heathcare, people collect and treat data for different roles differently..." exactly. However, if one of the objectives of FHIR is to make healtcare information semantically interoperable, would it not make sense to start with making it structurally agnostic? By extension, if we make the test for existence - and identity - of Person independent of Role, would we not have more flexibility to declare, for example: We know who this Person is independent of the Role, Location or Application?
I know I've come late to the party, but I have successfully demonstrated the efficacy of the model with GDPR... just wondered how FHIR came to the design decision. Thanks.
Grahame Grieve (Jun 03 2018 at 21:15):
yes, if that was our only goal, that's definitely what we would have done. But our primary goal is to support interoperability, not force people to make their data semantically consistent
John O'Gorman (Jun 03 2018 at 21:17):
You mean 'technically interoperable'?
Grahame Grieve (Jun 03 2018 at 21:19):
you could call it that, yes
John O'Gorman (Jun 03 2018 at 21:19):
Sorry - misspelled your last name on previous comment
John O'Gorman (Jun 03 2018 at 21:22):
So... if I could demonstrate a way to make data 'semantically consistent' within the FHIR architecture without messing with the current standard, that would be beneficial?
Grahame Grieve (Jun 03 2018 at 21:23):
yes for a given marginal sense of 'beneficial'. The data is not how it is because developers don't know how to create semantically consistent data, but because all sorts of business imperatives force people the other way. The most important of which is legacy data, or 'we are bound by our past mistakes'
John O'Gorman (Jun 03 2018 at 21:35):
Agreed on the 'developers/business' tension to a point, but would argue that no developers I know could work to a standard of semantic interoperability across enterprise applications even if they were asked to. As you say, the priority is 'fit-for-(a particular) purpose'.
WRT legacy data. My business partner and I responded to an RFI from BC Health in Canada to rationalize 40 soon-to-be decommissioned applications with 40Tb of data into an 'off-line' reference store of patient data. The idea is to be able to access this patient history (Post go-live of the new Uber App, in this case Cerner) and get an application independent, integrated view of patient medical history.
I think we can add something of value here... 'Home FHIR for Legacy Data' ?
John O'Gorman (Jun 04 2018 at 11:26):
Is there a need for FHIR Legacy Data applications?
Grahame Grieve (Jun 04 2018 at 11:43):
I'm not sure what you are asking
John O'Gorman (Jun 04 2018 at 11:50):
Maybe I'm not sure, either... I'm coming at healthcare data from a purely semantic POV - On a technical scale I am for all intents and purposes practically illiterate.
Having said that, would it help the FHIR cause to demonstrate its interoperability capabilities on low risk, high impact remediation of legacy data?
Grahame Grieve (Jun 04 2018 at 12:53):
I think we've got a few runs on the board, but more runs on the board are always good. Perhaps your best goal would be to get your application here: http://www.fhir.org/implementations/registry. This would allow you to describe your work in a multipage PDF document. Work is scheduled on this in a couple of months time to make it much better
John O'Gorman (Jun 04 2018 at 14:47):
Thanks @Grahame Grieve
Brian Postlethwaite (Jun 20 2018 at 23:13):
There are also the use cases where the Patient, Person and Pracitioner are all in different systems (potentially built by different orgs), so denormalization is quite normal here.
Using the external Person resource can be done to link across all the systems, and manage where changes are - even if isn't able to update - but be used in manual processes to rectify
Last updated: Apr 12 2022 at 19:14 UTC