Oprettelse af recepter gennem FMK sker ved at FMK kalder en webservice på receptserveren. Dvs. i modsætning til oprettelse af recept via EDIFACT sker oprettelsen ”øjeblikkeligt” i samme kald. En recept der ikke kan oprettes vil medføre at kaldet til receptserver og FMK vil rulle tilbage. Derimod til vil FMKs tidligere kald til receptserveren ikke rulle tilbage, dvs. at recepter oprettet i samme kald til FMK med ud fra andre lægemiddelordinationer vil ikke blive rullet tilbage. Dette kan f.eks. optræde, når der FMK kaldes med flere ”opret recept” dokumenter i samme kald.

Oprettelse af recepter valideres af både FMK og receptserver. FMK validerer f.eks. at pakningen findes på lægemidlet på den lægemiddelordination recepten oprettes ud fra (kun for lægemidler i taksten). Receptserveren foretager andre valideringer. Bemærk at receptserveren bl.a. tillader et andet og begrænset tegnsæt end FMK. Nedenstående er hentet fra ”Den Gode XML Recept” afsnit 2 (se MedCom - Den Gode XML Recept):

Indholdet i alle essentielle felter i datagrundlaget skal overføres i uændret form til applikationens database.
Dog må ®, − og typografiske hjælpetegn fjernes og felter concateneres, hvis funktionaliteten ikke forringes. 

Tegnsættet i databasen skal understøtte samtlige tegn i datagrundlaget. I praksis betyder dette, at der skal 
benyttes ISO 8859-1. 

Følgende tegn giver erfaringsmæssigt problemer og må derfor ikke anvendes: 

Tegn 	Code Page 865 (decimalt) 
$ 	36 
@ 	64 
[ 	91 
\ 	92 
] 	93 
{ 	123 
} 	125 
| 	124 
£ 	156 
1⁄2 	171 
1⁄4 	172 
¤ 	175 

Tegn, der normalt ikke findes på tastaturer: 
Semigrafik (CP 865 decimalt 169, 170, 176-223, 244, 245, 251, 254, 255) og styretegn (CP 865 decimalt 1-31) må
heller ikke anvendes. 

Receptordinationer blive hentet fra en lokal replikeret kopi af data fra Receptserveren. Alle læsninger vil ske fra replikaet, hvorimod oprettelse af receptordinationer sker gennem en webservice på receptserveren. Receptordinationer oprettet gennem FMK vil automatisk blive opdateret i replikaet.

I normal drift vil den lokale database maksimalt være 30 minutter efter receptserveren. I fejlsituationer er det dog relevant at vide præcis, hvornår sidste replikering fandt sted. Denne oplysning er indsat i response headeren som eksempelvis:

<PrescriptionReplicationStatusStructure>

<LatestReplicationDateTime>2009-11-16T11:52:00Z</LatestReplicationDateTime>

</PrescriptionReplicationStatusStructure>