Return

Step-by-Step Guide

This step-by-step guide aims to present the basic content and the composition of an IG. Furthermore the guide aims to explain the structure of the MedCom FHIR profiles. The guide is based on the MedCom Core Implementation Guide (IG).

Step 1

Go to MedCom Core IG.

• On the front page of the MedCom Core IG, you will find a short introduction to the content of the IG and a menu bar at top of the page (see Figure 1 ):

On the menu bar, you will find the following tabs:

• Table of Contents shows the content list of the IG
• Home shows the front page of the IG
• Profiles shows which profiles are included in the IG
• Extensions shows the extensions made for the IG.
• Artifacts shows the entire content of the IG.
• Download shows the possible download format of the IG.
  
  

Step 2

Click on the tab Profiles (see the red circle in Figure 2 ) to get an overview of which profiles are in the IG.

Step 3

Choose MedComCorePatient(see the red circle in Figure 3), and you will get to the front page of MedComCorePatient, (see Figure 4 ). This page introduces the MedComCorePatient profile. It includes a short description of the profile, its usage and the required content.

On top of the MedComCorePatients front page, you will find a menu bar with the following tabs:

• Content: Gives a short introduction to the profile and a table showing the profile content
• Detailed Description : Gives a detailed description of all elements in the profile
• Mapping: Gives an overview of how terms in the standard can be mapped to other HL7 standards, but not previuos MedCom standards. To get this information, you can look under each standard.
• Examples: Gives an overview of the examples for the given profile as in this case for the MedComCorePatient profile
  • If you select one of the examples you will be presented with the content of the narrative text. If you select the tabs XML, JSON or TTL instead, you will see the entire content of the MedComCorePatient.
• XML: Shows the entire content of the MedComCorePatient profile in XML format
• JSON: Shows the entire content of the MedComCorePatient profile in JSON format
• TTL Shows the entire content of the MedComCorePatient profile in TTL format
  
  
  

Step 4

If you scroll down the MedComCorePatients front page, you will find a menu bar with five tabs where three of them represent tables that explain ‘The content of the profile’ and which changes are made from the parent profile or resource, which, is in this case DkCorePatient (see Figure 5). .

• The three tables are:
  • Differential Table: Shows what is changed from the resource the profile is based on.
  • Snapshot Table: Shows all the content of a profile. Not all should be included in a MedCom standard.
  • Snapshot Table(Must Support): Shows the required content of a profile.

Step 5

Click on the tab ‘Snapshot Table (MustSupport)’(see Figure 6). It is important to notice that the sender and receiver system must be able to handle the content shown when choosing the tab “Snapshot Table (MustSupport)”.

The table contains five headlines (see Figure 6):

• Name:
  • The element name.
• Flags:
  • I = a rule.It can be seen further down the page.
  • ∑ = summary. It describes if it is possible to search for the content of the element.
  • ?! = modifier element. An element which potentially can modify the understanding of an entire message.And example could be if the patient is deceased as it changes the understanding of the content.
• Cardinality (Card):
  • Cardinality describes how many times an element may or must appear. Given the minimum cardinality of 1 for Patient.identifier and Patient.name, the information for these elements must always be included when exchanging a MedCom standard. Not only must a Patient.name be included, but it must also always be the patient’s official name, indicated by Patient.name:Official. Information about Patient.telecom, Patient.deceased, Patient.address and Patient.managingOrganization must be included if the information is available in the sender system, given the minimum cardinality of 0.
  • Given the maximum cardinality of * for Patient.identifier, Patient.name, Patient.telecom and Patient.address it is allowed to slice the element. For the element Patient.deceased, it is only allowed to include the information once.
• Type:
  • Describes the data type of the element. For more information about the data type click here.
  • One might notice the type at the top of the elements saying DKCorePatient, which means that the MedComCorePatient profile inherits from a Patient profile developed by the Danish HL7 affiliate. You can read more about inheritance and the work for HL7 Denmark here.
• Description and Constraints:
  • A short description of the element as well as rules associated with the element.
    
    

Step 6

Now you can, choose another profile; namely the MedComCoreEncounter

• Here you will see the type Reference(…) at the element Encounter.subject. This means that the element references the MedComCorePatient profile and that an encounter must always be associated with a patient.
• For the elements Encounter.status and Encounter.class, the type is code or coding, meaning that a predefined structured code must be selected from a ValueSet. which can be seen in the column ‘Description & Constraints’.