Skip to main content
Skip table of contents

Single Pregnancy Record access

The pregnancy record in the BadgerNet Platform represents an active care record for a single pregnancy episode for a unique person. If that person has more than one pregnancy, the pregnancies will exist as distinct BadgerNet care records, linked by the fact that the pregnant person has the same National ID.


Care Locations in the pregnancy record

BadgerNet Care Locations are places or groups of individuals associated with a place where the care of the pregnant person occurs. These can be hospital maternity wards, midwifery-lead units, community maternity teams, GP practices etc.

A BadgerNet pregnancy record will always be linked to at least one Care Location: by default, this is the location in which the record was created. Care Locations throughout the country can provide care as part of this pregnancy episode.

At any one time, there is always one “active care location” assigned to a single pregnancy record.

Any Care Location can “pull” the active care to their Care Location, and this can be achieved with the BadgerNet Spine by a Spine Client System sending [BNetPregObs_ActiveCareLocation] FHIR resource data. When a Spine Client System updates the record with a [BNetPregObs_ActiveCareLocation] FHIR resource, that Spine Client's associated Care Location becomes the Active Care Location.

In defining a care location as the active care location, an entry is made to the medical record that that care location and associated users are responsible for care at that particular point in the pregnancy.

Spine Client Systems and BadgerNet users can update the pregnancy record at any time, except key demographics data items, which can only be updated by a Spine Client System or BadgerNet User at the currently Active Care Location. For Spine Client Systems, “key demographic data items” represent any of the data in the [patient] FHIR resource.


Creating a new pregnancy record

Any Spine Client System can create a new pregnancy record at any time. As all Spine Client Systems of type “MAT” are associated with a single Care Location, then this Care Location becomes the initial stakeholder of the created pregnancy record.

To create a pregnancy record, a Spine Client System will use the request that is defined in the Creating a Pregnancy section of the documentation. If the client attempts to create a pregnancy record which already exists within the Spine, a HTTP 409 Conflict error will be returned to the client. In this circumstance, a Spine client can attempt to find this pregnancy record (and thus the pregnancy record’s Logical ID) by using the Finding a Pregnancy request.

BadgerNet Pregnancy Stakeholders

Access rights to each pregnancy record are driven by the concept of care record “stakeholders”.

You have access to a pregnancy record if you are one of the stakeholders of that record.

A stakeholder is either a Care Location or a single BadgerNet user. If a stakeholder is a Care Location, then all BadgerNet users associated with that Care Location have access to these records.

Every BadgerNet Pregnancy record will have at least one stakeholder - the Care Location at which the pregnancy record was created.

What is a Stakeholder?

A care record stakeholder for a single pregnancy record is defined as any of the following:

  1. A BadgerNet user associated with a Care Location that has been an active care provider for this pregnancy at any time during the pregnancy.

  2. A MAT Spine Client System that is associated with a Care Location that has been an active care provider for this pregnancy at any time.

  3. A MAT Spine Client System that is associated with a Care Location where any Spine Client System has written to or read from that care record using the Spine API.

  4. A single BadgerNet user that has ever manually requested record access using a BadgerNet Client Application.

What can a Pregnancy Stakeholder do?

  1. A BadgerNet user, using a BadgerNet Client Application, can read all data in the patient care record and perform any care record updates as needed for those pregnant people within their Care Location.

  2. A Spine Client System instance can access for both reading and writing any of the FHIR-modelled data for this pregnancy that matches the BadgerNet Spine Record Filter assigned to that Spine Client System.

What can a Pregnancy Stakeholder NOT do?

  1. Delete/remove a pregnancy record in its entirety. This is handled via national administration or Care Location administrators where that Care Location is the only one for that pregnancy.

  2. Spine Client System stakeholders cannot delete any resulting BadgerNet Care Record notes that were created in error. If a BadgerNet note entry is made as a result of a Spine Client System data bundle needs to be deleted, this can be handled by emailing the Clevermed Support Team at support@clevermed.com with the Logical ID of the respective pregnancy record and ID of the FHIR Resource to be deleted.

  3. “Push” active care to another Care Location. All Care Locations must “pull” care of a pregnancy record.

How to become a stakeholder

A Spine Client System becomes a stakeholder for a single pregnancy by doing any of the following:

  1. Using the Find pregnancy endpoint, passing a Break Glass reason to identify a single pregnancy record.

  2. Using the pregnancy keys to write ANY data to a single pregnancy record. This includes creating or auto-updating a pregnancy record.

If the Spine Client System sends a “Change Care Location” data item (BNetPregObs_ActiveCareLocation FHIR resource), then all BadgerNet users and any other Spine Client System instance associated with that Care Location become stakeholders in this pregnancy record. Changing the Care Location by this means will make a note in the pregnancy record that this Care Location is responsible for care from this point in time.

Note: It is also possible to send a BNetPregObs_ActiveCareLocation resource with a historic [starttime] value in it. This is valid and will not affect the currently active Care Location as this is determined based on the last [starttime] for any Care Location.


Common Questions

Can a Non-BadgerNet user see or access the full BadgerNet record?

No, only BadgerNet users see the full BadgerNet record and only via one of the BadgerNet Client Applications. A Spine Client System only has access to its respective FHIR record.

Can a BadgerNet user access the FHIR Spine data?

No, only a Spine Client System using the FHIR API can access the FHIR patient data.

Is the FHIR record and the Native BadgerNet record kept in sync?

Yes. Where there is a mapping between the published FHIR Profiles and the native BadgerNet care record, they are kept in sync in both directions. When a Spine Client System sends FHIR data to the Spine, it is mapped to BadgerNet synchronously. When any data changes in the raw BadgerNet record from any source, then its respective FHIR record is asynchronously updated to reflect this change. This will happen normally within a few seconds after the BadgerNet record has been updated but could be up to thirty seconds.

Does the BadgerNet record know which individual user of a Spine Client System has performed data changes?

The BadgerNet Spine does record details of the human user logged in, or associated with, the data bundle being submitted. When the BadgerNet Spine is sent a FHIR data bundle from the Spine Client System instance, the Spine API will capture the metadata value that includes who the associated human user is for that data bundle. This metadata value for every transaction is then logged in the Spine Audit Trail. 

Separate from the BadgerNet Spine audit trail, each underlying BadgerNet raw care record audit trail for the transaction will record that ‘Spine Client System XXX has made this record change’.  Each Spine Client System must keep its own detailed audit trail log of all patient care record transactions.

 

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.