Er is één metamodel, maar er zijn meerdere logische modellen. Logische modellen bereiden de implementatie voor van bepaalde onderdelen van het metamodel. Deze versie van het MedMij Afsprakenstelsel kent drie logische modellen. Elk daarvan hoort bij een of enkele specifieke implementatie-component(en) in MedMij Afsprakenstelsel. Het gaat om de volgende componenten:

• de vier door MedMij Registratie gepubliceerde lijsten: Gegevensdienstnamenlijst, OAuthclientlist, Whitelist en Zorgaanbiederslijst;
• de in het MedMij Afsprakenstelsel te publiceren Catalogus van Gegevensdiensten;
• de in het MedMij Afsprakenstelsel te publiceren (Hostname van de) MedMijStelselNode;
• de twee van Deelnemers gevraagde rapportages: Beheerrapport en Portabiliteitsrapport.

De vier lijsten staan gecombineerd in één logisch model, onder de klasse MedMijBeheerlijst, omdat zij basiskenmerken delen. Iets dergelijks geldt voor de twee rapporten, onder de klasse MedMijRapport.

Logische modellen gehoorzamen het metamodel, maar verbijzonderen dat. In de stap van metamodel naar logisch model kunnen er (logische) klassen, invarianten en basisklassen bijkomen. Maar de logische modellen bouwen vooral ook voort op het metamodel door klassen en attributen daarvan te gebruiken. In dat geval hebben logische klassen, waarde en basisklassen dus overeenkomstige klassen in het metamodel. De overeenkomsten staan hieronder bij het logische model genoemd in een tabel. Waar de tabel bij een zekere logisch klasse, waarde of basisklasse de overeenkomst met het metamodel niet noemt, is deze nieuw voor het logische niveau.

Logische klassen hebben minder of meer attributen dan de overeenkomstige klassen in het metamodel. Waar het er minder zijn, hoeven de weggelaten attributen dus niet te worden opgenomen in de te implementeren component, bijvoorbeeld van een te publiceren lijst. Waar het er meer zijn, worden deze attributen overgeërfd van een klasse in het metamodel waarvan de overeenkomstige klasse in dat metamodel bestaansafhankelijk was. In het metamodel was laatstgenoemde klasse dus toegankelijk voor de bestaansafhankelijke klasse, maar in het specifieke logische model niet meer aanwezig en dus ook niet meer toegankelijk. Zou de betreffende klasse in het logische model het attribuut dus niet hebben overgenomen, zou deze verloren zijn.

Waar een invariant uit het metamodel past binnen de scope van het specifieke logische model, verschijnt deze ook als invariant bij het logische model, hoewel de formulering zal zijn aangepast aan de ordening en naamgeving in het logische model. Daarenboven kunnen op logisch niveau ook nieuwe invarianten verschijnen. De meeste daarvan zijn verervingen: in de stap van het metamodel naar een logisch model raken verbanden verbroken tussen klassen. Als die verbanden toch van belang zijn in het logische model worden er attributen uit het metamodel verorven van een bepaalde klasse in het metamodel naar een lagere klasse, waarvan wel een pendant voorkomt in het logische model. Met "lagere klasse" wordt bedoeld dat deze bestaansafhankelijk is van de andere (hogere) klasse. Zo'n verervingsinvariant staat opgeschreven met een ←. Vóór dat pijltje staat het ervende attribuut van de logische klasse, erachter staat het pad in het metamodel  naar de verervende klasse.

Ook de basisklassen uit het metamodel worden, waar van toepassing, overgenomen door het logische model. Op een enkele plek verschijnen in het logische model ook nieuwe basisklassen.

De logische modellen hebben een meer op implementatie toegespitste structuur dan het metamodel. Dat metamodel is gestoeld op associatieklassen en bestaansafhankelijkheid, de logische modellen zijn meer hiërarchisch. Hiërarchie is een insnoering van associatieve bestaansafhankelijkheid, maar past beter bij menige gangbare implementatietechnologie, waaronder zeker XML, waarin de vier lijsten geïmplementeerd worden. Die insnoering betekent wel dat de logische modellen minder duurzaam en minder uitbreidbaar zijn dan het metamodel; wat voor het metamodel een eenvoudige uitbreiding is kan voor de logische modellen een stevige ingreep zijn. Dat is de prijs van hiërarchie.

Bij de vertaling van de associativiteit van het metamodel naar de hiërarchie van de logische modellen is een aantal vuistregels gebruikt.

• De top van de hiërarchie van een logisch model wordt bepaald door de scope van de implementatiecomponent. De Zorgaanbiederslijst, bijvoorbeeld, somt allereerst de Zorgaanbieders op. Vanuit dat "logische centrum" wordt de hiërarchie van boven naar beneden afgelopen, zonder de scope van de implementatiecomponent te overschrijden. De stap naar beneden in de hiërarchie krijgt in het logische model typisch de vorm van een uses-relatie (de gestippelde pijl).
• Onderweg wordt een compositiehiërarchie aangelegd en in elke stap een selectie gemaakt uit de in het metamodel beschikbare attributen, op basis van de scope van de implementatiecomponent. Daarbij worden logische klassen niet gecombineerd tot een grofmaziger klasse, zelfs niet als er geen enkel attribuut overblijft. De klasse-granulariteit van het logische model is dus vergelijkbaar met die van het metamodel.
• Bovendien worden, zoals hierboven beschreven, attributen die in het metamodel buiten de scope dreigen te vallen, maar wel nodig zijn, vererfd naar binnen de scope. Waar dat gebeurt, wordt de vererving gepreciseerd in de lijst van logische invarianten.
• Lagere klassen in de uses-hiërarchie vallen geheel binnen de logische scope van de hogere. Een hiërarchie creëert zo ook gesloten "name spaces". Dat betekent dat hun naamgeving eenvoudiger en korter kan dan in het metamodel , waar alle contexten juist open zijn. In de logische modellen krijgen de namen van de klassen dus pas betekenis wanneer hogere klassen mee worden beschouwd. Maar dat vereenvoudigt de implementatie. In een aparte tabel bij elk logisch model wordt voorkomen dat door deze naamwijzigingen het verband met het metamodel verloren zou gaan.
• Een enkele keer heeft het vorige punt de consequentie dat er een homoniem dreigt te ontstaan binnen één logisch model (zoals  Gegevensdienst en Gegevensdiensten in de logische model van de lijsten en de rapporten). In dat geval worden de namen uitgebreid zodat hun hiërarchische context zichtbaar wordt (namelijk met _GNL, _OCL, _ZAL, _BR en _PR).

Merk op dat de uses-hiërarchie de bestaansafhankelijkheidsrelatie ondersteboven zet. In de corresponderende klassen in het metamodel wordt in de uses-relatie de gebruikte klasse boven de gebruikende geplaatst, in de logische modellen juist andersom. Dit kenmerkt het doorslaggevende verschil tussen de conceptuele denkwijze van het metamodel en de bouw-gerichte denkwijze van de logische modellen. Voor de consistentie en duurzaamheid van het MedMij Afsprakenstelsel is het zaak om in het modelbeheer het metamodel centraal te plaatsen en vervolgens de logische modellen ermee in overeenstemming te houden. Het metamodel zorgt zo ook voor de duurzame consistentie tussen de verschillende logische modellen. Van die consistentie zijn de betrouwbaarheid en interoperabiliteit afhankelijk die door het MedMij Afsprakenstelsel geleverd moet worden.

De klasse Interfaceversie_ZAL in het logisch model heeft een corresponderende conceptuele klasse "ZorgaanbiederInterfaceversie" die nog niet is opgenomen in het metamodel. Deze klasse is een associatie van de klassen "Zorgaanbieder" en "Interfaceversie".