Skip to content
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

Please fix logical IDs #190

Open
reeager opened this issue Jun 7, 2024 · 9 comments
Open

Please fix logical IDs #190

reeager opened this issue Jun 7, 2024 · 9 comments

Comments

@reeager
Copy link
Collaborator

reeager commented Jun 7, 2024

Please fix logical ids to continue to be unique but must remove the following:

  • spaces
  • tildes
  • be less than 64 character

This is to ensure the IDs are meeting R4.

@alan-francis
Copy link
Contributor

We are creating the logical Ids for the following resources in the pattern described below:

  1. Bundle- Custom uuid-<PAT_MRN_ID>-<ENCOUNTER_ID>
  2. Patient - <FACILITY_ID>-<PAT_MRN_ID>
  3. Consent - consentFor-<PAT_MRN_ID>
  4. Observation - observationResponseQuestion-<ENCOUNTER_ID>-md5(<RECORDED_TIME>)-<QUESTION_SLNO>

We will be generating the above ids without spaces, tildes and perionds.
But the bundleId & observationIds tend to be more than 64 characters.

@reeager @raphaelvp @ratheesh-kr @shah

@reeager
Copy link
Collaborator Author

reeager commented Jun 18, 2024

@reeager periods can be used- update made.

@reeager
Copy link
Collaborator Author

reeager commented Jun 18, 2024

For Consent: mrn, assigning auth, Organization (custodian).

@ratheesh-kr
Copy link
Collaborator

The following are the generic id-primitive and dateTime-primitive rules that FHIR follows.

id-primitive

  • The id primitive in FHIR must adhere to specific constraints to ensure uniqueness and consistency:
    • Type: String
    • Length: 1 to 64 characters
    • Allowed Characters:
      • Lowercase alphabetic characters (a-z)
      • Numeric characters (0-9)
      • Hyphen (-)
      • Dot (.)
      • Underscore (_)
    • Regular Expression Pattern: ^[A-Za-z0-9\-\.]{1,64}$

dateTime-primitive

  • The dateTime primitive in FHIR follows a pattern derived from ISO 8601. It can represent:
    • Full Date and Time: YYYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm]
    • Date Only: YYYY-MM-DD
    • Year and Month: YYYY-MM
    • Year Only: YYYY
  • Components:
    • YYYY: Four-digit year
    • MM: Two-digit month (01-12)
    • DD: Two-digit day of the month (01-31)
    • T: Literal character 'T' used as a separator between the date and time parts
    • hh: Two-digit hour (00-23)
    • mm: Two-digit minute (00-59)
    • ss: Two-digit second (00-59)
    • Z: Indicates UTC (Coordinated Universal Time) if present
    • (+|-)hh: Time zone offset from UTC

@reeager @shah @raphaelvp

@alan-francis
Copy link
Contributor

alan-francis commented Jul 2, 2024

@reeager ,

  • we understand from the above document that we need to hash all the created logical Ids with the sha256 method.
  • Also we need to use the ~ as the concatenation string for each ID.
  • Can we have a more clarity on where to find the value for visit_number to be used for creating the IDs in Encounter and Observation?
  • Also the only Date-time field that we currently have is the RECORDED_TIME inside the screening CSV. So should we use that as the period:start/ message_date ?
  • If so, as there is no Rejection for an incorrect format of the RECORDED_TIME we may not have control over the format which will be then used in the ID generation process.

@shah @raphaelvp @ratheesh-kr

@reeager
Copy link
Collaborator Author

reeager commented Jul 5, 2024

@alan-francis

  • Tildes are not an allowed character for IDs.
  • I am not sure we are going to get visit_number, this might have to be derived.
  • Yes to your question about recorded time. The team should also start formatting recorded time correctly. We should discuss this with Ready.

@raphaelvp
Copy link
Collaborator

@reeager,

Please provide clarifications for the following:

  • For visit_number, if it needs to derived, specify the logic and source data to derive from.
  • There are specific format requirements in the Logical ID design document from the Data Lake team. If the RECORDED_TIME is incorrectly formatted, it will fail for other fields also.

@reeager
Copy link
Collaborator Author

reeager commented Jul 9, 2024

  • We can use encounter # for visit_number.
  • Let's talk to Ready about recorded_time.

@alan-francis
Copy link
Contributor

@reeager : So we can use the ENCOUNTER_ID from the SCREENING csv for visit_number. Also as this ENCOUNTER_ID is not a mandatory one and we are generating this if not available from FACILITY_ID and PAT_MRN_ID, we can do the same for visit_number as well.

@shah @raphaelvp @ratheesh-kr

@raphaelvp raphaelvp moved this from Todo to In Progress in 1115 Waiver Phase 1 (Q1 2024) Jul 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

4 participants