Patient.Municipality should be standard Patient.ManagingOrganization element

jpriebe-epic commented 1 year ago

This extension should be replaced by the standard R4 element managingOrganization

jpriebe-epic commented 1 year ago

municipality code content can be better supported as content within a linked Organization resource (e.g. Municipality identifiers)

mrinnetmaki commented 1 year ago

I don't think we like to say that a municipality manages the patient.

The patient chooses the municipality in which they live and to which they pay their tax.

The whole thing just became a bit more complicated when we introduced the Wellbeing Services Counties this year (known as Regions in other Nordic countries). This is a new level of bureaucracy now in charge of provision of public healthcare.

So, we typically check the municipality of the patient, and derive the wellbeing services county based on the municipality, and use the wellbeing services county to see what the patient is entitled to, to whom to send the bill, etc...

The cardinality of .managingOrganization is one. Municipalities themselves don't have patient registries. The .managingOrganization field does not seem right.

jpriebe-epic commented 1 year ago

Maybe patient.address would be better than?

Though still - honestly the managingOrganization concept doesn't seem too far off from what you describe - this organization (e.g. municipality/Wellbeing Services Counties) is in charge of provision of care for the patient. For example managing organization points to an organization of type government representing either the specific municipality or wellbeing services counties?

I think the complexity of Wellbeing Service Counties could be handled with Organization resources and references. If you start with a specific municipality, you can chain up to the more broad Wellbeing Service Counties via partOf

mrinnetmaki commented 1 year ago

Also address does not cut it. You may live somewhere and want your mail to be delivered there, but pay your taxes in a different municipality.

mrinnetmaki commented 1 year ago

Epic does express this as the .managingOrganization. @jpriebe-epic to provide examples.

jpriebe-epic commented 1 year ago

In the Epic database for Apotti, we have items for:

Home Municipality. This is the data Apotti gets from DVV (government-assigned) on the organization that owns care for the patient (and gets tax revenue). In FHIR terms, this is represented as an Organization in Epic's database, link from a patient record.
Primary Care Organization. Very similar concept to above, but the patient can opt to choose differently where they receive care. Represents patient preference instead of government assignment. In Apotti, this determines how patients are sorted out to different GP's. In FHIR terms this is also represented as an Organization resource if you ask for the data from Apotti's Epic installation.

Because these are two separate concepts in Finland, it might make sense to define them separately, using one of them as an extension and use managingOrganization for the other.

In Epic's FHIR resources for Patient today, we serve managingOrganization for #2 above. Here's an example (managingOrganization at the end):

{
                       "resourceType": "Patient",
                       "id": "eMMKGfU7AJS5yjSRNjZdLxA3",
                       "identifier": [{
                                              "use": "usual",
                                              "type": {
                                                                     "text": "EPI"
                                              },
                                              "system": "urn:oid:1.2.840.114350",
                                              "value": "248951"
                       },
                       {
                                              "use": "usual",
                                              "type": {
                                                                     "text": "ASGMPI"
                                              },
                                              "system": "urn:oid:1.2.840.114350.1.13.861.1.7.5.737384.233181",
                                              "value": "86179"
                       },
                       {
                                              "use": "usual",
                                              "system": "urn:oid:1.2.840.114350.1.13.861.1.7.5.737384.4399",
                                              "value": "21890"
                       }],
                       "active": true,
                       "name": [{
                                              "use": "usual",
                                              "text": "Meiko Lufhir Jr., PhD",
                                              "family": "Lufhir",
                                              "given": ["Meiko"],
                                              "suffix": ["JR.",
                                              "PHD"]
                       }],
                       "telecom": [{
                                              "system": "phone",
                                              "value": "321-544-2222",
                                              "use": "home"
                       },
                       {
                                              "system": "phone",
                                              "value": "321-841-3333",
                                              "use": "work"
                       },
                       {
                                              "system": "other",
                                              "value": "595-693-5599"
                       },
                       {
                                              "system": "email",
                                              "value": "meikolu.fhir@gmail.com"
                       }],
                       "gender": "F",
                       "birthDate": "1978-03-22",
                       "address": [{
                                              "use": "home",
                                              "line": ["100 Main St",
                                              "G-442"],
                                              "city": "Madison",
                                              "state": "WI",
                                              "postalCode": "53703",
                                              "country": "USA"
                       }],
                       "maritalStatus": {
                                              "text": "Married"
                       },
                       "generalPractitioner": [{
                                              "reference": "https://weiyuwashere/iminatable/api/FHIR/STU3/Practitioner/efv90i4pFs9fOm7QQhHOUHw3",
                                              "display": "Amber Hxl, MD"
                       }],
                       "managingOrganization": {
                                              "reference": "https://weiyuwashere/iminatable/api/FHIR/STU3/Organization/emkOnojd0znvJbO89nRki1A3",
                                              "display": "HXL Service Area"
                       }
}

jpriebe-epic commented 1 year ago

Reading this again - I agree managingOrganization doesn't totally fit what you're trying to convey with Patient.Municipality. Sounds like they are distinct concepts that should be represented separately (this is how Epic has implemented this in my prior post)

My suggestion now -

Can the concept of Patient.Municipality be represented as a link to an Organization resource (or Perhaps a Location resource)? This Org resource can have a sliced identifier specific to the municipality code, and maybe a type that defines it as a government municipality entry (to differentiate from healthcare facility)

For example:

{
                       "resourceType": "Patient",
                       "id": "eMMKGfU7AJS5yjSRNjZdLxA3",
                      ...
                      "managingOrganization": {
                                              "reference": "https://weiyuwashere/iminatable/api/FHIR/STU3/Organization/emkOnojd0znvJbO89nRki1A3",
                                              "display": "HUS Hospital"
                       }
                      "municipality": {
                                              "reference": "https://weiyuwashere/iminatable/api/FHIR/STU3/Organization/a63i23n65hoalkihd",
                                              "display": "Helsinki Municipality Health Services"
                       }
}

This municipality element can used to accomplish the goal you mention

derive the wellbeing services county based on the municipality, and use the wellbeing services county to see what the patient is entitled to, to whom to send the bill, etc...

The benefit of this as opposed to a patient.municipalitycode extension is you get all the rich data about the Organization resource represented as well and linked.

The patient.managingOrganization element can be separately reserved to where the patient is receiving their care.

mrinnetmaki commented 1 year ago

Interesting. Would you expect that reference to the municipality to always resolve and return a FHIR resource? Or would it be enough that there would be the reference with an identifier that holds the required information?

I'm a bit doubtful whether all parties are willing to create a separate resource for this. A simpler extension could be easier.

Also, just as a clarifying detail: you've written Helsinki Municipality Health Services as the display. But what we really want to express with the extension is City of Helsinki or City of Espoo. And from that systems would (through a query to another system, perhaps), deduce that the Wellbeing Services County primarily responsible for the care of the patient is Helsinki or Länsi-Uudenmaan Hyvinvointialue.

jpriebe-epic commented 1 year ago

I don't think I'm going to die on this hill, given one goal is simplicity and I might be over-specifying here. Other nodes like address.city don't link to resources for example.

An extension might make sense. Epic's database in Apotti for example just has a pick list of Billing Municipalities (similar to extension) - compared to a link to a separate database (as we do for registers and privacy information as discussed in Provenance)

I suppose the benefits of linking a separate resource:

Compared to just extensions and municipality code there is a data model for all the additional organization elements (phone number, physical office, etc etc). I am not sure if this is useful in this case, but it might be.
A separate organization resource can be managed separately (you can organization.search with some filters to get a list of municipalities, or do an update to a single organization resource and get all links updated "for free" compared to having to update each patient's extensions individually

Vs an extension has the benefits of simplicity and ease of implementation.

In terms of the reference resolving: If doing a link it should always resolve, but maybe not within the same transaction. There are different ways to implement it:

If you're calling a FHIR server with REST doing a GET on a patient, it will be a link to another resource URL not contained there but reachable by another GET to the FHIR server:
```
GET {url}/Patient/1234
```

... Municipality reference:organization url={url}/Organization/2345

GET {url}/Organization/2345

...details


- You can do the same REST call on a patient but with a [_include](https://build.fhir.org/search.html#_revinclude) parameter to return a bundle containing both patient and organization.

GET {url}/Patient/1234?_include=Patient:Municipality

... Municipality reference:organization url={url}/Organization/2345 url={url}/Organization/2345 ...details



- Bundles can be similarly constructed with internally-resolving links for other application use cases (seen a lot of this in profile development)

jpriebe-epic commented 1 year ago

There's also a middle option, since reading into the FHIR documentation on reference there's also an option for including a (non-FHIR) identifier and a display value along with the reference, like:

<Patient>
    ...
    Municipality
        Reference
            reference url={url}/Organization/2345
            type=Organization
            identifier="HEL"
            display="City of Helsinki"
</Patient>

In specification-speak the identifier is a Logical reference (not to a FHIR resource) and not a Literal reference (a FHIR resource URL) - but the reference elements can contain both.

mrinnetmaki commented 1 year ago

This is what I was considering. In our national infrastructure, most systems figure out these things from systems that are not FHIR aware. So there might not ever be a FHIR resource for City of Helsinki, and also not a need for it. But a unique identifier might be handy.

mrinnetmaki commented 1 year ago

I suppose the benefits of linking a separate resource:

Compared to just extensions and municipality code there is a data model for all the additional organization elements (phone number, physical office, etc etc). I am not sure if this is useful in this case, but it might be.

A separate organization resource can be managed separately (you can organization.search with some filters to get a list of municipalities, or do an update to a single organization resource and get all links updated "for free" compared to having to update each patient's extensions individually

I don't think we have any meaningful use for a phone number or a physical office for a city or for a Wellbeing Services County.

We may very well have that need for an organization that is truly a .managingOrganization for the patient, though. As discussed in https://github.com/fhir-fi/finnish-base-profiles/issues/15.

jpriebe-epic commented 1 year ago

Ok - I'll agree Organization is too much for this

What about patient.address.county?

jpriebe-epic commented 1 year ago

Doesn't fit. Extension is the best solution for now.

fhir-fi / finnish-base-profiles

Patient.Municipality should be standard Patient.ManagingOrganization element #86