What about dosage

[pablocorilus]

Dosage doesn't link to a resource, what are the fields that you see on this. Is https://hl7.org/fhir/R4B/dosage.html#Dosage the reference of what the profile is going to use? For instance the timing is much broader than what is now supported in kmehr. @costateixeira @bdc-ehealth

[bdc-ehealth]

@pablocorilus

For now, there haven't been created any limitations on https://hl7.org/fhir/R4/dosage.html#Dosage (we use R4). I know there is a tendency ( I think of the efforts by Dirk Broeckx) to keep the dosage simple, but I would like to leave this open to the community.

[costateixeira]

A long time ago we identified the cases for dosage. I think we had them all covered (some of them required some clarification but they were supported). If this is correct, I would leave the dosage open - i.e. as it is the base spec, leaving for implementers to use it - I expect no extensions needed.

[JensPenny]

Just to add to this: I recently modelled something in our base API's based on the Dosage structure from FHIR. Dosage is not a resource, but it's a structure. We just use it as an object in our API's and attach it to the resource that uses it. For now: that means we just take the dosage object, marshal it, and persist it like that. The same happens for timing: timing is not a resource (you won't persist a discrete timing on its own), but it is a structure. For now we also just marshal and save this.

For the timing: I think most transformations from KMEHR to Timing might be possible, but you can't go from Timing to KMEHR, if that makes sense. There might be some issues with dayperiod, but for periodicity this should work.

[smals-jy]

Hello,

I'm Jacques. I made my own library on my free time to help me deal with Dosage object : fhir-dosage-utils .
It seems to work quite nicely, with its generic approach it was built on. Feel free to consult the examples I collected.

To answer @JensPenny questions about periodicity and dayperiod points, I had to do that while analyzing FHIR impacts in the VIDIS project (since I would like to have like everyone complete test cases) :

CD-DAYPERIOD

In FHIR, it is going to be mapped under when and offset fields in the Timing object which express the Dosage.

KMEHR code	when	offset	Notes
afterbreakfast	PCM
afterdinner	PCV
afterlunch	PCD
beforebreakfast	ACM
beforedinner	ACV
beforelunch	ACD
betweenbreakfastandlunch	CM
betweenlunchanddinner	CD
betweendinnerandsleep	CV
duringbreakfast	CM
duringdinner	CV
duringlunch	CD
morning	MORN
thehourofsleep	HS
aftermeal	PC
betweenmeals	C
afternoon	AFT
evening	EVE
night	NIGHT

CD-PERIODICITY

In FHIR, it is going to be mapped under frequency / period and periodUnit fields in the Timing object which express the Dosage.
periodUnit will follow the UnitsOfTime Valueset.

KMEHR code	Frequency	Period	PeriodUnit	Notes
D	1	1	d
DA	1	8	d
DD	1	3	d
DE	1	11	d
DN	1	9	d
DQ	1	5	d
DT	1	2	d
DV	1	4	d
DW	1	12	d
DX	1	10	d
DZ	1	6	d
J	1	1	a
JD	1	3	a
JH2	1	0.5	a
JQ	1	5	a
JT	1	2	a
JV	1	4	a
JZ	1	6	a
M	1	1	mo
MA	1	8	mo
MC	1	18	mo
MD	1	3	mo
ME	1	11	mo
MN	1	9	mo
MQ	1	5	mo
MS	1	7	mo
MT	1	2	mo
MV	1	4	mo
MX	1	10	mo
MZ2	1	6	mo
O1	1	2	d
U	1	1	h
UA	1	8	h
UD	1	3	h
UE	1	11	h
UH	1	0.5	h
UN	1	9	h
UQ	1	5	h
US	1	7	h
UT	1	2	h
UV	1	4	h
UW	1	12	h
UX	1	10	h
UZ	1	6	h
W	1	1	wk
WA	1	8	wk
WD	1	3	wk
WE	1	11	wk
WN	1	9	wk
WP	1	24	wk
WQ	1	5	wk
WS	1	7	wk
WT	1	2	wk
WV	1	4	wk
WW	1	12	wk
WX	1	10	wk
WZ	1	6	wk

For the "ondemand" code, for me it is a asNeededBoolean set to true.

[smals-jy]

@JensPenny I don't know if you or someone else explored the transformation from KMEHR CD-ADMINISTRATIONUNIT to UCUM ? Doesn't seem the topic was already raised by someone unless I'm wrong ?

If we follow the FHIR specs, unit shall be a UCUM code but it could be open to something else (e.g. a ValueSet that just "copy" the KMEHR codes like BeCdHcParty did). Each choice has it advantages and drawbacks :

• Maintenance of codes : addition / deprecations / ....
• Lack of UCUM translations in Dutch / French and German as stated on UCUM

[JensPenny]

I'd prefer that we don't give the option to add another valueset to the fhir specs, especially for the units of measurements. The mapping will have to happen somewhere, and most of the administrationunits in kmehr are dimensionless non-units. For example: tablet could map to {tablet} or {tbl}. The reason why you would still have to translate them, is that you need them to be in ucum to do any meaningful calculations with them. If you have a dosage of 1000 ml, and you want to calculate how long this will last with a flow of 100 ml/h, you'll still need to translate the kmehr unit to something you can calculate stuff with. Using ucum makes this process way easier.

The UCUM internalization page mostly looks to be about other (localized) non-si units, but translating the ucum units is indeed not provided out of the box. As far as I know there are 2 approaches to this issue:

1. You provide translations for the base terms. For all ucum, you split them into terms and translate these, while using 'per' for division.
2. You provide a base set of commonly used values and translate these. The rest is english. You can find an example in pdf or docx in this repository

[smals-jy]

I share your opinion : conversions and calculations are quite important to take into account, like showing a proper posology to patients and professionals. I saw that UK recommends this : Use UCUM where available, otherwise SNOMED CT .

So here is my proposal for the current units of measurements used in Belgium (which could be improved with everyone feedbacks) :

KMEHR code	UCUM code	SNOMED CT	Notes
00001	5.mL
00002		732978007	Ampule
00003		413568008	Application - unit of product usage
00004		428641000	Capsule
00005		336624003	High compression (extensible) bandage
00006		408102007	Dose
00007	[drp]
00008		419672006	Bottle
00009		732996003	Implant
00010		129331004	Perfusion
00011		422237004	Inhalation
00012		257867005	Insertion
00013		732989000	Chewing gum
00014		336624003	High compression (extensible) bandage
00015		337087003	Enema syringe
00016	mL
00017		73153001	Ovum
00018		34258004	"Pearl" doesn't exist like that in SNOMED. So "Spherical shape" is the closest match
00019		429587008	Lozenge
00020		419702001	Patch
00021		732988008	Cartridge
00022		733006000	Pen
00023		415215001	Puff
00024		429671000	Sponge
00025		733006000	Pen
00026		430293001	Suppository
00027		418530008	Tube
00028		116251003	Wick
00029		428672001	Bag
00030		426148002	Sachet
cm	cm
dropsperminute	[drp]/min		Could be split into two units in fact [drp] for the "drops" part min for the "perminute" part
gm	g
internationalunits	[IU]
mck/h	ug/h		Could be split into two units in fact ug for the "mck" part h for the "h" part
mck/kg/minute	ug/kg/min		Could be split into three units in fact ug for the "mck" part kg for the "kg" part min for the "minute" part
measure		767524001	Unit of measure
mg/h	mg/h		Could be split into two units in fact mg for the "mg" part h for the "h" part
ml/h	ml/h		Could be split into two units in fact ml for the "ml" part h for the "h" part
tbl	{TBL}
tsp	[tsp_m]
unt/h	[IU]/h		Could be split into two units in fact [IU] for the "unt" part h for the "/h" part
mg	mg
mg/ml	mg/mL		Could be split into two units in fact mg for the "mg" part mL for the "ml" part
meq	meq
miu	m[IU]
iu	[IU]
mmol	mmol
effervescent-tablet	{TBL}		UCUM doesn't have the "effervescent" part
micrograms	ug
bandage		63995005	Bandage
piece	[IU]		As it is quite arbitrary, let's reflect it as is
box		419694003	Spray
liter	L
syringe		733020007	Syringe
ampoule		732978007	Ampule
bottle		419672006	Bottle
syringe-ampoule		465315001	Syringe/ampule

As you can see, some units can't be present in UCUM and will be in SNOMED CT. My biggest concern is the interoperability between softwares : I would prefer having the UK guidelines enforced here in Belgium instead of handling custom curly braces codes unknown to other software vendors that will cause at some point issues.