Add types and parsing support for automated referral workflows

[ryankelley]

Porting in changes we have had on the Kno2 fork for a number of years, these changes add support for the data types used in the 360x workgroup.

360X Project - Closed Loop Referral - Implementation Guide

The 360X Project seeks to enable providers—using existing health data exchange standards and technologies—to exchange:

• Referral requests containing relevant patient clinical information
• Result of referral containing relevant patient clinical information

Implementation Guide Link

Appendix C: Use of HL7 V2 message payload

OSU_O51 Specific Table: The catch and necessity here is:

Using the V2.5.1 definition, even though this is a V2.9 message structure.

[github-actions[bot]]

Unit Test Results

       5 files     111 suites   19s :stopwatch: 1 037 tests    984 :heavy_check_mark: 53 :zzz: 0 :x: 2 102 runs  2 020 :heavy_check_mark: 82 :zzz: 0 :x:

Results for commit 42af827f.

:recycle: This comment has been updated with latest results.

[milkshakeuk]

@ryankelley thanks for the PR 😊, could you provide some more info about the 360x work group, is this part of the standard hl7v2 specification?

[ryankelley]

@milkshakeuk Done, I put a high level summary with some links in the description, also tests will pass on ubuntu now

[milkshakeuk]

@ryankelley I'm still trying to understand where this logically sits, since it's not part of the official hl7v2 standards as published by hl7.org which nhapi is trying to provide types for. The C# types (just like the Java types in the hapi library this is a port of) are generated from the hl7 "normative" database (which isn't itself normative but its data is sourced from the normative specification).

I do feel like what you are bringing here in your PR is definitely something to consider, though where it lives I'm not sure, if it were to belong in nhapi I would be leaning towards it being its own dotnet project (and nuget package) which you would load in the additional message and types via the app.config approach (maybe)?

@duaneedwards @AMCN41R Do you have any thoughts on this.

@ryankelley I would also be keen to hear your thoughts on the best approach for this assuming it were to be part of the nhapi project (which I'm not against).

[duaneedwards]

The way I thought about these things seems to be similar to how @milkshakeuk has described. In other words, keeping the nHapi project basically just the result of the codegen step from the source database.

For example, Australia and New Zealand each have their own flavours of HL7 and I've typically handled their custom message requirements in separate projects basically as @milkshakeuk described above.

I'd be cautious about mixing the output of the code generated messages with any custom messages, it'd be quite easy to blow away custom work by regenerating from the source database. So my preference would be to keep them separated.

Curiously though, I reviewed the commits and noted that this pull request adds the SIU S26 trigger event for v2.5.1.
I checked my copy of the 2.5.1 standards document and this event is present in the standard.

@milkshakeuk When you get some time, can you please check your copy the source DB to see if the SIU S26 trigger event for v2.5.1 is present? It only appears to be present for v2.3 currently in the code generated files ...

[milkshakeuk]

@duaneedwards I will have a look

[milkshakeuk]

@duaneedwards there are now some txt (generated from running the generators using the DB I have) files for testing the source generators (It uses the Verify nuget package compare what's generated vs what's in the files).

I see this in the event mapping verify file, is that what you are expecting?

https://github.com/nHapiNET/nHapi/blob/1d026fbfdfc6c8c27c9f02dcfea1936906322e29/tests/NHapi.NUnit.SourceGeneration/Generators/EventMappingGeneratorTests.MakeAll_GeneratesAllEventMaps_251.verified.txt#L274

its also in the actual eventmap file: https://github.com/nHapiNET/nHapi/blob/1d026fbfdfc6c8c27c9f02dcfea1936906322e29/src/NHapi.Model.V251/EventMapping/EventMap.properties#L272

looks like we map SIU_S26 events to SIU_S12 according to the above ^

[ryankelley]

I am going to close this out, I believe the extendibility through the app.config will work. I am testing how this works fully in .net 6, but I expect it to satisfy the requirements.

[milkshakeuk]

@ryankelley I do this already for a project in my day job, I'll have a look tomorrow and reply to this thread the general approach for mixing (app/web).config and .net6.

I do want to add appsetting.json support at some time in the future but the old app.config way still works even in modern .net projects.

[milkshakeuk]

@ryankelley so it looks like we do this in the csproj (aspnetcore + .net6)

csproj

  <ItemGroup>
    <None Include="App.config" />
  </ItemGroup>

App.config as described here

<configuration>
  <configSections>
    <section name="Hl7PackageCollection"
             type="NHapi.Base.Model.Configuration.HL7PackageConfigurationSection, NHapi.Base" />
  </configSections>
  <Hl7PackageCollection>
    <HL7Package name="EPR.X.V24.X" version="2.4.X" />
  </Hl7PackageCollection>
</configuration>

It "should" be that simple.

[milkshakeuk]

@ryankelley did you manage to get this working?