Is there a way to configure scope checking in routes? I need to restrict patients to only access their own data.

This line prevents the insertion of a new resource using PUT.

In order to retain the existing ID for a resource, it must be inserted via PUT (not POST) with the ID. I'm curious if there's an appetite to change that?

I caught your great webinar the other day, so first off thanks for that.

I thought I heard that the IHE mCSD profile was on your roadmap or maybe you even already support it, but looking at the README and the roadmap link today I think I'm missing it.

Are you planning/have support for mCSD? If not yet, do you have a timeline?

Also wondering if you are welcoming contributions/have a contribution document?

tl;dr Bundles of type transaction sent to Hearth with a POST will fail. I realized bundle transactions may or may not be supported by servers, or I made a mistake but this does work on http://fhirtest.uhn.ca/baseDstu3/

Reproduction:

• Generate synthea fake record.
• Modify the type to be transaction.
• Add POST method and URL to each resource under entry.
  POST to Hearth.

Error: 'Specifying an id is not allowed on a create action'

In a case that we have resource data from two different sources that sometimes might be slightly different and need to be kept separately. Is multiple databases be an ideal solution for this?

Resources like Location and Organization have a partOf field that is a Reference to the same type of resource. I don't see how to pass that information in the genChainedParamQuery function.

For example, for Organization you can use partof.identifier for a chained query. But I don't know what to put for the chainedModule instance since it refers to itself which hasn't finished loading yet. I tried "this" and "module" with no luck. I also tried doing it the same as the others by requiring itself and creating an instance.

So what can you put for HERE:

queryUtils.genChainedParamQuery(queryObject['partof.identifier'][constants.NO_MODIFER], 'partof.reference', 'identifier', HERE, (err, clause) => { })

Or does this just have to be done in some completely separate way. I could duplicate the resource module without the chained parameters and the use that, but that seems excessive and then requires two files to be updated when other parameters are changed so it doesn't seem ideal.

Thanks!

Suggestion is to add the ability to programmatically return a capability statement for behavior supported by Hearth. This was required for testing at the 2018 IHE NA Connectathon.

I'm curious how Hearth can/could handle different versions of the same documents. For a use case, say, for example, that a ministry of health using Hearth has to store different versions of it's facility info because they are updating records and may need to rollback.

I don't see in FHIR how it supports namespaces/domains or other ways to declare something akin to MongoDB collections that are versioned. Interested in your thoughts.

Hi,

I'm trying to setup a demo instance of Hearth to test compatibility with OpenMRS. However, after starting the server, all requests seem to return a 401 unauthorized error.

I am testing it in an Ubuntu 16.04 VM, sending API requests from Postman on the same machine. I have tested using Postman on other publicly available demo FHIR servers, so it does not appear to be the issue. I am trying to do a GET request at http://127.0.0.1:3447/fhir/metadata. My understanding of the FHIR standard is that this should get conformance data?

However, the response I get back is as follows:

{
    "resourceType": "OperationOutcome",
    "issue": [
        {
            "severity": "information",
            "code": "login",
            "details": {
                "text": "Unauthorized"
            },
            "diagnostics": "Unauthorized"
        }
    ]
}

The server seems to be starting up correctly, this is the console output where I do not see any obvious errors.

yarn run v1.7.0
$ node lib/server.js
2018-07-26T13:30:42.153Z - info: Loaded FHIR resource module: Binary
2018-07-26T13:30:42.158Z - info: Loaded FHIR resource module: Default
2018-07-26T13:30:42.159Z - info: Loaded FHIR resource module: DocumentManifest
2018-07-26T13:30:42.161Z - info: Loaded FHIR resource module: DocumentReference
2018-07-26T13:30:42.163Z - info: Loaded FHIR resource module: Immunization
2018-07-26T13:30:42.165Z - info: Loaded FHIR resource module: Location
2018-07-26T13:30:42.175Z - info: Loaded FHIR resource module: Matching
2018-07-26T13:30:42.176Z - info: Loaded FHIR resource module: Organization
2018-07-26T13:30:42.191Z - info: Loaded FHIR resource module: Patient
2018-07-26T13:30:42.192Z - info: Loaded FHIR resource module: Practitioner
2018-07-26T13:30:42.194Z - info: Loaded FHIR resource module: QuestionnaireResponse
2018-07-26T13:30:42.231Z - info: Using OpenHIM style authentication
2018-07-26T13:30:42.235Z - info: [undefined] Hearth FHIR server running on 0.0.0.0:3447
2018-07-26T13:30:42.644Z - info: Initializing MongoDB connection to mongodb://localhost/hearth-dev
2018-07-26T13:30:42.670Z - info: Initializing MongoDB connection to mongodb://localhost/hearth-dev
2018-07-26T13:30:42.742Z - info: Workers for matching queue successfully started
2018-07-26T13:30:42.743Z - debug: Checking if default sysadmin exists
2018-07-26T13:30:42.744Z - info: Initializing MongoDB connection to mongodb://localhost/hearth-dev
2018-07-26T13:30:42.797Z - debug: Default sysadmin exists
2018-07-26T13:30:43.713Z - debug: Worker 1 No records in queue
2018-07-26T13:30:43.749Z - debug: Worker 2 No records in queue

Is there anything that I'm required to do as part of the setup process that is not in the README? Also, could I know if there are others who have managed to get this working with OpenMRS?

Thanks,
Jiahao

Current behaviour:
The resource validation is being applied whether the config value is set to 'true' or 'false'

Expected behaviour
Setting the validation.enabled value to 'false' should disable the resource validation

Bug solution
https://github.com/jembi/hearth/blob/master/lib/server.js#L70

The places where this config is being checked needs to be updated to check the string value coming back from the config. At the moment, the conditions are assuming these are Booleans and evaluate to true for both string values ('true' / 'false')

When can we expect to see R4 definitions in Hearth? I did add the R4 definitions to my fork, but wasn't sure if that is right.

https://github.com/korada/hearth/tree/feature/r4-updates/lib/fhir/definitions