Service interface description

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.

Contents

FHIR RESTful API

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

Supported interactions

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.

Read interaction

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).

Search interaction

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.

History of a resource

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.

History of a Person resource

Most elements in a Person resource returned by the service will contain fregMetadata to differentiate current info from historic information.

History of a RelatedPerson resource

Only the relationship element contains fregMetadata indicating what relationships are considered current information by FREG.

History of a Provenance resource

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.

Dataminimization by default

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.

SPECIAL NOTE on addressConfidentiality

The server expects the use of _elements operation to limit the returned elements in a search result, however the addressConfidentiality element is returned by default (actually Person.meta.security.code element). The reason for the inclusion of this element in all search results irrespective of the _elements operation is that knowledge about the security.code stated is necessarry to interpret the address information for the returned Person resource correctly.

Person.meta.security is considered MANDATORY

The support of the Person.meta.security element is considered MANDATORY by all systems implementing access to the Person-API. MANDATORY meaning:

  • The element is returned by default from the responder service
  • All requestor systems SHALL be able to display the information in the data element for human use.
  • Any user given access to the information through the system or subsystems should be able to interpret this information in a meaningfull way
  • Requestors SHALL be able to process and store the information

Some information made available by the service has special security and legal obligations and must be handled according to the relevant legislation. Any failure to support these requirements could lead to the harm or death of the Person whom the information concerns.

addressConfidentiality = fortrolig

The code = "fortrolig" actually means that the address information of this person should not be given to any other person than the healthcare personell that needs this to provide actual healthcare services. It also means that the system should display information to the users about the nature of the security risks concerning this specific information.

In other cases systems or users that lack the necessary security clearance will not be able to read the address information of this person. In these cases the element explains why this is the case and makes the system or user capable of interpreting the missing information in a meaningful way.