Receiving Newborn Demographic Data in a Well-Known Format

[JohnNKing]

Story

Sentence

As a hospital, so that newborn demographic data can be processed, I need the TI service to be able to receive the data in a well known format.

Pre-conditions

• Only a single, fake hospital is supported.
• A well known format of our choice is supported.

Acceptance Criteria

• Demographic data must be transmitted securely in non-development environments.
• The hospital receives confirmation that the newborn demographic data was successfully received by the TI service. (Notification from the lab is not yet expected)

Tasks

Research

• [x] Review HL7 LOI IG and map data elements on NBS cards
• [x] Map ADT-01 IG to HL7 LOI to compare overlap
• [x] Decide on the protocol and format for receiving newborn demographic data
• [x] Decide on the internal format to support
• [x] Decide if next of kin info will come from the FHIR patient resource - it will!
• [x] Determine a list of demographic data fields and types (from FHIR patient profile & NBS cards; review LOI; cross reference FHIR patient profile with per-state spreadsheet)
• [x] Get an example(s) of ADT HL7v2 messages for a newborn: https://confluence.hl7.org/display/OO/v2+Sample+Messages

Engineering

• [x] Parse FHIR format message (via a FHIR library?) - @halprin, @tjohnson7021
• [x] Decide if next of kin is in scope
• [x] Parse out next of kin - @halprin
• [x] Decide on acceptance response (also FHIR? custom?)
• [x] Return acceptance response
• [x] Foundational: DAST scanning -@Jorge
• [x] Foundational: API documentation (OpenAPI) - @tjohnson7021, @halprin
• [x] Foundational: Improved Linting (Sonar) - @halprin
• [x] Change e2e tests (e2e-execute.sh) to run through the JAR file instead of Gradle. @Jorge
• [x] Add support for the request body to be a FHIR bundle instead of just a Patient resource. - @halprin
• [x] Add support for the US Core Profile for the Patient resource. This will probably add support for some of the missing fields that we didn't find in the default Patient resource. - @halprin
• [x] Foundational: Arrange meeting with Security Engineer and/or ISSO to talk ATO - @JohnNKing
• [x] Looking into how to store private keys in Azure. - @halprin
• [x] Move FHIR example(s) used in tests into a file in the resources - @tjohnson7021
• [x] Extract MRN as the patient id

RS-Specific

• [x] Reach out to Brick to get us on boarded as a RS sender and receiver - @halprin
• [x] Get our RS sender client ID for their staging environment - @halprin
• [x] Get our RS receiver public key - @halprin
• [x] Schedule time with Rick and Jim to discuss ADT messages - @sfradkin, @JohnNKing

Definition of Done

• [x] Threat model updated (re-look at this and see if there's anything to do) @jorg3lopez
• [x] Code refactored for clarity and no design/technical debt (DRY-up some of the unit test data) @tjohnson7021
• [x] Adhere to separation of concerns; code is not tightly coupled, especially to 3rd party dependencies.
• [x] Source code is merged to the main branch. @jorg3lopez
• [x] Unit test coverage of our code >= 90%
• [x] Code is reviewed or developed by pair; 1 approval is needed but consider requiring an outside-the-pair reviewer. @jorg3lopez
• [x] Build process updated (update our CI to test build and run Docker container?) @jorg3lopez
• [x] Feature toggles created and/or deleted. Document the feature toggle.
• [x] Source code documentation created when the code is not self-documenting. (let's check the PatientDemographicsController and see if we need to add anything) @tjohnson7021
• [x] API documentation generated
• [x] Code quality checks passed
• [x] Security & privacy gates passed
• [x] Load tests passed (run these) - @halprin
• [x] Documentation and diagrams created or updated (update architecture diagrams) - @halprin
• [x] API(s) are versioned
• [x] Debug logging

Research Questions

• What will be the internal format for the TI service? (If FHIR, what type of resource/elements?): Decided on FHIR
• Which data elements will we initially support? (MSH, PID, and NK1 segments from the order message [this overlaps with ADT-01]): Answer: MSH & PID. Which transaction types will we support? (incomplete LOI; ADT?)

Decisions

• Well known format / Internal Format: FHIR R4 Patient Resource with baby demographic data that maps to the NBS card
• For now, initial receipt of order data to match internal format
• Move to other story: "Decide on the protocol and format for the TI service to receive"

Notes

• FHIR Patient examples.
• Demographic data we'll extract if its there in the FHIR resource.
  • First name. name[use:official|0].given[0]
  • Last name. name[use:official|0].family
  • Patient ID. identifier[value.exists].value
  • Sex. gender (looks like FHIR uses this as sex and there is a Patient extension that is used for gender identity)
  • Birthday. birthDate
  • Birth time. _birthDate.extension.valueDateTime (this contains the date in addition to the time so that it can be accurately tracked, https://hl7.org/fhir/R4B/extension-patient-birthtime.html)
  • Race. extension.where(url='http://hl7.org/fhir/us/core/StructureDefinition/us-core-race').extension.where(url='text').value (this is from the US Core Profile)
  • Birth order. multipleBirthInteger
  • Next of kin. firstName, lastName, phoneNumber
• Skipping for now.
  • Weight at birth.
  • Gestational age.

[MikeC-A6]

Starting with FHIR R4 Patient Resource in JSON

[halprin]

Waiting for a CDCgov GitHub organization owner to extend a SonarCloud binding to our repository.

[halprin]

Looks like the powers that be have given our repo access. I have now enabled the SonarLinting check as required for PRs to main.

[halprin]

FHIR Patient examples.

[halprin]

Azure has a Key Vault service. For our purposes, there are two areas that apply to us.

• Keys.
• Secrets.

For the keys, Azure can create RSA and EC keys or allows RSA keys to be uploaded. All the actions that you can do with this key is handled by Azure on your behalf. You cannot export the private key. So, if you need to do something with the private key that Azure doesn't support, you're out of luck.

Secrets are generic text strings. You can set them, update them, and retrieve them however you like. We could use this to store the private key.

I believe the best bet for us is to store the private key as a secret in Azure Vault Store because that gives us the best flexibility going forward. We have the option of doing actions with the private key that Azure hasn't foreseen or do things that require our code to act on it directly.

[halprin]

We have two client IDs in staging. Both are assigned to the same public key for now.

flexion.simulated-hospital and flexion.etor-service-sender.

[scleary1cs]

This Story helps complete the requirement: MVP-REQ-08 - Each intermediary will support at least one format for outbound orders