nhsconnect / careconnect-reference-implementation Goto Github PK

Acceptance Test 3.1.9

When running the search Encounter?date=gt2017-10-19T10:00 two records are not being returned that I would expect.

Encounter 4141 has a period 2017-10-19 | 09:35:24 to 2017-10-19 | 10:08:31 which means that the encounter was active after 10:00.

Encounter 4189 has a period 2017-10-19 | 09:47:10 to 2017-10-19. This one is more abstract given that the absence of a time suggests the Encounter finished anywhere between 00:01 and 23:59. This would theoretically make a period anywhere between 9:47 to 23:59 which includes times greater than 10:00.

When running the searches date=gt2017-10 or date=gt2017-10-19, a bundle with 0 results is returned.

date=gt2017-10: 10001, 10003, 10004, 10005, 10006... is expected
date=gt2017-10-19: 100007, 100018, 100032 is expected

date=gt2016 does seem to work correctly.

timeDate can represent periods of time rather than discrete datetime values. Because they are used in Encounter periods, there are a number of related issues around the way in which searches should behave.

Any query for an Encounter which includes a time should return Encounters that only have dates recorded given that a date alone encompasses a range of times. For example, Encounter?date=2017-10-17T13:58 should return 4509 which has a start and end dates but no times. Those Encounters which only have a start date should be handled this way also.

Ref: https://www.hl7.org/fhir/search.html#date
The range of the value as defined above; e.g. For example, the date 2013-01-10 specifies all the time from 00:00 on 10-Jan 2013 to immediately before 00:00 on 11-Jan 2013

date=2017-10-17T13:59 should return 4129 which has a start time of 13:59. This works ok but it should also be returning Encounters such as 4139 that starts at 13:39 and finishes at 14:15.

Ref: https://www.hl7.org/fhir/http.html#capabilities

In the following link there is the incorrect linking to the profiles as the profiles do not resolve
Metadata link:
http://194.189.27.193/careconnect/STU3/metadata
Link which can not be followed:

&

&

http://194.189.27.193/careconnect/STU3/Patient?birthdate=sa2015-05-11
Expected 200-OK Bundle with 3 patients (1046. 1053 & 1068) returned.
Received 200-OK 0 Patients,

UI implements search by id as an identifier search using system/value:
http://yellow.testlab.nhs.uk/careconnect-ri/resource?serverId=home&pretty=true&resource=Condition_

_id is one of the common parameters and should be an id field. See: http://hl7.org/fhir/stu3/search.html#all

Altered dao to make search case insensitive

Issue also relates to OPTIONS [baseurl]?_format=json

Hi, I am getting the below error when trying to start the latest release?

ERROR: Service 'ccri' failed to build: ADD failed: stat /var/lib/docker/tmp/docker-builder404952759/target/careconnect-ri.war: no such file or directory

authoredon only has date values but should have date and time values.

I am trying to access the Patient endpoint via a very simple browser-client demo hosted on heroku.

This app sits behind https and as such the browser raises 'Mixed content' warnings because the ccri endpoints are http only.

I tried switching to https ccri endpoints but got a certificate expired error.

Is it intended to make ccri available via https?

On my host (CentOS7, mvn 3.0.5, java 1.8), some builds yield ccrigatewayhttps war files that are difficult to start. This is caused by two versions of lib/bcprov-*.jar getting pulled in by the build. The classes in this jar define a circular dependency between org.bouncycastle.asn1.ASN1EncodableVector and org.bouncycastle.asn1.DEREncodableVector. If you are lucky, at start up this cycle is resolved in the same jar file and all works fine. If you are unlucky, the classes are pulled from different versions of the jar and an infinite loop kicks off. See https://stackoverflow.com/questions/17584495/unable-to-complete-the-scan-for-annotations-for-web-application-app-due-to-a for a similar situation.

The fix that worked for me was to add a packagingExcludes clause into the pom.xml file to eliminate one of the redundant jar files: I picked the one with the oldest version and now the service starts for me every time.

I will post a patch for the pom.xml file later.

Searching Condition with asserted-date using the lt prefix returns a bad request.

The expected beahviour is a 'less than' search.

Acceptance Test 3.1.1

See also equivalent issue with C# validation FirelyTeam/firely-net-sdk#435

Obs-7 states "If code is the same as a component code then the value element associated with the code SHALL NOT be present"

Example entry has no component and so not the same as the code. e.g.
https://gist.github.com/KevinMayfield/7f537f96efbe702c9fd2825e18f4cd53

This GET request https://data.developer.nhs.uk/ccri-fhir/STU3/MedicationStatement?patient=1010&_format=json will return the payload of the MedicationStatement where the patient logical id is 1010. However, this GET request https://data.developer.nhs.uk/ccri-fhir/STU3/Patient?_id=1010&_format=json&_revinclude=MedicationStatement:patient returns the patient with the logical id of 1010 but the MedicationStatement payload does not return.

http://194.189.27.193/careconnect/STU3/Patient?email:exists=false

Expected 1 patient to be returned.

Received 200-OK no patients.

Patient 1001 doesn't have an email address.

http://194.189.27.193/careconnect/STU3/Patient?birthdate=ap1917-06-04

Expected 11 patients to be returned.

Received 200-OK 0 Patients

http://194.189.27.193/careconnect/STU3/Patient?birthdate=ne1918-05-20
Add this possibility to the other servers. Provide a list of what is not appropriate and what should be supported in the Imp Guide

Currently, the secure endpoint only supports Authorization scopes that are based on the resource name - for example "user/Patient.read" or "patient/Medication.*".

The service should also be prepared to honour wildcard scopes - for example "user/*.read".

Acceptance Test 3.1.12

When running the following search...

asserted-date=gt2017-10-18

4 results were expected (10013, 10015, 10035, 10039) but 0 results are returned.

When running the query directly against the database, the rows are returned OK which would suggest the data is correct and running a query such as gt2017-09 returns a large set of results which appear to be correct.

Given that the identifier is a string it is syntactically correct to send an alphanumeric search string.

Documentation for the practitioner search in PractitionerRole has a typo. organation should be organization.

Searching Condition with asserted-date using the gt prefix returns a bad request.

The expected behaviour is a "greater than" search.

Acceptance Test 3.1.10

When setting the header's Content-Type to 'application/xml' or 'application/json' the server returns the DSTU2 standard Content-Type response.

For example, including the header Content-Type: application/xml in the request prompts the server to return Content-Type:application/json+fhir in the response. It should be fhir+json.

Ref: https://www.hl7.org/fhir/http.html#mime-type

Dates are presented with time values of T00:00:00 when there is actually no time associated to the date.

For example, Encounter 4145 has a date period.startdate of "2017-10-15T00:00:00". This should be "2017-10-15"

A search request of http://194.189.27.193/careconnect/STU3/Patient?birthdate==eb1919-07-13 returns a single patient with the dob of 1919-07-13.

A search request of http://194.189.27.193/careconnect/STU3/Patient?birthdate=eb1919-07-13 returns 200-OK no patients (which is also wrong).

Using == seems to change the interpretation of the request. Should this be trapped somehow (or at least interpreted as just an =)?

http://194.189.27.193/careconnect/STU3/Patient?gender=male

Expected 51 patients.

Received 200-OK no patients.

Are codes case insensitive?

Hello

I am trying to test out the reference implementation of the CareConnect API here:
https://data.developer.nhs.uk/ccri/exp. When trying to "sign in" to the open id connect server with my google id, I seem to end up in an infinite redirect loop. The log shows a CORS error just before redirect.

Apologies if this is the wrong place to report issues of this sort.

Thanks
Alex

http://194.189.27.193/careconnect/STU3/Patient?family=Vic

Expected 2 patients returned (1001 & 1058).

Received 200-OK no patients.

Fresh repo clone, startServer.sh fails:

Step 4/5 : ADD target/ccri-fhirserver.jar ccri-fhirserver.jar
ERROR: Service 'ccriserver' failed to build: ADD failed: stat /var/lib/docker/tmp/docker-builder007796907/target/ccri-fhirserver.jar: no such file or directory

(Have tried on Mac and Fedora with the same result)

Similar sounding issue to issue #66 (Cant Start - Missing careconnect-ri.war?), but link to alternative docker-compose file suggested by @KevinMayfield broken

Any suggestions?

Should the StructureDefinition & OperationDefinition be included in the capability statement. They have not been tested

Inside the HAPIRestfulConfig class, there are half-a-dozen attempts to set configuration variables using the @value annotation, for example:

	@Value("${fhir.oauth2.authorize:https://auth.hspconsortium.org/authorize}")
	private String oauth2authorize = "http://purple.testlab.nhs.uk:20080/authorize";

At the time these variables are used, in the initialize method, these @value expressions have not been applied. I think this is because the HAPIRestfulConfig class is not marked for scanning when Spring resolves property values, and so the @value expressions are ignored.

I think these configuration variables should be moved into the Config class which has been declared asa @configuration class and so @value resolution should work. Inside the Config class, the relevant variables could be wrapped into one or more @bean(s) for later retrieval by the HAPIRestfulConfig.initialize method.

I will try to prepare a fix later this week, and I am interested in any comments or guidance.