DocumentationSupportCosta Rica · Contact
ESENPT
Let’s talk
Infrastructure

Cloud Repositories

Clinical projects rarely stall for lack of ideas. They stall waiting for somewhere to put the data. We hand over the repository already running — FHIR, medical imaging or signed documents — with authentication, authorization, auditing and conformance already solved.

Request a proposal→See what it includes
The starting point

Standing up the repository is not the project. It is the toll you pay to start it.

No health organization wants to be in the business of running servers. It wants to publish lab results, share a study with another centre, keep a consent form that will hold up as evidence. But first someone has to solve a FHIR server, an authorization server, validation against the national profile, encryption, data residency, backups, audit trails and someone who answers at three in the morning. That toll is paid in months and with a team most institutions neither have nor want to hire. We already paid it: you get the repository running.

What we deploy

Three repositories, one platform underneath

You choose what you need to hold. What holds it up — identity, authorization, audit, encryption, backup and operations — is not quoted separately: it is the same foundation for all three, and it is included.

R4 / R5

FHIR repository

Structured clinical data

When you need it

When you need to store and expose clinical information — people, results, immunizations, conditions, medication — in a form another system understands without a bespoke integrator for every connection.

  • RESTful FHIR API

    Search, read, write, transactions and standard operations over R4 or R5, with paging and concurrency control.

  • Profiling and validation

    Every resource is validated against the national or institutional guide at write time, not in an audit months later.

  • Terminology solved

    SNOMED CT, LOINC and national ValueSets available to validate, expand and translate codes without standing up a separate server.

  • Bulk extraction

    Bulk Data and export operations for analytics, reporting and dashboards, without hitting the API that serves clinical operations.

  • Versioning and history

    Every change keeps the previous version: you can reconstruct what the data said on a given date.

PACS / VNA

Imaging repository

Imaging studies and reports

When you need it

When studies are locked inside the vendor's PACS, getting them out costs money every time, and sharing a case with another centre still means burning a disc.

  • DICOM archive and VNA

    Vendor-neutral storage: studies stop depending on the equipment or the supplier that produced them.

  • DICOMweb

    WADO-RS, QIDO-RS and STOW-RS so viewers and clinical systems consume studies over the web, with nothing installed on the workstation.

  • Embedded viewer

    Diagnostic and reference viewing inside the record, with access governed by the same authorization server.

  • Ingestion and routing

    Reception from modalities and existing PACS, with routing rules, study reconciliation and de-identification for teaching and research.

  • Structured report

    The study report is also published as a FHIR resource, so the record can read it without opening the viewer.

Digitally signed

Document repository

Documents that hold up as evidence

When you need it

When a consent form, a discharge summary or a medical certificate has to be attributable to whoever issued it and provably unaltered — and today it is a loose PDF in a shared folder.

  • Signing and sealing

    Digital signatures in long-term formats plus time stamping, so the document remains verifiable years after it was issued.

  • Verification on intake

    Every incoming document is checked: valid signature, current certificate and a complete chain of trust, before it is filed.

  • Registry and retrieval

    A registry and repository with queryable metadata, so you find the right document without opening all of them.

  • Retention and preservation

    Retention policies by document type and preservation of signature validity over time.

  • Standards-based publishing

    Exposure through document exchange profiles, so another provider can retrieve the document without building its own integration.

Shared foundation — always included

The part that is routinely underestimated in the quote and turns out to be half the project.

Identity and authorization

A dedicated authorization server with SMART on FHIR and IHE IUA, client application registration, and permissions by role and use case.

Audit and traceability

Every access recorded with who, what, when and from where, in a queryable form and with the retention your regulation demands.

Encryption and residency

Encryption in transit and at rest, with the location of the data defined and stated in writing from day one.

Backup and recovery

Backups with restores tested on a schedule. A backup nobody has ever tried to restore is not yet a backup.

Monitoring and support

Observability, alerting and a support channel with committed response times. When something breaks, clinical staff are not the ones who find out.

Exit without hostage-taking

Your data is yours and leaves complete, in standard formats, the day you ask for it. No ransom, no bespoke conversions.

What you do not have to buy separately
  • Authorization server
  • Certificates and their rotation
  • Audit and retention
  • Backup with tested restores
  • Monitoring and alerting
  • Test environment
  • Version upgrades
  • Support with committed response
Access

The repository is not the risk. Who can read what is.

A clinical repository without an access architecture is an incident with a pending date. We deploy the full authentication and authorization circuit, not a list of usernames and passwords.

  1. 01

    The application identifies itself

    Every system that queries the repository is registered as a client, with its own credential and its own scope. There is no shared account half the team knows.

    • OAuth 2.0
    • Client registration
  2. 02

    The person authenticates

    The professional signs in with the identity the organization already uses — including the national digital signature where applicable — and not with an account created just for this system.

    • OpenID Connect
    • IHE IUA
  3. 03

    A narrow permission is issued

    The token says exactly what can be done and over what: this person, these resources, read only, for this long. A broad permission is a breach waiting for a date.

    • SMART scopes
    • patient/ · user/ · system/
  4. 04

    The repository decides and trims

    The repository does not trust the client to behave: it checks the permission on every call, applies consent and returns only what the permission reaches.

    • Per-resource authorization
    • Consent
  5. 05

    The trail remains

    Every access — granted and denied — is recorded in queryable form. When someone asks who saw that record, there is an answer instead of an investigation.

    • ATNA
    • AuditEvent

SMART on FHIR and IHE IUA are not a technical indulgence. They are the reason a third-party clinical app can connect to your repository without you opening the database to it, and the reason your repository can accept another institution's identity without creating accounts for its staff. A homegrown scheme works fine right up to the day you have to integrate with somebody else.

Conformance

Storing the data is not enough: it has to meet the profile

A repository that accepts anything passes the problem on to whoever consumes it. We validate against the implementation guide at write time, while fixing it is still cheap.

When a national guide exists

The situation

Costa Rica has published its HL7© FHIR© R5 implementation guides: Core, terminology, lab results and medical imaging reports. Whatever gets published has to meet them.

How we solve it

The repository is configured against those profiles: every incoming resource is validated, and whatever fails is rejected or quarantined with an explicit reason instead of contaminating the repository. Meddyg took part in designing, profiling and publishing those guides.

When there is none yet

The situation

In many domains — and many countries — there is still no published national profile, and waiting for one is not an option for a project that already has a date.

How we solve it

We define a minimal institutional profile on top of the base standard, taking from international reference models what we know the national guide will end up asking for. From day one the data is stored in a shape that migrates to the national guide without rewriting what is already loaded.

What validation actually checks

Structure and cardinality

That the resource carries the elements the profile requires and none of the ones it forbids.

Terminology

That codes belong to the ValueSet the profile binds to, and not to a similar-looking internal list nobody else understands.

References

That whatever the resource points to exists and is of the right type, so the record does not fill up with broken links.

Profile rules

The invariants the guide declares, which no structural check catches on its own.

Evidence you can hand over

A conformance report you can present to whoever asks, detailing what was validated and with what result.

Operations

What “turnkey” actually means here

Easy to say and hard to honour. These are the concrete commitments that go in writing, and the way each one gets verified.

Availability

The commitment

A service level agreed in writing, with announced maintenance windows and response times differentiated by severity.

How it is verified

A periodic availability and incident report detailing every event, its cause and what changed so it does not recur.

Backup and recovery

The commitment

Defined frequency and retention, and recovery objectives agreed before signing rather than discovered during the incident.

How it is verified

Restore tests run and documented on a real environment, not on a written procedure.

Encryption and residency

The commitment

Encryption in transit and at rest, and the physical location of the data defined and stated from the start of the contract.

How it is verified

An architecture and configuration document your security or data protection officer can review.

Versions and upgrades

The commitment

Upgrades to the engine, the profile packages and the terminologies, including R4 and R5 coexistence while the ecosystem makes up its mind.

How it is verified

A test environment on the new version before production is touched, and a written rollback plan for every major change.

Observability

The commitment

Monitoring of the repository and its integrations, with alerts that reach our team before the problem reaches a consulting room.

How it is verified

Usage, latency and error dashboards accessible to your team, not only to ours.

Exit without hostage-taking

The commitment

Your data is yours. The day you decide to take it elsewhere, it leaves complete and in standard formats — images in DICOM, resources in FHIR.

How it is verified

An exit plan written into the contract: what gets exported, in what format and how long it takes to deliver.

Method

From the decision to a repository in production

Six stages. The second one prevents most incidents, and it is the one almost always skipped when a repository is bought off a catalogue.

  1. 01

    Scope and sizing

    We define what the repository will hold, who queries it, at what volume and how fast it grows. This produces a real size and a credible cost of operation, not a catalogue quote.

    What you keep
    • Use cases and volumes
    • Data and documents to host
    • Sizing and cost of operation
  2. 02

    Access design

    We define who the clients are, what each may ask for, how the person authenticates and what role consent plays. This is the cheapest possible stage to discover that someone could have read too much.

    What you keep
    • Client and permission matrix
    • SMART on FHIR / IUA design
    • Audit and retention policy
  3. 03

    Deployment and hardening

    We stand up the environments, apply hardening, encryption and the agreed residency, and get backups tested before the first real record arrives.

    What you keep
    • Test and production environments
    • Documented security configuration
    • Backup with verified restore
  4. 04

    Loading and conformance

    We load existing data or studies validating against the profile, and separate what fails from the start instead of letting it in and finding out when someone queries it.

    What you keep
    • Initial migration or ingestion
    • Conformance report
    • Agreed handling of exceptions
  5. 05

    Integration

    We connect the repository to your clinical systems, to the viewers, to the modalities and to whatever ecosystem it has to answer.

    What you keep
    • Integrations in operation
    • End-to-end testing
    • Technical interface documentation
  6. 06

    Operation and handover

    We run the repository under the agreed commitments and leave your team able to understand what happens inside it, even though they do not have to operate it.

    What you keep
    • Operations runbook
    • Dashboards and alerting
    • Internal team training
Deliverables

What the organization ends up holding

Not a server and a password: the repository running, plus everything needed to audit it, explain it and — if one day you want to — take it with you.

The repository running

Test and production environments deployed, hardened and monitored, with access handed over to your organization.

Documented access architecture

Registered clients, scopes by role and use case, and the procedure to onboard or revoke a consumer without depending on us.

Conformance report

Which profiles the repository validates, with what result over the loaded data, and which exceptions remain open and why.

Operations runbook

Backup, restore, escalation and the procedures for the failures we already know will happen at some point.

Queryable audit trail

The access log with its defined retention and a concrete way to answer who saw what, without opening a ticket with the vendor.

Exit plan

What gets exported, in what standard format and how long it takes. Written up front, not negotiated the day you want to migrate.

Experience

Repositories already in operation

The three repository types on this page map to work Meddyg has already delivered, not to a catalogue line.

RepositoryFHIR in production

First national FHIR server for EDUS/CCSS

Meddyg implemented and deployed to production the first FHIR server to receive notifiable disease, immunization and lab result reports from EDUS, Costa Rica's national digital health record run by the Caja Costarricense de Seguro Social, and later from other health providers.

RepositoryMedical imaging

PACS architectures in public hospitals of the Dominican Republic

Meddyg implemented PACS and diagnostic workstation architectures for DICOM-based medical imaging exchange in public hospitals of the Servicio Nacional de Salud (SNS).

RepositorySigned documents

Digitally signing FHIR resources with the Central Bank of Costa Rica

The BCCR invited Meddyg to help integrate the JAdES format into GAUDI, its digital signature and sealing platform. Meddyg provided the technical assistance for the BCCR's teams to enable signing of FHIR resources.

RepositoryConformance

The guides we validate against, we helped write

Meddyg took part in designing, profiling and publishing Costa Rica's HL7© FHIR© R5 implementation guides: Core, terminology, lab results and medical imaging reports. Repository validation is not configured from outside the standard.

The cases above correspond to documented Meddyg work. DICOM, HL7© FHIR©, IHE and SMART on FHIR are standards and reference models we apply — not clients, and not certifications.

Who it is for

Who ends up needing a managed repository

Almost never an IT department shopping for servers — usually a clinical project that needs to move.

Private hospitals and clinics

That need a standards-based clinical foundation without building — and then sustaining — an infrastructure team to run it.

Imaging centres and laboratories

That want to stop depending on the vendor's PACS and deliver their results where the clinician already works.

Public health institutions

That have to meet the national guide and prove traceability for every access to a person's information.

Clinical software companies

That need a conformant FHIR backend for their product without diverting their team into building and operating one.

Insurers and health plan administrators

That receive clinical information from third parties and must hold it with access control, retention and evidentiary value.

National and regional programmes

That need a dependable reception point for notifications, registries or reports coming from many providers at once.

Self-assessment

Signs that you need one

You have a clinical project stalled waiting for somewhere to store the data.
You need a FHIR server in production and nobody on your team has run one before.
Getting studies out of your current PACS costs money every time you try.
You have been told to meet the national guide and have no way to validate what you publish.
You cannot answer today who looked at a person's record last month.
You keep documents that ought to hold up as evidence and today they are unsigned files.

If two or more sound familiar, the problem is not an infrastructure budget: it is time. A managed repository goes live in weeks, not in the next budget cycle.

How long has your project been waiting for infrastructure?

Tell us what you need to hold and who has to query it. We will tell you which repository fits, what it includes, how long it takes to go live and what it costs to keep running.

Request a proposal→Talk to a specialist
Continuity

Before and after the repository

The repository settles where the data lives. Around it there are decisions worth making first and work that continues afterwards.

Interoperability assessmentWhen it is still unclear which systems produce the information the repository will receive.Architecture definitionWhen the repository is one piece of a larger architecture that is not defined yet.Implementation GuidesWhen the profile the repository has to validate against is not written or published yet.Data modelingWhen what is about to be loaded means different things depending on the system it comes from.FHIR layerWhen the systems feeding the repository do not speak FHIR and are not going to be replaced.HIE IntegrationWhen the repository also has to answer a national exchange ecosystem.
See all services→