-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Live waveform data in Emap #66
base: develop
Are you sure you want to change the base?
Conversation
is not needed as long as project.build.sourceEncoding property is set.
emap setup; fix docs
the waveform queue. Fixing this a proper way was too awkward.
get around Spring circular dependency problems.
before enabling multi-row INSERTs
inserts are merged into fewer multi-row inserts
sequence for every single row.
order of messages.
allow more data to be put in during validation.
to allow for configurations where not all data sources are present.
out the numeric SQL data type a bit better.
Detect overlapping data
hl7 waveform when running validation. Some refactoring to make testing better.
Read HL7 dump from file and other misc fixes
PR checklistDefault guide for a PR (if multiple PRs for the work, only keep one version of it and link to it on the other PRs)
|
Setup script changes and misc bug fixes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Certainly a lot there, hopefully I made sense of most of it. Some comments and questions but nothing blocking
...in/java/uk/ac/ucl/rits/inform/datasinks/emapstar/controllers/VisitObservationController.java
Outdated
Show resolved
Hide resolved
...in/java/uk/ac/ucl/rits/inform/datasinks/emapstar/controllers/VisitObservationController.java
Outdated
Show resolved
Hide resolved
emap-star/emap-star/src/main/java/uk/ac/ucl/rits/inform/informdb/visit_recordings/Waveform.java
Show resolved
Hide resolved
// derived from real data | ||
1, List.of(11, 12, 14, 15, 16), | ||
2, List.of(17, 18, 19, 20, 21), | ||
3, List.of(22, 23, 24, 25, 26), | ||
4, List.of(27, 28, 29, 30, 31), | ||
5, List.of(33, 34, 35, 36)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doesn't need to be fixed now but would be nice to have this as an input file rather than copiled in the code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about it but couldn't really see the use case.
If you want it as completely external data (ie. can change it with no docker rebuild, an env var points to an external file or something), then I'd argue this data is still important enough that you'd need some form of version control for it (eg. another git repo), which adds a dependency and thus complexity and moves away from our monorepo benefits.
If you just mean moving it to a CSV but keeping it in the repo, then it's still going to need a docker rebuild when it gets changed, but by using CSV you've lost the benefits of type/syntax checking that the java compiler provides. Perhaps if we had a dedicated config directory containing CSVs with this sort of data, we could exclude this from the docker build but mount it into the container instead. But it would only save us a rebuild as often as this data changes, which isn't very often.
* it seems to copy data to structures that aren't what I want as final output (Varies[]), | ||
* whereas this parser doesn't attempt to process the contents of any fields, allowing | ||
* the calling code to do as it wishes. | ||
* It's about 100-1000x faster. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ha fun, did you try and other HL7 parsers btw?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None other than HAPI
I think it's time to create this PR now. I would be particularly interested to see @stefpiatek 's feedback.
I appreciate it's quite large, but @skeating has been reviewing it in chunks, going into the
sk/waveform-dev
branch from which we're now merging. So this is not the first time it's been seen by anyone except me!waveform_hf_data.md
, the main design document, is a good place to start reading.Project board is at https://github.com/orgs/UCLH-DHCT/projects/3/views/1