Stream: implementers
Topic: birth address
AbdulMalik Shakir (Dec 15 2018 at 17:29):
I have a need to capture the patient's birth address, however, the address-use value set does not contain the concept birth address as one of its values. Has anyone else had this requirement? If so, how did you resolve it? Thanks.
Eric Haas (Dec 15 2018 at 18:06):
add an extension to Address
AbdulMalik Shakir (Dec 15 2018 at 18:24):
add an extension to Address
Thanks @Eric Haas That is an option I will consider.
Although I am troubled by the use of an extension being such a prominant method of work around for defects or deficencies in the standard. I could add an extension to the address datatype, add a birth address extension to patient, or use a birth address observation with patient as it's subject. I asked what others have done in the hope of reuse instead of reinvention.
As I think about it now, I think my real question is what is the process by which birth address can added as a value in the address use value set? Doing so would get rid of the need for a work around.
Grahame Grieve (Dec 15 2018 at 19:55):
- It's not a defect in the standard because you don't agree with a decision the committee made
- it's the first listed extension here: http://hl7.org/fhir/patient-profiles.html (it's not a deficiency in the standard that you haven't read it completely )
if you think that there's a problem, the order of events is roughly
- ask here
- create a gForge task proposing a change
- follow the committee deliberations which will be tracked in the task / in the announcements
John Silva (Dec 15 2018 at 20:49):
I think I get the 80% rule but I don't understand why things like birthPlace, patient-birthtime, etc are 'standard extensions' (if that isn't an oxymoron) and maintained by HL7? It's strange to me (and I suppose others new to FHIR) why these are extensions (especially when we had them in V2 and pretty widely used) yet something like 'animal' (whatever that property is used for veterinary) is standard ; sure doesn't seem like that follows the 80% rule.
Grahame Grieve (Dec 15 2018 at 21:00):
if you look at hL7 v2, there's a long tail of patient demographic information that is rarely used. The committee surveys across usage to see what is actually widely used. I've never seen birthplace used in v2, for instance. The PA committee continues to be interested in usage, it helps decide what things are part of patient, what are standard extensions, and what are not.
Animal was included on a different basis, to do with safety, but after very much argument it has been moved to an extension in R4
Jens Villadsen (Dec 15 2018 at 21:00):
FYI: animal is an extension from R4
Lloyd McKenzie (Dec 15 2018 at 23:45):
The exclusion of data elements that aren't widely used across the spectrum of healthcare isn't a defect/deficiency. It's a FHIR design feature. It ensures that the base resources are lightweight and easy to understand and also that it's very clear to implementers which data elements they should expect wide support for (and correspondingly, what they shouldn't necessarily expect support for). It's one of the things that makes FHIR easy to use and it also drives interoperability by encouraging consistency. If you don't support a core element in FHIR, it's reasonable to ask the question "why" and it's an obvious place to consider adding capability. On the other hand, if you don't support one of the 100+ "core" elements in PID+PD1, there's absolutely no incentive to consider adding it because there's no indication how likely it is for anyone else to do so.
HL7 defines "common" extensions for data elements that aren't used on a sufficiently wide basis to justify their inclusion in the resource, but which are still sufficiently common and consistent across the world that defining a "standard" way to do it is useful. It gives implementers a starting place to look when they face a requirement that they can't find in the immediate resource. If you can't find something in core or the standard extensions, then asking on chat.fhir.org is a good strategy because there may be a standard way to do what you want that you've missed/misunderstood. And if not, it may be that the community will encourage you to submit a change request to add the capability to the specification - likely as a core extension. On the other hand, if it's not supported and it's esoteric to a particular country or extremely niche area, you still have the ability to convey the data using a custom extension - and have the option of further standardizing its use through an implementation guide that applies to the relevant community.
In the case of birthPlace, it's really only relevant to systems that are deeply involved with identity management - which is a very small subset of the systems that create and manage Patient instances - thus why it's handled as an extension rather than core.
John Silva (Dec 16 2018 at 05:46):
Yeh!! (on animal being removing from 'core' and moved to extension! That helps for many patient-centric systems that have nothing to do with animal care. Yes, I've heard about the fact that it's not just about the animals but their use in trials and such, but that doesn't seem to fit the 80% rule, if I interpret it right.)
Yes, of course V2 had 'bloat' -- it was the "union of every use case"; I get it. I guess birthplace is important for MPIs and insurance systems, identity management systems, but not 'every system'. I also raised the question a while back about birthDate (and time) and was told about the patient-birtdatetime (?) extension. I guess the question as to how many systems need to know about the time of birth is another one 'in the grey area'; yes, this too could be used in an MPI, for example, in helping to differentiate multiples born on the same date, or in baby care (again with multiples), or in neonatal care where the date and time makes a difference on care treatments (yes, hours are very important to neonates). Oh well, these decisions have already been made and as an individual, I don't have enough of a justification for "petitioning" (via gForce) for considering them for core use. I suspect many in the "end user" (not committee) community do not have the wherewithal or bandwidth to work through when things that they feel are very important to their use case(s) are important (or not) to the community as a whole.
Brian Postlethwaite (Dec 16 2018 at 06:10):
If you're interested about the birth time discussion, I wrote a blog post about it.
https://brianpos.com/2016/10/19/patient-birth-date-no-time/
René Spronk (Dec 16 2018 at 12:39):
The solution for birth-address in v2 was to label one of the many addresses as the birth address, because the PID field called BirthPlace was not intended to be used as the birth address. The same use-case (birth address) is obviously dealt with differently in different standards, so in FHIR it's a separate element. An extension, because those countries using common law don't really care about it, but most other countries do. Because birthPlace doesn't meet the 80% rule, but it is used by multiple countries, HL7 has predefined a standard extension for it. In general you're recommended to serach Simplifier.net for extensions (for an X use case), as that may be faster than trying to find it in the standard itself.
John Silva (Dec 16 2018 at 14:17):
@Brian Postlethwaite - thanks for your article, it's good to see some of the discussion behind this. I'm very familiar with the issues around date/times and timezones, etc.; I've worked on products that have to deal with this; it is very complicated. (If only Ben Franklin didn't come up with DST! ;-) ) However, having a birthdate only doesn't always solve the problem. For example, if I need to calculate the hours since birth, how does the system know what time zone that date was recorded in? Do I then also need to record (somewhere) the birthPlace ( ;-) ) and the time zone and the timezone offset, specifically for that instance (because time zone switches can change over time by local laws.) One approach is to convert the local date (date/time really) into UTC since that really represents the 'exact instant in time' but now you've lost the 'where this occurred' info. Not an easy problem and I suppose, people/systems will come up with their own way of handling it. However, the need for birthDate as date/time values doesn't go away, and to your point, maybe it's not in the 80% of the use cases so it's best left out of the core (and the complications only left to those systems that have to deal with it.)
AbdulMalik Shakir (Dec 16 2018 at 19:11):
I see that my use of the term 'defect' may have been a poor choice in words. What I intended to state was that there will come a time when the standard as stated is not able to support a given use case. Perhaps "deficiency" would have been a better word choice. I imagine that for any deficiency there will be multiple workaround solutions, including the use of extensions.
I now understand that the maintenance process for discovery and reconciliation of perceived deficiencies is to begin by noting the observation here on Zulip. One might find that there is an existing solution already within the standard that addresses the perceived deficiency, and that there is no deficiency at all. It is also possible to have the perceived deficiency confirmed as a deficiency in which case the next step would be to open a ticket in gForge to initiate deliberations on the issue which will eventually come to a resolution and may result in a change in the standard to be included in the next release.
Is my understanding correct?
It seems to me that many of the questions I have put to Zulip about the use of the standard for a use case for which I have noted a perceived deficiency that the response is a suggestion to create an extension. I know that I am working from a small sample size, but is the use of extensions the more popular (perhaps preferred) way of resolving perceived deficiencies? In other words, is creating an extension more preferred than modifying the standard?
Grahame Grieve (Dec 16 2018 at 19:47):
creating an extension is easier, and the extension is retrospectively active. Creating an extension also drives consistency in implementations (or lack of consistency in requirements) and is therefore an excellent data collection tool that feeds into an ongoing discussion of whether a requirement is common enough to drive a change to the actual underlying standard. Which does happen. So rather than thinking of an either/or thing, you should be thinking in terms of overall process
Lloyd McKenzie (Dec 16 2018 at 23:28):
Extensions are actually the "standard" way for conveying most data elements. The number of country-specific and edge-case data elements far out-numbers the set of commonly used data elements. Thus the failure to have most elements in the core specification isn't a deficiency. It's by design that edge cases will need to use extensions. The ability to use extensions means that it's pretty much impossible to encounter a situation where FHIR can't express what's needed. The only challenge is how to ensure that "edge-case" data elements are represented consistently across systems that are designed independently. And that's what HL7 extensions, the HL7 artifact registry, implementation guides and chat.fhir.org are all intended to help.
Alexander Henket (Dec 20 2018 at 00:25):
... and in thinking about extensions: core extensions have our preference for anything we think is of relevance outside our Dutch scope, so we'll try to get consensus for those before turning to building our own.
Craig Newman (Jan 11 2019 at 18:27):
Is it safe to assume that the patient birth place extension (http://hl7.org/fhir/extension-patient-birthplace.html) can only be used for the Patient resource and can't be applied to Patient.contact or RelatedPerson if there was a use case for those locations? I don't see extensions for these locations in R4 (http://hl7.org/fhir/patient-profiles.html and http://hl7.org/fhir/relatedperson-profiles.html) but I'm not confident I know all of the best places to look for extensions. What are the best places to look for existing extensions to use? Thanks.
Lloyd McKenzie (Jan 11 2019 at 20:38):
The only context declared for that extension is Patient. The extensions registry (http://hl7.org/fhir/extensibility-registry.html) lists all HL7-defined extensions. If you've got a good use-case for adding birthplace to those other locations, you can certainly submit a change request. Why do you need it?
Craig Newman (Jan 12 2019 at 17:58):
I asked because I'm part of the v2-FHIR project and was looking at mapping NK1 to either Patient.contact or RelatedPerson. One of the NK1 fields is birth place. I've never seen this used, but i figured it would be worth including in the mapping if a FHIR extension existed. As a group, i don't think we've decided if v2 mapping will be targeted to be 100% or just the "commonly used" stuff.
Lloyd McKenzie (Jan 12 2019 at 18:13):
My leaning is not to create extensions unless we have a clear need for them - there's a whole bunch of stuff in v2 that's either not used anwhere or only used in a super-small number of systems. By defining an HL7 extension, we're adding a degree of weight that "sharing this is a good idea and has a good use-case". We should only define things if we actually believe that to be true.
Lloyd McKenzie (Jan 12 2019 at 18:13):
(My personal opinion - not official policy)
Yunwei Wang (Jan 22 2019 at 17:45):
Just curious, what is the use case to know the birth place of a contact person?
Craig Newman (Jan 22 2019 at 21:26):
I don't have a use case, but it's in the v2 NK1 segment (NK1-38) and I ran across it in a v2 to FHIR mapping exercise and was just following through to see if an existing FHIR element existed for it. I don't know what the original v2 motivation was.
René Spronk (Jan 23 2019 at 11:43):
In quite a few countries the tuple (birth name, birth city, birth date) [as data which doesn't change over time] form the core demographics characteristics of a person. Hence this would be useful on Patient, RelatedPerson (=the closest thing to NK1), Practitioner, etc. But one would probably not use it on Patient.Contact, if one has full identifying details of a contact it should probably be captured as a RelatedPerson, not as Patient.Contact.
Lloyd McKenzie (Jan 23 2019 at 15:40):
RelatedPerson is someone you expect to do something. Patient.contact is just that - a contact. Which you use isn't driven by how much information you have, but rather whether the person is an informer/performer/witness/other function in the patient's healthcare activities.
AbdulMalik Shakir (Oct 19 2019 at 14:20):
I have a need to capture the birth address of a patient. I notice that there is a birthplace extension defined but wonder if consideration was given to including birth as an address use thereby allowing the patient.address element to be sliced by use. How do I extend the address.use value set to include the concept of birth address?
Lloyd McKenzie (Oct 19 2019 at 14:58):
You can't extend a fixed value set. Given that there's a standard extension, there isn't a need to either. It would be surprising to most systems you see a patient's birth address amongst their list of addresses. (Not all systems will support or expose Address.use)
Last updated: Apr 12 2022 at 19:14 UTC
