drajer-health / ecrnow Goto Github PK

Multiple practitioner is retrieved at line[1], but only one practitioner is used due to overwriting logic at line[2]. If intension is to use only one practitioner then retrieve only one this will save time, if intension is use all practitioner then change code accordingly.
[1] - https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/service/LoadingQueryR4Bundle.java#L84
[2] - https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/cdafromR4/CdaEicrGeneratorFromR4.java#L45

Note: some of the logic in LoadingQueryR4Bundle.java is moved to R4ResourcesData.java, with that [1] is replaced with [3]
[3] - https://github.com/drajer-health/eCRNow/blob/Cerner-SonarFixAndITtests/src/main/java/com/drajer/sof/utils/R4ResourcesData.java#L721

At first condition is added at line[1] when retrieved the resource from FHIR call and later again populated from the bundle at line[2]. I think this is a defect and should be fixed. Also, similar issue with other resources like Immunization, DiagnosticReport, MedicationStatement, Observation(currently commented), etc.. All resources should be cross checked.

[1] - https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/service/LoadingQueryR4Bundle.java#L154
[2] - https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/cdafromR4/CdaEicrGeneratorFromR4.java#L57

Note: some of the logic in LoadingQueryR4Bundle.java is moved to R4ResourcesData.java, with that [1] is replaced with [3]
[3] - https://github.com/drajer-health/eCRNow/blob/Cerner-SonarFixAndITtests/src/main/java/com/drajer/sof/utils/R4ResourcesData.java#L790

In immunization section, date/time field is populated as below with "DateTimeType" string instead of only date/time value (2014), in narrative text and effectiveDtTm fields.

DateTimeType[2014]
<effectiveTime value="DateTimeType[2014]"/>

code System names are not standardized in code, translation and value elements.



Post the RR to the EHR using a Document Reference.

combines a set of unencoded URL params; these should be urlencoded (libraries like https://www.npmjs.com/package/qs can help)

The 4 Critical and 1 high issues in the attached document need to be addressed before deployment in production. 2 of the critical issues can be considered related to #65

com.drajer.ecrnowais-ecr-now_Trunk_2020-12-07 DeveloperWorkbook.pdf

Display name is not populated in code, translation and value elements. Use coding.text if display is not present.




Add support to populate Pregnancy Observation and Travel History entries in Social History Section.

[1] - https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/cdafromR4/CdaSocialHistoryGenerator.java#L72

Add timestamp columns to capture the last update time for the record for all tables.

added EICR xml validation

Logged passwords:
https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/model/ClientDetails.java#L373
https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/model/ClientDetails.java#L381

Different loggers:
https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/model/ClientDetails.java#L11
https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/model/ClientDetails.java#L15-L16
https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/model/ClientDetails.java#L369-L390

Fails to filter the encounter based on dt/tm due to exception at line[1]. Here period.getEnd() will be NULL as it won't be present always. Also, the dates "start" and "end" will also be null as per the logic at line[2].

[1]- https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/utils/R4ResourcesData.java#L84
[2]- https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/launch/LaunchController.java#L438

Also, need to cross check the logic at [3], sends failure response if encounter missing in the request. Instead, if it is able to retrieve the encounter based on patient ID then it push return success.
[3]- https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/launch/LaunchController.java#L173

Line[1] will throw expectation as Occurrence can be of 3 different types. If it is not of type DateTimeType then it will throw expectation and other resource entries in the bundle won't be processed.

[1]-https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/utils/R4ResourcesData.java#L676

Try to retrieve getOccurrence and then check for the type.
Same issue with Immunization[2] as well, need to cross check.
[2]- https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/utils/R4ResourcesData.java#L612

Code looks for identifiers based on below URL.
http://hl7.org/fhir/ValueSet/identifier-type
http://hl7.org/fhir/v2/0203
But, Cerner patient r4 response has MRN with below URL.
http://terminology.hl7.org/CodeSystem/v2-0203

There is a bug at line[1], it should be using the method getXmlForEmail.

[1]-https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/cdafromR4/CdaFhirUtilities.java#L352

Patient Ids:
- Algorithm will look for Patient Ids in FHIR resources Patient.identifier of type MR.
- If the System Values are populated as urn:oid, they will be used as is and the identifier will copied over to the CDA.
- If the system value matches some code system URL that can be translated to an OID, then the identifier will be copied over to CDA.
- If the system value cannot be translated to an OID or the system value is not populated and the default AA OID is configured in the App, the identifier will be copied over to the CDA.

- All other types of identifiers will be ignored (Non MR types).

Currently code look for agro-birthsex with url http://fhir.org/guides/argonaut/StructureDefinition/argo-birthsex. it should also support us-core-birthsex with url http://hl7.org/fhir/us/core/StructureDefinition/us-core-birthsex.

We need a rest API to delete a test patient for automation in our CI/CD environment

In the results section of the EICR document generated through application, text has 3 columns in the table. The order in which the table columns appear is not in sync with the order in which the table data is displayed. This happens due to the use of HashMap [CdaTesultsGenerator, Method-generateResultsSection] to store row values.

Code Snippet:

     for (Observation obs : results) {

    String obsDisplayName = CdaGeneratorConstants.UNKNOWN_VALUE;
    List<Coding> cds = null;
    if (obs.getCode() != null && obs.getCode().getCodingFirstRep() != null) {

      cds = obs.getCode().getCoding();

      if (!StringUtils.isEmpty(obs.getCode().getCodingFirstRep().getDisplay())) {
        obsDisplayName = obs.getCode().getCodingFirstRep().getDisplay();
      } else if (!StringUtils.isEmpty(obs.getCode().getText())) {
        obsDisplayName = obs.getCode().getText();
      }
    }

    Map<String, String> bodyvals = new HashMap<>();
    bodyvals.put(CdaGeneratorConstants.LABTEST_TABLE_COL_1_BODY_CONTENT, obsDisplayName);

    String val = CdaGeneratorConstants.UNKNOWN_VALUE;
    if (obs.getValue() != null) {

      val = CdaFhirUtilities.getStringForType(obs.getValue());
    }

When processing Telecom for patient only phone[1] is supported but not email, add support for email.
[1] -https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/cdafromR4/CdaHeaderGenerator.java#L476

When the specific lab test matches, the matching code should be in the code element of the observtaion and the other codes should be in the translation.

The observation value should be the value from the lab test, .

PAtient Id :
Encounter Id:

Observation with the matching LOINC code in the code element.

Value element should contain the value from the FHIR result value. If the value matches, then we should add the SDTC value set and value set version to the element.

For determining Encounter location to be used for jurisdictions.

- Algorithm will look for Encounter.location.address in the FHIR Resource, 
	- If address is found , then the address will be used in the CDA document.
	- If the address or location does not exist, then 
		- Check the Encounter.service Provider.address 
			- If found, we will use that.

- If we do not find an address after the above algorithm, then we will not produce an eICR.

- In future, we can add the following to the algorithm to determine address: 
	
	- Check Encounter.participant —
		 - Practitioner . Address 
		- - Practitioner Role .address
		- - Organization.address 

If it is found then use it.

Vulnerabilities that need to be addressed before production deployment.

Vulnerabilities reported in frontend/package-lock.json
kind-of - Known security vulnerability in 3.2.2 https://nvd.nist.gov/vuln/detail/CVE-2019-20149
object-path - Known security vulnerability in 0.11.4 https://github.com/mariocasciaro/object-path/security/advisories/GHSA-cwx2-736x-mf6w

Vulnerabilities reported in frontend/yarn.lock
acorn - Known security vulnerability in 6.1.1 https://github.com/acornjs/acorn/issues/929
dot-prop - Known security vulnerability in 4.2.0 https://nvd.nist.gov/vuln/detail/CVE-2020-8116
elliptic - Known security vulnerability in 6.4.1 https://nvd.nist.gov/vuln/detail/CVE-2020-13822
handlebars - Known security vulnerability in 4.1.2 https://nvd.nist.gov/vuln/detail/CVE-2019-19919
http-proxy - Known security vulnerability in 1.17.0 https://github.com/http-party/node-http-proxy/pull/1447/files
kind-of - Known security vulnerability in 6.0.2 https://nvd.nist.gov/vuln/detail/CVE-2019-20149
lodash - Known security vulnerability in 4.17.11 https://nvd.nist.gov/vuln/detail/CVE-2020-8203
minimist - Known security vulnerability in 0.0.10 https://nvd.nist.gov/vuln/detail/CVE-2020-7598
node-forge - Known security vulnerability in 0.7.5 https://nvd.nist.gov/vuln/detail/CVE-2020-7720
serialize-javascript - Known security vulnerability in 1.7.0 https://nvd.nist.gov/vuln/detail/CVE-2020-7660
websocket-extensions - Known security vulnerability in 0.1.3 https://github.com/faye/websocket-extensions-node/security/advisories/GHSA-g78m-2chm-r7qv
yargs-parser - Known security vulnerability in 11.1.1 https://github.com/yargs/yargs-parser/commit/63810ca1ae1a24b08293a4d971e70e058c7a41e2

In EncompassingEncounter section CODE is always nullflavour as it is using encounter.type instead of encounter.class[1]. As per spec Value Set: ActEncounterCode urn:oid:2.16.840.1.113883.1.11.13955 should be used for CODE. Valueset ActEncounterCode is used in Encounter.class as per [2].

[1] - https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/cdafromR4/CdaHeaderGenerator.java#L383
[2] - https://www.hl7.org/fhir/v3/ActEncounterCode/vs.html

Currently passwords are clear text and they need to be encrypted, look at using Kubernetes as an option.

At line [1] createEicrStatus is used, I think it should be CloseOutEicrStatus.
[1] - https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/eca/model/CloseOutEicrAction.java#L70

Logic at line[1] will add duplicate Practitioner to the Bundle as Encounter may contain same Practitioner multiple time with different relationship. This would eventually cause duplicate in CDA.

[1]-https://github.com/drajer-health/eCRNow/blob/master/src/main/java/com/drajer/sof/utils/R4ResourcesData.java#L721

Add unique Practitioner to the bundle.

clientsecret in clientDetails table should be encrypted

Address for guardian is not supported in header section.

The Open Source OWASP Dependency checker reports the attached vulnerabilities. Some can be addressed by uplifting to Spring Boot 2.3.7.

dependency-check-report.zip