|Services for Person information|
|Read and Search|
|Read and Search roadmap|
|Person REST interactions|
|Custom search parameters|
|RelatedPerson REST interactions|
|Provenance REST Interactions|
|Authentication and authorization|
|Person information intro|
|Address datatype profiles|
|gd-HumanName datatype profile|
|Readers Guide and RESTful FHIR|
The service interface provides person information to the actors in the healthcare sector. The services provides functionality to read and search for specific persons and makes it possible to synchronize locally stored person information in the connected software solutions.
The service interface conforms to the relevant parts of the FHIR RESTful API specification version R4. The service interface will not support any parts of the specification not mentioned in the CapabilityStatement PersonServerRequirements.
Link to the R4 version of the FHIR RESTful API specification
Please read the detailed description of the supported read and search parameters in the FAQ
The services provides functionality to read and search for specific resources stored on the server, in the FHIR RESTful API this functions are called read interaction and search interaction respectively. When a read/search interaction is invoked, the server responds with all the resources that meet the read/search criteria and returns either the specific resource or a special FHIR resource called a Bundle, that contains a collection of resources. The server only supports read/search interactions mentioned in the CapabilityStatement PersonServerRequirements. Currently only Person and RelatedPerson are supported.
The Read interaction will provide services to read the latest version of the person document, identified by the id of the Person Resource from the master person index (value of the id element). The read interaction will provide services to read older versions of the person document based on a set of criteria (date, version id etc).
The search interaction will provide services to search for a person document based on a set of search parameters. This includes search for identifiers (FNR/DNR), name and birthDate in particular.
Every Person resource returned by the server contains both current information and all historic information (e.g. information that was current at some earlier point in time). The consumer of the information must read the fregMetadata.currentInfo element to tell the current and historic information apart.
Most elements in a Person resource returned by the service will contain fregMetadata to differentiate current info from historic information.
Only the relationship element contains fregMetadata indicating what relationships are considered current information by FREG.
New Provenance resources are generated on all changes to the other resources returned by the service. Each Provenance resource references a version specific target resource.
The service expects the clients to specify what information elements they need (based on "tjenstlig behov") using the _elements operation. When the _elements operation is missing from the read/search statement, no information is returned to the client.