Open brianraila opened 11 months ago
If you use FHIR extensions instead, you can write an extension handler to map these values into the patients extended data (https://help.santesuite.org/developers/service-apis/hl7-fhir/extending-fhir-interfaces#extension-handlers). An example is available in the source tree at https://github.com/santedb/santedb-fhir/blob/version/3.0/SanteDB.Messaging.FHIR/Extensions/Patient/NationalityExtension.cs. This is the easiest approach.
If you must extend the patient resource, then you will need to write a handler for the new resource, including all of the serialization logic provided by Firely (https://github.com/FirelyTeam/firely-net-sdk). This will give you maximum flexibility in the structure of the resource type at a significant cost to undertake.
Note that both methods would use extensions on the internal data structure in SanteDB, which cannot be queried. For example, it would be possible to retrieve the county, sub-county and ward when retrieving a patient. It would not be possible to retrieve all patients in a county, sub-county or ward. To add query support means extending the schema in the system which is not supported using plugins.
Trevor is correct that the extension method is the route with the least amount of effort. Additionally, you may want to consider the information modeling, since county or subCounty would be attributes of an address rather than a patient, this would be important when writing your extension handler - as you can store the additional data in appropriate RIM model fields (EntityAddress
). SanteDB already provides a multitude of address component types above what FHIR provides, for example, county is already a field which is provided in SanteDB's internal RIM (CountyOrParish
) and sub-county or ward may also be appropriately mapped to PrecinctOrBorough
(depending on your address hierarchy in the jurisdiction you're targeting).
You can also add custom address part types by registering new concepts for the address types and ensuring those concepts belong to the AddressPartType
concept set. This will allow any matching logic to use readily available criteria, for example to do blocking on sub-county: address[Home].component[SubCounty].value
which is better indexed than using a direct extension.
Thanks @justin-fyfe @ThreeSevenths
Let me try that. I will let you know how it goes.
I have the following FHIR profile. I would like to capture additional data on the Patient resource posted to the MPI via the FHIR API.
How can I go about this.