Create HAPI HL7 classes for EVN, ROL, AL1, DG1, PR1, IN1, IN3
User Story
As a sender of ADT data, I would like to be able to send any HL7 version
Description/Use Case
We'll want to investigate and create our HAPI HL7 classes for the new segments present in ADT_* messages that will support multiple versions of HL7.
Risks/Impacts/Considerations
Dev Notes
This will be very similar to what we did for ORU_R01 where the goal is to undeprecate all fields and expand the type to the largest version in the spec (i.e. some 2.5.1 fields are CE, but in 2.7 they are CWE, so the a new class should set them as CWE)
Acceptance Criteria
- [ ] The following segments are investigated for whether they HAPI HL7 2.7 version can be used (i.e. is expansive enough with no deprecated fields)
- ROL
- EVN
- AL1
- DG1
- PR1
- IN1
- IN3
- [ ] A new HAPI HL7 class is created for any segment that 27 version is not sufficient
- [ ] A new HAPI HL7 message is created for each ADT type we're supporting using the new classes and the existing ones created
- ADT_01
- ADT_03
- ADT_04
- ADT_08
Hey team! Please add your planning poker estimate with Zenhub @adegolier @arnejduranovic @david-navapbc @jack-h-wang @JFisk42 @kant777 @mkalish @thetaurean
If this task is started before https://github.com/CDCgov/prime-reportstream/issues/16307 then it should be able to address the comment here about removing the hapi v26 dependency.
@jack-h-wang to verify that this ticket is not a blocker to 16409
to be refined
AL1, DG1, IN1, IN3 were implemented in #16549. On a quick check, the EVN 2.7 class should be sufficient but we will need to create ROL and PR1 classes.
Ticket was rescoped and effort has been reduced