Weave Code
Ras Laravel Package
sysvale/ras
Laravel package by Sysvale for handling RAS (Registro de Atendimento em Saúde) data, providing PHP models, validation, and integration helpers for healthcare attendance records.
At a glance
Frequently asked questions about Ras
- What is sysvale/ras used for in Laravel applications?
- sysvale/ras is a Sysvale package for handling RAS (Registro de Atendimento em Saúde) data in Laravel applications. It provides PHP models, validation, and integration helpers so you can build, validate, and serialize healthcare attendance records that follow the LEDI layout. It is best treated as an adapter at the edge of your system rather than as a domain modelling library.
- How do I install sysvale/ras with Composer?
- Install it as a normal Composer dependency using composer require sysvale/ras and pin the version you have validated, for example 1.6.0. Because the package tracks an externally mandated healthcare specification, you should avoid floating constraints and commit the exact version in composer.lock. After installing, check whether a service provider and publishable config file are registered, then run your test suite against golden-file fixtures before deploying.
- Which PHP and Laravel versions does sysvale/ras support?
- The release notes for v1.6.0 only mention the update to LEDI 8.4.0 and do not state a PHP or Laravel version matrix. You should inspect the package composer.json require and require-dev sections, plus CI configuration, to confirm the supported PHP floor, Laravel constraints, and any required PHP extensions. Add that matrix to your own dependency policy before approving the upgrade.
- What is LEDI 8.4.0 and why does the v1.6.0 release of sysvale/ras matter?
- LEDI is the externally governed layout and validation standard that RAS records must conform to, and it has its own version release cadence. The sysvale/ras v1.6.0 changelog contains a single entry stating that the package now updates to LEDI 8.4.0. That makes the release a specification-tracking bump rather than a product feature release, so it should be scheduled and reviewed like a compliance dependency.
- Is the LEDI layout version configurable at runtime in sysvale/ras?
- The available information does not say whether the LEDI version is read from configuration or hardcoded in a constant. This matters because a configurable layout version lets you switch between 8.3 and 8.4 in different environments, while a hardcoded constant forces an application release. Inspect the config file and package source for the version string before planning your rollout.
- Can I run LEDI 8.3 and LEDI 8.4 side by side with sysvale/ras?
- It is not documented whether v1.6.0 still supports the 8.3 layout during a grace period or whether parallel support is possible. If the layout version is configurable, you may be able to select it per environment or per counterparty endpoint. Otherwise, side-by-side operation would require pinning different package versions in separate services.
- Does sysvale/ras v1.6.0 introduce breaking changes to its public API?
- The v1.6.0 changelog is a single line about updating to LEDI 8.4.0 and says nothing about renamed enums, changed method signatures, new required fields, or exception types. Because a nominal minor bump can still change serialization or validation behavior, review the full diff from 1.5.x to 1.6.0 before upgrading. Treat any change to public classes or config keys as a breaking change for your integration layer.
- How should I test sysvale/ras payloads against the official LEDI example documents?
- Wrap the package behind your own gateway or serializer interface and write contract tests that feed official LEDI 8.4.0 example documents through it. Assert on the generated payload and on validation failures, including edge cases such as missing required fields and changed code tables. It is not stated whether the package ships 8.4.0 golden-file fixtures, so building your own fixture set is the safer assumption.
- How do I stop LEDI specification bumps from leaking into my domain code?
- Keep sysvale/ras as a leaf dependency behind interfaces you own, such as a DocumentGateway or LayoutSerializer. Your domain and persistence layers should never import the package namespaces, enums, or schema constants directly. That way a future LEDI version bump becomes a change in one adapter class plus fixtures instead of a cross-cutting refactor.
- What are the production risks of adopting sysvale/ras and how do I mitigate them?
- The main risks are change opacity, because a one-line changelog is thin change control for a compliance dependency, and compliance asymmetry, because adopting 8.4.0 early can break counterparties still validating against 8.3 while adopting late risks rejection after the regulator cutover. Mitigate by pinning the version, adding contract tests, and confirming the official deadline. Also assess maintainer activity and a fork or mirror contingency, since single-maintainer packages tracking government specs are common.
Weaver
How can I help you explore Laravel packages today?