Best-practices


Introduction


In this module we will provide you with a couple of modeling guidelines / best-practices that have been evolved at Firely for FHIR profiling. Feel free to adopt them in your project!

The topics covered in this module are:

  • General guidelines
  • Open versus closed modeling
  • Extensions
  • ValueSets
  • Mappings
  • Name element

Reading material


1. General guidelines

1.1 Reuse

Before you start profiling, always start by checking what's already out there. You may use one of the following sources to do so.

Besides saving yourself the effort of reinventing the wheel, alignment with existing work will make interoperability easier in the future. For the same reason, it is important to conform to national or regional profiles as much as possible. Another advantage of knowing what's out there is that you may find others to collaborate with, for example by browsing Simplifier projects.

1.2 Publishing your work

To enhance opportunities for collaboration and reuse of existing work, it is good practice to share your own solutions as well by publishing them on Simplifier, so others in the community can find them. You can sign up for a Simplifier account for free. The Simplifier documentation page contains information on how to create your first project, add project members and upload your work. In a paid account you may use custom workflows and issue tracking to manage the feedback loop of your project. For optimal collaboration, we advise you to create a Git repository and use our Github integration for automatic synchronization. Finally, it is important to create an implementation guide that developers can use to implement your use case. The implementation guide should contain at least the following information: data definitions, use case descriptions, actors, interactions and examples. You may use our IG-editor in Simplifier or any other tooling that suits you (e.g. a WiKi page or a simple PDF file).

1.3 Naming conventions

Before you start building profiles, agree on the naming conventions that you will use in your project, as it will be a lot harder to change them later on. Some general rules to follow:

  • UpperCamelCase for resources
  • lowerCamelCase for elements and slices
  • lowercase for extensions, using the following format: [context]-[name], e.g. patient-age
  • Consider including the resource type in the name of your profile
  • Use the name of your project, region or country as a prefix or postfix (postfix is generally preferred over a prefix as it makes it easier to search on resource type when browsing resources). The practice in FHIR is to use a country postfix for national projects and the project postfix otherwise.

1.4 Saving a profile

When saving a profile, extend the filename with the resource type, for example: myPatient.structuredefinition-profile.xml or workedOnMonday.structuredefinition-extension.xml.

This'll help you tell the StructureDefinition files apart, which are otherwise all just the same StructureDefinition FHIR resource.

1.5 Narrative

Always fill the narrative with a short description of what this (a profile or an extension), what FHIR resource is it profiling or extending, and a one-sentence description of what it does. For example, An extension <description> or A profile on <resource> <description>

Imagine that a system should just be able to render the narrative of your resource to the user and they should have a pretty good understanding of what it's about.

Set the narrative status to blank, since it is neither generated nor additional content, but a summary.

1.6 Definition

Copy paste the description (Properties tab) into the definition so the same short summary shows up at the start of the resource when in the Details view. For an example, see how they did this in the KULE HelseVest Prescription project.

2. Open versus closed modeling

Depending on the scope of the project, you'll want to consider an open or a closed modeling approach.

An open model is more generic, having few constraints, while a closed model is more specific, having more constraints.

National and regional projects would benefit from an open modeling approach to retain the biggest amount of flexibility for downstream projects. Downstream projects, on the other hand, might want to go with a closed modeling approach to set a contract on what kind of data can be received in order to have an easier time building the systems (database design and so on).

2.1 Differences between open and closed modeling

Example 1 – Open model  

Observe how most of the cardinalities are left at their default (grey) in this open model, with the explicitly constrained cardinalities in black.  

Example 2 – Closed model  

Most cardinalities in this closed model have been constrained and unnecessary elements have been explicitly dissallowed.

The advantages and disadvantages between open and closed modeling are summarized in the table below.  

Open modeling Closed modeling
Pros Forward compatibility No need to support all elements
Focus on what must be supported More specific models
More generic data fit Smaller, straightforward models
More implementer feedback
Cons Implementers might need to support all of the elements More versions of models
Larger, vaguer models Only backwards compatibility
Less implementer feedback New elements require new version

2.2 Guidelines for selecting a modeling approach

Our vision at Firely is to try to use an open modeling approach as much as possible - this way your models will be more generic and reusable. Elements that are not used can be freely ignored, while the mandatory ones will be present. In the end, however, the choice completely depends on your use case.

2.2.1 Constraining maximum cardinality

For the reasons mentioned above, we try to avoid constraining maximum cardinality to 0. Depending on the use case you can even take this one step further by not constraining maximum cardinality at all. Instead, you could choose to slice the element and constrain the cardinality of the slice. This makes it easier for client systems to send their data to you (and others) without having to create custom interfaces to strip out unrelated data, yet you can still find the data you need. However, be careful with specifying everything in slices and leaving the rest open. When everything falls in the open slice it will still be valid and it will make no sense to validate against your profile.

In the end it all depends on your use case. You may want to specify exact expectations for smaller use cases that have already been derived from national, regional or domain profiles. If you know you only need one occurrence for your use case, and the parties participating in that use case have no intention to support FHIR beyond that use case, it is defendable to make that explicit and limit the cardinality.

2.2.2 Constraining minimum cardinality

Another consideration is to use the MustSupport flag to mark elements that are relevant to your profile, instead of setting the minimum cardinality to 1. Of course this will depend on the meaning of MustSupport in your profile (which should be clarified in your implementation guide).

3. Extensions

3.1 Reuse

Whenever considering building a new extension, check if one already exists at:

If you find an appropriate one, use it! If you find one that similar but not quite what you need, contact the author to see if you can collaborate on extending it to a wider usecase.

3.2 Description

Always fill in the description in both the extension and in the profile when you make use of the extension.

This is so a viewer looking at the profile doesn't have to dig up the corresponding extension just to see the description.

3.3 Purpose

Always fill in the purpose field to describe why you created the extension. Not per se necessary for the profile.

As the FHIR landscape is evolving, new extensions might come up or the core specification could be updated to cover your usecase. Without having listed the original requirements or purpose, you could be confused looking at the extension five years down the road and wondering why is it seemingly duplicating functionality - when in reality such functionality didn't exist back when you created the resource.

3.4 MustSupport

Only apply mustSupport in the profile and not when defining the extension itself, since you don't know if the extension "must be supported" in every use case it's going to be used in.

More information on when to use mustSupport and isModifier can be found here: https://fhirblog.com/2014/02/18/ismodifier-and-mustsupport-in-fhir/

3.5 isModifier

The isModifier flag must be provided in the extension itself, because once you create it, you know that it's going to effect the meaning of the resource you apply it in.

4. ValueSets

4.1 Extension valueset binding

When binding valuesets to an extension, create a preferred binding, to give the potential user of the extension more context as to what that field should be. You can then choose to up the binding level (to extensible or required) at the profile level if you wish. The extension is more reusable this way as opposed to picking extensible or required straight on the extension.

Place the valueset binding on the value[x] element, not the root extension element itself.

When selecting the type of reference, use this rule: * If the binding refers to an explicit value set - the normal case - then use a Reference(ValueSet), preferably containing the canonical URL for the value set. * If the reference is to an implicit value set - usually, an IETF RFC that defines a grammar, such as mime types - then use a uri.

4.2 Extending required valuesets

If a valueset is required in FHIR and you need to add codes to it, make a new extension and valueset.

5. Mappings

When filling out mappings from your profile/extension to other models, use the comments field to describe imperfect mapping to prevent confusion decision flip-flopping later on.

Always try to fill in the mapping to the logical mapping.

Don’t use name field.

Use the 'Alias' field to provide translations of the element/concepts name.

Use mapping in the profile, not needed in the extensions.

6. Name element

Tip: use this element for naming your slices and setting name references. In case of name references, you can use those to create re-usable structures with the resource.


Real-life examples


Here below are examples of customers that we helped building profiles.

Nictiz

Nictiz is the centre of expertise for standardization and eHealth in The Netherlands. HL7 Netherlands core and MedMij profiles are published on Simplifier. MedMij is a national project that aims to give Dutch citizens integrated access to all their health data in one personal health environment. FHIR is used as a standard to exchange health information between the involved parties. The profiles are based on standardized clinical building blocks called Health and Care Information Models (HCIM).

Naming conventions

In general, the project uses the following naming convention for naming resources:

http://[domain]/fhir/[ConformanceResource]/[project]-[name]-[semver.major]

Examples are:

  • Dutch core Patient: http://fhir.nl/fhir/StructureDefinition/nl-core-patient

  • HCIM for Dispense: http://nictiz.nl/fhir/StructureDefinition/zib-Dispense-1.0

File naming and storage

All profiles and extensions are stored in a Git repository that is linked to the Simplifier project, so changes in the Master branch are automatically updated in the Simplifier project. The example below shows the folder structure, that is organized by resource type / HCIM. The naming of the files shows the content you can expect:

  • The files starting with 'conceptmap' contain ConceptMaps
  • The extension-allergyintolerance-duration contains an extension for duration on the AllergyIntolerance resource from the HL7 core specification
  • The zib-AllergyIntolerance is the actual profile on AllergyIntolerance based on the HCIM AllergyIntolerance
  • The zib-AllergyIntolerance-example contains an example of a resource that conforms to this profile
  • The zib-AllergyIntolerance-Reaction-Certainty is an extension on this profile as defined by Nictiz

Implementation guide

The implementation guide for the MedMij project was built in a WiKi page.

Stichting Koppeltaal

Stichting Koppeltaal is a Dutch organization that enables FHIR-based exchange of data between e-health applications in the care sector.

Reuse of national profiles

Koppeltaal reuses the Dutch national profiles as far as these are available. The example below shows the KoppeltaalPatient profile, which is derived from the nl-core-patient profile.

url1..1uriFixed Value
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ0..1uri
valueΣ0..1string
periodΣ0..1Period
assignerΣ0..1Reference(Organization)
displayΣ0..1string
url1..1uriFixed Value
valueCodeableConcept0..1CodeableConcept
url1..1uriFixed Value
valuePeriod0..1Period
url1..1uriFixed Value
value[x]0..0
url1..1uriFixed Value
systemΣ1..1uri
versionΣ0..1string
codeΣ1..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
person-age0..1ExtensionBinding
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ1..1uriFixed Value
valueΣ1..1string
periodΣ0..1Period
assignerΣ0..1Reference(http://hl7.org/fhir/StructureDefinition/KoppeltaalOrganization)
activeΣ ?!0..1boolean
nameΣ0..*nl-core-humanname
systemΣ1..1codeBinding
valueΣ1..1string
useΣ ?!0..1codeBinding
rankΣ0..1positiveInt
periodΣ0..1Period
genderΣ0..1codeBinding
birthDateΣ0..1date
deceasedBooleanboolean
deceasedDateTimedateTime
addressΣ0..*nl-core-address
maritalStatus0..1CodeableConceptBinding
multipleBirthBooleanboolean
multipleBirthIntegerinteger
photo0..*Attachment
relationship0..*CodeableConceptBinding
role0..*CodeableConceptBinding
name0..*nl-core-humanname
systemΣ1..1codeBinding
valueΣ1..1string
useΣ ?!0..1codeBinding
rankΣ0..1positiveInt
periodΣ0..1Period
address0..*nl-core-address
gender0..1codeBinding
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ0..1uri
valueΣ0..1string
periodΣ0..1Period
assignerΣ0..1Reference(Organization)
displayΣ0..1string
period0..1Period
url1..1uriFixed Value
valueCoding0..1CodingBinding
url1..1uriFixed Value
valueCoding0..1CodingBinding
url1..1uriFixed Value
value[x]0..0
comment0..*Extension(string)
language1..1CodeableConceptBinding
preferred0..1boolean
practitionerRole0..1Extension(Reference(nl-core-practitionerrole))
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ0..1uri
valueΣ0..1string
periodΣ0..1Period
assignerΣ0..1Reference(Organization)
displayΣ0..1string
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ0..1uri
valueΣ0..1string
periodΣ0..1Period
assignerΣ0..1Reference(Organization)
displayΣ0..1string
referenceΣ0..1string
reference-identifier-resource-type1..1Extension
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ0..1uri
valueΣ0..1string
periodΣ0..1Period
assignerΣ0..1Reference(Organization)
displayΣ0..1string
typeΣ1..1codeBinding

HelseVest

HelseVest is a Norwegian health authority, responsible for the western region of Norway. The KULE HelseVest Prescription project aims to provide integrations for medication prescription.

Definition field

Below is an example of the details tab of the MedicationStatement resource. The definition field shows the the description of the resource that was copied from the description field and is directly visible at the top of the Details tab.

MedicationStatement
Definition

A prescription as defined by KULE Helse Vest Norwegian project, based on the national standard M1 eResept standard.

Control..*
InvariantsDefined on this element
kuleprescribing-5: Reason not taken must be filled if wasNotTaken is true (xpath: f:wasNotTaken/@value=false() or exists(f:wasNotTaken))
MedicationStatement.extension
Control..*
Slicing This element introduces a set of slices. The slicing rules are:
  • unordered
  • Open
  • discriminators: url
MedicationStatement.extension(authoredOn)
Definition

Dato for forskrivning.

Control1..1
TypeExtension(MP9 Authored On)
Must Supporttrue
Alternate NamesauthoredOn, Forskrivningsdato
MedicationStatement.extension(drugUseType)
Control..1
Binding Angir bruk av et legemiddel, f.eks. om det benyttes fast eller gis ved behov (OID=9101).
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-legemiddelbruk
TypeExtension(Drug use type)
Must Supporttrue
Alternate NamesBruk
MedicationStatement.identifier
Control..*
Slicing This element introduces a set of slices. The slicing rules are:
  • unordered
  • Open
  • discriminators: system
MedicationStatement.identifier(prescriptionInstance)
Definition

Several MedicationStatements will be issued in case of a single prescription requiring multiple medications or different periods and this identifier allows you to reconcile them into a single prescription.

Control1..1
Must Supporttrue
MedicationStatement.identifier.use
Control..*
Fixed Valueofficial
MedicationStatement.identifier.system
Control..*
Fixed Valueurn:oid:2.16.578.1.34.5.5
MedicationStatement.identifier(LIB)
Control..1
MedicationStatement.identifier.use
Control..*
Fixed Valuesecondary
MedicationStatement.identifier.system
Control..*
Fixed Valueurn:oid:OID-FOR-LIBS-HERE.
MedicationStatement.identifier(eResept)
Control..1
Alternate NamesMsgId
MedicationStatement.identifier.use
Control..*
Fixed Valuesecondary
MedicationStatement.identifier.system
Control..*
Fixed Valueurn:oid:OID-FOR-ERESEPT-HERE.
MedicationStatement.informationSource
Control..*
Type Choice of: Reference(Patient), Reference(PractitionerNorway), Reference(RelatedPerson)
Must Supporttrue
Alternate NamesHelseperson, Organisasjon
MedicationStatement.status
Control..*
Must Supporttrue
MedicationStatement.status.modifierExtension
Control..*
Slicing This element introduces a set of slices. The slicing rules are:
  • unordered
  • Open
  • discriminators: url
MedicationStatement.status.modifierExtension(prescriptionStatus)
Control..1
TypeExtension(Prescription status)
Must Supporttrue
Requirements

The need to set the status on a MedicationStatement to 'paused' when the resource is used as a prescription of medication.

Comments

Receiving systems should prioritise prescririptionStatus over status if it's present.

When the prescrtiptionStatus is set to 'on-hold', MedicationStatement.status should be set to 'intended'.

Meaning if MissingCode needed is available in MedicationStatement.status and the extended code was not required.
MedicationStatement.status.modifierExtension.valueCode
Control..*
MedicationStatement.wasNotTaken
Control..*
Must Supporttrue
MedicationStatement.reasonNotTaken
Control..*
Must Supporttrue
MedicationStatement.reasonForUse[x]
Control..*
Binding Angir bruksområde for legemiddel. Det overføres til M1 og blir med på utskrift på apoteketikett. Brukes i FEST og Eresept (OID=7488).
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-bruksomrade-til-etikett
[x] NoteSee Choice of Data Types for further information about how to use [x]
Must Supporttrue
Alternate NamesBruksomrade
MedicationStatement.effectivePeriod
Control..*
TypePeriod
Must Supporttrue
MedicationStatement.effectivePeriod.start
Definition

Time when the dosage starts.

Control1..*
Requirements

Cardinality is at 1..1, overring M1 cardinality, per Chapter 4 rules in https://ehelse.no/Documents/E-resept/Dokumentarkiv-Meldingsdefinisjoner/Brukskonvensjoner%20for%20avansert%20strukturert%20dosering%20versjon%201.1%20per%20130913.pdf.

Alternate NamesStarttidspunkt
MedicationStatement.effectivePeriod.end
Definition

Time when the dosage ends.

Control..*
Alternate NamesSluttidspunkt
MedicationStatement.medicationReference
Control..*
TypeReference(KULE Medication)
Must Supporttrue
MedicationStatement.dosage
Control..*
InvariantsDefined on this element
kuleprescribing-1: Dosage must include a freetext if no structured dosage is used (xpath: not(exists(f:text)) or not(exists(f:timing)))
kuleprescribing-3: Either detailed timing information or coded dosage information can be specified, but not both (xpath: not(exists(timing) and exists(extension[@url='http://hl7.no/fhir/StructureDefinition/kule-short-dosage'])))
kuleprescribing-4: daysNotAdministeredAmount must always be used in combination with daysAdministeredAmount (xpath: not(exists(extension[@url='http://hl7.no/fhir/StructureDefinition/kule-days-not-administered-amount'])) or exists(extension[@url='http://hl7.no/fhir/StructureDefinition/kule-days-administered-amount']))
MedicationStatement.dosage.extension
Control..*
Slicing This element introduces a set of slices. The slicing rules are:
  • unordered
  • Open
  • discriminators: url
MedicationStatement.dosage.extension(calculationBasis)
Definition

To specify what forms the basis for calculating the dose (weight, age, body surface, other).

Control1..1
TypeExtension(Dose calculation basis)
Must Supporttrue
Alternate NamescalculationBasis, DoseresEtter
MedicationStatement.dosage.extension.valueCode
Control..*
MedicationStatement.dosage.extension(daysAdministeredAmount)
Definition

Number of days total a drug is to be used within the specified period.

Control..1
TypeExtension(Days administered amount)
Must Supporttrue
Alternate NamesdaysAdministeredAmount, DagerPa
MedicationStatement.dosage.extension(daysNotAdministeredAmount)
Definition

Number of days a drug is NOT to be used. This element is always in combination with daysAdministeredAmount.

Control..1
TypeExtension(Days not administered amount)
Must Supporttrue
Alternate NamesdaysNotAdministeredAmount, DagerAv
MedicationStatement.dosage.extension(shortDosage)
Definition

Ved rekvirering skal feltet "kortdose" følge med i M1 dersom DSSN feltet ikke er endret etter valg av kortdose som kommer fra FEST.

Kortdose skal ikke sendes i M1 når bruker ikke har valgt kortdose eller har redigert i feltet for DSSN.

Apotek skal kunne bruke kortdose for effektivt å kunne finne fram til ønsket avansert dosering basert på kortdose.

Control..1
Binding Dosage timing codes used by LIB data from FM (Forskrivningsmodulen/Prescription Module) and Kjernejournal systems in the Helse Vest Norway.
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-coded-dosage-timing
TypeExtension(Short dosage)
Must Supporttrue
Alternate NamesshortDosage, Kortdose
MedicationStatement.dosage.text
Control..*
Must Supporttrue
Alternate NamesDosVeiledEnkel
MedicationStatement.dosage.timing
Control..*
MedicationStatement.dosage.timing.extension
Control..*
Slicing This element introduces a set of slices. The slicing rules are:
  • unordered
  • Open
  • discriminators: url
MedicationStatement.dosage.timing.extension(administerAtSpecificTime)
Definition

Medication must be given/taken at exact times.

Control1..1
TypeExtension(Exact timing)
Must Supporttrue
Alternate NamesadministerAtSpecificTime, GisEksakt
MedicationStatement.dosage.timing.extension(extension)
Definition

Number of units of time that must pass between each time the drug is given/taken.

Control..*
Binding Dette kodeverket inneholder benevning for tidsenheter. Skal benyttes for datatypen PQ når enhet skal være tidsenhet (OID=9088).
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-benevning-tidsenhet
TypeExtension(Timing interval)
Must Supporttrue
Alternate NamesadministrationInterval, Intervall, Gjentagelsesintervall
MedicationStatement.dosage.timing.repeat
Control..*
InvariantsDefined on this element
kuleprescribing-2: Either specificTime or timePeriod can be specified, but not both (xpath: not(exists(f:extension[@url='http://hl7.no/fhir/StructureDefinition/kule-time-of-day']) and exists(f:extension[@url='http://hl7.no/fhir/StructureDefinition/kule-timeperiod'])))
MedicationStatement.dosage.timing.repeat.extension
Control..*
Slicing This element introduces a set of slices. The slicing rules are:
  • unordered
  • Open
  • discriminators: url
MedicationStatement.dosage.timing.repeat.extension(specificTime)
Definition

Exact time of day medication must be taken at (e.g. 09:00, 12:30, 15:00).

Control..1
TypeExtension(Time of day)
Must Supporttrue
Alternate NamesspecificTime, Klokkeslett
MedicationStatement.dosage.timing.repeat.extension(timePeriod)
Definition

Time period of the day the drug should be taken at (eg. morning, noon, afternoon, etc).

Control..1
TypeExtension(Time period of the day)
Must Supporttrue
Alternate NamestimePeriod, Tidsomrade
Comments

Timing.repeat.when is not used as the binding is of strength "required" and is semantically incompatible with OID 8325 from volven.no

MedicationStatement.dosage.timing.repeat.extension(dayOfWeek)
Control..*
Binding Days of the week
The codes SHALL be taken from http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.9.5.4--2015-04-01T00:00:00
TypeExtension(MP9 Day Of Week)
Must Supporttrue
Alternate NameswhichWeekdays, FasteUkedager
MedicationStatement.dosage.asNeeded[x]
Control..0
[x] NoteSee Choice of Data Types for further information about how to use [x]
Requirements

Not used to align with DIPS - see drugUseType extension instead.

MedicationStatement.dosage.site[x]
Control..*
[x] NoteSee Choice of Data Types for further information about how to use [x]
Must Supporttrue
MedicationStatement.dosage.route
Control..*
Must Supporttrue
Alternate NamesAdministrasjonsvei
MedicationStatement.dosage.route.coding
Control..*
Binding Administrasjonsvei (OID=7477).
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-administrasjonsvei
MedicationStatement.dosage.route.text
Control..0
MedicationStatement.dosage.quantityQuantity(SimpleQuantity)
Control..*
Binding Enhet som skal inngå i doseringstekst som sendes i M1 og inngår på apotek-etiketten. Kodeverk til bruk i M30 fra versjon 2.4, og i M1 (OID=7480).
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-enhet-for-dosering
TypeQuantity(SimpleQuantity)
Must Supporttrue
MedicationStatement.dosage.rate[x]
Control..*
[x] NoteSee Choice of Data Types for further information about how to use [x]
Must Supporttrue
Slicing This element introduces a set of slices. The slicing rules are:
  • unordered
  • Open
  • discriminators: @type
MedicationStatement.dosage.rate[x](ratio)
Control..*
TypeRatio
[x] NoteSee Choice of Data Types for further information about how to use [x]
Must Supporttrue
MedicationStatement.dosage.rate[x].numerator
Control..*
Binding Dette kodeverket inneholder benevning for legemidlers styrke Skal benyttes for datatypen PQ når enhet skal være legemidlers styrke. Kodeverket oppdateres kun for verdier som inngår i nyeste versjon av FEST (OID=9090).
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-maleenhet-for-legemidlers-styrke
Alternate NamesVolum
MedicationStatement.dosage.rate[x].denominator
Control..*
Binding Dette kodeverket inneholder benevning for tidsenheter. Skal benyttes for datatypen PQ når enhet skal være tidsenhet (OID=9088).
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-benevning-tidsenhet
Alternate NamesTidsenhet
MedicationStatement.dosage.rate[x](range)
Control..*
TypeRange
[x] NoteSee Choice of Data Types for further information about how to use [x]
Must Supporttrue
MedicationStatement.dosage.rate[x].low(SimpleQuantity)
Control..*
Binding Dette kodeverket inneholder benevning for legemidlers styrke Skal benyttes for datatypen PQ når enhet skal være legemidlers styrke. Kodeverket oppdateres kun for verdier som inngår i nyeste versjon av FEST (OID=9090).
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-maleenhet-for-legemidlers-styrke
Alternate NamesVolum
MedicationStatement.dosage.rate[x].high(SimpleQuantity)
Control..*
Binding Dette kodeverket inneholder benevning for legemidlers styrke Skal benyttes for datatypen PQ når enhet skal være legemidlers styrke. Kodeverket oppdateres kun for verdier som inngår i nyeste versjon av FEST (OID=9090).
The codes SHALL be taken from http://hl7.no/fhir/ValueSet/kule-maleenhet-for-legemidlers-styrke
Alternate NamesVolum

Implementation guide

The implementation guide for the KULE HelseVest Prescription project was built using our IG-editor in Simplifier.


Exercise


In this exercise you will specify the profiles and extensions that are needed to implement the use case given below. Start by reading the case description.

Here below are a couple of links that you may find useful during this exercise:

    Case description
    A Dutch hospital wants to exchange data from patients and donors around lung transplantations. This data includes:
  • Measurements from both the patient and the donor (e.g. weight, height, total lung capacity, lab results). An additional mandatory field is required to specify if a measurement belongs to the patient or the donor.
  • Medication prescription for the patient. The timing schedule for giving medication to the patient needs to include additional codes to define that medication should be scheduled before, during or after transplantation.

Steps to follow

1. Build profiles

  1. Visit Simplifier.net and search if there are any profiles that you can reuse. If there are any, save them in your project folder and use them as your base profiles.
  2. Build one profile for the exchange of measurement data and one profile for the exchange of medication prescriptions.
  3. Save your profiles. Name your files properly and don't forget to complete the narrative.

2. Build extensions

  1. Visit Simplifier.net and search if there are any extensions that you can reuse. If there are any, save them in your project folder.
  2. Build additional extensions that you may need to meet all requirements. Name your files and extensions properly and don't forget to complete the description and purpose of the extensions.
  3. Add the extensions to your profiles.
  4. Constrain the extensions (e.g. change the cardinality, isModifier flags and ValueSet bindings) at the right level.
  5. Don't forget to include a description at the profile level.

3. Publish your work

  1. Add a new project on Simplifier and upload your resources.
  2. Don't forget to add an introduction to the project, so others know what it is about.
  3. Building an implementation guide is outside the scope of this module, but if you want you can try it out in the 'Guide' tab of your project. If you want to learn more, follow the module 'Validating and publishing your work' (not available yet) or contact one of our Profilers.

Feedback


We are always looking for ways to improve our products. The Profiling Academy was built using our own IG-editor in Simplifier. If you have any feedback on this module or on our Profiling Academy in general, please leave a comment in the Issue Tracker of the project.


Get in touch


Start profiling

Most modules end with an exercise. Use Forge to start profiling yourself. Just contact us at simplifier@fire.ly if you need any help.

Learn more

Follow one of our predefined or tailor-made courses. We will make sure you know FHIR inside-out.

Need help or advice?

Let us assist you with your FHIR use case. Visit our company website to know more about our services or get into contact with Rien Wertheim right away.