Skip to main content

Interoperability Architecture, With Clear Activation Boundaries

Standards-based architecture supports scoped connections to labs, pharmacies, clearinghouses, registries, and health information exchanges. Each external connection requires the relevant partner approval, credentials, onboarding, and production validation.

Review Connection Boundaries

Standalone Patient Portal

An EMR name is not a capability promise

Each clinic receives a versioned capability manifest for the exact connection being validated. The portal renders only supported reads, requests, and writes. It shows source, freshness, expected delay, and delivery state instead of implying that every FHIR or vendor connection supports the same workflow.

Example patient portal connector capabilities and activation boundaries
DomainInitial contractBoundary
RecordsPatient, results, medications, conditions, allergies, documentsRead only until each write is separately validated
SchedulingAppointments plus request, cancel, or reschedule where supportedVendor and clinic workflow specific
Messages and refillsSubmission with destination acknowledgementNo silent delivery or urgency inference
BillingStatements, balances, validated payment path, receiptsDepends on the system of record and processor

Built on Healthcare Standards

Krasyn speaks the language of healthcare IT. Native support for the standards that power modern interoperability.

FHIR R4

FHIR R4 data models and server architecture for patient, encounter, observation, and medication resources. External production exchange is scoped and validated per connection.

HL7 v2

HL7 v2.x interface architecture for lab orders, results, ADT feeds, and other traditional healthcare exchanges after partner onboarding and validation.

CCD / C-CDA

Structured CCD and C-CDA document support for patient summaries and transitions of care; exchange with an outside organization requires a validated delivery path.

EDI Transactions

ANSI X12 EDI workflows are built around clearinghouse connectivity. Production Availity activation is pending application approval.

USCDI

USCDI v3 data classes are mapped in the data model for patient access and exchange. Conformance is verified per deployment; independent ONC certification is not claimed.

Direct Messaging

Direct Secure Messaging is a partner-scoped activation path, not a universally live connection today. Address provisioning and production exchange must be validated during onboarding.

Connection Paths, Scoped Before Go-Live

Core charting works without these external connections. Each path below identifies what the product models today and what still requires partner activation and validation.

Laboratory

Lab interface architecture for electronic order entry and result delivery after partner onboarding. Real order routing and discrete result return depend on the selected lab vendor, credentials, and production validation.

National and regional reference labs via scoped HL7 and FHIR onboarding, or an interim lab-portal workflow at launch. Specific lab partners are confirmed per practice during onboarding.

E-Prescribing

Electronic prescribing launch scope is limited to legend (non-controlled) medications with drug interaction checking, allergy alerts, and validation before transmission. EPCS and controlled-substance prescribing are post-launch.

DoseSpot for non-controlled ePrescribing after production activation. EPCS is not available at launch.

Imaging & Radiology

Radiology order entry and structured results workflows are supported in the product model. Electronic routing, DICOM retrieval, and imaging result return are partner-scoped activation items.

Radiology information systems, PACS vendors, and imaging centers after partner validation.

Clearinghouses

EDI-based claim submission (837P), eligibility verification (270/271), claim status inquiry (276/277), and electronic remittance advice (835) are supported through clearinghouse connectivity after production activation.

Availity production activation is pending application approval and credentials.

Immunization Registries

Krasyn records immunizations with structured history and documentation. Automated state IIS query or submission is not available today and requires state-specific onboarding and production validation.

No live IIS connection is claimed today. Future state-registry connections require jurisdiction-specific approval and validation.

Health Information Exchanges

Krasyn has standards-based architecture for scoped HIE projects. No live Carequality, CommonWell, or universal regional-HIE connection is claimed today.

Regional HIE onboarding is scoped per customer; Carequality and CommonWell enrollment remain roadmap items.

Developer-Friendly Architecture

Krasyn is built for extensibility. Our FHIR server and upcoming REST API make it straightforward to build on top of the platform.

FHIR R4 Server

Built-in FHIR R4 server exposes patient, encounter, observation, medication, and other clinical resources via standard RESTful endpoints.

Available

REST API

A comprehensive REST API for practice management, scheduling, and clinical data access is in development. Developer sandbox and documentation will be available at launch.

Coming Soon

Compliance & Certification

Krasyn is designed around healthcare regulatory requirements, with formal certifications and production integrations claimed only after the relevant evidence is complete.

HIPAA

Designed to support HIPAA-compliant workflows with encryption, audit logging, access controls, and BAAs where required.

SOC 2

SOC 2 readiness is on the roadmap; formal attestation is not claimed at launch.

ONC Health IT

ONC certification is not claimed. Certification language requires a completed ONC-ACB process.

21st Century Cures Act

Patient-access and export architecture is designed with Cures Act obligations in mind; independent compliance certification is not claimed.

Ready to Connect Your Practice?

See how Krasyn connects to your lab, pharmacy, and billing systems as each integration is activated.