XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Not Persuasive with Modification
    • Icon: Medium Medium
    • International Birth And Child Model (FHIR)
    • current
    • Patient Care
    • Informative
    • Thought Process
    • 5.1
    • Hide

      This IG is focussed on the method of transmitting data of a fetus in a transaction. It  explains how data should be communicated. It does not describe how data should be stored in an EHR. Some systems are capable of creating a pseudo-patient in their EHR, while other systems capture the data in a body-structure type  of class. Key is that users must be able to recognize what the subject is of the resource ( for example observation). If the system is able to identify the subject not being the (mother) patient itself, then it should be a small step to distinguish data into categories for maternal, fetus and child data. The IG does have the intent to promote the recognition of the fetus as a separate subject, thus making it perhaps more logical to store it in a similar way. 

      If a system is not able to recognize that the subject of measurements or results, such as blood type or femur length   are not  the mother , then it is not only considered semantically incorrect, but also prone to unsafe practice. Certainly in the case of multiple births, institutions that have to deal with these type of pregnancies, must be able to register the data of the fetusses separately, otherwise they cannot fulfill their care properly.

      We do recognize that their might be an issue when different EHR might want to match the data of multiple subjects. I.e. which data belongs to which fetus? This issue needs to be addressed in the next publication of the IG. 

      Apparantly the intent of the IG is not clear enough. Therefore the resolution is classified as "with modification" and the authors should make it more clear in the next publication.

      Show
      This IG is focussed on the method of transmitting data of a fetus in a transaction. It  explains how data should be communicated. It does not describe how data should be stored in an EHR. Some systems are capable of creating a pseudo-patient in their EHR, while other systems capture the data in a body-structure type  of class. Key is that users must be able to recognize what the subject is of the resource ( for example observation). If the system is able to identify the subject not being the (mother) patient itself, then it should be a small step to distinguish data into categories for maternal, fetus and child data. The IG does have the intent to promote the recognition of the fetus as a separate subject, thus making it perhaps more logical to store it in a similar way.  If a system is not able to recognize that the subject of measurements or results, such as blood type or femur length   are not  the mother , then it is not only considered semantically incorrect, but also prone to unsafe practice. Certainly in the case of multiple births, institutions that have to deal with these type of pregnancies, must be able to register the data of the fetusses separately, otherwise they cannot fulfill their care properly. We do recognize that their might be an issue when different EHR might want to match the data of multiple subjects. I.e. which data belongs to which fetus? This issue needs to be addressed in the next publication of the IG.  Apparantly the intent of the IG is not clear enough. Therefore the resolution is classified as "with modification" and the authors should make it more clear in the next publication.
    • Mike Padula / Rob Hausam : 4 - 0 - 0
    • Clarification
    • Non-substantive

    Description

      This model asserts that we can distinguish data into categories for maternal, fetus and child data. This does not seem to be accurate for existing EHR data modeling for maternal data.  Modeling interoperability for fetal data will require more focused work on EHR data models before it could move into the interoperability space.

      A few examples -

      A fetus is not assigned a unique patient identifier and will not be able to meet many standard constraints as a FHIR Patient including Legal Name, Legal Sex or Birthdate. Not having those elements makes patient matching and deduplication impossible between systems.

      Tracking of an individual fetus for birthing events with multiple fetuses is not always consistent in a clinical setting today.

      The guide refers in 5.1.5 to the mother and newborn relationships portion of the patient guide. The mother and newborn relationship section is explicit that there will not be a new patient or related person until the child is born.

      Attachments

        Activity

          People

            Unassigned Unassigned
            john_stamm John Stamm
            Isaac Vetter
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: