Stream: implementers
Topic: Different address data types for patient
Martin Grundberg (Feb 15 2019 at 15:03):
We are looking at how a Swedish profile for a patient could look like and particularly address formats.
In the core profile we have this:
address Σ 0..* Address An address for the individual
Address formats seem to differ slightly between different countries, so other countries seem to have created their own address data types:
Netherlands: https://simplifier.net/NictizSTU3-Zib2017/nl-core-address
Norway: https://simplifier.net/HL7Norwayno-basis/no-basis-Address
This seems to be a good way to define national requirements for an address.
Question
A patient can according to the patient resource have multiple addresses, that is correct and good! But a patient can also have addresses in different countries. All the national profiles we have looked at only support one address data type.
Is there a way to profile so that a patient can have 0..* addresses, where each address is of different address data types? Maybe in our Swedish profile we want to have 0..* address of data type swe-core-address, but also 0..* address of data type address?
I know from working with Patient data in the UK that there were different address formats for "UK address" and "non-UK address", and we would want something similar here "Swe address" and "non-Swe address".
Martin Grundberg (Feb 15 2019 at 15:06):
The requirement seems to be a mix of slicing and how you can choose data type based on your requirement using attribute[x]
Lloyd McKenzie (Feb 15 2019 at 15:39):
You can define a must-support slice of address that's 0..* of addresses complying to your national profile and leave it open, which allows for other types of addresses too. It's up to you whether you create an "everything" profile that defines minimum must-support expectations for arbitrary addresses.
Elliot Silver (Feb 15 2019 at 18:44):
Can you slice on the country and require the swe-core-address when the country is Sweden, but leave it open otherwise?
Lloyd McKenzie (Feb 15 2019 at 21:30):
That's tricky. If you have a Swedish address captured in a Canadian system, there's no guarantee it's going to comply with the Swedish profile.
Grahame Grieve (Feb 16 2019 at 03:10):
I'm not sure that I follow what's going on here. A patient can have only one address from Sweden?
Lloyd McKenzie (Feb 16 2019 at 04:42):
The slice would be 0..*. It would just say there's a need to support Swedish-formatted addresses.
Martin Grundberg (Feb 20 2019 at 14:18):
Ah, is it that simple?
Create a slice on Address, set that slice to 0..* and change the data type to the Swedish address data type?
Do you need a second slice for the 0..* address?
What I would want (or potentially want) is something like this:
Address
0..* swe-core-address (where this is a new data type for the national Swedish address format)
0..* address (where this is the standard address data type)
There are lots of patients in Sweden who will live in the country for half the year, and then move to a nicer sunnier country in winter. And in that second country, the Swedish address format doesnt apply, but of course, correspondance might need to go to either their Swedish or foreign address.
Ideally, and maybe that was what Elliot was getting at, you would want the address data type to correspond to the country in which the address is. Need to think a bit more about that :)
Lloyd McKenzie (Feb 20 2019 at 16:03):
There's no need for a second slice if the base is already 0... That would say "you can have 0.. addresses. Within that, you must support 0..* addresses that comply with the swedish profile.
Elliot Silver (Feb 20 2019 at 18:26):
@Martin Grundberg Yes, that was exactly what I was getting at -- for the systems that this applies to, there are no restrictions on international addresses, but if the address is in Sweden, then your Swedish profile applies.
Lloyd McKenzie (Feb 20 2019 at 18:35):
If you wanted to apply the rule to all Swedish addresses, you could slice by country - though you'd have to constrain country to a value set for that to work well
Thomas Tveit Rosenlund (Dec 06 2019 at 13:42):
How would you discriminate the different Address slices conforming to different address profiles?
I have tried this for the Norwegian master person index, and the validator can not understand what profile it should validate against, It just tries out the first one in the list of allowed profiles and throws errors at me because the address given is actually conforming to another profile. I have not done any slicing, just given an option of more than one address profile in the profile definition like this:
<element id="Person.address">
<path value="Person.address" />
<definition value="Grunndata uses Five different address content types expressed in gd-Address profiles that further restricts the use of the http://hl7.no/fhir/StructureDefinition/no-basis-Address to contain information from the norwegian Master person index.
Based on: http://hl7.no/fhir/StructureDefinition/no-basis-Address" />
<type>
<code value="Address" />
<profile value="http://ehelse.no/fhir/StructureDefinition/gd-Address-cadastral" />
<profile value="http://ehelse.no/fhir/StructureDefinition/gd-Address-international" />
<profile value="http://ehelse.no/fhir/StructureDefinition/gd-Address-street" />
<profile value="http://ehelse.no/fhir/StructureDefinition/gd-Address-box" />
<profile value="http://ehelse.no/fhir/StructureDefinition/gd-Address-freeform" />
</type>
<mustSupport value="true" />
</element>
Thomas Tveit Rosenlund (Dec 06 2019 at 13:43):
Is it possible to state what profile I try to conform to in the person instance somehow?
Thomas Tveit Rosenlund (Dec 06 2019 at 13:53):
@Martin Grundberg How did you discriminate the address types? Did you post a profile somewhere?
Lloyd McKenzie (Dec 06 2019 at 17:49):
How are you validating?
Thomas Tveit Rosenlund (Dec 06 2019 at 18:11):
@Lloyd McKenzie I use my for-validation catalog: https://github.com/HL7Norway/Grunndata-profiles/tree/gd-Person21/for-validation-gd-r4
To validate my examples: https://github.com/HL7Norway/Grunndata-profiles/tree/gd-Person21/examples
In particular the gd-person: https://github.com/HL7Norway/Grunndata-profiles/blob/gd-Person21/examples/gd-Person-04021950128-version-2.xml
fails running the official validator like this:
java -jar C:\Users\Thomas\Downloads\org.hl7.fhir.validator.jar gd-Person-04021950128-version-2.xml -ig C:\GitRepo\grunndata-r4\for-validation-gd-r4 -version 4.0.1
Thomas Tveit Rosenlund (Dec 06 2019 at 18:14):
I can understand the codesystem error, as the definition of 3402 codesystem does'nt actually contain any codes. The validator seems to think that the address should be conforming to the gd-Address-cadastral profile, even though I try to actually provide a gd-Address-street type address.
Detected Java version: 1.8.0_31 from C:\Program Files\Java\jre1.8.0_31 on amd64 (64bit). 3636MB available
Arguments: gd-Person-04021950128-version-2.xml -ig E:\GitRepo\grunndata-r4\for-validation-gd-r4 -version 4.0.1
Directories: Current = E:\GitRepo\Grunndata-R4\examples, Package Cache = C:\Users\Thomas\.fhir\packages
.. FHIR Version 4.0, definitions from hl7.fhir.r4.core#4.0.1
.. connect to tx server @ http://tx.fhir.org
(v4.0.1)
+ .. load IG from E:\GitRepo\grunndata-r4\for-validation-gd-r4
.. validate [gd-Person-04021950128-version-2.xml]
FAILURE validating gd-Person-04021950128-version-2.xml: error:1 warn:0 info:4
Error @ Person.address[0].extension[0].extension[0].value.ofType(Coding) (line 77, col18) : Unknown Code urn:oid:2.16.578.1.12.4.1.1.3402#0238 in urn:oid:2.16.578.1.12.4.1.1.3402 for 'urn:oid:2.16.578.1.12.4.1.1.3402#0238'
Information @ Person.extension[0].extension[1] (line 10, col78) : This element does not match any known slice for the profile http://ehelse.no/fhir/StructureDefinition/gd-person-status
Information @ Person.address[0].extension[4] (line 128, col80) : This element does not match any known slice for the profile http://ehelse.no/fhir/StructureDefinition/gd-Address-cadastral
Information @ Person.address[0].line[0].extension[0] (line 143, col86) : This element does not match any known slice for the profile http://ehelse.no/fhir/StructureDefinition/gd-Address-cadastral
Information @ Person.address[0].line[0].extension[1] (line 146, col103) : This element does not match any known slice for the profile http://ehelse.no/fhir/StructureDefinition/gd-Address-cadastral
Lloyd McKenzie (Dec 06 2019 at 18:17):
Hmm. It should be happy so long as one of the profiles is valid. @Grahame Grieve ?
Grahame Grieve (Dec 06 2019 at 18:18):
so I understand saying that the address could be one of 5 different profiles, but why slice it?
Thomas Tveit Rosenlund (Dec 06 2019 at 18:23):
@Grahame Grieve I did not actually slice it, just gave five different options for possible profiles the Address can conform to. Sorry if the first post was confusing on that point.
Grahame Grieve (Dec 06 2019 at 19:29):
I haven't had any luck reproducing this. can you turn this into a simple test case - a single set of profiles and examples - the demonstrates the problem?
Thomas Tveit Rosenlund (Dec 07 2019 at 19:07):
@Grahame Grieve Just made a quick testproject to demonstrate the problem without any confusing other artifacts. Uploaded it here: https://github.com/thomiz/TestAddressTypes
When I try to validate the Person example that should be conformant to the complex address type, it succeeds, but the validator do not understand that there is in fact another Address type where this behaviour is defined.
E:\GitRepo\testing>java -jar c:\Users\Thomas\Downloads\org.hl7.fhir.validator.jar Person-test.xml -ig . -version 4.0.1
FHIR Validation tool Version 4.1.19-SNAPSHOT - Built 2019-12-06T08:56:29.651+11:00 - Git 89195efad312
Detected Java version: 1.8.0_31 from C:\Program Files\Java\jre1.8.0_31 on amd64 (64bit). 3636MB available
Arguments: Person-test.xml -ig . -version 4.0.1
Directories: Current = E:\GitRepo\testing, Package Cache = C:\Users\Thomas\.fhir\packages
.. FHIR Version 4.0, definitions from hl7.fhir.r4.core#4.0.1
.. connect to tx server @ http://tx.fhir.org
(v4.0.1)
+ .. load IG from .
.. validate [Person-test.xml]
Terminology server: Check for supported code systems for urn:iso:std:iso:3166
Success...validating Person-test.xml: error:0 warn:0 info:1
Information @ Person.address[0].extension[1] (line 23, col81) : This element does not match any known slice for the profile http://example.org/fhir/StructureDefinition/AddressWithExtension
Thomas Tveit Rosenlund (Dec 07 2019 at 19:09):
Seems the validator always tries out the first profile, but don't test if the example conforms to the second one. I would expect the validator not to ouput the Information text if it finds the second Address profile.
Grahame Grieve (Dec 09 2019 at 06:02):
ok so I'm committing a fix for this, but the information message has not gone away. it has changed a little:
Grahame Grieve (Dec 09 2019 at 06:03):
Information @ Person.address[0].extension[1] (line 23, col81) : This element does not match any known slice for the profile http://example.org/fhir/StructureDefinition/AddressWithExtension (validating against http://example.org/fhir/StructureDefinition/AddressWithExtension [AddressWithExtension])
Grahame Grieve (Dec 09 2019 at 06:03):
this is valid.
Grahame Grieve (Dec 09 2019 at 06:04):
Warning @ Person.address[0] (line 16, col11) : Found multiple matching profiles among choices: ; [http://example.org/fhir/StructureDefinition/AddressWithTwoExtensions, http://example.org/fhir/StructureDefinition/AddressWithExtension]
Thomas Tveit Rosenlund (Dec 09 2019 at 11:42):
Warning @ Person.address[0] (line 16, col11) : Found multiple matching profiles among choices: ; [http://example.org/fhir/StructureDefinition/AddressWithTwoExtensions, http://example.org/fhir/StructureDefinition/AddressWithExtension]
OK, so the profile still matches even though one includes a definition for the profile, and the other does not. I would probably have to declare one of the two mandatory to achieve a singular match then.
Thanks for your help @Grahame Grieve
Grahame Grieve (Dec 09 2019 at 12:07):
yes
Last updated: Apr 12 2022 at 19:14 UTC
