As for our needs, I believe we need to take a step-by-step approach. To start, it is best to create a
C_FastHealthcareInteroperabilityResources.class.php controller to accept queries and CRUD operations. If the base
Controller class doesn't allow for complex variable URI paths (i.e.:
/Patient/32/_history/4), I suppose we can use a query string for that as a workaround. Getting this code in place will put pressure on the existing codebase modernization work because the controller layer should really be "talking" with various service classes to get at the data, all while following known OpenEMR domain rules. We definitely don't want duplicate code!
Once a request comes in, we can use a FHIR parser that PHP calls. We may need to be clever here... the PHP FHIR parser doesn't appear to be very mature so we may need to think of a way for PHP to make a call to a Node.js script. Like Brady mentioned, the Java solution will most likely have an impact on user installs so it's best to stick with something simple like PHP/Python/Node from a dependencies perspective.
Once we get a good amount of the FHIR spec covered, the final step will be a good time to look into SMART-compliance and, perhaps, move away from the basic
C_FastHealthcareInteroperabilityResources.class.php controller (may need to use a separate Node server) to ensure we are fully compliant with SMART. I don't think it is a good idea to do this right out of the gate because this is very complex and I have a feeling the auth piece will be difficult.
As far as my https://github.com/MatthewVita/fake-patient-web project goes. I am very interested in pivoting the solution so that it's essentially a fork of https://github.com/smart-on-fhir/sample-patients but uses NAMCS data. As a bonus, I'd like to incorporate it all with the existing https://github.com/smart-on-fhir/smart-stub server. Elements from this dataset can then be used for the CRUD operations of our FHIR server for proper testing.