-
Notifications
You must be signed in to change notification settings - Fork 124
Profile
We are currently focused on being fully compliant with the US Core implementation of FHIR. In order to do this, we need to offer support for many resource profiles. On this Wiki page you will find all the current resource profiles we are supporting and instructions for how you can use them in an app leveraging node-fhir-server-core
.
Supporting a profile in your application using node-fhir-server-core
is very easy. We take care of a lot of the hard work for you like defining arguments, sanitizing arguments, checking scopes, token and user validation, defining routes, and converting the data into compliant US Core resources. All profiles are opt-in only and to tell the core server that you want to support a particular profile, you just need to provide the service that conforms to the profiles interface and the versions you intend to support. There are other configuration options available which will be covered below.
Here is a simple example of setting up a config object to be used in node-fhir-server-core
. In particular, pay attention to the profiles section in config.js
.
// config.js
const { VERSIONS } = require('@asymmetrik/node-fhir-server-core').constants;
module.exports = {
profiles: {
// These profile keys, e.g. patient, observation, etc
// are defined in the Profile Configuration section below
patient: {
service: path.resolve('./src/patient/patient.service.js'),
versions: [ VERSIONS.STU3 ]
}
}
};
// app.js
// Assuming you have already installed all the required dependencies
const FHIRServer = require('@asymmetrik/node-fhir-server-core');
const config = require('./config');
let server = FHIRServer.initialize(config);
server.listen(3000, () => server.logger.verbose('Server is up and running!'));
We support the following profiles. The profile_name
can be substituted anywhere in this document you see profile_name
and the profile_key
is the property you use in the profiles config object.
profile_name | profile_key |
---|---|
AllergyIntolerance | allergyintolerance |
CarePlan | careplan |
CareTeam | careteam |
Condition | condition |
Device | device |
DiagnosticReport | diagnosticreport |
Goal | goal |
Immunization | immunization |
Location | location |
Medication | medication |
MedicationRequest | medicationrequest |
MedicationStatement | medicationstatement |
Observation | observation |
Organization | organization |
Patient | patient |
Practitioner | practitioner |
Procedure | procedure |
Profiles have the following configuration options:
-
Type:
string|object
-
Description: Path to a service module or the actual module itself (e.g.
require('path/to/service')
). -
Required:
Yes
-
Default:
none
- Type: `Array
-
Description: An array of strings containing the versions you intend to support. You cannot add anything you want here, only valid versions supported in core will be used. See
exports.VERSIONS
in the constants file. -
Required:
Yes
-
Default:
none
-
Type:
object
-
Description: Set profile specific cors options. These will override the default
corsOptions
set in the server config. Please see https://github.com/expressjs/cors#configuration-options for details. Themethods
configuration will not be honored if specified here. This is controlled by@asymmetrik/node-fhir-server-core
and cannot be overridden. -
Required:
No
-
Default:
none
Currently each and every profile you intend to support, must conform to this interface. None of the profiles need extra methods at the moment but if/when they do, we will add a section to this Wiki documenting those as well on a per profile basis. The three methods that must be implemented in your service are getCount
, get<profile_name>
, and get<profile_name>ById
. For example, in a patient service, you need three methods exported, getCount
, getPatient
, and getPatientById
. Each method must also return a promise and will receive the following three arguments:
-
req
- The request object from Express -
logger
- A Winston logger instance used bynode-fhir-server-core
. -
context
- An object containing some information that may be useful when you are performing queries.
Here are some descriptions and examples of those three methods.
- Description: Return the number of resources of this type in your data store.
-
Return:
Promise.<number, Error>
-
Routes: No specific route, this is required to support count in the capability statement under
[version]/metadata
. - Example:
module.exports.getCount = (req, logger, context) => new Promise((resolve, reject) => {
logger.info(`Version >>> ${context.version}`);
db.patients.count((err, count) => {
if (err) {
logger.error('Error with Patient.getCount');
return reject(err);
}
return resolve(count);
});
});
- Description: Get the resource given one of several valid argument(s) and/or combination(s) of arguments in the req.query.
-
Return:
Promise.<object, Error>
-
Routes: Enables
/[version]/[profile_name]
via GET and/[version]/[profile_name]/_search
via POST - Example:
module.exports.getPatient = (req, logger, context) => new Promise((resolve, reject) => {
let query = buildQuery(req.query);
db.patients.find(query, (err, patients) => {
if (err) {
logger.error('Error with Patient.getPatient');
return reject(err);
}
return resolve(patients);
});
});
- Description: Get the patient given an id in the req.params.
-
Return:
Promise.<object, Error>
-
Routes: Enables
[version]/[profile_name]/:id
via GET - Example:
// In patient service
module.exports.getPatientById = (req, logger, context) => new Promise((resolve, reject) => {
db.patients.find({ _id: req.params.id }, (err, patient) => {
if (err) {
logger.error('Error with Patient.getPatientById');
return reject(err);
}
return resolve(patient);
});
});
Consult the table below to view any and all arguments supported by individual profiles. They all support this set of common arguments as well as the ones defined in the argument files below.