omnibase/health

Concepts

omnibase/health adds seven entities beside omnibase/office's (Office, Member, the agenda, the vault's Document): each one completes an office's record rather than repeating it.

The practice and its team

PracticeType: msp, health_centre, medical, nursing, physiotherapy, midwifery, paramedical. Practice::isHomeCareFirst() is true when the practice offers care at home and its type puts it first (a nursing practice): a site then shows care at home before appointments.

Sector: sector_1, sector_2, optam, not_contracted, contracted. Practitioner::getRpps() is the member's registryId; isPhysician() is profession code 10.

The patients

A profile is not a medical record: nothing clinical is kept in it. PatientProfiles::of($user) makes it when first needed, and on omnibase/office's ClientAccountEvent::CREATED (an account opened from the practice's invitation). PatientProfile::erase() empties it.

An appointment booked or requested online takes the patient's name as their profile writes it ("Camille ÉRABLE"), not the account's identifier (AppointmentNaming, on AppointmentEvent::BOOKED and REQUESTED). DependentBeneficiaries offers the dependants to omnibase/office's booking.

Care at home

HomeCareRequest (health_home_care_request): the patient (and the dependant it is for), the address and phone, careType (injection, dressing, blood_test, hygiene, infusion, monitoring, medication, other), frequency (CareFrequency: once, daily, every_other_day, weekly), start and end dates, preferred time, the prescription (a vault Document), the notes (encrypted, notesCipher), status (CareStatus: pending, accepted, refused, cancelled), the service area it fell in, who was assigned, the series of appointments made, when it was sent and decided. getVisitCount() counts the visits its frequency gives between the dates, in calendar days (Care at home).

The roles

What each one reads of a patient's documents is the voter's (Medical secrecy).

Medical secrecy

Documents

omnibase/office's vault lets the recipient and the sender read a document, and nobody else unless a regime says so. Base\Health\Security\CareTeamAudience is that regime:

"Follows the patient" is Base\Health\Service\CareTeam: the members the patient has, or had, an appointment with (not a cancelled one), and the practice's physician they declared as their "médecin traitant". The patient's objection is PatientProfile::sharingOpposition, set in their own profile.

Every view, download, deposit, withdrawal - and every refusal - is in the access log, which the patient reads in /espace/donnees and the coordination in the back office.

E-mails

None holds health data: a booking's e-mail says when and with whom, not why nor what for; "a document awaits you" has neither the document nor its title; "a message awaits you" has neither its text nor its subject. All of it is read signed in.

At rest

Documents, their titles and file names, appointments' reasons, home care notes: encrypted by omnibase/office's Cipher. Messages and their subjects: by omnibase/mailbox (encrypt: true). Both fail closed without their key.

The staff's second factor

Whoever reads patients' data signs in with more than a password. The application requires a second factor of the staff's role through omnisense/omnibase (its docs/20-architecture/account-security.md):

# config/packages/base.yaml
base:
    security:
        two_factor: { required_roles: [ROLE_STAFF], postpone: false }

A staff account (ROLE_STAFF, held directly or through the role hierarchy) with no second factor is sent to its enrolment page (/settings/security-required) from every page until it has one - no "not now" with postpone: false - and cannot switch its last factor off afterwards. Patients choose.

The bundle sets nothing itself: without these lines nothing is required, and the compliance widget says so ("Double authentification de l'équipe": missing). It then counts the staff accounts that have no second factor yet (a warning until each has one).

required_roles is fixed when the container is built. A site whose development and test accounts have no second factor lifts the obligation per environment - through a parameter, because a list given again under when@dev is added to the first one, not put in its place:

# config/packages/base.yaml
base:
    security:
        two_factor: { required_roles: '%app.second_factor_roles%', postpone: false }

parameters:
    app.second_factor_roles: [ROLE_STAFF]

when@dev: &no_second_factor
    parameters:
        app.second_factor_roles: []
when@test: *no_second_factor

(Until omnibase had the rule, the bundle redirected by itself - StaffTwoFactorSubscriber, switched by health.staff_two_factor - to /settings. Both are gone: an application that still sets health.staff_two_factor removes the line, and a test that asserted the redirect to /settings expects /settings/security-required.)

The video

End to end between the two browsers, the relay one's own. It is not listed by the ANS: no reimbursable teleconsultation through it - the compliance widget and /teleconsultation say so.

Hosting

Health data must be hosted by an HDS-certified host. The bundle cannot check that; it asks for the host's name (Settings), prints it in the legal notice, and marks it missing until it is given.

Home care

$request = $homeCare->submit($patient, [
    'street' => '8 rue du Moulin', 'postalCode' => '67998', 'city' => 'Aubach', 'phone' => '…',
    'careType' => 'dressing',            // injection, dressing, blood_test, hygiene, infusion, monitoring, medication, other
    'frequency' => 'daily',              // once, daily, every_other_day, weekly
    'startDate' => $from, 'endDate' => $until, 'preferredTime' => 'morning', 'notes' => '…',
], $dependent, $prescription);

1. The address is checked first against omnibase/office's ServiceAreas (postcodes, towns, or a radius). Outside all of them: HomeCareException('home_care.error.outside_area'), and nothing is kept - not the request, not the prescription.
2. Inside: a HomeCareRequest, pending. The note is stored encrypted; the prescription, if any, is a document of the vault.
3. The practice answers in /admin/agenda/soins-a-domicile: who goes, the day and hour of the first visit. HomeCare::accept() books the visits as a series (Booker::series()): one at the request's frequency from the first visit to the end date, counted in calendar days, all or none. Or refuse().

The members offered are those who have a home-visit appointment type (channel: home).

Patients' data

/espace (ROLE_USER): the next appointments (join the video room, add to a calendar, cancel), the documents not read yet, the home care asked, the care team. /espace/profil: who they are for the practice, their "médecin traitant", and their say on sharing within the team. /espace/proches: their Dependents - who they book for (the booking then offers them, through omnibase/office's BeneficiaryProviderInterface).

A PatientProfile is not a medical record: nothing clinical is kept in it.

Rights (GDPR art. 15, 17, 20)

Base\Health\Service\PatientData, from /espace/donnees:

• export($user): one array - account, profile, dependants, linked identities, appointments with their reasons decrypted, home care requests, the list of documents, who accessed them;
• zip($user): data.json and each available document, decrypted;
• erase($user): the profile emptied, the dependants removed, the appointments to come cancelled, the pending requests cancelled, the documents they deposited destroyed, those sent to them withdrawn. What must be kept stays, bare, until health:purge.

Retention

health:purge removes, after health.retention months: past appointments, decided home care requests, the access log; documents expired or withdrawn, their files destroyed; contact requests (omnibase/office's contact.retention_months); closed video rooms' handshakes. The durations are the practice's to set with its DPO; the defaults are placeholders, not legal advice.

Identity

The bundle provides one thing: Base\Health\Entity\IdentityLink - a provider, its sub, the account

• with a unique index on (provider, sub), and its repository (findOneBySub()).

An identity is attached by its sub, never by an e-mail address. An address proves nothing about who someone is; attaching a health account to whoever shows the same address would hand it over.

The protocol itself is not the bundle's: an application uses drenso/symfony-oidc-bundle (two clients) and writes its linker. The rule it should follow:

• an identity already linked signs in its account;
• someone already signed in who comes back from the provider links it to their account;
• Pro Santé Connect, nobody signed in: the practitioner of the team whose RPPS number it is (PractitionerRepository::findOneByRpps() - the national identifier is "8" + RPPS); nobody of the team: refused;
• FranceConnect, never seen: a first visit - sign in to an existing account to link it, or open a patient's account from the identity.

FranceConnect v2 answers its userinfo as a signed JWT, which drenso's client does not read (it json_decode()s the body): verify it against the provider's JWKS (lcobucci/jwt).

The back office

The screens are loaded when omnibase/admin is installed. Each one opens its writes to a role of the practice with omnibase/office's OpenToTrait.

The screens

Reading the Annuaire Santé

The practitioners' action registry (/{entityId}/registry) calls PractitionerRegistry::refresh($practitioner): with the member's RPPS number (registryId), the Annuaire Santé gives the profession and the MSSanté address, written on the Practitioner. It flashes admin.registry.read with the name and profession, admin.registry.no_rpps without a number, admin.registry.unknown when the registry does not know it, admin.registry.unavailable with the error when it cannot be read. The key is the API keys page's (api.annuaire_sante.key), else omnistate.annuaire_sante.api_key.

The home care requests

/admin/agenda/soins-a-domicile (health_admin_home_care, ROLE_STAFF) lists the requests waiting, inside the back office's frame. Each is accepted or refused with a POST to /admin/agenda/soins-a-domicile/{id}/accept or /refuse (health_admin_home_care_decide): accepting takes the member who goes and the first visit, and books the series (Care at home); the flash says how many visits were booked and for whom (admin.home_care.flash.accepted), or that the request was refused; a refusal of the booking (a slot taken) is flashed with its own message.

The tiles

Settings and keys

On omnibase/admin's settings page, health.legal.hds: the host certified for health data (HDS) the practice declares. On the API keys page, the Annuaire Santé's key.

Compliance

Six checks are added to omnibase/office's compliance tile:

yield MenuItem::block('health_requests', 'Soins à domicile', 'fa-solid fa-house-medical')->setSize(2);
yield MenuItem::block('health_inbox', 'Messages', 'fa-solid fa-envelope')->setSize(2);
yield MenuItem::linkToCrud(\Base\Health\Entity\PatientProfile::class, 'Patients', 'fa-solid fa-user');
yield MenuItem::linkToRoute('health_admin_home_care', [], 'Soins à domicile', 'fa-solid fa-house-medical');

Configuration reference

The health tree

Dumped with Symfony's YamlReferenceDumper from Base\Health\DependencyInjection\HealthConfiguration:

health:

    # The roles the groups give (security.yaml's hierarchy puts both under ROLE_STAFF).
    roles:
        practitioner:         ROLE_PRACTITIONER
        secretary:            ROLE_SECRETARY
        staff:                ROLE_STAFF
        coordination:         ROLE_ADMIN

    # The permanent banner: who to call.
    emergency:
        samu:                 '15'
        europe:               '112'
        deaf:                 '114'
        pharmacy:             '3237'

        # The out-of-hours medical line (permanence des soins).
        oncall:               '116 117'

    # Months each thing is kept once over (health:purge), to be set by the practice with its DPO.
    retention:
        appointments:         36
        home_care:            36
        access_logs:          36
        signals:              1
        documents_after_expiry: 1

    # Whether the video solution is listed by the ANS (reimbursable teleconsultation). The one built in is not: the back office says so.
    teleconsultation_referenced: false

Each key is a container parameter (%health.roles.staff%, %health.retention.appointments%, %health.teleconsultation_referenced%...). The retention defaults are placeholders, to be set by the practice with its DPO.

The command

bin/console health:purge removes what has outlived its retention (Patients' data); --dry-run says what would go and removes nothing. Run it from cron, once a day.

What the bundle sets for omnibase/office

The team's and the member's templates (practitioners, with their fees and next slots), the contact form's warning (no medical data there), the patient space's menu. Its services plug into omnibase/office's and omnibase/mailbox's interfaces:

Base\Health\Transmission\MssanteTransmitterInterface is a contract without an implementation (sending to Mon espace santé takes an operator and a CPS card).

Twig functions

Translations

The domain health, in French only (ICU format).

Testing

Running the suite

Inside a host application that has omnibase/office (the suite boots the host's kernel once, for omnisense/omnibase's class aliases):

php vendor/bin/phpunit -c vendor/omnibase/health/phpunit.xml.dist

The bootstrap also reads the omnibase/* packages the bundle requires or suggests from beside the checkout, when the host has not installed them.

omnisense/omnibase-harness has no omnibase/office: its test health stops at the first class it needs (Base\Office\Controller\Admin\OpenToTrait). With omnibase/office's checkout on the harness's autoloader and no kernel, 14 of the 23 tests pass; the 9 others (CareTeamAudienceTest, four of StaffTwoFactorCheckTest) need the kernel's App\Entity\User aliases, so a host with omnibase/office.

What the tests check