Pasientens Måledata
Pasientens Måledata (PMD) is a data sharing service being established in Norway to centralize and share vital health measurements, such as pulse and blood pressure, among healthcare providers.
PMD is a NOT a master data storage, and has no opinion about and does no interpretation of its data.
PMD is a FHIR-API
PMD implements a subset of the FHIR REST API specification, with the following limitations:
- Only one resource type is available:
Observation(see Observation). - Bundle endpoint only accepts Observation resources. For other constrains, see bundle docs.
- Patients are automatically created and managed internally by the system.
Getting started
In order to use the PMD API, you must:
Select an environment
| Environment | URL | Usage | Authentication | Availabilty |
|---|---|---|---|---|
| Dev | pmd.dev.nhn.no | Internal development environment | None | Internett, Helsenett |
| Test | pmd.test.nhn.no | Close-to-production test environment | HelseID | Internett, Helsenett |
| Production | pmd.nhn.no | Production environment (trial phase) | HelseID | Helsenett |
To gain access to the production environment you must be enrolled in the trial.
Authenticate with HelseID
You can explore our API without authentication in our Dev environment.
All endpoints are protected by HelseID. To use the PMD API the client therefore must implement HelseID with DPoP. The end users must log in at security level 4 (BankID or Buypass Security).
See the official HelseID documentation and their official support channels for more information about HelseID, OpenID Connect and DPoP.
How PMD implements FHIR
PMD API follows the FHIR R5 specification, while also being backwards compatible with R4 for Observation resources.
Resource: Observation
PMD stores standard Observation resources, as well as the VkpObservation profile.
Consume or produce FHIR observations
FHIR observations can be created through bundles, and read through search.
Currently it is only possible to create new observations; deleting and updating observations must be done manually.
Bundles
POST /
Content-Type: application/fhir+json (or application/json)
Body: <FHIR bundle>
PMD only supports uploading bundles of type=collection. This allows inserting observations into PMD.
Only resources of resourceType=Observation will be stored in PMD, others will be ignored.
Warning
Currently, it is not possible to update observations; if the same observation is sent to PMD twice, two separate observations will be stored in PMD.
Each resource will be treated independently; internal bundle links are ignored.
Request validation
A minimal bundle that PMD will accept looks like the following:
{
"resourceType": "Bundle",
"type": "collection",
"entry": [
{
"resource": {
"resourceType": "Observation",
"subject": {
"identifier": {
"system": "urn:oid:2.16.578.1.12.4.1.4.1",
"value": "20716819028"
}
}
}
}
]
}
Bundle requirements:
resourceType=Bundletype=collection
Entry requirements:
resource.resourceTypemust be set, but onlyresourceType=Observationwill be processedresource.subject.identifier.system=urn:oid:2.16.578.1.12.4.1.4.1resource.subject.identifier.valuemust be a valid NIN (fødselsnummer)
Warning
No further validation is done by PMD.
Response
A successful request will return a response bundle with type=batch-response. It contains an entry array that corresponds one-to-one with the entries in the request bundle - in order - including resources not processed (e.g. not observations). Each entry has a response containing its resulting standard HTTP status code.
The order of the entries in the response bundle matches the order in the request bundle, so you have to deduce the HTTP status codes for each resource from their position in the array.
The response to a successful bundle request with a single resource looks like the following:
{
"resourceType": "Bundle",
"type": "batch-response",
"entry": [
{
"response": {
"status": "200"
}
}
]
}
A failed bundle request will get an OperationOutcome response: read more
Search
POST /Observation/_search
Content-Type: application/x-www-form-urlencoded
Body: patient.identifier=12345678901&date=ge2019-10-01&date=le2020-01-01
Search allows searching for observations for a single patient at a time over a given time period.
If you need additional search parameters (e.g by code), please reach out to us at komlink@nhn.no.
A search query is formatted as a URL encoded query string sent in the body of a POST request, with the correct Content-Type header set.
A failed search request will get an OperationOutcome response: read more
Available search parameters
patient.identifier=<nin>- (required) national identity number ("fødselsnummer") for the patientdate=ge<date>- (optional) greater than or equal, e.gdate=ge2019-10-01date=le<date>- (optional) less than or equal, e.gdate=le2020-01-01
Allowed date formats
Dates must be in RFC3339 format, but can have arbitrary precision as defined in the FHIR datetime specification.
If a time is specified, a time zone is required.
Examples:
2006-01-02T15:04:05.000Z07:00
2006-01-02T15:04:05Z07:00
2006-01-02
2006-01
2006
If a low precision date is used, the remaining datetime is set to zero values, i.e. 2006 will translate to 2006-01-01T00:00:00.000Z.
Find all observations for a patient
patient.identifier=12345678901
Find all observations for a patient between two dates
patient.identifier=12345678901&date=ge2019-10-01&le2020-01-01
Find all observations for a patient from a date
patient.identifier=12345678901&date=ge2019-10-01
Find all observations for a patient before (and including) a date
patient.identifier=12345678901&date=le2020-01-01
Error: OperationOutcome
A failed request will get a OperationOutcome response.
Example:
{
"issue": [
{
"code": "invalid",
"details": {
"text": "error parsing JSON request"
},
"severity": "error"
}
],
"resourceType": "OperationOutcome"
}