Stream: implementers
Topic: Patient extension ?
Luma Delaplace (May 16 2017 at 13:50):
Hi everyone! We are developping an application to be used by pediatric palliative care units to coordinate children’s healthcare in a context of palliative cares. But we are new to FHIR and still trying to figure out how to implement it on the best possible way.
For the patients data for instance, the Patient ressource covers well most of the information we have (name, contact data, date of birth etc). But we also need to include:
Date of 1st contact
Contact origin
Contact motive
Inclusion date
Weight at inclusion
Height at inclusion
Lansky score
Place of death
Should we create an extension to the Patient resource or instead do something like:
-
use ReferralRequest where
"Date of 1st contact" is authoredOn
"Contact origin" is requester
"Contact motive" is type (or reasonCode ? ) -
use Encounter where
"Inclusion date" is period
the fact that it is the first contact is coded in type
the incomingReferral points to the ReferralRequest created above -
use Observation for "Weight at inclusion", "Height at inclusion", "Lansky score"
basedOn points to the ReferralRequest created above
context points to the Encounter created above
And "Place of death" could be added as an exension of Patient.
What is the best way to include these data ?
Sorry if my question seems basic, I just started to work with FHIR, it is all very new to me
natus (May 16 2017 at 16:37):
Hi Luma,
Good question. I would say, you should had those derivative elements as extension in patient in order to ease calculus. But I am new to FHIR too.
I am really interested in the official answer too.
Patrick Werner (May 16 2017 at 18:50):
@Luma Delaplace always try to avoid extensions where ever it is possible. Extensions have a negative impact on the interoperability of the resource, as it is only interpretable by systems which are aware of an extension. Other systems are just ignoring the data which is stored in the extension fields.
Eric Haas (May 16 2017 at 19:26):
its unclear from the context what you are trying to achieve and what the definitions of many of these data elements are (such as what does contact refers to). But it looks like you are heading in the right direction. In FHIR clinical resource directly reference the patient resources an encounter or episode of care resources. Many patient characteristics can be represented with Observation while problems and conditions are handled by Condition. Regarding the extension there is a standard birthplace extension in FHIR and I think a deathplace extension is perfectly appropriate. Possibly even worthy of submitting a tracker.
Grahame Grieve (May 17 2017 at 06:03):
this seems like data related to clinical trial selection rather than to the patient directly.
Lloyd McKenzie (May 17 2017 at 16:33):
I don't see anything clinical-trial related here. It seems more like an EpisodeOfCare. That would let you capture some of this and you could group other things. If you do extend, I'd probably extend the episode rather than the patient overall. Place of death definitely makes sense as an extension on patient.
Lloyd McKenzie (May 17 2017 at 16:35):
@Patrick Werner Extensions are actually pretty common in FHIR and are a fine way to meet certain types of requirements. Certainly you should try to find a "core" way to do things first, but many of these items don't strike me as "core" elements.
Patrick Werner (May 17 2017 at 16:38):
my point was, try to avoid extensions if you can do the same with core resources. If you have to extend first have a look at existing core extensions. If you still can't find an extensions wich fits your needs create an extension. I always tell it like this to our students because their intuitive is to use a patient resource and persist everything within the patient as extensions.
Lloyd McKenzie (May 17 2017 at 16:43):
Agree with your approach. Extensions on Patient should be related to their demographics. Information about their care should generally be elsewhere.
Emmanuel Chevallier (May 18 2017 at 19:50):
I'm co-worker of Luma Delaplace she's not available actually, I transmit some answer.
Emmanuel Chevallier (May 18 2017 at 19:50):
@Eric Browne Haas
The application's aim is to allow palliative care units to better coordinate the children healthcare. It is more focused on events (encounters and/or episode of care) and less (at least for now) on keeping record of strictly clinical data (treatment, medical exams, etc). By contact I meant contact information, so adress and telecom.
Here is the data we are ask to include and the attributes of the Patient resource we are thinking in using :
ID --> identifier
Sex --> gender
Last name --> name
First name --> name
Date of birth --> birthDate
Address --> address
Date of death --> deceased[x]
Technical specification also included the following :
Date 1st contact : the date the first contact is made between the palliative care unit and the patient/or patient care unit. It is usually a phone call
Contact origin : the person / oragnisation/ practitionner who made the 1st contact
Contact motive : the reason of the 1st contact
Inclusion date : the date of the first encounter with the child patient
Weight at inclusion : the weight of the child patient at the first encounter with the palliative care unit
Height at inclusion : the height of the child patient at the first encounter with the palliative care unit
Lansky score : : the lansky score of the child patient at the first encounter with the palliative care unit
Place of death : the place where the child patient deceased (if deceased)
@Grahame Grieve Grieve
Our data is indeed not related to clinical trial, but the palliative care units want statistics on their activities (for all patients, how many encounters of type x in a given period of time, etc)
As advised @Lloyd McKenzie McKenzie, we are thinking to not to extend the Patient resource and keep only demographic data in it (except for the place of death which would be an extension of Patient).
Lloyd McKenzie (May 18 2017 at 21:08):
My leaning would be to have place of death an extension on Patient (and it makes sense to request it as a "standard" extension). Date of 1st contact would be EpisodeOfCare.period.start. The remainder would be extensions on EpisodeOfCare.
Lloyd McKenzie (May 18 2017 at 21:09):
Note that you could fully model out the initial contact as a Communication, Encounter, Observations for height, weight, lansky score. And it would be best to not have that information in multiple places. So ideally, your extensions would be "References" pointing to the appropriate resources.
Last updated: Apr 12 2022 at 19:14 UTC
