Where do we get MIF files?

[EvanMachusak]

I'm trying to use gmpr to create a library to handle documents with this extension oid:

<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:hl7-org:v3"
xmlns:cda="urn:hl7-org:v3"
xmlns:sdtc="urn:hl7-org:sdtc">
	<realmCode code="US"/>
	<typeId root="**2.16.840.1.113883.1.3**" extension="**POCD_HD000040**"/>

I can barely find any information on this anymore, much less a usable MIF file.

If they're out there, I'm struggling to find them. The closest thing to a MIF I have managed to find is this:

http://www.hl7.org/documentcenter/public/standards/V3/RIM/C30247/rim0247c.zip

I tried running the *.coremif files in that archive to see if I could get anywhere, and they fail to generate anything useful - something about not supporting RIM 2.1.7.

Any assistance would be appreciated.

[justin-fyfe]

You don't need to process MIF file to process CDA documents, you can add a reference to the CDA library and parse the structures (a pre-compiled version of MARC.Everest.RMIM.UV.CDAr2.dll should work for this structure).

If you really want to create your own C# or Java source files using GPMR you can grab the CDA MIFs from the HL7v3 distribution (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186) or the CDA distribution (http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7), you will need both coremif files (defining the structure of the RIM) and mif files (the POCD_HD00000040.MIF file) to generate the files.

I believe the pre-compiled assemblies were generated from the Normative Edition 2008 standard, however this was generated quite a while ago so I can't be sure.

[EvanMachusak]

Hey Justin - thank you for the response.

I want to rebuild the source code which generated MARC.Everest.RMIM.UV.CDAr2.dll because we're trying to integrate Everest in an all-.NET Standard ecosystem, and since the pre-builts are on the full framework (and 3.5, right?), we can't import it without locking ourselves into the .NET framework and it would prevent .NET core apps from playing nicely.

I tried going so far as to disassemble MARC.Everest.RMIM.UV.CDAr2.dll, but in so doing, the tools I have don't preserve the value of the [Structure] attributes, which look to me to be the cornerstone of the Everest system. When I manually add a name and namespace to the (disassembled) ClinicalDocument class, the reader is able to create those, but all of the child classes have empty [Structure] attributes and the deserializer chokes on them.

I didn't think it was a good approach to manually add names and namespaces to every [Structure] attribute in the disassembled codebase.

Am I totally off the rails, or am I on the right track? You might tell I'm new to CDA & CCD. I know FHIR pretty well, but we're trying to work with all the extant formats.

[justin-fyfe]

Perhaps we can follow-up via e-mail? You can reach me via LinkedIn or the email on my profile