Stream: implementers
Topic: Birth notice
Patricia Alves (Apr 08 2016 at 14:25):
Hi, can anyone tell me if there is any resource suitable for registering a birth notice, that includes information about the mother, type of birth and of information about the newborn (apgar measurements, body measures, confirmation of vaccinations taken at birth, etc)? Or I should use a set of resources for that, like: DiagnosticReport with a set of Observations for the measurements (and what other resources)? Thank you
Lloyd McKenzie (Apr 08 2016 at 17:58):
You'd definitely want a set of resources - so a profile on Bundle (possibly a FHIR Document, though not necessarily). If the focus is the birth, that would be Procedure. Then you'd also link in the various Observations, Immunizations, MedicationAdministrations, etc.
Eric Haas (Apr 09 2016 at 07:41):
Why not use a form = Questionnaire/ QuestionnaireAnswer? This is an approach that has been suggested by me and others for vitals records and case reporting as well?
Lloyd McKenzie (Apr 09 2016 at 14:33):
Questionnaire can be used as a data capture tool to represent absolutely anything - but the data within it is opaque and pretty non-standard. I.e. There'd be little chance of an arbitrary third-party being able to do anything computable with the data.
Lloyd McKenzie (Apr 09 2016 at 14:34):
In most cases, you'd want to take the data you capture using a Questionnaire (Questionnaires make excellent data capture tools) and convert it to other resources for use in subsequent retrieval/analysis/computation.
Eric Haas (Apr 09 2016 at 17:24):
Why can't the QA be exchanged and used like any other resource. especially for secondary use like pop health Especially if you develop an IG ( e.g. US Realm Case report ) and have references to resources as some of the answers. Im trying to understand the cons vs a using resource for notice.
Lloyd McKenzie (Apr 09 2016 at 20:54):
Well, if you want to find birth procedures, you'd search on Procedure where the Procedure.code is one of the codes for birth in SNOMED, CPT and other common coding systems. You could then find the date and time it had occurred, the method, who performed the delivery, etc. in standard places in the Procedure resource. If you capture the data in Questionnaire, there's no way to query against QuestionnaireResponse to find a birth record unless you know all of the possible Questionnaire ids that might be used to capture birth information. Furthermore, there'd be no way to know which questions captured the birth method, the birth time or other information without human inspection. Making use of Questionnaire for data exchange requires a significantly higher degree of pre-negotiation and agreement to get out any kind of data than using the topic-specific resources. Using Questionnaire as a means of primary data exchange means you're using FHIR as a transport for custom data structures
Eric Haas (Apr 11 2016 at 06:33):
Thanks Lloyd following up with SDC questions on a new stream
Patricia Alves (Apr 11 2016 at 08:08):
Thank you for your answer Lloyd, the Procedure makes sense. I shall use a Bundle with a Procedure to introduce information about the mother and the birth, where the Procedure.report references a DiagnosticReport with a set of Observations for the newborn. The pregnancy information can be registered in the Condition resource, being referred by the Procedure.reasonReference.
Where can I reference the newborn Immunizations? And where can I put information on the Puerperium?
Also, where can I register if the mother fulfilled the pre-natal monitorization ultrasounds and exams (and which)?
Thank you.
Lloyd McKenzie (Apr 11 2016 at 15:48):
Immunizations would be the Immunization resource. And they're not directly tied to the birth procedure. If you care about both the care leading up to the birth as well as the care afterwards, you might want to link everything through EpisodeOfCare. You'd have one episode that would be linked to everything associated with the pregnancy, including all of the visits, observations, etc. You could choose to algorithmicly filter which ones showed up in your bundle though. (The ultrasounds would most likely be ImagingStudy and the exams would either be encounters (if you just want to capture occurrence) or Observations or DiagnosticReports (if you want to capture the findings).
Patricia Alves (Apr 12 2016 at 10:10):
Thank you very much for your help!
I leave a suggestion for creating a new resource for registering the newborn information (if it was liveBirth, measurements, apgar results, if the newborn was admitted to Neonatology, etc.), since it is very complex to register all the newborn information using so much resources; and another resource for pregnancy monitoring, for the same reasons.
Lloyd McKenzie (Apr 12 2016 at 15:22):
When you're drawing on a whole bunch of different types of information, you should expect a bunch of resources. Each of the individual occurrences (each immunization, each observation, etc.) will be - and will need to be - a distinct resource. Compiling the information into a report/document will involve creating a Bundle of the relevant resources. We might create a profile that defines the specific set of information to be included.
Patricia Alves (Apr 13 2016 at 10:51):
That would be great :)
Patricia Alves (Apr 13 2016 at 11:43):
Another question if you can aswer please. On which resource(s).element can I register the mother's pregnancy data like: pregnancy days, pregnancy weeks, type of pregnancy (if it is simple, or multiple), pregnancy risk, reason of the risk, if was administered immunoglobulin, number of visits to the doctor during pregnancy, list of locations where the pregnant is being followed, name of the family doctor, name of the family nurse
Lloyd McKenzie (Apr 13 2016 at 15:10):
It depends. You can capture anything and everything as responses to a Questionnaire. However, that isn't terribly interoperable. If you want data that's queriable and can easily be used by decision support, then you're looking at using Observation and MedicationAdministration/MedicationStatement and possibly things like RiskAssessment, as well as EpisodeOfCare, CareTeam, etc. (Note that CareTeam is from STU 3)
Patricia Alves (Apr 13 2016 at 15:23):
Yes I understand what you mean, but with the use of all those separate resources I'm getting a Bundle with tens of linked resources just to send information from an hospital to the mother's primary care unit to register a birth. It is becoming such a complex structure that the main purpose of using FHIR messages to make uniform and standardized communications is being sort of "contradicted".
Lloyd McKenzie (Apr 13 2016 at 15:26):
If you want to send something super light-weight and it's not for general purpose interoperability (you don't expect anyone to query based on the data or to be able to access parts of the information for other purposes (e.g. what substances have been administered to the infant, what encounters has the mother had over the past year), then QuestionnaireResponse might be your best bet.
Patricia Alves (Apr 13 2016 at 15:35):
Sorry for this question, but when you say "to query based on the data", you mean to query the information directly on the resources in the message?
Lloyd McKenzie (Apr 13 2016 at 16:49):
Yes. So for example, if you wanted to be able to query to find birth weight or query to find head diameter across different ultrasounds or something like that.
Patricia Alves (Apr 13 2016 at 16:49):
Ah ok, we do not need to query the message then. We just want to send the data. What is your opinion on the use of a fhir document for this (http://www.hl7.org/fhir/documents.html)?
Lloyd McKenzie (Apr 13 2016 at 16:50):
A FHIR Document is a special type of Bundle, so that would fall within the first recommendation. You'd capture the different pieces and then wrap them all up in a document Bundle.
Patricia Alves (Apr 14 2016 at 08:22):
I think I'll go with the first recommendation with the bundle document, so that I can keep the data standard. Thank you for your help, it became easier to understand what to do.
Last updated: Apr 12 2022 at 19:14 UTC
