Core
Patient, Practitioner, Organization, Encounter, Consent and the resources most apps touch first.
FHIR apps
Your care team works in tables and pages. Your partners, analysts and integrations talk to the same data through standard FHIR R4. No mapping layer to maintain, because the tables are the resources.
GET /metadata
CapabilityStatement · 19 resources from Core
Clinical installed · 45 resources
GET /Patient?family=Okafor
Bundle · searchset · 1 match
POST / transaction
Patient + Observation · 2 created
GET /Observation/obs82/_history
3 versions from the event log
GET /ValueSet/$expand
LOINC vital signs · 9 codes
FHIR packs
Install Core to start. Add Clinical and Financial when the app needs them. The CapabilityStatement updates as packs are installed.
Patient, Practitioner, Organization, Encounter, Consent and the resources most apps touch first.
Conditions, observations, medications, allergies, procedures, care plans and questionnaires.
Coverage, claims and explanation of benefit records for eligibility and billing workflows.
The server
For the people doing the work
Nurses and coordinators never see a JSON resource. They see a patient list, a callback queue, a form. FHIR datatypes like CodeableConcept and HumanName render as fields that make sense.
How interfaces workStandards
Conditions, findings and procedures.
Observations, labs and vital signs.
Medications and prescriptions.
Diagnoses for billing and reporting.
HL7 v2, Consolidated CDA and X12 eligibility and claims are planned and not available today. Formal FHIR conformance testing is also planned.
We will show you how the resources map, what the server returns today and what is on the roadmap.